[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] A15 & A23: Attribute Values
> - 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC