RE: [security-services] Status code clarifications/cleanup

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

> The real problem is that QNames in attribute values are a totally 
> unsanctioned use of the XML namespace mechanism (as far as the XML 
> Namespaces spec is concerned, that is).  There was just 
> another huge thread on the problems associated with QNames in
> attribute values on XML-Dev...  It's been done so often, though, that
> I'm not really willing to fight to get rid of it.  But we should know
> the costs (see below).

I understand, but given the existence of xsi:type in the schema spec,
I'd have thought they (the Schema WG) at least "sanctioned" it enough to
specify enumeration more usefully in this case.

I guess the only other option is to use URIs as code values, which I
suppose has its advantages given the current state of tools. Just makes
them longer, of course.

> If we're really going to do this, I think we also need to 
> document who/what governs the uniqueness of this field.

I think we have to do it, because you can't say something's a QName and
then give it's value as just a local name, obviously. The language is
more or less like what's in the SOAP specification, for similar reasons.

> If we ever add another attribute to SAML that contains qualified
names,
> is it possible that it will share some values with the status code
values
> (thus being in a different scope), or will it be impossible to re-use
> values for that new attribute (suggesting that it's in the same
scope)?

I don't see an inherent problem if they collide, since the processing of
such attributes values is the responsibility of the application anyway.
If they do collide, it may or may not be significant, it depends on what
the attribute is.

> (The other weird thing about QNames in attribute values bothers me
more: 
> They're a function of a particular application (e.g., SAML) and not a 
> function of basic XML syntax and processing.  This means that such 
> attribute values are left out in the cold when you perform processing
on 
> XML documents qua XML, for example, changing prefixes throughout.)

I wholeheartedly agree, but I view that as a problem with the DOM (esp.
pre-level3) as much as with anything else. It *can* be part of basic XML
processing, it's just not there yet. And since we have xsi:type being
used for several things in SAML, the problem exists already (as I
discovered).

-- Scott