Well in the XML to SDO mapping, isDataType=true for properties where the type is an xsd:simpleType, while isDataType=false if the type is an xsd:complexType. So calling them simple or complex properties (or more specifically "properties of simple type" and "properties of complex type") seems reasonable. The SDO spec does also mention that dataType properties are sometimes referred to as attributes, and dataObject properties as references, so using that terminology would also be OK. I guess my personal preference would be simple/complex, since the term attribute is overloaded in SDO (attribute vs reference, and also attribute vs element in the XML).
Frank. Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 06:44:05 PM: > Hey Frank, > > Yes - I can see how trying to change the specification, at least in the > next couple of days, > might be a long shot :-) > > I guess I'll just put a SDOUtil method in to separate the "EAttributes" > from the "EReferences". > > That way when the SDOs are stored in ApacheDS, the DAS is not calling > isDataType > every time it processes a SDO property. > > Incidentally, terminology wise, would it be correct for me to call > EAttributes > simple properties and > EReferences > complex properties? > > Thanks, > - Ole > > > > > Frank Budinsky wrote: > > Hi Ole, > > > > It will probably be hard to convince people to add the extra lists to the > > SDO specification. It was intentionally designed to have one simple list. > > Adding some methods in Tuscany (in class SDOUtil) to return just the > > dataType or non-dataType properties is possible, but as SDO is now being > > standardized and there are multiple implementations of it, it's really > > best to avoid using implementation-specific APIs, if possible. > > > > getType().getProperties() returns all the properties (including from the > > base types) - it's like EMF's getEAllStructuralFeatures(). > > > > getType().getDeclaredProperties() returns just the locally defined > > properties - like EMF's getEStructuralFeatures(). > > > > Frank. > > > > > > Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 03:04:52 PM: > > > > > >> Super - Thanks Frank. > >> > >> This may be something I should be brining up to the SDO Specification > >> > > guys, > > > >> but it seems like Ecore's way of separating > >> the EAttributes and the EReferences into separate lists will > >> be more efficient from the perspective of of looking for various > >> class members. > >> > >> For instance sometimes I'm only interested in the EAttributes, and with > >> the EMF > >> API I have access to only the List containing the EAttributes, so the > >> time it takes > >> to iterate through this list is shorter than the time it takes to > >> > > iterate > > > >> through all the EStructuralFeatures, which it seems like what I would be > >> > > > > > >> doing with the > >> SDO API... > >> > >> Any thoughts? > >> > >> Could we perhaps add something to the Tuscany SDO implementation that > >> gives us the ability to iterate through the isDataType() members of the > >> SDO object > >> and also the non isDataType() members. > >> > >> In addition, Ecore has the eObject.eClass().getEAllEReferences .... or > >> EAttributes... > >> giving us the inherited members as well. Is this what the SDO object > >> returns > >> when calling > >> > >> getType().getProperties() > >> > >> except in return in effect all the EStructuralFeatures? > >> > >> Thanks, > >> - Ole > >> > >> > >> > >> Frank Budinsky wrote: > >> > >>> In SDO there's a list of properties (simple and complex combined) that > >>> > > you > > > >>> can get like this: > >>> > >>> List<Property> properties = userSDO.getType().getProperties(); > >>> > >>> If you are interested in the simple ones, you need to do something > >>> > > like > > > >>> this when iterating through the list: > >>> > >>> if (property.getType().isDataType()) ... > >>> > >>> Frank. > >>> > >>> Ole Ersoy <[EMAIL PROTECTED]> wrote on 03/29/2007 01:59:05 PM: > >>> > >>> > >>> > >>>> Hi, > >>>> > >>>> I asked this question a little differently before referring to EMF's > >>>> > >>>> > >>> ecore, > >>> > >>> > >>>> and I'll try again by restating what I wish to do. > >>>> > >>>> Suppose I have an SDO instance.... > >>>> > >>>> Class name UserSDO, > >>>> > >>>> instance userSDO > >>>> > >>>> I would like to get a list of all the non-complex object members of > >>>> userSDO > >>>> > >>>> So for instance if userSDO has some String members > >>>> like userName and userPassword > >>>> > >>>> I would like a list of these. > >>>> > >>>> Do I just use regular java reflection or does > >>>> the Tuscany SDO API have something similar to > >>>> EMF's EClass. > >>>> > >>>> If I were using EMF I could > >>>> do > >>>> EClass eClass = userSDO.eClass(); > >>>> > >>>> Then to get the members I would do > >>>> EList<EAttribute> attributes = eClass.getEAttributes(); > >>>> > >>>> If I wanted the complext object references I would > >>>> do > >>>> > >>>> EList<EReference> references eClass.getEReferences(); > >>>> > >>>> Does the Tuscany SDO API have something similar? > >>>> > >>>> Thanks, > >>>> - Ole > >>>> > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >> > >> > > > > > > --------------------------------------------------------------------- > > 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]
