Draft of schema

["Scott Cantor" <cantor.2@osu.edu>]

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.

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.

-- Scott

xrd.xsd