XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Guillaume VanhilleSubject: problem with deriving complex types by restriction. Validation problems
Author: Guillaume Vanhille
Date: 23 Mar 2005 05:39 AM
Good morning everyone,
I am writing a quite complex schema with many types derivated from other types and also several namespaces.

I have tried to derive one type by restriction in order to modify it or to add more constraints. I was working at the beginning with XML Spy 2004 rel.4 and everything seemed to look OK for it (even strange derivations that I thought impossible).
Just to have a comparison, i tried to validate my schema with topologi schematron validator and error messages appeared. What a nice surprise!<br>
To be sure I have installed a trial version of stylus studio and the same messages appeared.

file:///c:/Documents and Settings/Administrateur/guillaume/version 11-03/8583.xsd:1379,36: Recurse: There is not a complete functional mapping between the particles

I do not really understand what this means. Probably because of the limits of my English. I don't understand what the functionnal mapping problem is. Can somebody help me?
Even when I do a restriction without modifications with stylus editor, the validation fails.

But I have tried to validate with the other XML processors proposed by stylusstudio and not all of them generate a message error.
MSXML4.0 DOM is OK
.NET XML Parser generates a thousand errors
XSV 2.8 is OK

So who should I trust?

Thanks for your help. I am not desperate at this moment but by the end of the day I may be.

Giz'

Postnext
(Deleted User) 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


Postnext
Guillaume VanhilleSubject: Re: problem with deriving complex types by restriction. Validation problems
Author: Guillaume Vanhille
Date: 23 Mar 2005 09:04 AM
Well alberto,
thanks for your explanation. I have tried to read W3C specifications in order to have further information but they are a bit tough for my Schema level.

So here is some sample code

SCHEMA ELEMENT
<xs:schema targetNamespace="Books" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:root="Books" xmlns:ut="UsefulTypes">


BASE TYPE
<xs:complexType name="baseTypeDefinition">
<xs:annotation>
<xs:documentation>type to be redefined</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="pageNumber">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:maxInclusive value="127"/>
<xs:totalDigits value="3"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="content">
<xs:complexType>
<xs:sequence>
<xs:element name="something">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="([0-9A-Za-z][0-9A-Za-z]){1,127}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>

DERIVED TYPE
<xs:complexType name="derivedType">
<xs:complexContent>
<xs:restriction base="root:baseTypeDefinition">
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="pageNumber">
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:maxInclusive value="127"/>
<xs:totalDigits value="3"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="content">
<xs:complexType>
<xs:sequence>
<xs:element name="something">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="([0-9A-Za-z][0-9A-Za-z]){1,127}"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>

I have created the derived type with stylus: add new complex type, right click on it, quick edit by restriction and that's it.

I still have the error message: file:///c:/Documents and Settings/Administrateur/guillaume/debuggage/test8583.xsd:189,37: Recurse: There is not a complete functional mapping between the particles

Maybe you will see where the problem is. Maybe it comes from a namespace probleme, I have no idea.

Is the default validator in stylus more recommandable than MSXML4.0 ?

Thanks a lot
guillaume

Postnext
(Deleted User) 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

Posttop
Guillaume VanhilleSubject: Re: problem with deriving complex types by restriction. Validation problems
Author: Guillaume Vanhille
Date: 24 Mar 2005 04:46 AM
Thanks alberto,
using only global types was the solution! Now I will have some modifications to do on my schema :)

Thanks for helping me with your impressive schema knowledge. Maybe I will come back soon with some new topic!

Guillaume

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.