Cos-nonambig in xsd:choice group 'Unique Particle Attribution'

Question

Hello forum.
I've following XSD specification:
<?xml version="1.0" encoding="utf-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="data">
<xsd:complexType>
<xsd:choice>
<xsd:group ref="elem1" />
<xsd:group ref="elem2" />
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:group name="elem1">
<xsd:sequence>
<xsd:element name="order_no" type="order_no_type" />
<xsd:element name="someAttributeElem1">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:minLength value="1" />
<xsd:pattern value="[^|=]*" />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:group>
<xsd:group name="elem2">
<xsd:sequence>
<xsd:element name="order_no" type="order_no_type" />
<xsd:element name="someAttributeElem2" />
</xsd:sequence>
</xsd:group>
<xsd:simpleType name="order_no_type">
<xsd:restriction base="xsd:integer">
<xsd:totalDigits value="8" />
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
on
final SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
final Schema schema = factory.newSchema(xsd);
i get the following exception
org.xml.sax.SAXParseException: cos-nonambig: "":order_no and "":order_no (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
     at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:236)
     at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:172)
     at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:382)
     at com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.reportSchemaError(XSConstraints.java:315)
     at com.sun.org.apache.xerces.internal.impl.xs.XSConstraints.fullSchemaChecking(XSConstraints.java:463)
     at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:530)
     at com.sun.org.apache.xerces.internal.jaxp.validation.xs.SchemaFactoryImpl.newSchema(SchemaFactoryImpl.java:206)
     at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:489)
     at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:505)
Possibly this is related to the following bug?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4996456
So from my point of view reading the W3C Spec, in a choice the group is
distinct. So we should be able to use it like i did.
Is the an solution or workaround provided by JAVA init self or can anybody
tell me how to find an solution in an other JAVA library. I didn't work XML
validation that often, but in the past I did use some of the Apache
Frameworks. But as I can see in the error discription, Apache is already
involved.
Attention:
The original XSD is more complicatated and shared by different programms
in different Languages, C#, .Net, Navision. So, if there is no error in
the XSD which will be handled by the other frameworks less strict or
leniant, it will be complicated for to me to argue, that we have to change
the XSD so that we can handle it in Java.
TIA
Holger

Answer 1

Possibly this is related to the following bug?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4996456
Actually, as I read that bug (and I haven't gone back to the XSD spec to verify), it seems to say that the behavior you want is actually not valid -- the bug is that it would accept the choice with common first element and shouldn't have.
This seems to be the sort of lookahead problem that affects most grammars: you can't differentiate between two productions without reading one or more following symbols. Parser generators usually have a way to let you say "lookahead N tokens for this next production," but I don't believe XSD has anything like that. And I can't imagine that it would, as the structure of XML would require an essentially infinite lookahead.
But as I can see in the error discription, Apache is already involved.Yeah, the Sun JDK embeds Xerces and Xalan. To my knowledge, these two have pretty much taken over the Java parsing/transform space; there were some others (such as JDom), but they have pretty much been abandoned in terms of active development.
The original XSD is more complicatated and shared by different programms
in different Languages, C#, .Net, Navision. So, if there is no error in
the XSD which will be handled by the other frameworks less strict or
leniant, it will be complicated for to me to argue, that we have to change
the XSD so that we can handle it in Java.Well, you could simply point out that this is a case of Don't Repeat Yourself: if you have multiple complexTypes that share the same elements, that those elements should be extracted out into a common containing type.
But I think, if you read the spec carefully, you'll find that such structures are not permitted by XSD.