Re: [xri] Draft of schema

[Will Norris <will@willnorris.com>]

On Aug 25, 2009, at 9:19 AM, Scott Cantor wrote:

> I'm sending this to the list instead of uploading it because it's  
> not valid
> yet, so I can highlight an issue to decide (other than the host-meta
> changes).
>
> The main issue preventing validity is the usual problem with XSD and
> wildcarding, ambiguous content models. This happens when you create  
> choices
> or sequences that include a wildcard ##other along side optional  
> content
> from another namespace (in this case the use of XML Signature for both
> KeyInfo and Signature).
>
> When all the content is optional, as in this case, you get problems  
> even if
> you reorder things and move the Signature up to the top (which I  
> happen to
> prefer, BTW, but that's a personal thing).
>
> The solution I use, as found in SAML, is to create a locally defined
> Extensions element to wrap the wildcard, and put that in the content  
> model
> instead of the wildcard. This isolates the non-local elements from the
> explicitly defined content and resolves the conflict, at a cost of  
> an extra
> element. In practice, I also prefer it when implementing, because it  
> makes
> it simpler to find (or ignore) extensions.
>
> So instead of this:
>
> <xrd:XRD>
> 	<xrd:Subject/>
> 	<xrd:Type/>
> 	<frob:Frobnitz/>
> </xrd:XRD>
>
> You have this:
>
> <xrd:XRD>
> 	<xrd:Extensions>
> 		<frob:Frobnitz/>
> 	</xrd:Extensions>
> 	<xrd:Subject/>
> 	<xrd:Type/>
> </xrd:XRD>
>
> Obviously the cardinality on Extensions is normally 0 or 1, and I  
> tend to
> put it at the beginning, but it doesn't matter that much.

I'm not sure how others will feel about it, but I'd like to avoid the  
Extensions element if we can keep from it.  XML by its nature is  
intended to be extensible, so having to define an explicit Extensions  
element just seems weird.  What if we state that extension elements  
cannot come from the XRD namespace OR the DSig namespace?  Would that  
remove the ambiguity?  Would that be unnecessarily limiting to XRD  
extension authors?


> The only other XSD issue notable is that because I prefer to define  
> types
> for all the content models, the use of an element named Type (which  
> I think
> is a bad idea, FWIW) leads to a type called TypeType, which  
> obviously blows.
> Resolution on that as people see fit.

Yeah, I think I remember running into this.  It does blow, but I'd  
just go with it.

-will