OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sdo] SubstitutionGroup support in SDO 3


Hello All,

In JAXB 2.0 the solution to this problem was to add the class JAXBElement. 
The purpose of this class is to hold the XML element information in 
situations where the mapping metadata does not provide enough information, 
such as for substitution groups.

The JAXBElement class holds the following information:
- javax.xml.namespace.QName name (to hold name and namespace URI)
- java.lang.Object to hold the value.

We could create an SDO equivalent of this class.  Instead of the QName to 
hold onto the name it may be better to hold onto the property.

-Blaise

----- Original Message ----- 
From: "Frank Budinsky" <frankb@ca.ibm.com>
To: <sdo@lists.oasis-open.org>
Sent: Friday, February 15, 2008 4:03 PM
Subject: [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
>
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]