ISSUE 162: Unset Keys and XML Serialiization

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

Logged as:  http://www.osoa.org/jira/browse/SDO-162

---

Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Montag, 29. Juni 2009 21:12
An: Frank Budinsky; sdo@lists.oasis-open.org
Betreff: [LIKELY JUNK]AW: AW: [sdo] Unset Keys and XML Serialiization

Hi Frank,

 

Well, the problem is no unrelated to change summary, because otherwise we have to find a format in which to store complex keys.  Right now, sdo:refs and the created, modified and deleted lists are all xs:AnyURI, so, with the approach I'm suggesting, the XPath would be used for the reference, whenever the key of the referenced object is complex or unset. 

 

I'm just opening the issue for discussion, I don't really have a concrete proposal yet, but I'm thinking along these lines:

 

When creating a property through the API, you could call

 

DataObject t = dataFactory.create("commonj.sdo","Type");

DataObject p = t.create("property");

p.setType(someTypeWithAKey);

p.setContainment(false);

Property xsdTypeProp = typeHelper.getProperty("commonj.sdo/xml","xsdType");

p.set(xsdPropType,http://schema#AnyType);

 

When generating the schema, the XSD element would be have type "xs:xsdType".  In general, when generating XSD, if the sdox:xsdType property is set, you use whatever value is given, rather than then xs type normally associated with the SDO type.

 

Does that help?

 

Ron

 

---

pVon: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Mo 29.06.2009 17:57
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] Unset Keys and XML Serialiization

Hi Ron,

I see. I think I read your last note to fast. Since we have been talking about ChangeSummary a lot lately, I thought you were talking about sdo:ref attributes.

Could you explain more clearly how sdox:xsdType would be used?

Thanks,
Frank.

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

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

06/29/2009 11:28 AM

To	Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
cc
Subject	AW: [sdo] Unset Keys and XML Serialiization

Hi Frank,

I'm not sure that a rule like
If it can use a key to reference, it should, but if it can't, it falls back to an XPath.
makes so much sense. In the case of a complex key, or a simple key of type eg Integer, writing an XPath instead of a key value would result in invalid XML. It would be great to be able to serialize unset keys using XPath, but what would the XSD look like? That's why I'm thinking the solution has to be on the metadata level. Really, that's what has been already done with ID/ IDREF. Whoever wrote the XSD implicitly made the decision to require that keys must be filled. But the user who said that an property is a key is not necessarilly making a decision about the XML serialization. And what I want to achieve is that the user has the potential to specify a metamodel with keys, but still be able to serialize to XML, even when the keyfields are unset.

But even without this motivation, I think having an openContent property like "sdox:xsdType", or adding xsdType() to @SdoXmlProperty might be reasonable. After all, all we are talking about is allow the XSD type to be different from the default type derived from the SDO type. And we already have the dichotomy between SDO and XSD type, see for example sdox:string="true".

Ron

---

Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Montag, 29. Juni 2009 15:23
An: sdo@lists.oasis-open.org
Betreff: Re: [sdo] Unset Keys and XML Serialiization

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