Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Determinization in case of ambiguity or Should XML validators report on schemas that violate the UPA constraint?

From: "Michael Kay" <mike@--------.--->
To: "'Shlomo Yona'" <S.Yona@--.--->, <xmlschema-dev@--.--->
Date: 4/17/2007 12:49:00 AM
Once I fix your typographical quotation marks to turn them into ASCII
quotation marks, Saxon reports:
 
Error at xsd:schema on line 1 of file:/c:/temp/test.xsd:
  The zero-length string is not a legal namespace URI
Error at xsd:element on line 11 of file:/c:/temp/test.xsd:
  Cannot reference schema components in namespace foo as it has not been
imported
  (more of the same)
Error at xsd:all on line 25 of file:/c:/temp/test.xsd:
  Element <xsd:all> is not allowed as a child of <xsd:sequence>
Error at xsd:all on line 25 of file:/c:/temp/test.xsd:
  Within <xs:all>, an <xs:element> must have @maxOccurs equal to 0 or 1
Error at xsd:all on line 25 of file:/c:/temp/test.xsd:
  Within <xs:all>, an <xs:element> must have @maxOccurs equal to 0 or 1
 
When I fix these problems Saxon actually reports both your schema and the
instance as valid. This is because Saxon doesn't detect a UPA in the
situation where you have two element particles that both refer to the same
element declaration - if Saxon can determine unambiguously which element
declaration an element refers to, it doesn't report any ambiguity. A known
minor departure from the spec.
 
Michael Kay
http://www.saxonica.com/


  _____  

From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...] On
Behalf Of Shlomo Yona
Sent: 16 April 2007 08:57
To: xmlschema-dev@w...
Subject: Determinization in case of ambiguity or Should XML validators
report on schemas that violate the UPA constraint?



Hello,

 

In the following example schema the element <b/> can appear either as part
of a sequence model group or as part of a choice model group or as an all
model group.

This means that the instance does not follow the Unique Particle Attribution
Constraint (see: "Section 3.8.6: Constraints on Model Group Schema
Components " and Appendix H in "XML Schema Part 1: Structures Second
Edition, W3C Proposed Edited Recommendation").

 

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace=""
xmlns="foo">

            <xsd:element name="a">

                        <xsd:complexType>

                                    <xsd:sequence minOccurs="0"
maxOccurs="2">

                                                <xsd:sequence minOccurs="0"
maxOccurs="2">

                                                            <xsd:element
ref="b" minOccurs="0" maxOccurs="2"/>

                                                            <xsd:element
ref="c" minOccurs="0" maxOccurs="2"/>

                                                </xsd:sequence>

                                                <xsd:choice minOccurs="0"
maxOccurs="2">

                                                            <xsd:element
ref="b" minOccurs="0" maxOccurs="2"/>

                                                            <xsd:element
ref="d" minOccurs="0" maxOccurs="2"/>

                                                </xsd:choice>

                                                <xsd:all minOccurs="0"
maxOccurs="1">

                                                            <xsd:element
ref="e" minOccurs="0" maxOccurs="2"/>

                                                            <xsd:element
ref="b" minOccurs="0" maxOccurs="2"/>

                                                </xsd:all>


                                    </xsd:sequence>

                        </xsd:complexType>

            </xsd:element>

            <xsd:element name="b">

                        <xsd:complexType/>

            </xsd:element>

            <xsd:element name="c">

                        <xsd:complexType/>

            </xsd:element>

            <xsd:element name="d">

                        <xsd:complexType/>

            </xsd:element>

            <xsd:element name="e">

                        <xsd:complexType/>

            </xsd:element>

</xsd:schema>

 

 

My question is: should the following example be valid against the schema or
not valid?

 

<a>

   <b/><c/><b/>

</a>

 

 

I see that different XML validators behave differently on this example.
However, I did not see them report an error in the schema.

 

Now, please consider the following schema:

 

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="bar" xmlns="foo">

            <xsd:element name="a">

                        <xsd:complexType>

                                    <xsd:sequence>

                                                <xsd:sequence minOccurs="0">

                                                            <xsd:element
name="b">

 
<xsd:complexType/>

                                                            </xsd:element>

                                                </xsd:sequence>

                                    </xsd:sequence>

                        </xsd:complexType>

            </xsd:element>

</xsd:schema>  

 

Instance:

 

<a/>

 

Is it valid?

 

 

See, the element b might not appear and that's OK if you ask the inner
sequence but the outer sequence needs to "happen" once (the minOccurs="1" is
implied).

 

So, how should I read this? Is the above single <a/> element instance valid
or not with this schema? Is such a schema legal or not? If the schema is not
legal, must a schema processor report an error?

 

Thanks.

 

Shlomo.

 



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent