|
next
|
Subject: Re: problem with deriving complex types by restriction. Validation problems Author: (Deleted User) Date: 23 Mar 2005 06:39 AM
|
Hi Guillaume,
as you have just experienced, the XMLSchema specs are very complex; so you
can find schema validators enforcing a limited range of rules, and even
validators interpreting the same rules in different ways.
BTW, this is the reason why we bundle several validators with Stylus, and
let the user plug in the one they need to use in their deployment scenario.
Coming to the error "Recurse: There is not a complete functional mapping
between the particles" given by the default validator for Stylus (that is
Xerces-C++ 2.6), it is taken directly from the XMLSchema specs: § 3.9.6
Constraints on Particle Schema Components.
In that section there is a grid showing the rules to be applied when trying
to match the composition of the base type with the composition of the
derived type; the "Recurse" word specified in the error message tells me
that you are deriving from a base type that has a composition of xs:all or
xs:sequence.
The definition of the "Recurse" rule is here:
http://www.w3.org/TR/xmlschema-1/#rcase-Recurse.
The second point of the rule says:
"2) There is a complete order-preserving functional mapping from the
particles
in the {particles} of R to the particles in the {particles} of B such that
all
of the following must be true:
2.1 Each particle in the {particles} of R is a valid restriction of the
particle in the {particles} of B it maps to as defined by Particle
Valid
(Restriction) ( 3.9.6).
2.2 All particles in the {particles} of B which are not mapped to by any
particle in the {particles} of R are emptiable as defined by Particle
Emptiable ( 3.9.6).
"
In less formal words, if you have a base type that is defined as a sequence
of elements A, B and C, a valid restriction is a definition that has a
sequence of elements D, E and F where D is a restriction of A, E is a
restriction of B and F is a restriction of C. Another valid case is when
you have a sequence of A, an optional B and a C; in this case a valid
restriction would be D, F (because B can be empty).
Hope this helps; if you need a more specific description, please post the
type definitions that are involved with the error.
Alberto
|
next
|
Subject: Re: problem with deriving complex types by restriction. Validation problems Author: (Deleted User) Date: 23 Mar 2005 01:13 PM
|
Hi Guillaume,
the base type you have defined makes use of anonymous types in order to
define the "pageNumber" and "content" elements:
<xs:complexType name="baseTypeDefinition">
<xs:sequence>
[..]
<xs:element name="pageNumber">
<xs:simpleType>
[...]
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
This hits one of the under-defined areas of XMLSchema: whether two
anonymous types (the one in the base type and the one in the derived
type) must be considered to be "identical" if they are made of the same
components.
In the second edition of the specs the W3C realized this, and added this
comment:
"The wording of clause 2.1 [of the paragraph <Schema Component
Constraint: Type Derivation OK (Complex)>] above appeals to a notion
of component identity which is only incompletely defined by this version
of this specification. In some cases, the wording of this specification
does make clear the rules for component identity. These cases include:
* When they are both top-level components with the same component
type, namespace name, and local name;
* When they are necessarily the same type definition (for example,
when the two types definitions in question are the type definitions
associated with two attribute or element declarations, which are
discovered to be the same declaration);
* When they are the same by construction (for example, when an
element's type definition defaults to being the same type definition
as that of its substitution-group head or when a complex type definition
inherits an attribute declaration from its base type definition).
In other cases two conforming implementations may disagree as to
whether components are identical."
To be sure that your schema can be considered valid by all the
validators you should replace the anonymous types with references to
global types.
>Is the default validator in stylus more recommandable than MSXML4.0 ?
There is not much literature on the conformance level of the available
validators: some lists their limitations (like XSV), but others are
less detailed. And the absence of a complete test suite doesn't help.
So my suggestion is that you should try to process your schema using
the processor that you know your customer will use: Xerces-J, MS .NET,
Xerces-C++. And try to avoid using sofisticated constructs.
Hope this helps,
Alberto
|
|
|
|