RE: [security-services] RoleDescriptorType in Metadata schema

[Paul Madsen <p.madsen@entrust.com>]

Soctt, thanks for clarification, shows what reading the primer will do.


paul

>-----Original Message-----
>From: Scott Cantor [mailto:scantor@wideopenwest.com]
>Sent: Wednesday, October 06, 2004 3:56 PM
>To: 'Paul Madsen'; 'SAML SSTC (E-mail)'
>Subject: RE: [security-services] RoleDescriptorType in Metadata schema
>
>
>> In the Metadata schema, it is the RoleDescriptorType that is 
>> declared abstract rather than the RoleDescriptor element.
>
>Elements aren't abstract in XML schema, types are. Elements 
>can be of an
>abstract type, as this one is, in which case xsi:type must be used to
>declare the actual type.
>
>> Consequently, XML Schema allows RoleDescriptor to occur in 
>> metadata instances in addition to other elements of a type 
>> derived from RoleDescriptorType, 
>
>No, only the former. Try declaring a derived element and 
>putting it in a
>document, you'll get a failure because that's not in the 
>choice allowed for
>the EntityDescriptor.
>
>> So the following would be valid
>> 
>> <EntityDescriptor>
>>     <RoleDescriptor>
>>     </RoleDescriptor>
>> </EntityDescriptor>
>
>Nope. The type is abstract, and you have no xsi:type, therefore it's
>invalid.
>
>> as well as something like
>> 
>> <EntityDescriptor>
>>     <new:NewRoleDescriptor 
>> xsi:type="NewTypeDerivedFromRoleDescriptorType">
>>     </new:NewRoleDescriptor>
>> </EntityDescriptor>
>
>Also invalid, since your extension element is not a legal choice.
>
>> Was it the intent to allow the first case? Was it to avoid a 
>> substitution group?
>
>We don't permit substitution any more. The only legal way is:
>
><RoleDescriptor xsi:type="NewTypeDerivedFromRoleDescriptorType">
></RoleDescriptor>
>
>This is the same everywhere in the spec, Condition, Statement, 
>BaseID, etc.
>
>-- Scott
>