[sdo] [SDO-17]: SDO Identity and xsd:id

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

Ron Barack [27/Apr/06 02:23 PM] 
Here is our proposed solution:

1. Add commonj.sdo:id as "firstclass" SDO simple-type. Currently, xsd:id
maps to commonj.sdo:string. ID is a concept that applies to other
datasources, not just XML, and furthermore it is something it is easy to
imagine clients and DAS's wanting to know what the ID of an object is,
for instance, to build a hash map. Furthermore, whether or not the data
comes from XML, and whether or not the metadata comes from an XSD, we
still need to serialize it to XML. In order to support references, we
will need to know which of the fields should map to an xsd:id.

2. During XML serialization, all complex DataObjects must have an
element or attribute of type xsd:id. Of course, if the type has a
property of type commonj.sdo:Id we only have to render the property. If
no field of type xsd:id is found, then the serialization mechanism must
add one. On the opening tag for the dataobject, we add a new attribute
"sdo:id". The value of the attribute is left to the implementation, but
it must be enough, together with the type information, to uniquely
identify the object. That is, deserialization mechanism must be able to
create java references from the id, idref pairs. 


Steve Brodsky [12/May/06 01:48 AM] 
It may be easier to specify the ID via a helper instead of via a
Property. The reason is that if a DataObject did not already have an ID
Property then there may be nowhere to put it into the DataObject -
especially those that have been code generated. With a helper, there is
also some flexibility in the algorithm.

String getID(DataObject dataObject);
void setID(DataObject dataObject, String id);

If the DataObject has an instance property that represents the XML ID,
that property is used as the value.

Otherwise the value is determined and stored in an
implementation-dependent fashion.


Ron Barack [12/May/06 06:08 PM] 
In our implementation, we actually have this functionality on the Type,
since he's best in a possition to know about an object's properties.

We have 
String getId(DataObject);
Property getIdProperty();

GetIdProperty can return null, if there is no defined property of type
{commonj.sdo}Id. On the other hand, getId() never returns null. If there
is a defined property, then it returns the value of this property for
the specified data object. If no such property exists, then the type is
responsible for generating a unique id.

During marshalling to XML, we lookup if getIdProperty() exists, and if
it doesn't, we add an "sdo:id" attribute to the element.

Wow, so much action on so many issues!


Radu Preotiuc [23/May/06 10:50 PM] 
Aren't we complicating it too much by requiring that every serialized
element have an sdo:id? After all, the types may come from xsd in which
case you know you don't need to support multiple references.

We are fine with adding an SDO id type and use it for user-declared IDs
but would like to not make the sdo:id attribute mandatory for
serialization right now.


Ron Barack [23/May/06 11:13 PM] 
My intention in suggesting requiring that all complex types to be
serialized with an ID was to keep things simple, on the logic that it is
easier to program doing something every time, than to implementing the
logic to determine if it is really necessary. In particular, the logic
necessary to determine if a non-containment reference to a an object
exists (thereby making the ID attribute necessary) will be messy, and
will anyway require a 2-pass serialization mechanism, since the
reference to the object may come before or after the object itself. The
Use-cases we expect involve relatively large data graphs, therefore, we
put a prio on doing thing in one pass and in SAX.

Anyway, rather than doing the work to find if there are any references
to an object, it seems to me to be easier to implement the logic
described above, namely, if the object's type does not have an ID
property, add a "sdo:id" attribute to the object.


Blaise Doughan [27/Jun/06 04:28 PM] 
Solving this with IDREFs would mean requiring each data object to have
an ID (atleast each data object capable of being created or deleted). 

This becomes restrictive on the types of XML schemas and documents that
can be supported. xsd:ID by itself is very restrictive since the xsd:ID
value can only be used once in a document.

Also, the concept of an ID does not translate well to other data stores.
For example when pulling data from a relational database I might have
CUSTOMER and ADDRESS tables with an ID column that have common ID values
and therefore if I wanted to use the corresponding data objects in a
single data graph I would need to translate the primary key values to
maintain valid xsd:ID values. Also databases allow for compound primary
keys how would this translate to SDOs?

The key/keyref concept in XML schema would be a better model since it
translates better to the concept of database contstraints.


Ron Barack [28/Jun/06 01:19 AM] 
Hi Blaise, I'm drooling at the prospect of added key/ keyref support,
but I need to point out that the usage of the ID/ IDREF, at least in
this context, is a bit different. They are less like PKs in the
database, more like pointers in the java VM. They are there only to
support generation of references during deserialization of the document,
they are, in fact, the XML serialation of a java reference.

You are correct that, according to the proposal, every complex object
would need to have an ID. There are of course 2 cases. For those that
already have an ID, we are home free. For those that don't, the proposal
is that we add an "sdo:id" attribute to the tag. In such cases, there is
no requirement that the ID have any character other than uniquely
identifying the object within the document, not within the dataset, as
with a PK. For instance, an implementation could simply use a sequence
starting at one, everytime XMLHelper.save() is called. 

Do you think that key/keyref would be a better match here?


Ron Barack [28/Jun/06 01:32 AM] 
Sorry to double post, but just to clarify. It is not really that all
objects need an ID in thier normal java life. During serialization,
however, an artificial ID attribute, "sdo:id" will be added to all
objects on which an ID property is not already defined.


Steve Brodsky [28/Jun/06 07:56 PM] 
Perhpas this is better as methods on XMLHelper, it seems that would
clarify the use case.


Blaise Doughan [28/Jun/06 11:37 PM] 
Another item to consider is that by including sdo:id attributes into XML
elements will make it impossible to validate the XML against the XML
schema.

My requirement on a solution would be:
XML documents need to be able to validate against their XML schema.


Frank Budinsky [14/Sep/06 01:26 AM] 
Please correct me if I'm wrong, but I believe that the only part of this
proposal that we are still considering is whether to define a new
{commonj.sdo} ID type. The rest of the proposal was ruled out because of
the schema validation problem.

In last weeks call, people seemed generally OK with the idea of creating
the new ID type, but upon further reflection I do have a concern. As
Blaise pointed out in an earlier comment (above), xsd:IDs are not really
the same as a database ID, in the sense that they must be unique within
the document, not just within a Table. In other words, the scope is
different, so if we create an sdo:ID, it could not really be used as a
general ID mechanism. We would need to document it as needing to be
unique within a serialization, because its main purpose is for use as
the XML change summary ref value.

This makes me think that instead of introducing the concept of an xsd:ID
type of ID in SDO it would be better to keep it as an XSD specific
place: for example, XSDHelper.isID(Property). Maybe, we should add
another XMLInfo annotation (isID) on Property. It would be "true" on
Properties that map to xsd:ids in XML.

Thoughts?



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.