[NEW ISSUE] SubstitutionGroup support in SDO 3

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

I would suggest creating a new issue in the XML Fidelity component.


-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Gesendet: Freitag, 15. Februar 2008 22:04
An: sdo@lists.oasis-open.org
Betreff: [sdo] SubstitutionGroup support in SDO 3

Hi Guys,

I've been thinking about what should be the proper handling of 
substitutionGroups in SDO 3. Here is my first thought. It made good sense 
until I got to the isMany example (proposal #4, below), at which point I 
started to wonder if we should not allow setting substitutions through the 
DataObject API at all. We could instead provide an XMLHelper API to do it. 
Please take a look at the following proposal and let me know your 
thoughts.

Maybe we can add this issue to the agenda for next weeks call?

Thanks,
Frank.


SubstitionGroups in SDO 3
=======================

There are two dimensions of specialization in XML Schema vs. just one in 
SDO/Java. In both XSD and SDO you can have type B extend A, but in XSD you 
can also have substitutionGroups, the equivalent of variable b : B extend 
variable a : A. You can find examples of one, the other, or both, being 
used.

EXAMPLE:

<complexType name="A"> ... </complexType>

<complexType name="B"> 
    <complexContent>
        <extension base="A"> ... </extension>
    </complexContent>
</complexType> 

<element name="a" type="A"/>
<element name="b" substitutionGroup="a" type="B"/>
<element name="c" substitutionGroup="a" type="B"/>

<complexType name="testDO">
  <sequence>
    <element ref="a"/>
  </sequence>
</complexType> 


An SDO property "a" of type "B" could be legally serialized in any of the 
following ways:

<testDO1><a xsi:type="B"> some_B_value </a></testDO1>
<testDO2><b> some_B_value </b></testDO2>
<testDO3><c> some_B_value </c></testDO3>

In the SDO 2, all three of these are required to appear as a value for the 
property "a":

DataObject testDO1 = ...
testDO1.get("a") == some_B_value

DataObject testDO2 = ...
testDO2.get("a") == some_B_value

DataObject testDO3 = ...
testDO3.get("a") == some_B_value

SDO 2 does not require that when you reserialize any of the above 
dataObjects (testDO1, testDO2, or testDO3) that they will produce the same 
XML (i.e., round trip). 

More generally, in SDO 2, it is implementation dependent which of the 
three serializations is used for a property "a":

testDO.set("a", some_B_value);

may produce any of the three XML forms from above. SDO 2 does suggest that 
an implementation should use a best guess subsitution element if possible, 
but it is not required. Note that in this example there is no predictable 
best guess anyway, since "b" and "c" are both of type "B".


SDO 3 PROPOSAL #1:

Substitition elements will round trip (XML -> DataObject -> XML). Maybe 
this should be an option, but it is necessary for an implementation to 
claim XML fidelity.


SDO 3 PROPOSAL #2:

testDO.set("a", some_B_value); 

will produce: 

<a xsi:type="B"> some_B_value </a>  (NOTE this is changed from SDO 2 - no 
longer implementation dependent)

and

Property a = xsdHelper.getGlobalProperty(tns, "a", true); 
testDO.set(a, some_B_value); // note that this call is using the global a, 
not the local a property as in the previous example

will produce:

<a xsi:type="B"> some_B_value </a>

and

Property b = xsdHelper.getGlobalProperty(tns, "b", true);
testDO.set(b, some_B_value);

will produce:

<b> some_B_value </b>

and

Property c = xsdHelper.getGlobalProperty(tns, "c", true);
testDO.set(c, some_B_value);

will produce:

<c> some_B_value </c>


SDO 3 PROPOSAL #3:

Property a = xsdHelper.getGlobalProperty(tns, "a", true);
Property b = xsdHelper.getGlobalProperty(tns, "b", true);
Property c = xsdHelper.getGlobalProperty(tns, "c", true);

testDO1.get("a") == some_B_value // no change from SDO 2
testDO1.get(a) == some_B_value
testDO1.get(b) == null
testDO1.get(c) == null

testDO2.get("a") == some_B_value // no change from SDO 2
testDO2.get(a) == null
testDO2.get(b) == some_B_value
testDO2.get(c) == null

testDO3.get("a") == some_B_value // no change from SDO 2
testDO3.get(a) == null
testDO3.get(b) == null
testDO3.get(c) == some_B_value


SDO 3 PROPOSAL #4:

Many valued (isMany) subsitutionGroup elements:

<complexType name="testDO">
  <sequence>
    <element maxOccurs="unbounded" ref="a"/>
  </sequence>
</complexType> 

<testDO>
  <a xsi:type="B"> some_B_value1 </a>
  <b> some_B_value2 </b>
  <c> some_B_value3 </c>
</testDO>


Property a = xsdHelper.getGlobalProperty(tns, "a", true);
Property b = xsdHelper.getGlobalProperty(tns, "b", true);
Property c = xsdHelper.getGlobalProperty(tns, "c", true);

testDO.getList(a) == error
testDO.getList(b) == error
testDO.getList(c) == error

testDO.getList("a") == { some_B_value1, some_B_value2, some_B_value3 } // 
same as SDO 2

and

testDO.setList(a, someList) == error
testDO.setList(b, someList) == error
testDO.setList(c, someList) == error

testDO.setList("a", {some_B_value1, some_B_value2, some_B_value3})

will produce:

<testDO>
  <a xsi:type="B"> some_B_value1 </a>
  <a xsi:type="B"> some_B_value2 </a>
  <a xsi:type="B"> some_B_value3 </a>
</testDO>


Question #1: How to support get/set of isMany substitutions? Do we want to 
add an XMLHelper method to do it?

For example:

List<Settings> value = xmlHelper.getSubstitutions(testDO, "a");

would return a List of property/value pairs (class Setting) corresponding 
to the values of property "a". The following:

<testDO>
  <a xsi:type="B"> some_B_value1 </a>
  <b> some_B_value2 </b>
  <c> some_B_value3 </c>
</testDO>

would return:

{ (a, some_B_value1), (b, some_B_value2), (c, some_B_value3) }

You could set the "a" property in a similar way:

xmlHelper.setSubstitutions(testDO, "a", newSettingList);


Question #2: Maybe we should only allow single value properties to be set 
using the XMLHelper API (instead of proposals #2 and #3 from above)?

We could use the same methods, but when used for single valued properties 
(isMany == false) the List would always contain only one entry.

Thoughts?


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php