You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Thomson, Martin" <Ma...@andrew.com> on 2010/09/23 03:22:56 UTC
Simple nested restriction
I'm trying to understand why Xerces is rejecting what appears to be a simple restriction.
The base type permits either of A,B or A,C,D; the restricting types simply remove the choice:
Base = (A,(B|(C,D)))
i. Restriction = (A,B) -- OK
ii. Restriction = (A,C,D) -- Not OK
iii. Restriction = (A,(C,D)) -- Not OK
iv. Restriction = (A,((C,D)|)) -- Not OK
As the last two examples show, mimicking the structure of the base type with choices and sequences is too easily collapsed this to bluff it.
I get the impression that this is related to MapAndSum [1]. From my uneducated reading, it seems like MapAndSum never considered the simple case where the sequence mapped entirely to one of the particles of the choice.
XSV [2] accepts all four forms.
I can see how this might be viewed as a valid interpretation of the specification, but it's a real nuisance. Should I raise a bug report on this?
Cheers,
Martin
[1] http://www.w3.org/TR/xmlschema-1/#rcase-MapAndSum
[2] http://www.w3.org/2001/03/webdata/xsv
RE: Simple nested restriction
Posted by "Thomson, Martin" <Ma...@andrew.com>.
Thanks Sandy,
I'm glad that schema 1.1 is going to fix this. MapAndSum doesn't really achieve what it's intended for.
Even if I fool the "remove pointless particles" process by adding minOccurs/maxOccurs, this case doesn't get handled properly:
Base = (A|(B,C){2})
Restriction = (B,C){2}
I'll be eagerly awaiting the 1.1 version :)
--Martin
p.s. FYI, "[Error] foo.xsd:184:30: rcase-MapAndSum.2: Group's occurrence range, (4,4), is not a valid restriction of base group's occurrence range, (1,1)." Note that the reported number is double, thanks again to MapAndSum.
On 2010-09-24 at 03:28:56, Sandy Gao wrote:
> Martin,
>
> Xerces is doing what the schema 1.0 spec requires. It's the "remove
> pointless particles" that's causing the problem. See clause 2.2 of [1].
>
> So after the removal process, (ii) to (iv) all become (A,C,D). Now the
> base has a sequence of 2 items but the restriction has 3 items.
>
> This does look strange, which is why in schema 1.1 [2], the 5x5 table
> is
> replaced by a rule similar to "as long as the restriction doesn't allow
> more than the base".
>
> XSV accepts the schema docs because it's been updated to use the 1.1
> rules for particle restriction. In Xerces we are working on
> implementing
> schema 1.1, on a branch. The new particle restriction rules are not
> available yet.
>
> [1]
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-particle-
> restric
> t
> [2] http://www.w3.org/TR/xmlschema11-1/
>
> Thanks,
> Sandy Gao
> XML Technologies, IBM Canada
> Editor, W3C XML Schema WG <http://www.w3.org/XML/Schema>
> (1-905) 413-3255 T/L 313-3255
>
> From:
> "Thomson, Martin" <Ma...@andrew.com>
>
> To:
> "xerces-j-dev@xml.apache.org" <xe...@xml.apache.org>
>
> Date:
> 2010-09-23 12:19 AM
>
> Subject:
> Simple nested restriction
> ________________________________
>
>
>
>
> I'm trying to understand why Xerces is rejecting what appears to be a
> simple restriction.
>
> The base type permits either of A,B or A,C,D; the restricting types
> simply remove the choice:
>
> Base = (A,(B|(C,D)))
> i. Restriction = (A,B) -- OK
> ii. Restriction = (A,C,D) -- Not OK
> iii. Restriction = (A,(C,D)) -- Not OK
> iv. Restriction = (A,((C,D)|)) -- Not OK
>
> As the last two examples show, mimicking the structure of the base type
> with choices and sequences is too easily collapsed this to bluff it.
>
> I get the impression that this is related to MapAndSum [1]. From my
> uneducated reading, it seems like MapAndSum never considered the simple
> case where the sequence mapped entirely to one of the particles of the
> choice.
>
> XSV [2] accepts all four forms.
>
> I can see how this might be viewed as a valid interpretation of the
> specification, but it's a real nuisance. Should I raise a bug report
> on
> this?
>
> Cheers,
> Martin
>
> [1] http://www.w3.org/TR/xmlschema-1/#rcase-MapAndSum
> [2] http://www.w3.org/2001/03/webdata/xsv
>
Re: Simple nested restriction
Posted by Sandy Gao <sa...@ca.ibm.com>.
Martin,
Xerces is doing what the schema 1.0 spec requires. It's the "remove
pointless particles" that's causing the problem. See clause 2.2 of [1].
So after the removal process, (ii) to (iv) all become (A,C,D). Now the base
has a sequence of 2 items but the restriction has 3 items.
This does look strange, which is why in schema 1.1 [2], the 5x5 table is
replaced by a rule similar to "as long as the restriction doesn't allow
more than the base".
XSV accepts the schema docs because it's been updated to use the 1.1 rules
for particle restriction. In Xerces we are working on implementing schema
1.1, on a branch. The new particle restriction rules are not available yet.
[1]
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-particle-restrict
[2] http://www.w3.org/TR/xmlschema11-1/
Thanks,
Sandy Gao
XML Technologies, IBM Canada
Editor, W3C XML Schema WG.
(1-905) 413-3255 T/L 313-3255
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|"Thomson, Martin" <Ma...@andrew.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|"xerces-j-dev@xml.apache.org" <xe...@xml.apache.org> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|2010-09-23 12:19 AM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Simple nested restriction |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
I'm trying to understand why Xerces is rejecting what appears to be a
simple restriction.
The base type permits either of A,B or A,C,D; the restricting types simply
remove the choice:
Base = (A,(B|(C,D)))
i. Restriction = (A,B) -- OK
ii. Restriction = (A,C,D) -- Not OK
iii. Restriction = (A,(C,D)) -- Not OK
iv. Restriction = (A,((C,D)|)) -- Not OK
As the last two examples show, mimicking the structure of the base type
with choices and sequences is too easily collapsed this to bluff it.
I get the impression that this is related to MapAndSum [1]. From my
uneducated reading, it seems like MapAndSum never considered the simple
case where the sequence mapped entirely to one of the particles of the
choice.
XSV [2] accepts all four forms.
I can see how this might be viewed as a valid interpretation of the
specification, but it's a real nuisance. Should I raise a bug report on
this?
Cheers,
Martin
[1] http://www.w3.org/TR/xmlschema-1/#rcase-MapAndSum
[2] http://www.w3.org/2001/03/webdata/xsv
Re: Simple nested restriction
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Martin,
"Thomson, Martin" <Ma...@andrew.com> wrote on 09/22/2010 09:22:56
PM:
> I'm trying to understand why Xerces is rejecting what appears to be
> a simple restriction.
>
> The base type permits either of A,B or A,C,D; the restricting types
> simply remove the choice:
>
> Base = (A,(B|(C,D)))
> i. Restriction = (A,B) -- OK
> ii. Restriction = (A,C,D) -- Not OK
> iii. Restriction = (A,(C,D)) -- Not OK
> iv. Restriction = (A,((C,D)|)) -- Not OK
>
> As the last two examples show, mimicking the structure of the base
> type with choices and sequences is too easily collapsed this to bluff it.
>
> I get the impression that this is related to MapAndSum [1]. From my
> uneducated reading, it seems like MapAndSum never considered the
> simple case where the sequence mapped entirely to one of the
> particles of the choice.
>
> XSV [2] accepts all four forms.
>
> I can see how this might be viewed as a valid interpretation of the
> specification, but it's a real nuisance. Should I raise a bug report on
this?
If Xerces is doing what the XML Schema 1.0 specification says then by
definition it's working as designed and therefore not a bug. XSV [3] may
not be following all the rules.
XML Schema 1.1 is defining more sensible restriction rules so what you're
trying to do should probably work with Xerces' XML Schema 1.1 processor
once we implement that part of the 1.1 spec.
> Cheers,
> Martin
>
> [1] http://www.w3.org/TR/xmlschema-1/#rcase-MapAndSum
> [2] http://www.w3.org/2001/03/webdata/xsv
Thanks.
[3] http://lists.w3.org/Archives/Public/xmlschema-dev/2001Nov/0132.html
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Re: Simple nested restriction
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Martin,
"Thomson, Martin" <Ma...@andrew.com> wrote on 09/22/2010 09:22:56
PM:
> I'm trying to understand why Xerces is rejecting what appears to be
> a simple restriction.
>
> The base type permits either of A,B or A,C,D; the restricting types
> simply remove the choice:
>
> Base = (A,(B|(C,D)))
> i. Restriction = (A,B) -- OK
> ii. Restriction = (A,C,D) -- Not OK
> iii. Restriction = (A,(C,D)) -- Not OK
> iv. Restriction = (A,((C,D)|)) -- Not OK
>
> As the last two examples show, mimicking the structure of the base
> type with choices and sequences is too easily collapsed this to bluff it.
>
> I get the impression that this is related to MapAndSum [1]. From my
> uneducated reading, it seems like MapAndSum never considered the
> simple case where the sequence mapped entirely to one of the
> particles of the choice.
>
> XSV [2] accepts all four forms.
>
> I can see how this might be viewed as a valid interpretation of the
> specification, but it's a real nuisance. Should I raise a bug report on
this?
If Xerces is doing what the XML Schema 1.0 specification says then by
definition it's working as designed and therefore not a bug. XSV [3] may
not be following all the rules.
XML Schema 1.1 is defining more sensible restriction rules so what you're
trying to do should probably work with Xerces' XML Schema 1.1 processor
once we implement that part of the 1.1 spec.
> Cheers,
> Martin
>
> [1] http://www.w3.org/TR/xmlschema-1/#rcase-MapAndSum
> [2] http://www.w3.org/2001/03/webdata/xsv
Thanks.
[3] http://lists.w3.org/Archives/Public/xmlschema-dev/2001Nov/0132.html
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org