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: Options for change


Updated schema attached, 

	<element name="AttributeValue" type="saml:AttributeValueType"/>
	<complexType name="AttributeValueType">
		<choice>
			<choice minOccurs="0" maxOccurs="unbounded">
				<any namespace="##any"
processContents="lax"/>
				<element ref="saml:AttributeElement"/>
			</choice>
			<element ref="saml:BooleanData"/>
			<element ref="saml:IntegerData"/>
			<element ref="saml:StringData"/>
		</choice>
	</complexType>
	<element name="AttributeElement" type="saml:AttributeElementType"/>
	<complexType name="AttributeElementType"/>
	<element name="BooleanData" type="boolean"/>
	<element name="IntegerData" type="integer"/>
	<element name="StringData" type="string"/>


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> Sent: Wednesday, October 03, 2001 5:02 PM
> To: 'Eve L. Maler'; security-services@lists.oasis-open.org
> 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

draft-sstc-schema-assertion-21.xsd



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


Powered by eList eXpress LLC