RE: UPA Question

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