Hi Cédric, I may be missing something from your original query, but you can always use a schema as follows:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:ln="http://foo"; targetNamespace="http://foo";> <xs:element name="foo"> <xs:complexType> <xs:sequence> <xs:element name="bar" form="qualified" type="ln:barType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="barType"/> </xs:schema> (Note that the maxOccurs="unbounded" allows for you to have all the 'bar' elements you wish for.) What you -cannot- do is to have two 'bar' elements having different types within that context. For instance: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:ln="http://foo"; targetNamespace="http://foo";> <xs:element name="foo"> <xs:complexType> <xs:sequence> <xs:element name="bar" form="qualified" type="ln:barType" /> <xs:element name="bar" form="qualified" type="ln:zedType" /> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="barType"/> <xs:complexType name="zedType"/> </xs:schema> This latter schema fails an XML Schema rule: cos-element-consistent (2) http://www.w3.org/TR/xmlschema-1/#cos-element-consistent ----------------------------------- CITE ----------------------------------- If the {particles} contains, either directly, indirectly (that is, within the {particles} of a contained model group, recursively) or ·implicitly· two or more element declaration particles with the same {name} and {target namespace}, then all their type definitions must be the same top-level definition 1 all their {type definition}s must have a non-·absent· {name}. 2 all their {type definition}s must have the same {name}. <<----- this is what is breaking above 3 all their {type definition}s must have the same {target namespace}. ----------------------------------- CITE ----------------------------------- If you need separate types in a sequence, why not define a different element name? You could possibly amend your files by using an xpath on non-validated files, and then using a validator. <iteration operation="each"> <control space="file" value="^ </iteration> Or find a way of amalgamating your types into a single one! It's a bit hard to offer more of a solution without more detail. Although xml schema do have some weaknesses (for instance the inability to allow for mutually exclusive attributes within an element), I am a great fan. Likewise, although XercesC is not as ubiquitous as libxml, it's validation capabilities are particularly good. When paired with XQilla, which offers fantastic xpath capabilities, the libraries become especially useful for general xml processing. We use Obyx - a LAMP/REST aware document processing language that itself uses an xml syntax and provides the icing on the cake with a cherry on top. In Obyx, one could go through an entire fileset and replace second instances of 'bar' with something like the following (Though it doesn't test for adjacent BAR!) <iteration operation="each" xmlns="http://www.obyx.org"; note="replace foo/bar[2] elements with 'zed' "> <control space="file" value=".+\.xml" /> <body> <instruction note="load"> <output space="store" value="xmlinstance" /> <input space="file" context="field" value="#key" /> </instruction> <comparison operation="significant" note="only deal with necessary files"> <comparate space="store" value="xmlinstance#//foo/bar[2]" /> <ontrue> <iteration operation="repeat" note="for each instance of two bars in one foo"> <control space="store" value="xmlinstance#count(//foo/bar[2])" /> <body> <instruction note="get this iteration instance of bar/2"> <output space="store" value="bar_el" kind="text" /> <input space="store" context="field" value="xmlinstance#(//foo/bar[2])[#row]" /> </instruction> <mapping operation="substitute" note="replace second 'bar' with 'zed'. using text substitution"> <output space="store" context="field" value="xmlinstance#(//foo/bar[2])[#row]" kind="object" /> <domain space="store" value="bar_el" /> <match value="<zed " ><key value="<bar " /></match> </mapping> </body> </iteration> <instruction note="replace"> <output space="file" context="field" value="#key" /> <input space="store" value="xmlinstance" /> </instruction> </ontrue> </comparison> <s space="field" value="[done #key]" /> </body> </iteration> I hope something above helps! Ben. > Hi again, > > seems there is no problem. Seems my constructs are not > legal. You cannot put several "bar" with different types > the one after the other. > > So I guess I can't hardcore-validate my documents with > schemas. A big thanks to those who made XFDU and kids. > Space agencies of the world are, well, big like elephants. > A little bee like me has nothing to do but comply with > the rules of bureaucracy and XML stuff... > > C. > > ----- Original Message ----- >> From: "Cedric Roux" <s...@free.fr> >> To: c-users@xerces.apache.org >> Sent: Tuesday, May 29, 2012 6:19:55 PM >> Subject: problem with schema and complexType >> >> Hi Xerces, >> >> I have a problem. >> >> The following schema (work.xsd) "works": >> >> --------- >> <?xml version="1.0" encoding="UTF-8"?> >> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; >> xmlns:ln="http://foo"; >> targetNamespace="http://foo";> >> >> <xs:element name="foo"> >> <xs:complexType> >> <xs:sequence> >> <xs:element name="bar" form="qualified" type="ln:barType"> >> </xs:element> >> <xs:element name="bar" form="qualified" type="ln:barType"> >> </xs:element> >> </xs:sequence> >> </xs:complexType> >> </xs:element> >> >> <xs:complexType name="barType"/> >> >> </xs:schema> >> --------- >> >> Running "DOMPrint -n -s test-work.xml" with the following >> file (test-work.xml) produces good output. >> >> --------- >> <?xml version="1.0" encoding="UTF-8"?> >> >> <foo xmlns="http://foo"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://foo work.xsd" > >> <bar/> >> <bar/> >> </foo> >> --------- >> >> But the following schema (dont-work.xsd) does not "work". >> >> --------- >> <?xml version="1.0" encoding="UTF-8"?> >> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; >> xmlns:ln="http://foo"; >> targetNamespace="http://foo";> >> >> <xs:element name="foo"> >> <xs:complexType> >> <xs:sequence> >> <xs:element name="bar" form="qualified"> >> <xs:complexType /> >> </xs:element> >> <xs:element name="bar" form="qualified"> >> <xs:complexType /> >> </xs:element> >> </xs:sequence> >> </xs:complexType> >> </xs:element> >> >> <xs:complexType name="barType"/> >> >> </xs:schema> >> --------- >> >> With the following file (test-dont-work.xml) it fails >> with the error: >> Error at file "[...]/dont-work.xsd", line 12, column 47 >> Message: element 'bar' declared more than once in the same scope >> >> --------- >> <?xml version="1.0" encoding="UTF-8"?> >> >> <foo xmlns="http://foo"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://foo dont-work.xsd" > >> <bar/> >> <bar/> >> </foo> >> --------- >> >> On the other hand, the xmllint program from libxml is happy with >> both. >> >> The only difference between the two schemas is that the first one >> refers to a global empty complexType while the second schema embeds >> the complexType. >> >> Sorry for the vocabulary, this is all new to me. >> >> So what do I do wrong? Is xerces (3.1.1) correct here? >> (please, tell me it's a bug, my schemas are complex and >> I can't extract the complexType as I did for this tiny >> test case! I also need to put several elements the one >> after the other, in my real case attributes differ and >> many other little tiny details, I can't use minOccurs...). >> >> Regards, >> Cédric. >>
smime.p7s
Description: S/MIME cryptographic signature
