RE: UPA example

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).

Radu

On Tue, 2008-06-24 at 18:13 +0100, Michael Kay wrote:
> To add to that, in XML Schema 1.1 the UPA rule is relaxed so that if
> an element can match both an element particle or a wildcard particle,
> the element particle wins. So this schema will become valid.
>  
> Michael Kay
> http://www.saxonica.com/
> 
>         
>         ______________________________________________________________
>         From: xmlschema-dev-request@w3.org
>         [mailto:xmlschema-dev-request@w3.org] On Behalf Of Michael
>         Glavassevich
>         Sent: 24 June 2008 17:08
>         To: xmlschema-dev@w3.org
>         Subject: Re: UPA example
>         
>         
>         
>         Yes, it violates UPA. After the first occurrence of the
>         wildcard there would be a choice between the wildcard and
>         element particles and the two overlap in what they accept.
>         
>         Michael Glavassevich
>         XML Parser Development
>         IBM Toronto Lab
>         E-mail: mrglavas@ca.ibm.com
>         E-mail: mrglavas@apache.org
>         
>         boris@codesynthesis.com wrote on 06/24/2008 10:55:03 AM:
>         
>         > Hi,
>         > 
>         > Consider the following schema:
>         > 
>         > <schema xmlns="http://www.w3.org/2001/XMLSchema"
>         >    targetNamespace="test" 
>         >         elementFormDefault="qualified">
>         > 
>         >   <complexType name="AnyTargetNamespace">
>         >     <sequence maxOccurs="unbounded">
>         >       <element name="apple" type="string"/>
>         >       <any namespace="##targetNamespace"
>         processContents="skip" 
>         > maxOccurs="unbounded"/>
>         >     </sequence>
>         >   </complexType>
>         > 
>         > </schema>
>         > 
>         > My interpretation of the specification suggests that this
>         schema
>         > violates the Unique Particle Attribution constraint in that
>         a
>         > content like this:
>         > 
>         > <apple/>
>         > <apple/>
>         > <apple/>
>         > 
>         > Can be validated in two ways:
>         > 
>         > <apple/> validated by element
>         > <apple/> validated by any
>         > <apple/> validated by any
>         > 
>         > Or:
>         > 
>         > <apple/> validated by element
>         > <apple/> validated by any
>         > <apple/> validated by element
>         > 
>         > Does anybody think this is not the case and if so, why?
>         > 
>         > Thanks,
>         > Boris
>         > 
>         > -- 
>         > Boris Kolpackov, Code Synthesis Tools
>         http://codesynthesis.com/~boris/blog
>         > Open source XML data binding for C++:
>         http://codesynthesis.com/products/xsd
>         > Mobile/embedded validating XML parsing:
>         http://codesynthesis.com/products/xsde
>         
>         
> 
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the
> individual or entity named in this message. If you are not the
> intended recipient, and have received this message in error, please
> immediately return this by email and then delete it.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Received on Tuesday, 24 June 2008 19:30:08 UTC