Hi Ole, Your point about the benefits of separating properties into two lists, references and attributes, is well taken.
The SDO spec does say this in section 3.6: A Property whose Type is for DataObjects is sometimes called a reference; otherwise it is called an attribute. So, in documentation anyway, you can call DataObject typed properties "references", if you like. Calling DataType properties "attributes" is a little ambiguous, however, because it's overloaded with the concept of an XML attribute. Notice that XML/XSD split between element and attribute properties is different from the split between reference and attribute properties (as in EMF). An EAttribute can map to an attribute or element in XML. Same for EReference. Frank Ole Ersoy <[EMAIL PROTECTED]> wrote on 05/17/2007 10:17:42 AM: > Hi Frank, > > Frank Budinsky wrote: > > Ole, > > > > Type.isDataType() is the way to distinguish between complex and simple > > types. > > Thanks for the tip. > > I have several other comments below. > I'll just preface these by saying that > this is just my initial impression / hunch. > I figured I'd point these out while they are fresh > in case they end up being useful, and might > make it onto an SDO FAQ or something. > Since EMF has been around for some time, I imagine > their could be other EMFers with a similar questions/concerns. > > OK - Here goes: > > Ideally for me at least I would love it > if SDO had "EReferences", "EDataTypes", and "EAttributes". > > One benefit is that when documenting > I can just say "EReference". > > Currently I have to say something like "When Type.isDataType() returns > true". Minor point, but when writing a lot of documentation and > comparing type systems, it adds up. > (SIDE NOTE: I got to the bottom and noticed you pointed out the > DataObject Types and DataTypes labeling - Thanks). > > Also, (As I'm sure you know given that you co-authored the very > excellent Eclipse Modeling Framework Book :-) ) > with EMF EReferences are ready to go on their own list, > and the same goes for EAttributes. > > Now it seems > like the first natural step when processing a DataGraph > is to always check the Type of a Type... > > This is just my initial impression though, but > it does seem like this whole step could be skipped if > something similar to EReferences and EAttributes > were used. > > I think Tuscany may already have a utility for this, > but the EMF way still seems cleaner, faster, and better > organized to me. I a utility handled the separation > in Tuscany in order to avoid the isDataType check > when processing the DataGraph separating the DataTypes > from the DataObjectTypes does that lead to additional overhead? > Seems like EMFs approach is more efficient. > > Looking at the scenario backwards with the "Fastest and simplest" > API in mind it seems like XSD and EMF have it nailed. I guess the > only way I can prove it is by showing a use case where the additional > semantics of XSD and EMF lead to less calls. If I end up "Unproving" > it I think I'll be more at ease with the isDataType() call :-) > > > > > Simple types map to a type with isDataType=true, complex types map to > > types with isDataType=false. They are often referred to as "Data types" > > and "DataObject types", respectively. > > Ah - Thanks - That should definitely help with the documentation part. > I'll make sure I put these notes in the concept section of the > LDAP DAS Design Guide. I think I still like EReference and EAttribute > better, since I can put these in a class diagram, but it's a fairly > minor consideration. > > Thanks, > - Ole > > SNIP > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
