[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft of schema
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]