OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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

* 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

> - 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC