[security-services] Schema extensibility: anyAttribute?

["Eve L. Maler" <eve.maler@sun.com>]

Summary: In order to make it possible to extend SAML to add attributes to 
native elements, we would need to add <xsd:anyAttribute> all over the 
place.  Should we do this?

Explanation:

We have expended a lot of effort trying to get SAML's customizability 
"right".  We allow the extension of our native types to get new elements, 
and in selected places we allow for the addition of foreign elements by 
design.  Given our prohibition against changing SAML semantics with foreign 
markup, we wouldn't have to worry if foreign attributes were tacked onto 
native elements, and this is a relatively cheap and easy way to "extend" a 
vocabulary.

For example, if a SAML assertion producer finds it convenient to add ID 
attributes to various elements for internal management purposes, or if they 
want to state what natural language an attribute value is in, currently 
they can't do that and still validate the results:

   <saml:AttributeValue xml:lang="EN-US" AttValID="12345">...

Now, xml:lang is somewhat of a special case, since its semantics are baked 
into core XML, but you still need to account for it in the schema if you 
want to validate.  We may want to account for xml:lang and xml:space 
specially in the schema just because XML always allows them, but that 
doesn't answer the ID attribute case, or any other similar case.

The anyAttribute approach is used in some other schemas I know of, but in 
general they also use ##any and ##other a lot more too.

Do we want to allow this kind of flexibility in SAML?

	Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com