Shibboleth Developers

Issue 1 - use of xsi:type

At 1:53 PM -0500 12/17/01, Scott Cantor wrote:
> Some miscellaneous comments inline...
>
> >  <Attribute AttributeName="eduPersonAffiliation"
> >       AttributeNamespace="urn:mace:edu">
> >     <AttributeValue xsi:type="eduPerson:AffiliationType">
> >       <Affiliation>staff</Affiliation>
> >     </AttributeValue>
> >  </Attribute>
>
> Something I'd strongly suggest that applies to many of your examples is
> that if the content model is a simple string, don't complicate it by
> using an element. Just embed the string and specify an xsi:type of
> "string". Anywhere you don't need an extension schema, don't use one.
>
> That said, eduPersonAffiliation is not such a case. It should be an
> enumerated type to constrain its values, and I also think that as a
> multi-valued attribute, it should pass all of the values in one
> Attribute element, not as separate Attributes.

Both Bob and Scott have argued that if the AttributeValue is merely a 
simple string, we shouldn't create unnecessary complexity by using a 
new element. I think I'm convinced..... but for completeness sake I 
feel I have to ask .... do we gain any generality by using an 
element, by deferring the typing of a particular attribute value? 
Does using an element allow the code to be more general, to separate 
it from any nastiness resulting from being tied to a "simple string"?

One XML concept that's becoming much clearer to me is the difference 
between the elements in an XML document and a collection of standard 
programming objects (which are likely to have code associated with 
them). With XML, our programs still contain the logic to deal with 
the semantics of an element. With objects, there's a framework that 
separates that code from our programs, and makes the management and 
distribution of that code much simpler.

I  suppose, tho, we can still structure the code to use objects that 
correspond in some way to the XML  elements.

Different point -- in a later note, Scott has hinted at a possible cost :

At 10:02 AM -0500 1/8/02, Scott Cantor wrote:
> If you omit xsi:type, it's impossible to validate the assertion in one
> pass. Instead, the consumer has to parse the assertion except for the
> attribute values, and then parse the attributes one by one checking for
> proper syntax.
>
> About the only justification for this I could see is to innoculate the
> consumer against a single bad attribute. We'd have to define that as
> legal, I guess. I'm inclined to toss an assertion that doesn't validate
> entirely for phase one, and then revisit. I'm a few weeks from writing
> any of that code, however.

I understand this to say that we should use strings wherever 
possible. In addition, we should include xsi:type="string" where 
applicable, in order to vastly simplify the parsing of these elements 
by the consumer. Is that correct?

So, assuming no one can suggest some value that we obtain by using 
elements, the consensus seems to be to use simple strings whenever 
appropriate and possible?

Issue 2-- multi-valued Attributes

Did we ever specifically discuss whether multi-valued attributes for
which the person has multiple values should be passed as one attribute
or multiple?

Personally, I think passing one with the value defined as a sequence
makes more sense.

There seem to be several possibilities here  (I guess this belongs in 
the "I love  XML because its so flexible" category)

a bit of background... if  we  believe we should go in  the "simpler 
schemer is  better"  direction (ie use  simple strings wherever 
possible),  then most  attribute values would be  carried  like this:

<Attribute AttributeName="eduPersonAffiliation"
     AttributeNamespace="urn:mace:edu">
   <AttributeValue>staff</AttributeValue>
</Attribute>

there are  no additional elements within AttributeValue (ie we don't 
see <Affiliation>staff</Affiliation>).

Which has the distinct  advantage  of very little clutter. However, 
this isn't easily extensible to the multi-valued attribute situation, 
because

<Attribute AttributeName="eduPersonAffiliation"
     AttributeNamespace="urn:mace:edu">
   <AttributeValue>staff</AttributeValue>
   <AttributeValue>student</AttributeValue>
</Attribute>

isn't legal.

So, I can imagine the  following possibilities:

a) carry the multiple values within a single AttributeValue by using 
a new  element:

<Attribute AttributeName="eduPersonAffiliation"
    AttributeNamespace="urn:mace:edu">
  <AttributeValue xsi:type="eduPerson:AffiliationType">
    <Affiliation>member</Affiliation>
    <Affiliation>staff</Affiliation>
  </AttributeValue>
</Attribute>

b) package multiple Attribute elements  in a single assertion...

<Attribute AttributeName="eduPersonAffiliation"
     AttributeNamespace="urn:mace:edu">
   <AttributeValue>member</AttributeValue>
</Attribute>
<Attribute AttributeName="eduPersonAffiliation"
     AttributeNamespace="urn:mace:edu">
   <AttributeValue>staff</AttributeValue>
</Attribute>


c) others?
--

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--