Re: UPA Question

Hi Erik,

No, as you describe it it seems you understood the content model as
     <xs:sequence>
       <xs:choice>
         <xs:sequence>  <!-- note the sequence instead of choice -->
           <xs:element name="ElementB1" />
           <xs:element name="ElementA1"/>      <!-- (1) -->
         </xs:sequence>
         <xs:element name="ElementA1"/>        <!-- (2) -->
       </xs:choice>
     </xs:sequence>

In that case there is no ambiguity, but otherwise there is not 
requirement for ElementB1 to be present.

Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com


Erik Johnson wrote:
>>  Now when parser sees ElementA1 inside ElementC1 it has to ways of
> 
>>  associating a schema declarations to ElementA1: it can be ElementA1
> 
>>  from line (1) or it can be ElementA1 from line (2). Thus this schema
> 
>>  is ambiguous.
> 
>  
> 
> Thanks Boris (and George), this is very helpful.  Sure enough, when I 
> try the “syntactic-sugar-free” example, both toolkits report a UPA 
> violation.  Maybe one just can’t navigate the groups. 
> 
>  
> 
> But I have one more general question about schema validation: 
> 
>  
> 
> Isn’t the idea behind UPA to make sure that validators do not have to 
> “look ahead” to determine which particle the current node belongs to?  
> Given our schema (shown below), let’s say the validator is at ElementC1 
> and moves to the next node.  If that next node is ElementB1 we know we 
> are in the choice() particle containing ElementB1-ElementA1.  But if the 
> node after ElementC1 is ElementA1, we know we took the other choice() 
> route.  That doesn’t seem ambiguous to me because the first choice() 
> mandates the presence of ElementB1.  But if ElementB1 was declared with 
> minOccurs=0, that **would** be an ambiguous construct because the 
> validator wouldn’t know which particle it’s landed in when it sees an 
> ElementA1.  Am I over-thinking all this?
> 
>  
> 
> <xs:element name="ElementC1">
> 
>   <xs:complexType>
> 
>     <xs:sequence>
> 
>       <xs:choice>
> 
>         <xs:choice>
> 
>           <xs:element name="ElementB1" />
> 
>           <xs:element name="ElementA1"/>      <!-- (1) -->
> 
>         </xs:choice>
> 
>         <xs:element name="ElementA1"/>        <!-- (2) -->
> 
>       </xs:choice>
> 
>     </xs:sequence>
> 
>   </xs:complexType>
> 
> </xs:element>
> 
> 
> ------------------------------------------------------------------------
> *From:* Boris Kolpackov [mailto:boris@codesynthesis.com]
> *Sent:* Mon 11/27/2006 10:03 PM
> *To:* Erik Johnson
> *Cc:* xmlschema-dev@w3.org
> *Subject:* Re: UPA Question
> 
> Hi Erik,
> 
> Erik Johnson <ejohnson@epicor.com> writes:
> 
> 
>  > But after thinking about it, I don't think that the content model is
>  > ambiguous.
> 
> It helps to remove all the syntactic sugar to the see the problem clearly:
> 
> 
> <xs:element name="ElementC1">
>   <xs:complexType>
>     <xs:sequence>
>       <xs:choice>
>         <xs:choice>
>           <xs:element name="ElementB1" />
>           <xs:sequence>
>             <xs:element name="ElementA1"/>
>           </xs:sequence>
>         </xs:choice>
>         <xs:sequence>
>           <xs:element name="ElementA1"/>
>         </xs:sequence>
>       </xs:choice>
>     </xs:sequence>
>   </xs:complexType>
> </xs:element>
> 
> We can further simplify this schema fragment by replacing
> 
> <xs:sequence>
>   <xs:element name="ElementA1"/>
> </xs:sequence>
> 
> with just
> 
> <xs:element name="ElementA1"/>
> 
> which gives us:
> 
> 
> <xs:element name="ElementC1">
>   <xs:complexType>
>     <xs:sequence>
>       <xs:choice>
>         <xs:choice>
>           <xs:element name="ElementB1" />
>           <xs:element name="ElementA1"/>      <!-- (1) -->
>         </xs:choice>
>         <xs:element name="ElementA1"/>        <!-- (2) -->
>       </xs:choice>
>     </xs:sequence>
>   </xs:complexType>
> </xs:element>
> 
> 
> Now when parser sees ElementA1 inside ElementC1 it has to ways of
> associating a schema declarations to ElementA1: it can be ElementA1
> from line (1) or it can be ElementA1 from line (2). Thus this schema
> is ambiguous.
> 
> 
> hth,
> -boris
> 
> 
> --
> Boris Kolpackov
> Code Synthesis Tools CC
> http://www.codesynthesis.com <http://www.codesynthesis.com/>
> Open-Source, Cross-Platform C++ XML Data Binding
> 
> ------------------------------------------------------------------------
> This e-mail is for the use of the intended recipient(s) only. If you 
> have received this e-mail in error, please notify the sender immediately 
> and then delete it. If you are not the intended recipient, you must not 
> use, disclose or distribute this e-mail without the author's prior 
> permission. We have taken precautions to minimize the risk of 
> transmitting software viruses, but we advise you to carry out your own 
> virus checks on any attachment to this message. We cannot accept 
> liability for any loss or damage caused by software viruses.
>

Received on Tuesday, 28 November 2006 15:59:51 UTC