Re: [xri] Updated XRD schema for XRI Res 2.0 WD11

["Kermit Snelson" <ksnelson@subjectivity.com>]

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