Eric van der Vlist wrote: > Xsdvalid considers (against other implementations including Xerces2 and > IBM SQC) that the following schema is invalid: > > <?xml version="1.0" encoding="UTF-8"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";> > <xs:element name="foo"> > <xs:complexType> > <xs:sequence> > <xs:element name="bar" type="xs:token"/> > <xs:element name="bar" type="xs:token" nillable="true"/> > </xs:sequence> > </xs:complexType> > </xs:element> > </xs:schema> > > and says: > > > repro.xsd:E:7:16: d?claration d'?l?ment "bar" incoh?rente > [cos-element-consistent] > > The rec says: > > > Schema Component Constraint: Element Declarations Consistent > 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, that is, all of the following must be > true: > 1 all their {type definition}s must have a non-?absent? {name}. > 2 all their {type definition}s must have the same {name}. > 3 all their {type definition}s must have the same {target namespace}. > > And lists type definitions are properties of element declarations at the > same level as the nillable property. > > My interpretation is thus that you shouldn't raise a > cos-element-consistent error when the types are the same and the > nillable attribute is different.
You are right and removing this error message would be easy to do. The big problem is that xsdvalid/XXE cannot detect this instance as being valid: --- <foo> <bar>my token</bar> <bar xsi:nil="true"/> </foo> --- and, at the same time, detect this other instance as being invalid: --- <foo> <bar xsi:nil="true"/> <bar>my token</bar> </foo> --- For xsdvalid/XXE, <foo> elements can contain <bar> child elements and a *single content model* is allowed for all these <bar> child elements. For xsdvalid/XXE, --- type="xs:token" --- and --- type="xs:token" nillable="true" --- clearly specifies two different *content models*. The only sensible thing we can do is to document this behavior as being a limitation of xsdvalid/XXE (well, we could also completely rewrite our WXS validation engine but we currently do not plan to do that :-)). See also other limitations of xsdvalid/XXE: http://www.xmlmind.com/xmleditor/_distrib/docs/xsdvalid/xsdvalid.html#id.s6.2
