JAXB Schema design, having enum dynamic value - xsd

I have following schema
<xs:simpleType name="enumType">
<xs:restriction base="xs:string">
<xs:enumeration value="STRING_ONE"/>
<xs:enumeration value="STRING_TWO"/>
</xs:restriction>
</xs:simpleType>
As long as i get a known string, I can swithc and it to my jaxbobject which expects a enumType object. But what if i don't know this string ? is there a way to handle it based on JAXB Schema ? I know based on enum its not possible.
Edit: Trying to make it more clear
Wit the given Schema design, my JAXBObject, which accepts enumType as a parameter, can only have 2 input values i.e. STRING_ONE or STRING_TWO which will be converted to XML as part of marshalling.
The question is, that what if, I want to handle a situation through my schema design that if I can have an object of enumType then good otherwise I can give an XML to JAXBObject instead of enumType and it still parses it.

From the XSD point of view, it sounds like you want to be able to write
<xs:simpleType name="soft-enumeration">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="STRING_ONE"/>
<xs:enumeration value="STRING_TWO"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:union memberTypes="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
This type includes the enumeration you describe, but it then unions it with xs:string, so as to accept other values as well. If your schema interface gives you access to information about which member type of the union was used, then you can use that information to treat instances of STRING_ONE and STRING_TWO differently from other strings.
I have no idea whether jaxb does anything useful with this idiom, however; there you're on your own.

Related

Handling a leading zero in a wsdl

I got provided an XSD that had a type representation as follows:
<xs:element name="PhoneNumber">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:pattern value="04[0-9]{8}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Now when we use Apache CXF to convert this from the XSD to autogenerated code which assigns it as a BigInteger.
So what I would like to know:
Is that piece of XSD valid? (I tend to think not as an Integer will never exist with a leading zero)
Is there anyway to get Apache CXF to handle such a condition and force the type to be a string?

SimpleType - Aggregation or Abstraction

I face a weird problem. I'm supposed to use a number of third party XSDs for a webservice. My framework of choice is Apache CXF, and I generate code using its Maven plugin. So far so good, everything works, neither generation nor webservice itself is problematic.
But, since the authors of the XSDs are weird and I cannot change them myself, I face a problem: They use a lot of basically duplicated SimpleType-definitions. They all bear their own name, but do the same thing.
Example:
<xs:simpleType name="VehicleFittedWithEcoInnovInd">
<xs:restriction base="xs:string">
<xs:maxLength value="1"/>
<xs:enumeration value="Y"/>
<xs:enumeration value="N"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TypeApprTranspDangerGoodsInd">
<xs:restriction base="xs:string">
<xs:maxLength value="1"/>
<xs:enumeration value="Y"/>
<xs:enumeration value="N"/>
</xs:restriction>
</xs:simpleType>
And many more (Numbers, Stringdefinitions etc etc).
So the question is, is it possible, through a jaxb-plugin or similar, to aggregate these SimpleTypes into one, or at least generate an abstract class structure, so that the amount of irrelevant duplicate code is reduced?

XSD what is the difference between attribute with type and attribute with restriction?

I am doing some xsd cleanup activity with limited knowledge on XSD. The file I have contains a complex element with two attribute defined, but differently.
<xs:attribute name="DecisioningRequestType"
type="xs:string"
use="required"/>
<xs:attribute name="ProcessingRequestType"
use="required">
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:attribute>
Through when xml is created, both attribute contain a string value, but I am trying to understand what difference does it make when the attribute are defined with restriction? Isn't that I can define my second attribute similar to the first attribute shown above?
If it is same, I can bring a uniformity in defining the attributes in my XSD file through this cleanup.
Attribute with restriction means that the type of the attribute value is defined
inline, directly within the definition of the attribute itself.
That is used when, on one hand, the attribute type is something special (not just a base type) but, on other hand, it is used only for that attribute.
So, defining that type as a separate component would be redundant.
But in your case, the construct:
<xs:attribute name="ProcessingRequestType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:attribute>
although is valid, actually doesn't restrict anything (it is an empty restriction).
So, it is equivalent to
<xs:attribute name="ProcessingRequestType" type="xs:string" use="required"/>
A true restriction would look something like this:
<xs:attribute name="ProcessingRequestType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="typeA"/>
<xs:enumeration value="typeB"/>
<xs:enumeration value="typeC"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
That means that the attribute value is a string, however restricted to be only one from the list: "typeA", "typeB", "typeC".
The declaration of an attribute requires that the type of the attribute be specified; this can be done either with a type attribute giving the name of the type, or with an inline declaration of an anonymous type.
The use or non-use of the XSD restriction element is orthogonal to the difference between a type attribute and a simpleType child. In the case you give, the restriction is vacuous; the inline declaration could just as easily have taken the form
<xs:simpleType>
<xs:union memberTypes="xs:string"/>
</xs:simpleType>
You write both attribute contain a string value -- this is true enough, as far as it goes, but the two attributes do not have the same type: one is associated with type xs:string and the other with an anonymous type whose value and lexical spaces are the same as those of xs:string (because it was created by a vacuous restriction of xs:string). In some cases, that difference can be important.

How to allow typed values to be empty with an XML schema?

I have some XML documents over which I have no control whatsoever. Their structure is well-defined, but it is described in a bunch of PDFs, which, despite being very exact, don't make automated validation very tractable. I'm trying to write a XML schema to make (most of) the rules in those PDFs executable.
All the elements are mandatory. But about half of them can be either empty or have simple typed content.
When defining datatypes for these elements, I defined two versions of each: a "normal" one, and another that can be empty. I did this by defining unions with an empty datatype:
<xs:simpleType name="empty">
<xs:restriction base="xs:string">
<xs:length value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="codPostal">
<xs:restriction base="xs:string">
<xs:pattern value="^[0-9]{4}-[0-9]{3}$"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="opt_codPostal">
<xs:union memberTypes="empty codPostal"/>
</xs:simpleType>
Is there a less repetitive way of doing this?
You can use xs:nillable.
In XSD
<xs:simpleType name="codPostal">
<xs:restriction base="xs:string">
<xs:pattern value="^[0-9]{4}-[0-9]{3}$"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="OptionalString" type="codPostal" nillable="true" />
In Document
<OptionalString xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />
This is most useful for non-string types (e.g. datetime etc) as for strings you could just use zero length.
<OptionalString />
Unfortunately you need to specify the "nil" attribute on the document. As far as I know, the only non-intrusive way to do what you want is the union type approach that you've already chosen.

Xsd, Validate empty or minimum length string

Currently I have an Xsd validating with this rule
<xs:simpleType name='shipTo'>
<xs:restriction base='xs:string'>
<xs:minLength value='6'/>
</xs:restriction>
</xs:simpleType>
I need to allow blanks as well, but if a value is entered, it's minimum length should still be 6.
Can I do this without resorting to this xs:pattern and regex?
<xs:simpleType name='shipTo'>
<xs:restriction base='xs:string'>
<xs:pattern value='^(?:|[\w]{6,})$'/>
</xs:restriction>
</xs:simpleType>
The regex will work, but you should really make the element that you will be assigning shipTo to optional, and not include it in the XML file if it has no value.

Resources