Shibboleth Developers

["Scott Cantor" <>]

> I really don't understand why it's not "legal".  Given the 
> current SAML schema:
> 
>   <complexType name="AttributeType">
>     <complexContent>
>       <extension base="saml:AttributeDesignatorType">
>         <sequence>
>           <element ref="saml:AttributeValue"/>
>         </sequence>
>       </extension>
>     </complexContent>
>   </complexType>
> 
> doesn't the "sequence" mean there can be a, you know, 
> sequence of elements, each of which is an AttributeValue?

No. The content model defined in that schema is a single element called
AttributeValue, and its occurrence facets are left defaulted to min=1
and max=1. It must appear, and it can only appear once.

> If it doesn't mean that, surely this schema (which is 
> supposed to get fixed anyway to get rid of the 
> AttributeValueType, I think), can be fixed to make this be 
> so?  Is there some deep XML reason why multiple values can't 
> be straightforward?

Sure, you just add maxOccurs="unbounded" to the element. I guess the
justification would be that if you have a multi-valued attribute, it
should have, umm, multiple Values? :-)

> So where does the "<Affiliation>" tag come from?  From an XML 
> schema definition for the "eduPersonAffiliation" AttributeName?

Presumably.

> Does that mean there has to be XML schema 
> work done for each and every AttributeName? Can someone show 
> an example of that schema definition?  Sounds like a lot of 
> (needless) extra work to me.  I find this deeply puzzling.

It's not necessary to have a schema if the type of your value is one of
the schema built-in types. However, while there is a way to express that
you want a list of a built-in type like string as your syntax, you still
have to define that as a simpleType with a schema, as it's not a
built-in type.

So you may not need a whole element called Affiliation, but you still
need a schema. Further, fully type-aware parsers are still rare, and its
often easiest currently to keep to the built-in types or build complex
types that express what you want in terms of a content model of built-in
types and avoid lists and such.

Finally, note that with Affiliation, you have a defined domain of values
that shouldn't be left unconstrained anyway, so you want to define an
enumeration type in a schema as it is.

The schema for what Steven wrote would be:

<simpleType name="AffiliationEnumType">
  <restriction base="string">
    <enumeration value="member"/>
    <enumeration value="faculty"/>
    ....
  </restriction>
</simpleType>
<complexType name="eduP:AffiliationType">
  <sequence>
    <element name="Affiliation" type="eduP:AffiliationEnumType"
maxOccurs="unbounded"/>
  </sequence>
</complexType>

The SAML assertion would of course define a namespace prefix eduP for
this namespace (whatever it is) and qualify the Affiliation elements
with it, as well as specify the type of the AttributeValue element with
xsi:type="eduP:AffiliationType"

For anyone glazing at this point, part 0 of the XML Schema spec is a
non-normative, very readable way to learn it, although it assumes you
have XML and namespaces down well (esp. namespaces).

-- Scott

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

    http://archives.internet2.edu/

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