Hi Frank,
I think I may have figured out what I'm talking about :-)
Suppose I'm loading Ecore from its XMI Document.
So I'm loading several XMI
elements that are either
of the type EDataType or EClassifier.
So this could be viewed
as iterating
through the document's elements.
I have to do this iteration in
order to load the Ecore Type System.
So I have an opportunity here
to check each element I'm
loading and add it to
either an EDataType list
or an EClassifier list.
If I choose skip creating the lists,
and later I need a list of
all the EDataTypes, then I
have to iterate through
something like
EcorePackage.eContents()
and sift out the EDataType instances.
So now I'm doing additional work
that could have been avoided
had I just created the lists when
the model was loaded.
The reason this crossed my mind,
is because I need a list of all the
EDataType instances in Ecore.
It looks as if I have to filter them
out from eContents().
Do you know by chance whether SDO 2
has such a list.
The reason I need it is because I need
to write the equivalent of the SDO base
type system to ApacheDS. So if such
a list were just available through the API
it would make life a little simpler :-)
So to summarize for me it seems like opportunities
to create generic lists like
eDataTypes(): EList<EDataType>
or
eClassifiers() : EList<EClass>
makes the API more friendly and efficient to work with.
If SDO had something like ClassType, SimpleType, and ComplexType
the generic lists like:
EList<SDOSimpleType>
EList<SDOComplexType>
could be created during Type system loading.
because SDO would now have the semantics for
generically specifying a list of simple types and
complex types.
Cheers,
- Ole
Frank Budinsky wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
