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] Why use name-value pairs for modelingattributes?


Hi Joseph,

Joseph Reagle wrote:
> [Thanks Prateek, I feared you forgot me! <smile/> Also, I fear this message 
> will be bounced by Oasis, so I'm cc:ing the w3c archive...]
> 
> On Monday 16 September 2002 09:51 am, Eve L. Maler wrote:
> 
>>(Note that the first example below should look more like this:
>><Attribute
>>   AttributeNamespace="http://www.finance.org/V1";
>>   AttributeName="CreditRating">
>>   <AttributeValue>Good</AttributeValue>
>></Attribute>
> 
> 
> Right, this struck me as very odd because there's no "normal" Infoset item 
> for this information, the namespace declaration is verbose (though I'm glad 
> you didn't stick only a prefix in there!), it's difficult to write a schema 
> to validate it, and  there's no other parameters that I can associate with 
> it. If it was XML, I could have a nested/parameterized structure, validate 
> it, extend it, query it with XPath or forthcoming XQuery, etc. Now that I 
> understand the way in which you are attempting to query it I see the 
> motivation at least...

I'm not sure what you mean about having a "normal" info item for the 
information; it's a SAML attribute specification, which is a first-class 
item in SAML terms.  You're right that it's a little more verbose than 
if SAML were to require all attribute information to be supplied with 
foreign elements, but the only way to make the verbosity really go away 
is with QNames in content.

We actually did plan for the ability of SAML users to extend this 
structure if they wish, by specializing AttributeValueType.  But SAML is 
also usable out of the box with a structure that gives you the basic 
name/value tuple.  (And, as I pointed out earlier, if someone really 
wants to give attribute information their own "spin", they can always 
use XSD substitution groups.)

>>There are a number of other ways we could have done it; one would be (a
>>well-formed version of) the one apparently suggested by Joseph:
>>
>><finance:CreditRating
>>   xmlns:finance="http://www.finance.org/V1";>
>>Good
>></finance:CreditRating>
>>
>>I don't know if we really considered this option seriously.
> 
> 
> Yep! I can then get at it with XPath or XSLT, don't need a special query 
> thingy.

SAML's protocol deliberately offers querying that is specific to SAML 
semantics.  XPath and even XML Query would offer ultimate flexibility 
but only "XML-level" thinking, whereas SAML queries offer 
attribute-aware (and authentication-aware and 
authorization-decision-aware) thinking.  We did consider leveraging XML 
Query for all SAML queries, but decided it would mean too-high support 
requirements for conforming authorities.

>>We should probably consider what our true stance is on "QNames in
>>content", since currently we're inconsistent and this doesn't offer a
>>lot of guidance as to future design.
> 
> 
> I'd avoid it if I could. (I have in the specs I've authored, and I've 
> recommended it to others with mixed success and in the end it will be their 
> headache...)

I absolutely agree with you (though I wonder, with xsi:type always being 
an option, if anyone can really get away without supporting it anymore).

	Eve

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com



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


Powered by eList eXpress LLC