Since we say "MUST be prefixed", I interpret this to mean that it's not
acceptable to use a non-prefixed (but implicitly qualified) value. So I
think Scott's first example wouldn't be correct. Comments from anyone
on this? Do we need to broaden the language in a future version?
Eve
Scott Cantor wrote:
>>"All status code values defined in this document are QNames
>>associated with the SAML protocol namespace, and MUST be prefixed
>>appropriately when they appear in SAML messages."
>>
>>To my understanding, this means a valid status code value
>>would be: "urn:oasis:names:tc:SAML:1.0:protocol:Success"
>>
>>For example,
>><abc:StatusCode xmlns:abc="urn:oasis:names:tc:SAML:1.0:protocol"
>>Value="urn:oasis:names:tc:SAML:1.0:protocol:Success"/>
>
>
> No, that's not a QName. A QName is a namespace prefix and a local name
> (the prefix being optional), not a complete namespace and a local name.
>
> So you have to have:
>
> <StatusCode xmlns="urn:oasis:names:tc:SAML:1.0:protocol"
> Value="Success"/>
>
> or
>
> <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
> Value="samlp:Success"/>
>
> There are inconsistencies in various XML APIs and specs in terms of
> properly handling QNames in attribute values and element content,
> because the usage wasn't initially expected or defined. But it's
> increasingly common.
>
> Personally, I had to define a QName type and implement some of the
> behavior I needed, but some parsers may provide some of that.
>
> -- Scott
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 883 5917
XML Web Services / Industry Initiatives eve.maler @ sun.com
