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
Conferences Close Tree View
+ Stylus Studio Feature Requests (1192)
- Stylus Studio Technical Forum (14621)
-> - Stylus Studio - Registrar en o... (1)
-> + Stylus Studio - Registrar en o... (2)
-> + Can a pipeline send a file by ... (2)
-> + After Updateing WIN10 to WIN11... (12)
-> + Where do I add the custom java... (3)
-> + Where is the Diagram tab? (5)
-> + Applying XSLT to Word DOCX/XML (2)
-> - CSV conversion via ConvertToXM... (1)
-> + Text symbols in SS not same as... (4)
-> + Exposing xquery as webservice ... (6)
-> + Syntax Identifier (2)
-> + Saving a Converted XML as an X... (5)
-> + Output document cannot be pars... (4)
-> - Archiving output from conversi... (1)
-> + EDIFACT guideline from Stylus ... (3)
-> + CSV file putting all the data ... (5)
-> + Can't install Home version 64b... (5)
-> + presale - Can I covers this sc... (5)
-> + Problem with UNB (5)
-> + Splitting EDIFACT files pipeli... (4)
-- [1-20] [21-40] [41-60] Next
+ Website Feedback (249)
+ XSLT Help and Discussion (7625)
+ XQuery Help and Discussion (2015)
+ Stylus Studio FAQs (159)
+ Stylus Studio Code Samples & Utilities (364)
+ Stylus Studio Announcements (113)
Simon  CoxSubject: Type restrictions involving element substitution groups - validator inconsistencies
Author: Simon Cox
Date: 29 Sep 2004 10:49 AM
Originally Posted: 29 Sep 2004 10:32 AM
Derivation-by-restriction is an area of great inconsistency between XML Schema validation engines. Attached are a set of example schemas and matching instance documents that attempt to establish substitution-group chains. Elements down the chain have a content model derived by restriction from a parent type, in which the specific restriction is to select one member of a substitution group whose head is the content of the parent type. I find the following inconsistent validator behaviour 1. Stylus Studio's built-in validator doesn't like any of them 2. XSV and .NET find all of them OK 3. Xerces-J thinks rT1.xml is OK, but rejects rT2.xml and rT3.xml on similar grounds "There is not a complete functional mapping between the particles. The particle of the type is not a valid restriction of the particle of the base." In the restrictionTest2.xsd case the issue appears to concern an inconsisent interpretation of xs:anyType and derivations therefrom. In the restrictionTest3.xsd case the issue concerns the position of maxOccurs attributes (compare with restrictionTest1.xsd which passes). This all may seem arcane, but these patterns are representative of a specific mapping used to convert UML models to XML in a major project that is on its way to ISO status. If anyone has any insights, they would be gratefully received. Simon Cox







(Deleted User) Subject: Type restrictions involving element substitution groups - validator inconsistencies
Author: (Deleted User)
Date: 30 Sep 2004 05:38 AM
Hi Simon,
to add more material to your analisys, the Schema Quality Checker
from IBM only finds the third schema as invalid (you can download it
from http://www.alphaworks.ibm.com/tech/xmlsqc)

Speaking of the built-in validator (that is Xerces-C++ 2.5), it seems
to me that it doesn't perform one of the steps of the validation by
restriction, the one that should replace any element with a choice
between the components of the substitution group. I am opening a bug
on the Xerces-C++ bug tracker to let them know of this limitation.

Thanks for the nice testcase,


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!  

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.