Re: Pending changes for draft 9 of XSD.

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

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.)

>
> Jeff Bohren wrote:
>
>> Draft 8 has batch semantics broken out as a separate capability.
>>
>