Hi Frank,
Frank Budinsky wrote:
Hi Ole,
Your point about the benefits of separating properties into two lists,
references and attributes, is well taken.
Super :-)
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.
Sure - Absolutely. I was hoping for something like EAttribute or
EReference, that we can draw on a Class Diagram. I like these
because they have clear mappings to XSD already, so there's there's
minimal chance of confusion when talking about the mapping.
Right now I have two choices for the equivalent of an EReference in
SDO. I can call it a reference or I can call it a member/property
that is a SDO DataObject type.
So if SDO had an EReference ("SReference") equivalent class, we could
just say SReference.
I love EMF because it's so elegant in this sense. It's really easy
to know precisely what something is.
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.
Indeed.
So I think this is saying that SDO further restricts
the typing that EMF allows, or at least the mapping
to XML Schema instances (I need to read some more SDO 2 stuff).
The part I'm hanging on is whether
when loading the SDO type system
we "loose" some information so
we have to recalculate it at runtime.
And if we have to recalculate it, do we loose
efficiency?
When we load an ecore instance we can examine
the EClass and know what members are
EAttributes and what members are EReferences,
the proceeds to process these lists separately.
If I examine and SDO Type reflectively
I think I'd have to first iterate through
all the member types and separate the two
into the equivalent of EReferences and EAttributes.
(SOAP BOX: Personally I feel like this is a little bit of a typing
black hole, but that could be it's just because I'm EMF biased.
I think I just like knowing that an EAttribute is an EAttribute
and an EReference is an EReference).
Then I can go ahead an process the DataGraph efficiently.
So I'm really wondering whether the processing that separates
the simple from the complex types is best handled during
type system loading.
Maybe the end result is the same.
It sounds like there are two possible end games.
One is that SDO types stay the way they are
and are augmented by utilities that separate
simple from complex types in the type system,
so that DataGraphs can be efficiently processed.
The other is to build in the equivalent
of XSD Simple and Complex Types into the SDO Typing system.
I think the criteria for which one is best are
Type system efficiency and developer preference.
It could be neat to have some sort of scoring
system for it on OSOA.
Although this of coarse depends on whether I'm making any sense. :-)
Cheers,
- Ole
SNIP
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
