[sdo] [SDO-114]: Clarify behavior when storing Type / Property asa value in a DataObject

[Radu Preotiuc-Pietro <radup@bea.com>]

Ron Barack [18/Jun/07 10:56 AM] 
Most of this relates back to the old debate on ("Type & Property should
implement DataObject"). Either a commonj.sdo.Type or a {commonj.sdo}Type
may be used when calling set("type")...so much easier when a
commonj.sdo.Type is a {commonj.sdo}Type.

As far as XML serialization goes, the sdoModel.xsd requires an "anyUri"
to be used for the type. From here on, though, the spec is even more
incomplete than usual. In the examples we see that something like
"namespace#name" is expected. A small nit with the Tuscany
implementation is why in their implementation seems to serialize the uri
as "namespace#//name". Personally, I could live with either. Anyway,
that covers the case where the value of the property "type" in
{commonj.sdo}Property is a commonj.sdo.Type. For an example of this
usage see xmlXML.xml.

The whole thing gets much uglier when considering what to do when the
value to which "type" was set is an {commonj.sdo}Type. As far as I'm
concerned, the only way to handle this that is consistent with the rest
of the spec is to give the XMLPath to the description of the referenced
data object within the current document. That is, the {commonj.sdo}Type
is just a data object being referenced from a data object. Since
{commonj.sdo}Type doesn't have an xs:ID field, the we should just give
its address in the document.... something along the lines of
"type='#types[34]'". On the other hand sdoModel.xml itself references
such type DataObjects simply using the format "'#Name". This seems
problematic, since we are not guarenteed that all the types in a file
will be in the same namespace, and therefore, there is no guarentee that
the name is unique. Such an approach has the advantage of better
readability, but seems to requires more special handling.


Blaise Doughan [09/Aug/07 05:05 PM] 
I propose we move this issue to 3.0 as the resolution will depend on how
we resolve "If Type and Property will become DataObjects" ("Type &
Property should implement DataObject").


Michael B. Yoder [23/Aug/07 01:00 AM] 
For when this issue is discussed further, an additional consideration is
the C++ side. A C++ analog to Typehelper.define is desirable (one atomic
step prevents the user from having to consider multi-thread safety). If
Type/Property are not made into DataObjects, then its seems like you
would need to additional DataObject API to accommodate Type and Property
(additional overloads on DataObject to set/get that take a Type or
Property). This seems like an awkward one off (similar to a special
check for instances of Type or Property in the Java DataObject set/get
API).

One idea would be to just no longer allow Types/Property objects in type
definition. Go with DataObject's only. Would that work? It's a bit
cumbersome to create a DataObject just to specify a type. But I guess
creating a Type object is too. It seems like the most convenient thing
usage wise might be for types to be set with a URI, as mapped in SDO
from XSD QName, e.g. dob->set("type", "commonj.sdo#String").



Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.