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

["Marcel Jemio" <mjemio disa org>]

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
>