[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Options for change
> ><complexType name="AttributeValueType"> > > <sequence> > > Do you mean <choice> here? Having these all in order doesn't > seem right. yeah > > <any namespace="##any" processContents="lax" minOccurs="0" > >maxOccurs="unbounded"/> > > <element ref="saml:BooleanData" minOccurs=0 > >maxOccurs="unbounded"/> > > <element ref="saml:IntegerData" minOccurs=0 > >maxOccurs="unbounded"/> > > <element ref="saml:BooleanData" minOccurs=0 > > (StringData, I assume) again yeah > >maxOccurs="unbounded"/> > > </sequence> > ></complexType> > ><element name="BooleanData" type="boolean"/> > ><element name="IntegerData" type="integer"/> > ><element name="StringData" type="string"/> > > > > > >Using generic slots the namespace can specify the use of the > slot, for > >example: > > > ><AttributeValue Namespace="urn:whatever:academic-agreement-2001" > > Name="MemberOfFaculty"> > > <StringData>MIT.EDU</StringData> > ></AttributeValue> > > > ><AttributeValue Namespace="urn:whatever:academic-agreement-2001" > > Name="IsA Student"> > > <BooleanData>true</BooleanData> > ></AttributeValue> > > > > > >This leave the problem that the attribute slot is intended > to be extensible > >but an extension schema can't declare an extension that is > only for use as > >an attribute value. > > > >With generic data slots and an extension point: > > > > > ><complexType name="AttributeValueType"> > > <sequence> > > <any namespace="##any" > processContents="lax" minOccurs="0" > >maxOccurs="unbounded"/> > > <element ref="saml:AttributeElement"/> > > <element ref="saml:BooleanData" minOccurs=0 > >maxOccurs="unbounded"/> > > <element ref="saml:IntegerData" minOccurs=0 > >maxOccurs="unbounded"/> > > <element ref="saml:BooleanData" minOccurs=0 > >maxOccurs="unbounded"/> > > </sequence> > ></complexType> > ><element name="AttributeElement" type="saml:AttributeElementType"/> > ><complexType name="AttributeElementType"/> > > If you do this, then there's no reason to have the ##any wildcard, is > there? We should pick one of the two ways, I think... The problem is that the rest of the schema uses the 'strongly typed' extension mechanism but when it comes to attributes people wanted to be able to use #any... I would prefer having the strongly typed extension point, the problem with that is that if someone wanted to use an existing attribute schema (e.g. name and address directory data) they would then have to create a wrapper for that purpose alone. On the other hand if you are creating something that is intended to be used as an attribute extension then the 'principled approach' is more desirable. Phill
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC