Re: [provision] AddRequestType#container won't work.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

We *could* define a single identifier type for both target and pso--I'd 
call that Option 3. 
However, I think that a single identifier type would be more than a 
little confusing.  A target is *not* a pso, and I think it's important 
to be clear that the core operations (e.g., modify lookup delete) apply 
to psos and not to targets.  Having a separate PSOIdentifierType helps 
to make that clear.

Even if we did define a single identifier type for both target and pso, 
I think it would need to have an optional "targetId" (not 
"containerId").  We need to know (e.g., in order to validate the object 
against the schema) the *target* that ultimately contains the pso, not 
the immediate parent of the pso.  It would be undesirable to have to 
recurse (or otherwise lookup) the target.

I still favor Option 2,  which is an explicit CHOICE of IdentifierType 
or PSOIdentifierType.  I don't think that extensibility is particularly 
important for target and pso identifiers (and option 3 is no more 
extensible than option 2).

Is there something else that makes Option 3 better?

Jeff Bohren wrote:

>There best solution to this is to just have one identifier type for both
>PSOs and targets. The identifier type would have an optional container
>ID. If the identifier is used to identify a PSO, the container ID points
>to the target, or the containing PSO. If the identifier is used to
>identify a target, the container ID is not present.
>
>This could be defined as:
>
>	<complexType name="IdentifierType">
>		<complexContent>
>			<extension base="spml:ExtensibleType">	
>				<sequence>
>					 <element name="containerId"
>type="spml:IdentifierType" minOccurs="0"/>
>				</sequence>
>				<attribute name="ID" type="string"
>use="optional"/>
>			</extension>
>		</complexContent>				
>	</complexType>
>
>Jeff Bohren
>Product Architect
>OpenNetwork Technologies, Inc
> 
>Try the industry's only 100% .NET-enabled identity management software.
>Download your free copy of Universal IdP Standard Edition today. Go to
>www.opennetwork.com/eval.
> 
> 
>
>-----Original Message-----
>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>Sent: Thursday, December 02, 2004 1:45 AM
>To: PSTC
>Subject: [provision] AddRequestType#container won't work.
>
>Along the lines of "element ref won't work", it seems to me that the 
>"container" element of AddRequestType is another place where we expect 
>polymorphic acceptance of PSOIdentifierType as IdentifierType.  Although
>
>PSOIdentifierType is derived from IdentiferType, I believe that these 
>are two different types.
>
>Here I see two approaches (of which I think Option 2 is better).
>
>Option 1: XSI-TYPE - XSD specifies base type, doc element specifies a 
>derived type.
>PRO(?): Extensible (will accept custom identifier types).
>CON:   Fancy (some tools may not understand this feature.)
>
>For example,  AddRequestType would contain
>    <sequence>
>         <element name="containerId" type="spml:IdentifierType" 
>minOccurs="0"/>
>         <element name="data" type="spml:ExtensibleType" minOccurs="0"
>/>
>         <element name="capabilityData" type="spml:CapabilityDataType" 
>minOccurs="0" maxOccurs="unbounded" />
>   </sequence>
>
>The requestor must specify the derived type of containerId (if it's not 
>IdentifierType):
><addRequest>
>    <containerId xsi:type="PSOIdentifierType" ...>...</containerId>
>    <data>...</data>
></addRequest>
>Option 2: CHOICE - Specify a choice of derived types.
>PRO:  Explicit (and therefore validated by parser).
>PRO?CON?: Not extensible (won't accept custom identifier types).
>
>For example,  AddRequestType would contain
>    <sequence>
>         <choice minOccurs="0">
>            <xsd:element name="targetId" type="IdentifierType"/>
>            <xsd:element name="psoId" type="PSOIdentifierType"/>
>         </choice>
>         <element name="data" type="spml:ExtensibleType" minOccurs="0"
>/>
>         <element name="capabilityData" type="spml:CapabilityDataType" 
>minOccurs="0" maxOccurs="unbounded" />
>   </sequence>
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
>kgroup.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
>
>  
>