[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] A Modest Proposal about Attribute Names
> In short, I think there are several proposals here: > > 1. To join the attribute's name and governing namespace into a single > URI-based string > > 2. To reduce the syntax to merge <Attribute> and <AttributeDesignator> > > 3. To reduce the syntax to get rid of <AttributeValue> and just put > content in <Attribute> directly. > > I'm not sure about #1, but my intuition says to leave it > alone. I'm not in favor of #2 and #3. I'm in favor of #1, because after working through various examples and syntax experiments within our project, I've become convinced that identifying attributes with URI (most likely URN) strings is going to be the least confusing to deal with. If we have to populate two potential SAML attributes, we'll have to arbitrarily decide without any real justification how or whether to separate the URI. So I guess this would get us off the hook. ;-) As for #3, while it sounds nice in theory, there are problems in practice when combined with trying to define schema for simple attribute value types (basically what Eve noted). If you start with a content model of a single attribute (Name) and a sequence of any elements, that's complex content. According to my testing and review of some recent xml-schema-dev postings, it's legal to derive a new type and restrict the complex content to simple content, such as xsd:string. Unfortunately, there are lots of current parsers that break when you do that. Even if it did work, you end up having to define a new type no matter what, because setting xsi:type="xsd:string" would never allow the Name attribute in the Attribute element. As far as Shibboleth is concerned, we're going to end up with custom schema types for most attributes anyway, but for those wanting to use built-in types alone for attribute values, this would make it impossible. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC