RE: [saml-dev] SAML 2 AuthnContext Schema Problems

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

> Above, we see the PasswordType being defined normally, and 
> then RestrictedPasswordType being defined as a restricted 
> version of PasswordType. That's cool so far, but the problem 
> is, the new attribute "RestrictedLength" is being 
> surreptitiously introduced within the <restriction> block. 
> This is not allowed -- a restriction block can only contain a 
> subset of the elements in the base type, and cannot introduce 
> new ones.

That's not true, actually. It's supposed to be legal for a restricted
complex type to introduce a replacement element that is itself a restricted
subtype of the original element. If it weren't, restriction would be useless
because you couldn't constrain the value space of an element in the content
model of the base in a new restricted subtype, which is pretty much the
whole point.

But, I'm not disputing you, the current draft is wrong. What I'm finding
though is that the solution is odd, at least if the SQC tool can be
believed. It's the *name* of the replacement element that's causing
problems. The name has to be the same even if the type is different. This
fits with the idea that restrictions don't introduce new markup that isn't
valid against the base, which changing element names does. Fixing this
requires local element declaration instead of using ref:

>   <xs:complexType name="PasswordType">
>     <xs:sequence>
>       <xs:element ref="Length" minOccurs="0"/>

I change this to <xs:element name="Length" type="LengthType" .../>

>   <xs:element name="RestrictedPassword" type="RestrictedPasswordType"/>
> 
>   <xs:complexType name="RestrictedPasswordType">
>     <xs:complexContent>
>       <xs:extension base="PasswordType">
>         <xs:sequence>
>           <xs:element ref="RestrictedLength" minOccurs="1"/>

And this to <xs:element name="Length" type="RestrictedLengthType"/>

And then SQC says it's correct. This is strange, IMHO, but it just exposes
the weirdness of local elements. They're sort of different elements, but
sort of the same, I guess.

> A good, strict schema validator will catch these problems and 
> help sort them out (as we did). We recommend these schemas be 
> fixed in this regard for the next draft iteration.

Your solution won't fly, because it completely shifts around the content
model in the subtypes. They may as well be different types without a
relationship.

It definitely won't fix the context classes, which exist entirely on the
basis of restrictions that should be valid against the original schema. Once
you extend, it's no longer compliant with the generic "superclass" schema.

I'm hoping I can figure out a way to make this change relatively seamlessly,
but it's tricky, and I don't know these schemas well. Maybe John K. can
chime in.

-- Scott