This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4952 - Sequence:Sequence Restriction (Recurse)
Summary: Sequence:Sequence Restriction (Recurse)
Status: NEW
Alias: None
Product: XML Schema Test Suite
Classification: Unclassified
Component: Microsoft tests (show other bugs)
Version: 2006-11-06
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Henry S. Thompson
QA Contact: XML Schema Test Suite mailing list
URL:
Whiteboard:
Keywords: disputedTest
Depends on:
Blocks:
 
Reported: 2007-08-15 13:11 UTC by Michael Chan
Modified: 2010-03-26 15:43 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Chan 2007-08-15 13:11:31 UTC
The schema has base particle of sequence restricted to a derived particle of sequence.  Within the restricted sequence, the particles are not valid restrictions with the corresponding particles in the base type.  However, the spec says, "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)."

Since the particles are not valid restrictions, the scenario used should be scenario that checks invalidity

testcase affected: msData/particles/particlesW006.xsd
Comment 1 Michael Kay 2007-08-18 21:28:32 UTC
Personal response.

In my view this is a case where the bug is in the spec, not in the test. This is an example of a situation where all instances of R are in fact valid instances of B (because of the maxOccurs="0"), but the algorithm in the spec fails to recognize the fact. In Schema 1.1 this will be a valid restriction. I don't think there is really much to be gained at this stage in testing conformance of products to rules that are known to be deficient. Nor is there much to be gained by patching up the Schema 1.0 rules.
Comment 2 Henry S. Thompson 2010-02-04 14:03:09 UTC
Even if Mike's analysis is right, this should be changed to invalid, and some 
of us (e.g. XSV) will get it wrong
Comment 3 David Ezell 2010-03-26 15:43:40 UTC
The WG believes this test is wrong for 1.0, but that behavior is less than desirable.  A new test, properly defined, is required for 1.1.