RE: [higgins-dev] IdAS: Model as Metadata

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Since it was originally proposed I've been trying to get comfortable with
making metadata simple and single valued. I've been trying to apply the "the
simplest thing that could actually work" principle as justification. 

To make the change we need to reimplement "source" metadata as a single
string (vs. a complex metadata object consisting of two fields: ContextId
and SubjectId), eliminate TimeSpan metadata, etc. For each kind of complex
metadata that we'd originally envisioned, I've been able to imagine a
workaround. However, I'm somewhat concerned that we're limiting
expressiveness too much (i.e. we're not making the API future-proof--an IdAS
consumer will have a strong need for complex metadata and not be able to
have it). 

As a consequence (and for the reasons Tom and Jim outline below) I'm
definitely open to revisiting the "simple metadata" approach. 

-Paul

PS: I'd also like to know if, other that API simplification, there were any
compelling Context Provider implementation-related advantages to the "simple
metadata" approach. Was that part of the motivation for it?

Tom wrote:
> 
> When we last refactored metadata, I saw the making of metadata as simple
> and single valued as a concession anyway.  It seemed acceptable though to
> eliminate some complexity.  Nevertheless, I'm still on the fence regarding
> this particular proposal (assuming "thinking out loud" constitutes a
> proposal).  I can see advantages and disadvantages.  In this case,
> however, the disadvantages I believe apply to both the consumer and the
> provider.  The two biggest ones that come to mind are:
> 
> 1. Both the consumer and the provider have to special case the metadata
> handling for dealing with the model.
> 2. No special APIs to make dealing with model specific concepts and
> semantics.
> 
> We did a lot of gymnastics to avoid making updates ugly for the consumer
> and I think this change would look similar.  One "just thinking out loud"
> solution could be to wrap our model APIs around metadata.  Of course, I
> don't know if the use of metadata would then be justified if all we're
> trying to do with the proposed change is remove seemingly duplicate code.
> Maybe we need to enumerate all the advantages too in case I'm missing
> something.
> 
> Tom
> 
> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 6/1/2007 6:21 PM >>>
> Thinking out loud here -- I mentioned this on the last dev call.
> 
> I believe IdAS consumers need the ability to make updates to aspects of a
> context's model (i.e. add a new subject type, or add a new attribute
> type).
> 
> So to do that, we would naturally start introducing a bunch of add*
> methods to the model interfaces like we did for context and its sub-
> elements.  This starts feeling like a duplication of similar methods, so I
> started wondering if there's a simpler way.
> 
> What if we decided to remove the interfaces in
> org.eclipse.higgins.idas.api.model, and instead define some metadata types
> that can be used to represent model elements?  If we could make this work,
> I would prefer it for a few reasons:
> 1) It reduces the number of interfaces we have,
> 2) I think the model of an element is a good example of metadata (it truly
> is data that describes the data),
> 3) It makes us start using metadata -- helping to prove out the design.
> 
> The problems I see with doing it:
> P1) Metadata is too simple: Today, metadata is always single-valued and a
> simple type. So if we wanted an IContext to have metadata for the digital
> subject models it supports, we would have to basically have one huge
> string value.  This makes updates very unfriendly.  We would want to allow
> metadata to be multi-valued such that we could have a metadata element
> with a type of "http://...#DigitalSubjectModel"; and multiple values where
> each value represents a supported digital subject model.  Furthermore, it
> would be good if each digital subject model were complex such that a
> specific sub-element could be updated (i.e. so one could add to the list
> of attributes valid for that subject).  I know... we just got done making
> metadata simple and single-valued, and now I'm proposing to change it
> back.
> P2) Lack of functional methods in metadata: like
> IAttributeSimpleValueModel::toLexicalForm(Object).  I'm not sure if this
> is a real problem or if these methods were just for convenience.
> 
> As much as I hate re-visiting P1 so soon after refactoring metadata, I
> wonder if we were too hasty is assuming metadata will always be simple and
> single valued -- and if so, now would be a good time to change since not
> to many (if any) people are using it yet.
> 
> Duane is gone for a couple weeks, but in talking to him yesterday about
> this, he agreed in switching from the I*Model interfaces to using
> metadata.
> 
> Let me know what you all think.
> 
> Jim
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev