GNOME.org
 

RE: [xml] xmllint complains about non-determinist content model

Robin - 

Unless others on the list have other ideas but no...  The validation
must know "where" to validate the contained parts.  The alternatives
have been to use Schematron/XSLT but I'm not an expert in either...
Your special-case code might have to do if you cannot add a "group"
element

Good luck,
-mj


-----Original Message-----
From: Robin Munn [mailto:rmunn pobox com] 
Sent: Tuesday, December 23, 2003 4:09 PM
To: Marcel Jemio
Cc: xml gnome org
Subject: Re: [xml] xmllint complains about non-determinist 
content model

On Tue, Dec 23, 2003 at 03:28:47PM -0500, Marcel Jemio wrote:

Robin -

This is the "famed" non-deterministic or ambiguous content model 
scenario...  How is the parser supposed to know which 

content grouping 

to validate element "name"  to?  It can't in your scenario. 

 Even if 

you were to use the schmea "group" to abstract your "name/email" 
grouping, that would still qualify as non-deterministic.

Is this an inclusive-or example?  If so the best way I have 

found to 

do this, is to represent the:

              <xsd:sequence>
                  <xsd:element ref="name"/>
                  <xsd:element ref="email"/>
              </xsd:sequence>


Under another element so your final would like similar to this:

  <xsd:element name="person">
      <xsd:complexType>
          <xsd:choice>
              <xsd:element ref="name"/>
              <xsd:element ref="email"/>
              <xsd:element name="group">    

                   <xsd:sequence>

                     <xsd:element ref="name"/>
                     <xsd:element ref="email"/>
                 </xsd:sequence>

                </xsd:element>

          </xsd:choice>
      </xsd:complexType>
  </xsd:element>


Yes this adds another layer to your scenario but there is no error.


Thanks for the suggestion. Yes, this is inclusive-or: a 
<person> element can have a <name> element or an <email> 
element, or both; the only thing forbidden is a <person> 
element with neither a <name> or an <email>.

(In the actual project I'mn working on, the offending tag 
occurs about five or six levels deep in our XML structure; I 
abstracted it down to the simplest possible example of the 
problem for my question).

Unfortunately, at this stage in the project we have far too 
much code already written to make it feasible to change the 
XML spec by adding a <group> tag to group the "name+email" 
combination. What I think I will end up doing is something like this:

    <xsd:element name="person">
      <xsd:complexType>
          <xsd:sequence>
              <xsd:element ref="name" minOccurs="0">
              <xsd:element ref="email" minOccurs="0">
          </xsd:sequence>
      </xsd:complexType>
    </xsd:element>

and write special-case code to check for the invalid case of 
a <person> element with no <name> or <email> (which would be 
considered valid by that schema fragment). I hate to be 
writing special-case code when I thought the <xsd:choice> 
element was going to be the exact thing I needed, though.

This still doesn't seem right. Is there really no way to 
express in XML Schema the concept "A alone, or B alone, or A 
and B, but not neither"?

--
Robin Munn
rmunn pobox com
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]