> 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=
=2E  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 "lo=
ok ahead" to determine which particle the current node belongs to?  Given=
 our schema (shown below), let's say the validator is at ElementC1 and mo=
ves to the next node.  If that next node is ElementB1 we know we are in t=
he choice() particle containing ElementB1-ElementA1.  But if the node aft=
er ElementC1 is ElementA1, we know we took the other choice() route.  Tha=
t doesn't seem ambiguous to me because the first choice() mandates the pr=
esence of ElementB1.  But if ElementB1 was declared with minOccurs=0, t=
hat *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-thin=
king 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 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 atta=
chment to this message. We cannot accept liability for any loss or damage=
 caused by software viruses.