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
www.---.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 =93syntactic-sugar-free=94 example, both toolkits report a UPA 
> violation.  Maybe one just can=92t navigate the groups. 
> 
>  
> 
> But I have one more general question about schema validation: 
> 
>  
> 
> Isn=92t the idea behind UPA to make sure that validators do not have to=
 
> =93look ahead=94 to determine which particle the current node belongs t=
o?  
> Given our schema (shown below), let=92s say the validator is at Element=
C1 
> 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 th=
e 
> node after ElementC1 is ElementA1, we know we took the other choice() 
> route.  That doesn=92t 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=92t know which particle it=92s 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@c...]
> *Sent:* Mon 11/27/2006 10:03 PM
> *To:* Erik Johnson
> *Cc:* xmlschema-dev@w...
> *Subject:* Re: UPA Question
> 
> Hi Erik,
> 
> Erik Johnson <ejohnson@e...> 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 clear=
ly:
> 
> 
> <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 immediatel=
y 
> 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.
> 


From mike@s... Tue Nov 28 16:13:40 2006
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1Gp5aW-0007PO-Rk
	for xmlschema-dev@l...; Tue, 28 Nov 2006 16:13:40 +0000