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:schemaLocation
attribute of thesa:createOrderByValueRequest
now points to the OSS/J SA schema instead of our custom schema. Now thesa:createOrderByValueRequest
is resolved. - The sub element of
sa:createOrderByValueRequest
now is asa:orderValue
, but using thexsi:type
attribute the validator is hinted that the actual element is theCustomOrderValue
sub type of the abstractOrderValue
. - The previous point was not enough to actually resolve the
CustomOrder
type. In order to get that resolved anxsi:schemaLocation
attribute 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