other or no namespace nondeterminism "problem"

["Gabe Wachob" <gabe.wachob@amsoft.net>]

I'm not a big fan of WXS schemas, and here's yet another reason. It's easy
for implementations like libxml2 to get wrong. 

The non-determinism issue here is a bug in libxml2 - the schema IS NOT
really non-deterministic - ##other never includes xml elements not in
namespaces at al, and ##local only include xml elements not in namespaces.
See e.g. http://www.w3.org/2001/05/xmlschema-errata#e1-11 and
http://xsd.stylusstudio.com/2006May/post04004.htm 

We need to include both the ##other and ##local namespaces - what we are
after is "any element NOT in the xri://$xri*($v/2.0) namespace".. 

What namespace an element is in is determined through analysis of the
surrounding XML document and whether there is a default namespace defined at
the lexical position at which the XML element is in. 

I'm loathe to dumb down the XML schema (and lose semantics) to work around a
(pretty common) bug in XSD validators. 

The only real workaround I would have is to change the XSD snippet to (and
this is now looking silly): 

> <xs:group name="otherelement">
>    <xs:choice>
>       <xs:any namespace="##any" processContents="lax"/>
>    </xs:choice>
> </xs:group>

We'd simply have to document the restriction about not allowing the xrd
namespace as an otherelement group member. Yech.

The other option is to specify RelaxNG as the normative schema, and we
wouldn't have to deal with this at all. RelaxNG is much more aligned with
the requirements we have for expressing constraints on valid XRD XML
documents... Though that means doing some work (it wouldn't be nearly as
much work as it took to come up with that schema...) 

	-Gabe

> -----Original Message-----
> From: kermit.snelson@gmail.com [mailto:kermit.snelson@gmail.com] On Behalf
> Of Kermit Snelson
> Sent: Friday, October 19, 2007 4:08 PM
> To: OASIS XRI TC
> Subject: Re: [xri] Updated XRD schema for XRI Res 2.0 WD11
> 
> I've noticed the following issues so far:
> 
> 1) libxml considers the following construct to be non-deterministic,
> meaning that both XRD and XRDS draft schemas are currently failing to
> compile:
> 
> <xs:group name="otherelement">
>    <xs:choice>
>       <xs:any namespace="##other" processContents="lax"/>
>       <xs:any namespace="##local" processContents="lax"/>
>    </xs:choice>
> </xs:group>
> 
> The exact error messages I'm getting, with line numbers, are:
> 
> % dix -r application/xrd+xml =kermit | xmllint --noout --schema
> draft-XRD-cd02-v9.xsd -
> draft-XRD-cd02-v9.xsd:105: element complexType: Schemas parser error :
> local complex type: The content model is not determinist.
> draft-XRD-cd02-v9.xsd:176: element complexType: Schemas parser error :
> local complex type: The content model is not determinist.
> WXS schema draft-XRD-cd02-v9.xsd failed to compile
> 
> % dix -r application/xrds+xml =kermit | xmllint --noout --schema
> draft-XRDS-cd02-v4.xsd -
> draft-XRDS-cd02-v4.xsd:15: element complexType: Schemas parser error :
> local complex type: The content model is not determinist.
> WXS schema draft-XRDS-cd02-v4.xsd failed to compile
> 
> However, both schemas may be made to compile cleanly and still
> validate on elements with foreign namespace prefixes (such as openid:)
> by changing the above construct to:
> 
> <xs:group name="otherelement">
>    <xs:sequence>
>       <xs:any namespace="##other" processContents="lax"/>
>    </xs:sequence>
> </xs:group>
> 
> Although I'm no XML Schema expert, my guess is that because any
> non-prefixed child of an XRD element is assumed to be within the xrd:
> namespace, there is no way for libxml to decide whether an unprefixed
> element name is "##local" or "##other".
> 
> 2) Because the draft XRD schema no longer lists the deprecated
> "content" value in the xs:enumeration for the "match" attribute, quite
> a few XRDSs "in the wild" are failing to validate, e.g.:
> 
> % dix -r application/xrd+xml "@ootao*andy" | xmllint --noout --schema
> draft-XRD-cd02-v9.xsd -
> -:25: element Type: Schemas validity error : Element
> '{xri://$xrd*($v*2.0)}Type', attribute 'match': [facet 'enumeration']
> The value 'content' is not an element of the set {'default', 'any',
> 'non-null', 'null'}.
> -:25: element Type: Schemas validity error : Element
> '{xri://$xrd*($v*2.0)}Type', attribute 'match': 'content' is not a
> valid value of the local atomic type.
> -:27: element Path: Schemas validity error : Element
> '{xri://$xrd*($v*2.0)}Path', attribute 'match': [facet 'enumeration']
> The value 'content' is not an element of the set {'default', 'any',
> 'non-null', 'null'}.
> -:27: element Path: Schemas validity error : Element
> '{xri://$xrd*($v*2.0)}Path', attribute 'match': 'content' is not a
> valid value of the local atomic type.
> - fails to validate
> 
> I don't know whether the use of deprecated attribute values should
> lead to validation failure or not. However, validation failure is
> currently what's happening. Thoughts?
> 
> =Kermit
> 
> On 10/16/07, Drummond Reed <drummond.reed@cordance.net> wrote:
> >
> >
> >
> >
> > XRI Resolution 2.0 editors and implementers:
> >
> >
> >
> > To maximize our momentum to finalize the spec, I put in another session
> > tonight to update the XRD schema to reflect everything in WD11 ED06.
> Thanks
> > to the very elegant original schema design by Gabe, it only took about
> an
> > hour. It has been posted to:
> >
> >
> >
> >
> > http://www.oasis-open.org/committees/download.php/25745/draft-XRD-cd02-
> v9.xsd
> >
> >
> >
> > Gabe, Bill: you are now the tag team charged with: a) reviewing this,
> and
> > then b) producing the RelaxNG version of it.
> >
> >
> >
> > But many eyes make better work, so all other editors/implementers:
> please
> > look this over closely (and test instance XRDS documents against it).
> Please
> > post any and all feedback to the list.
> >
> >
> >
> > =Drummond
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php