Re: [provision] Re: Pending changes for draft 9 of XSD.

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

These issues were discussed on the list and their resolutions have stood 
for quite a while now . (These resolutions have appeared in a summary of 
XSD issues and in an agenda.) 

I would prefer not to wait.  Would it be possible for you to respond on 
the list? If it will help, I will forward the email thread relevant to 
each issue.

Jeff Bohren wrote:

>I have some disagreements with issues 15, 16, and 17. I would like to
>discuss those changes in at the F2F or a subsequent call before I make
>them in the XSDs.
>
>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: Wednesday, December 01, 2004 10:13 AM
>To: Jeff Bohren
>Cc: provision@lists.oasis-open.org
>Subject: Re: [provision] Re: Pending changes for draft 9 of XSD.
>
>Adding number 23.
>
>Gary P Cole wrote:
>
>  
>
>>Adding number 22.
>>
>>Gary P Cole wrote:
>>
>>    
>>
>>>Nope; I missed some from this week. For completeness, I'll add them 
>>>as 19-21 below.
>>>
>>>Gary P Cole wrote:
>>>
>>>      
>>>
>>>>I think the following are all the pending changes. Seven are from 
>>>>today's working group call; eleven were left undone from previous 
>>>>agreements on the list:
>>>>
>>>>*1. Need to break out async as a separate capability.
>>>>The async capability should contain the cancel and status operations
>>>>and any type that is specific to these operations.
>>>>
>>>>2. Iterator should be *optional* in SearchResponseType.
>>>>In today's working group call, you suggested that the XSD should
>>>>        
>>>>
>allow
>  
>
>>>>the provider to omit content for every response in case of error.
>>>>(I think this means that no response should require a sub-element.)
>>>>
>>>>3. <pso> should be minOccurs="0" and maxOccurs="unbounded" in 
>>>>SearchResponseType.
>>>>This allows the provider to return any number of objects.
>>>>
>>>>4. <iterator> should be minOccurs="0" and maxOccurs="1" in 
>>>>SearchResponseType.
>>>>If the provider returns all matching objects (or if there is an
>>>>        
>>>>
>error),
>  
>
>>>>then there is no need for a provider to return an iterator.
>>>>
>>>>5. <modification> should be minOccurs="1" and maxOccurs="unbounded" 
>>>>in ModifyRequestType.  This requires a requestor to specify at least
>>>>        
>>>>
>
>  
>
>>>>one modification and allows a requestor to specify multiple 
>>>>modifications for the same object.
>>>>
>>>>6. The "component" element should be of type SelectionType (rather 
>>>>than IdentifierType) in ModifyRequestType.  This allows a requestor 
>>>>to use an XPATH expression to specify the component of an object 
>>>>that the provider is to modify.
>>>>
>>>>7. SelectionType should be enhanced to allow a requestor to specify 
>>>>any number of mappings from a prefix (that may be used in the 
>>>>expression that is the value of the "path" attribute) to a namespace
>>>>        
>>>>
>
>  
>
>>>>URI.
>>>>
>>>>8. Add a sub-element to PSOType to contain the XML that represents 
>>>>an object.  (Previously, we'd said that the XML that represents an 
>>>>object was open content of the <pso> element, but had not made 
>>>>explicit any order between this open content and the <psoId> element
>>>>        
>>>>
>
>  
>
>>>>and any <capabilityParameter> elements.)
>>>>
>>>>*9.    LookupRequestType should require an element of type 
>>>>PSOIdentifierType.
>>>>        (The XSD currently says minOccurs="0".)
>>>>
>>>>*10.   Add a value of 'unsupportedExecutionType' to ErrorCode.
>>>>
>>>>*11.   Rename "ObjectClassRefType" to "SchemaEntityRefType".
>>>>         (Less DSML-specific. Avoids overloaded term "objectClass".)
>>>>
>>>>*12.   ObjectClassRefType/SchemaEntityRefType must contain
>>>>          *exactly one of* "objectClassName" (String) or 
>>>>"elementName" (QName).            (It would be weird to have both 
>>>>and useless to have neither.)
>>>>
>>>>*13.   Rename all instances of PSOIdentifierType to "psoId".
>>>>         (Avoids confusion with instances of IdentifierType.
>>>>        
>>>>
>Shorter.)
>  
>
>>>>*14.    Move ProcessingType and OnErrorType to the batch capability.
>>>>          (Only the batch operation uses these types.)
>>>>
>>>>*15.    Remove (optional) requestID from SpmlRequestType
>>>>          and add (required) requestID to CancelRequestType
>>>>          and add (required) requestID to StatusRequestType
>>>>
>>>>*16.    Don't need CancelResultsType; ResultCode and ErrorCode 
>>>>should suffice.
>>>>
>>>>*17.    Replace "statusReturns" with optional boolean attribute 
>>>>"returnOutput".
>>>>
>>>>*18.    BatchRequestType should require at least one
>>>>        
>>>>
>batchableRequest.
>  
>
>>>>          (XSD currently says minOccurs="0".)
>>>>        
>>>>
>>>
>>>*19.    Camel-case 'oneLevel', 'subTree' and 'maxReturn' in search 
>>>capability.
>>>
>>>*20.    Rename "state" namespace to "suspend" for suspend capability.
>>>
>>>*21.    The "active" attribute of ActiveResponse should be optional.
>>>           (In case of error, any value of "active" could be 
>>>misleading.)
>>>
>>>      
>>>
>>22. Rename "target" sub-element of PSOIdentifierType to "targetId".
>>      (Avoids confusion with instances of TargetType.)
>>
>>    
>>
>*23. Camel-case "capabilityParameter" throughout.
>
>
>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.
>
>  
>