> - We have the opportunity to *require* that <AttributeValue>
> be supplied
> with an xsi:type. Do we want to do that, so that attribute
> values are as
> processable as possible, or should it be enough if someone
> wants to get
> this information out of the attribute namespace?
I would suggest not requiring it. A couple of reasons:
* the data may not be defined in terms of an XML schema (sure, we could
require you to always type it as a string, or something, but that seems
hack-y)
* the data may include elements of types from multiple schemas under the
<saml:AttributeValue>. For example, I might have a value made up by
inserting two elements as children of <AttributeValue>, with each element of
a type from a different schema. While I could declare a third new schema
defining a type for this composition I shouldn't NEED to.
* The field may contain well formed XML that doesn't have an associated
schema
> - If we don't require xsi:type, then I think it would be nice
> to have a
> non-normative note explaining briefly how this could be done.
> Doesn't have
> to be a SHOULD, to my mind, but doesn't have to throw people
> over to a
> whole other unnecessary document either.
However we decide to do this is fine with me. I only note that we have often
mentioned the principal that non-normative text should be kept to a minimum
in the core--and this would definitely by usage advice, not normative text.
C.
