You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ole Ersoy <ol...@gmail.com> on 2007/05/17 05:34:22 UTC
SDO Type System Comment
Hi,
This really belongs in something like a
osoa.org sdo design spec discussion, but
it's not up yet, so I hope it's ok to post here.
As I'm fine tuning the LDAP DAS Design Guide
I find myself saying this alot:
"an SDO Type that is the semantic equivalent
of an XSD Complex Type"
If I were discussing EMF and XSD
I would just say "EClass".
Just seems like SDO would map a lot cleaner
to other typing systems if it included
the semantics of Complex and Simple types.
Seems like it makes the API more efficient too,
since it becomes natural to keep simple and
complex types in separate lists. I'm guessing
that doing this upfront within the core SDO API
would make most products derived from the SDO API
more efficient since developers would become
accustomed to dealing with the distinction.
Anyways - just my two cents. I figured I'd throw
it out there for general awareness
in case others were interested.
Cheers,
- Ole
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Type System Comment
Posted by Ole Ersoy <ol...@gmail.com>.
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 <ol...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Type System Comment
Posted by Ole Ersoy <ol...@gmail.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Type System Comment
Posted by Frank Budinsky <fr...@ca.ibm.com>.
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 <ol...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Type System Comment
Posted by Ole Ersoy <ol...@gmail.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO Type System Comment
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Ole,
Type.isDataType() is the way to distinguish between complex and simple
types.
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.
Frank.
Ole Ersoy <ol...@gmail.com> wrote on 05/16/2007 11:34:22 PM:
> Hi,
>
> This really belongs in something like a
> osoa.org sdo design spec discussion, but
> it's not up yet, so I hope it's ok to post here.
>
> As I'm fine tuning the LDAP DAS Design Guide
> I find myself saying this alot:
>
> "an SDO Type that is the semantic equivalent
> of an XSD Complex Type"
>
> If I were discussing EMF and XSD
> I would just say "EClass".
>
> Just seems like SDO would map a lot cleaner
> to other typing systems if it included
> the semantics of Complex and Simple types.
>
> Seems like it makes the API more efficient too,
> since it becomes natural to keep simple and
> complex types in separate lists. I'm guessing
> that doing this upfront within the core SDO API
> would make most products derived from the SDO API
> more efficient since developers would become
> accustomed to dealing with the distinction.
>
> Anyways - just my two cents. I figured I'd throw
> it out there for general awareness
> in case others were interested.
>
> Cheers,
> - Ole
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org