For the following schema, Say both a and b are String type. JAXB generates a variable called aOrB. I know I can use instanceof if a and b are differnet types. But they are both String type now, how do I tell the differences? Someone mentioned to use something like Qname, JAXBElement . I have no idea how to do that. Can someone pls shine some light? thanks
<xs:choice maxOccurs="unbounded">
<xs:element ref="a" minOccurs="1" />
<xs:element ref="b" minOccurs="1" />
I got it, its (JAXBElement) object).getName().getLocalPart() . sorry for the false alarm
Related
One of the things I've written down for the airing-of-grievances for Festivus this year is how Xerces/SAX2 reports parsing errors.
Take this bit of XSD:
<xs:sequence>
<xs:element ref="element1" />
<xs:element ref="element2" />
<xs:element ref="element3" />
<xs:element ref="element4" minOccurs="0" />
<xs:element ref="element5" />
<xs:element ref="element6" minOccurs="1" />
<xs:element ref="element7" minOccurs="0" />
<xs:element ref="element8" minOccurs="0" />
<xs:choice minOccurs="0">
<xs:element ref="choiceElement1" />
<xs:element ref="choiceElement2" />
</xs:choice>
<xs:element ref="element9" minOccurs="0" />
</xs:sequence>
and sample XML
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<xmldocument xmlns="http://www.somewebsite.com/xsd/xmldocument" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.somewebsite.com/xsd/xmldocument xmldocument.xsd">
<transaction msgId="MESSAGE-ID">
<element1>KS0003</element1>
<element2>2016-05-09</element2>
<element3>10:20:50</element3>
<element5>99433</element5>
<element8>jesse</element8>
</transaction>
</xmldocument>
I get this error:
RAW SAX2 ERROR: Error at file "/tmp/QACXV0Z346", line=10, column=17,
XML element=element8, Element 'element8' is not valid for content
model:
'((element1,element2,element3,element4,element5,element6,element7,element8,(choiceElement1|choiceElement1)),element9)'
Seems to me the problem here isn't element8, it's element6, which is set to required but is the one actually missing in the XML.
I have some code that attempts to parse out this string and figure out what the real problem is, but the error string doesn't contain any information about optional elements, etc. I may not be setting things up correctly - maybe. I have a problem in general with SAXException - it's nearly useless - so what I need is more information from something that tells me what the real problem is.
We're using Xerces 2.6 or 2.8 because we're running on an IBM i and they don't provide updates to stuff like this unless you upgrade the OS.
Xerces error messages are actually quite good.
You might argue that in this particular case, it would be better to say something along the lines of
Encountered element8 but element6 was expected.
That's fine for this simple case, but realize that in the general case, there can be an arbitrarily complex expression covering what possibly could have been expected. Be prepared to introduce a whole lot of complexity to concisely explain what all would be allowed at a given point where parsing goes awry. Citing the first point of contradiction along with the violated parent content model requirement is not a bad diagnostic in general.
I would like to validate a custom XML document against a schema.
This document would include a structure with any number of elements, each having a specific attribute. Something like this:
<Root xmlns="http://tns">
<Records>
<FirstRecord attr='whatever'>content for first record</FirstRecord>
<SecondRecord attr='whatever'>content for first record</SecondRecord>
...
<LastRecord attr='whatever'>content for first record</LastRecord>
</Records>
</Root>
The author of the XML document can include any number of records, each with an arbitrary name of his or her choosing. How is this possible to validate this against an XML Schema ?
I have tried to specify the appropriate structure type in a schema, but I do not know how to reference it in the appropriate location:
<xs:schema xmlns="http://tns" targetNamespace="http://tns" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="RecordType"> <!-- This is my record type -->
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="attr" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="1" name="Records">
<!-- This is where records should go -->
<xs:complexType />
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
What you describe is possible in XSD 1.1, and something very similar is possible in XSD 1.0, which is not to say it's an advisable design.
In XML vocabularies, the element type normally conveys relevant information about the type of information, and it is the name of the element type that is used to drive validation in most XML schema languages; the design you describe is (some would say) a little bit like asking if I can define an object class in Java, or a struct in C, which obeys the constraints that the members can have arbitrary names, as long as one of them is an integer with the value 42. That, or something like it, may well be possible, but most experienced designers will feel strongly that this is almost certainly not the right way to go about solving any normal problem.
On the other hand, doing unusual and awkward things with a system can sometimes help in learning how to use the system effectively. (You never know a system well, said a friend of mine once, until you have thoroughly abused it.) So my answer has two parts: how to come as close as possible to the design you specify in XSD, and alternatives you might consider instead.
The simplest way to specify the language you seem to want in XSD 1.1 is to define an assertion on the Records element which says (1) that every child of Records has an 'attr' attribute and (2) that no child of Records has any children. You'll have something like this:
...
<xs:element minOccurs="1" maxOccurs="1" name="Records">
<xs:complexType>
<xs:sequence>
<xs:any/>
</xs:sequence>
<xs:assert
test="every $child in * satisfies $child/#attr"/>
<xs:assert
test="not(*/*)"/>
</xs:complexType>
</xs:element>
...
As you can see, this is very similar to what InfantPro'Aravind' has described; it avoids the problems identified by InfantPro'Aravind' by using assertion, not type assignment, to impose the constraints you impose.
In XSD 1.0, assertion is not available, and the only way I can think of to come close to the design you describe is define an abstract element, which I'll call Record, as the child of Records, and to require that the elements which actually occur as children of Records be declared as being substitutable for this abstract type (which in turn requires that their types be derived from type RecordType). Your schema might say something like this:
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="Records">
<xs:complexType>
<xs:sequence>
<xs:element name="Record"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="RecordType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="attr"
type="xs:string"
use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Record"
type="RecordType"
abstract="true"/>
Elsewhere in the schema (possibly in a separate schema document) you will need to declare FirstRecord, etc., and specify that they are substitutable for Record, thus:
<xs:element name="FirstRecord" substitutionGroup="Record"/>
<xs:element name="SecondRecord" substitutionGroup="Record"/>
<xs:element name="ThirdRecord" substitutionGroup="Record"/>
...
At some level, this matches your description, though I suspect you did not want to have to declare FirstRecord, SecondRecord, etc.
Having described ways in which XSD can do what you describe, I should also say that I wouldn't recommend either of these approaches. Instead, I'd design the XML vocabulary differently to work more naturally with XSD.
In the design as you specify it, every record appears to have the same type, but in addition to the content of the element they are allowed to convey a certain additional quantity of information by having a different name (FirstRecord, SecondRecord, etc.). This additional information could just as easily be conveyed in an attribute, which would allow you to specify Record as a concrete element, rather than an abstract element, giving it an extra "alternate-name" attribute. Your sample data would then take a form like this:
<Root xmlns="http://tns">
<Records>
<Record
alternate-name="FirstRecord"
attr='whatever'>content for first record</Record>
<Record
alternate-name="SecondRecord"
attr='whatever'>content for first record</Record>
...
<Record
alternate-name="LastRecord"
attr='whatever'>content for first record</Record>
</Records>
</Root>
This will be more or less acceptable depending on whether you or your data providers or tools in your tool chain attach some mystic or other significance to having the string "FirstRecord" be an element type name instead of an attribute value.
Alternatively, one could say that the point of the design is to allow Records to contain an arbitrary sequence of elements of arbitrary structure (on this account, the restriction to xs:string is just an artifact of your example and is not really desired in reality) as long as we have, for each record, the information recorded in the 'attr' attribute. Easy enough to specify this: define 'Record' as a concrete element with an 'attr' attribute, accepting one child which can be any XML element:
<xs:element name="Record">
<xs:complexType>
<xs:sequence>
<xs:any processContents="lax"/>
</xs:sequence>
<xs:attribute name="attr"
use="required"
type="xs:string"/>
</xs:complexType>
</xs:element>
The value of the 'processContents' attribute can be changed to 'strict' or 'skip' or kept at 'lax', depending on whether you want FirstRecord, SecondRecord, etc. to be validated (and declared) or not.
I guess this is not possible with XSD alone!
When you say
any number of records, each with an arbitrary name of his or her choosing.
That forces us to use <xs:any/> element but! Having an element declared as any doesn't allow you to validate attributes under it..
So .. the answer is NO!
This is a similar question to How to create a schema for an unordered list of XML nodes, with occurrence constraints, but actually slightly simpler. However I am having great trouble understanding the logic behind sequences and choices (and especially when they are nested into sequences of choices or choices of sequences), and although I've studied it for a long time I can't understand how the example above works.
What I need is schema for a list of nodes, ChildA and ChildB, whereby ChildA can occur 0-n times, but ChildB only 0-1 times. (Actually I need several nodes of each type, but if I can do it for ChildA and ChildB, extending it to ChildX etc. and ChildY etc. should be simple). There should be no order constraint. I'd appreciate any help. Any links that explain schema indicators in depth would also be helpful.
This would be the simplest solution that quickly came to my mind. The key point here is to use another sequence inside the "main" sequence. The schema is kept deterministic by setting the inner sequence to start with <ChildB> and <ChildB> is kept optional by setting the cardinality of that sequence to 0-1.
This is an XMLSchema 1.0 solution.
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- Schema for elements ChildA and ChildB
The requirements are as follows:
* ChildA and ChildB may occur in any order.
* ChildA is optional and may occur multiple times.
* ChildB is optional and may occur once only.
-->
<xs:element name="root">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="AB-container" type="AB-type" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="AB-type">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="ChildA" type="xs:string" />
<xs:sequence minOccurs="0">
<xs:element name="ChildB" type="xs:string" />
<xs:element minOccurs="0" maxOccurs="unbounded" name="ChildA" type="xs:string" />
</xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:schema>
Short answer is that it cannot be done in XSD 1.0; in XSD 1.1 you could use an xsd:all compositor (since the restriction from XSD 1.0 of having only maxOccurs = 1 has been removed) - however, XSD 1.1 's problems are that i) it is only available freely as a beta Xerces version - as far as I know, and at this time; ii) there's a SAXON edition supporting it, last time I saw references to it you would have to pay for that and iii) you would have a hard time interoperating with other folks since most of them are still on XSD 1.0.
IF you can use Schematron - definitely more accessible than XSD 1.1 since it is just XSLT 1.0/2.0, then it should be easy to code it such that the count of particular element particles meets a specified criteria; it would augment an XSD where the compositor would be a repeating xsd:choice, where the choice options are elements from your allowed set.
Some people try to explain XSD compositors by making a parallel with constructs from regular expressions. If you are familiar with that, then xsd:all in XSD 1.0 is similar to square brackets (much simpler though, no concept of a range or negation), xsd:choice is like | (pipe, alternation) and xsd:sequence is the rest (where it matters the order in which you write your stuff).
I see that other people on SO recommend W3Schools. I didn't try it myself, hence me passing this on to you with the disclaimer.
#Dave is adding some dumb attribute to ChildB okay? Since your requirement on childB is 0-1 we can achieve the desired solution by adding a fixed attribute to childB and enforcing unique constraint on the attribute.
<complexType name="childAType">
<simpleContent>
<extension base="string"></extension>
</simpleContent>
</complexType>
<complexType name="childBType">
<simpleContent>
<extension base="string">
<attribute name="value" type="string" fixed="123"></attribute>
</extension>
</simpleContent>
</complexType>
<element name="root">
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="childA" type="tns:childAType" minOccurs="0" maxOccurs="unbounded"></element>
<element name="childB" type="tns:childBType" minOccurs="0" maxOccurs="unbounded"></element>
</choice>
</complexType>
<unique name="childB.max.once">
<selector xpath="./tns:childB"></selector>
<field xpath="#value"></field>
</unique>
</element>
Below is one of valid XML (order of B doesn't matter or B can be excluded)
<tns:root xmlns:tns=" ">
<tns:childA></tns:childA>
<tns:childB></tns:childB>
<tns:childA></tns:childA>
<tns:childA></tns:childA>
</tns:root>
However the below one is invalid
<tns:root xmlns:tns=" ">
<tns:childB></tns:childB>
<tns:childA></tns:childA>
<tns:childB></tns:childB>
<tns:childA></tns:childA>
<tns:childA></tns:childA>
</tns:root>
I reading articles about XSD on w3schools and here many examples. For example this:
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
But after I tried put this .xsd file in xjc - I see error log, dome like this:
The prefix "xs" for element "xs:schema" is not bound...
But all work correct when I change xs on xsd prefix.
So, can somebody, clarify for me what is different between xs and xsd?
Maybe, one prefix - it is old version and other for new version...
xs and xsd are XML prefixes used with qualified names; each prefix must be associated with a namespace. The association is done with an attribute that looks like xmlns:xs="...". xs and xsd are most common for XML Schema documents.
Should you choose s or ns1, it shouldn't make any difference to any tool for your scenario.
The error is not caused by your XML Schema file. I suspect there might be something else in your setup, maybe a custom binding file. Please check that or post additional information.
This XSD portion was obtained from: http://www.iana.org/assignments/xml-registry/schema/netconf.xsd
<xs:complexType name="rpcType">
<xs:sequence>
<xs:element ref="rpcOperation"/>
</xs:sequence>
<xs:attribute name="message-id" type="messageIdType" use="required"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc" type="rpcType"/>
And is the core to function calls in NETCONF being the node of an XML document. I am curious as to why it is not something like:
<xs:element name="rpcType">
<xs:complexType>
<xs:sequence>
<xs:element ref="rpcOperation"/>
</xs:sequence>
<xs:attribute name="message-id" type="messageIdType" use="required"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
</xs:element>
The reasoning is that in #1 when trying to marshall a bean (in jaxb2) I get the exception:
[com.sun.istack.SAXException2: unable to marshal type "netconf.RpcType" as an element because it is missing an #XmlRootElement annotation]
I have been reading this article over and over again, and really cant get a hold of the difference, and why it would be #1 vs #2...
It's not obvious, I'll grant you. It comes down to the type vs element decision.
When you have something like
<xs:element name="rpcType">
<xs:complexType>
This is essentially an "anonymous type", and is a type which can never occur anywhere other than inside the element rpcType. Because of this certainty, XJC knows that that type will always have the name rpcType, and so generates an #XmlRootElement annotation for it, with the rpcType name.
On the other hand, when you have
<xs:complexType name="rpcType">
then this defines a re-usable type which could potentially be referred to by several different elements. The fact that in your schema it is only referred to by one element is irrelevant. Because of this uncertainty, XJC hedges its bets and does not generate an #XmlRootElement.
The JAXB Reference Implementation has a proprietary XJC flag called "simple binding mode" which, among other things, assumes that the schema you're compiling will never be extended or combined with another. This allows it to make certain assumptions, so if it sees a named complexType only being used by one element, then it will often generate #XmlRootElement for it.
The reality is rather more subtle and complex than that, but in 90% of cases, this is a sufficient explanation.
Quite an involved question. There are many reasons to design schemas using types rather than elements (this approach is called the "venetian blind" approach versus "salami slice" for using global elements). One of the reasons is that types can be sub-typed, and another that it may be useful to only have elements global that can be root elements.
See this article for some more details on the schema side.
Now, as for the JAXB question in particular. The problem is that you created a class corresponding to a type and tried to serialise it. That means JAXB knows its content model, but not what the element name should be. You need to attach your RpcType to an element (JAXBElement), for example:
marshaller.marshal(new ObjectFactory().createRpc(myRpcType));
The ObjectFactory was placed into the package created by JAXB for you.
Advantages of Named Types
The advantage of a schema using global/named types is that child/sub types can be created that extend the parent type.
<xs:complexType name="rpcType">
<xs:sequence>
<xs:element ref="rpcOperation"/>
</xs:sequence>
<xs:attribute name="message-id" type="messageIdType" use="required"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:element name="rpc" type="rpcType"/>
The above fragment would allow the following child type to be created:
<xs:complexType name="myRPCType">
<xs:complexContent>
<xs:extension base="rpcType">
<xs:sequence>
<xs:element name="childProperty" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Impact on JAXB
Another aspect of named types is that they may be used by multiple elements:
<xs:element name="FOO" type="rpcType"/>
<xs:element name="BAR" type="rpcType"/>
This means that the schema to Java compiler cannot simply just pick one of the possible elements to be the #XmlRootElement for the class corresponding to "rpcType".