Anton Krouglov
Anton Krouglov

Reputation: 3409

How to check whether xsd schema is valid itself with a tool?

I wounder how to build up some reference proof telling schema valid or not. I have a dispute with a contractor. They use one tool, I am using other tools. They say schema valid, while I disagree. Googling yields almost nothing as everybody looks for xml validating. I need to validate the schema itself.

For instance consider this fragment (s0 is a default namespace):

<s:complexType name="PairOfIDCols">
    <s:complexContent>
        <s:extension base="s0:Cols">
            <s:attribute name="ID" type="s:string" use="required"/>
        </s:extension>
    </s:complexContent>
</s:complexType>
<s:complexType name="Cols">
    <s:sequence>
        <s:element name="Row" type="s0:PairOfNRows" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
    </s:sequence>
    <s:attribute name="ID" type="s:string"/>
    <s:attribute name="Name" type="s:string"/>
    <s:attribute name="Visible" type="s:boolean"/>
</s:complexType>

Is it valid part of schema? If it is not - which w3c schema definition it violates?

Upvotes: 2

Views: 3002

Answers (1)

Michael Kay
Michael Kay

Reputation: 163595

There is no definitive W3C-approved tool that will answer the question for you. You basically need to look at the errors being reported by a particular tool and compare them with the spec - which isn't easy, because the XSD specification is very tough reading. And of course, even when you get agreement that one tool is wrong, you have to decide what to do about it: abandoning use of that tool isn't always a practical option. Unfortunately with XSD there are quite a few deviations between tools (which is partly because the spec is such tough reading.... For those who believe in formal specification, I personally think readable specification is much more important.)

The particular issue here is, can a type R that is derived by extension from another type B contain a definition of an attribute that is already defined in B?

It's useful to know that there are three sets of rules a schema must satisfy to be valid:

(a) the schema-for-schema-documents defines the basic grammatical structure of elements and attributes in a schema document

(b) the constraints on the XML representation of a schema define additional rules for the XML representation that can't be conveniently expressed in the S4SD

(c) the constraints on the schema component model define rules that apply to the schema components constructed from the XML.

One of these rules in this case is in §3.4.6 Schema Component Constraint: Complex Type Definition Properties Correct; rule 4 says "Two distinct attribute declarations in the {attribute uses} must not have identical {name}s and {target namespace}s."

To work out whether this rule is violated we need to see how the {attribute uses} property is computed. This is given in §3.4.2:

{attribute uses}:   A union of sets of attribute uses as follows:
1 The set of attribute uses corresponding to the <attribute> [children], if any....

3 The {attribute uses} of the type definition ·resolved· to by the ·actual value· of the base [attribute]

This set clearly contains two attributes with the same name, which violates the constraint; UNLESS you interpret the term "union" as forming a set in which the duplicates have already been eliminated. A union operation eliminates members if they are identical. This then leads you into an infamous gap which the spec itself acknowledges in §3.4.6: "... a notion of component identity which is only incompletely defined by this version of this specification...."

In this case however the two attribute uses cannot be identical. One of the properties of an attribute use is the corresponding attribute declaration (a local <xs:attribute> like these two generates both an attribute declaration and an attribute use). One of the properties of an attribute declaration is its {scope}, which is essentially the containing complex type. These two attribute declarations have different {scope}, therefore they are distinct, therefore the two attribute uses have different {attribute declaration} properties, therefore the attribute uses are distinct, therefore the union includes both, therefore the schema is invalid.

Upvotes: 4

Related Questions