> From: Scott Cantor [mailto:]
> > From: Anne Anderson
...
> > Comment: If NameFormat is intended to map to a schema
> > specification (or surrogate) in which the name is defined,
> > please say so. "A URI reference representing the
> > classification of the attribute name for purposes of
> > interpreting the name" could mean as many things to as many
> > people as "NameQualifier" and "NameSpace" did.
>
> I think NameFormat is intended to map to a syntax and
> semantic for how the name identifies the attribute (just as
> NameIdentifier Format does). The one defined value (so far)
> says that the name is a URI, which means that the name alone
> identifies the attribute in the abstract sense.
> AttributeNamespace could have meant that, but some people
> felt it meant something different.
NameFormat doesn't classify the *attribute*, it classifies the *attribute name*. I personally feel that this is serious over-engineering, because none of my use cases involve a *run-time* decision based on whether a specific assertion contains an attribute name that is specifically a URI or an OID or whatever; if the attribute name format is significant, I expect to get that information from a profile rather than at run time. YMMV.
> ...
> > 4. Name and NameFormat
> > Comment: will these ever be used separately? Does anyone ever
> > want "all instances of the 'gorp' Attribute", regardless of
> > the NameFormat, or "all instances of Attributes with
> > NameFormat 'urn:oasis:tc:xacml:', regardless of the
> > Attribute's Name.
>
> My position on this has always been that this is silly, and
> we should just use URIs for names, but that's not the
> consensus opinion, so I think this is a step in the right
> direction to at least clarify what AttributeNamespace is for.
While I agree with Scott, it's seems clear that others don't, since XACML already has URIs for names and they have determined that they still need the additional metadata.
- irving -
