After doing a couple of architect and design projects in which the OSS/J Service Activation API played a role, this week we had to actually define a couple of extensions to the OSS/J Service Activation XML Schema's. You learn something new everytime you do something for the first time...
The core of the problem was that we had to define and use subtypes of the abstract orderValue type which is defined in the OSS/J SA spec. Defining the sub types was not the problem, that was done in a breeze. Using them in an XML document appeared to be a challenge. This was mainly caused by the fact that the abstract orderValue is used as a element in for example createOrderByValueRequest. Some snippets might clarify the issue:
The definition of the createOrderByValueRequest is as follows:
<element name="createOrderByValueRequest">
<complexType>
<sequence>
<element name="orderValue" type="sa:OrderValue"/>
</sequence>
</complexType>
</element>
orderValue is defined as:
<complexType name="OrderValue" abstract="true">
<complexContent>
<extension base="co:ManagedEntityValue">
<sequence>
<!-- SNIP -->
</sequence>
</extension>
</complexContent>
</complexType>
Our extension to orderValue is:
<complexType name="CustomOrderValue">
<complexContent>
<extension base="sa:OrderValue">
<sequence>
<element name="somefield" type="string"/>
</sequence>
</extension>
</complexContent>
</complexType>
Our initial attempt to use CustomOrder as part of createOrderByValueRequest
was as follows:
<?xml version="1.0" encoding="UTF-8"?>
<sa:createOrderByValueRequest
xmlns="http://xyz.com/ServiceActivation"
xmlns:co="http://java.sun.com/products/oss/xml/Common"
xmlns:sa="http://java.sun.com/products/oss/xml/ServiceActivation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xyz.com/ServiceActivation XmlXYZServiceActivation.xsd"
>
<CustomOrderValue>
<co:lastUpdateVersionNumber>1</co:lastUpdateVersionNumber>
<!-- SNIP -->
<someField>bla</someField>
</CreateVASOrderValue>
</sa:createOrderByValueRequest>
This did not work since the definition of createOrderbyValueRequest dictates that
a orderValue is expected as the only subelement. Aside from that, the validator
is also not able to resolve the sa:createOrderByValueRequest. We assumed this would
be resolved by the xsi:schemaLocation attribute that points to the XmlXYZServiceActivation.xsd
schema file which includes the imports the XmlServiceActivationSchema.xsd file
containing the OSS/J SA schema.
Mmm, now what... I'll leave all the failed attempts out, but this is what worked. The changes we had to make are:
- The
xsi:schemaLocationattribute of thesa:createOrderByValueRequestnow points to the OSS/J SA schema instead of our custom schema. Now thesa:createOrderByValueRequestis resolved. - The sub element of
sa:createOrderByValueRequestnow is asa:orderValue, but using thexsi:typeattribute the validator is hinted that the actual element is theCustomOrderValuesub type of the abstractOrderValue. - The previous point was not enough to actually resolve the
CustomOrdertype. In order to get that resolved anxsi:schemaLocationattribute that points to our custom schema file.
<?xml version="1.0" encoding="UTF-8"?>
<sa:createOrderByValueRequest
xmlns="http://xyz.com/ServiceActivation"
xmlns:co="http://java.sun.com/products/oss/xml/Common"
xmlns:sa="http://java.sun.com/products/oss/xml/ServiceActivation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/products/oss/xml/ServiceActivation XmlServiceActivationSchema.xsd"
>
<sa:orderValue xsi:type="CustomOrderValue" xsi:schemaLocation="http://xyz.com/ServiceActivation XmlXYZServiceActivation.xsd">
<co:lastUpdateVersionNumber>1</co:lastUpdateVersionNumber>
<!-- SNIP -->
<someField>bla</someField>
</sa:orderValue>
</sa:createOrderByValueRequest>
Sound fine, problem resolved... however, is this The Way to tackle this problem? XML Schema seems to provide various options
to tackle this problem and I'm not sure yet if this is the best way. One alternative we considered was to redefine the
createOrderByValueRequest element in our custom schema, but that would in practice imply that we would be
redefining the whole OSS/J SA schema in order to extend it. That's definitily not how it's intended to be. Any other options?
0 comments:






Post a Comment