- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Tue, 1 Jul 2008 13:58:45 -0600
- To: Boris Kolpackov <boris@codesynthesis.com>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>, xmlschema-dev@w3.org
On 25 Jun 2008, at 01:59 , Boris Kolpackov wrote: > ... > Radu Preotiuc-Pietro <radup@bea.com> writes: > >> Maybe it's also interesting to mention that, while in XML Schema >> 1.1 the >> Schema becomes valid, the instance >> >> <apple/> >> <apple/> >> <apple/> >> >> won't be valid still (based on my understanding, the third <apple/> >> element will map to the element particle and the validator will >> still be >> waiting for an element to map to the wildcard). > > Yes, I also think it won't be valid unless the parser in 1.1 is > expected > to do backtracking. I am also wondering if the authors of this > change to > the spec considered how hard it will be to explain something like this > to a user. Speaking for myself, yes, but in this case I am not entirely certain what aspects of the example are important for 'something like this'. I think explaining things to users would be somewhat simpler if we lost the Unique Particle Attribution rule entirely, but I have not succeeded in persuading the rest of the working group. As regards this particular example, though, I may be missing something; it doesn't seem to me hard to explain that when you have a content model which 1 allows an infinite number of repetitions of subsequences 2 starts a new subsequence each time an 'apple' element would be the third element, or later, in a subsequence 3 requires each subsequence to have two or more elements then a sequence of three 'apple' elements is not valid. If the user is surprised by the fact that some apple elements match the wildcard, not the element declaration, then perhaps the wildcard is overbroad and should exclude 'apple'? If the user is surprised by the fact that the wildcard does not capture all 'apple' elements after the first, then perhaps the outer sequence ought not to be repeatable? --Michael Sperberg-McQueen World Wide Web Consortium / MIT CSAIL
Received on Tuesday, 1 July 2008 19:59:21 UTC