Re: [sdo] Unset Keys and XML Serialiization

[Frank Budinsky <frankb@ca.ibm.com>]

Hi Ron,

I'm not understanding how this is a new problem. It was always the case that you couldn't use an IDREF to point to an object if the ID was unset. I think it that this:

"that non-containment references to DataObjects that have keys are rendered as the key, rather than as the Xpath "pointer" to the object."

implies:

"that non-containment references to DataObjects that have set (i.e., unset = false) keys are rendered as the key ...".

If it can use a key to reference, it should, but if it can't, it falls back to an XPath.

Frank.

"Barack, Ron" <ron.barack@sap.com>

"Barack, Ron" <ron.barack@sap.com>

06/29/2009 08:27 AM

To	<sdo@lists.oasis-open.org>
cc
Subject	[sdo] Unset Keys and XML Serialiization

Hi Guys,

The following scenario is causing me some sleepless nights.

We've said that non-containment references to DataObjects that have keys are rendered as the key, rather than as the Xpath "pointer" to the object. In other words, SDO 3.0 uses keys just as SDO 2.1 uses IDRefs. This works fine as long as the data is being fetched by the DAS, or when the client has some way of generating the keys.

But what about cases where the keys are generated by the backend (eg, DB), and where the client is creating some kind of complex data model, for instance, to ship over as a batch to the DAS. For example, suppose Customer has a non-containment relationship to address, and that the client wants to create 2 customers, each with a different address. If Address has a key field, then the user must set it, otherwise, looking at the XML you would never be able to determine which Address is associated with which Customer.

One possible solution would be to elimintate the effect of keys on XML serialization. This is undesireable, because using keys in this way produces XML that is not only more readable, but also XML that can be used as input to non-SDO based clients.

We would propose adding the capability for users to decide, based on their use-cases, whether the XML should be rendered in the 3.0 way, using keys for non-containment references, or in the 2.1 way, using Xpaths. If we had a rule that a key type MAY NOT be an xsd:AnyURI, then we could have a rule that if the XSD model demands an AnyURI, then the Xpath should be rendered. That would handle the case where XSD is the source of the SDO metadata. To support cases where the metadata is derived from Java annotations, we would need to add an field to @SdoXmlPropertiy. To support cases where the metatdata comes directly through the API, we'd have to specify a new open context property.

I will be opening this as an issue.

Best Regards,
Ron