Summary of XSD issues.

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

Gerry,

I promised a quick roundup of proposed changes.  Sorry I didn't send it 
sooner.

1) Rename ObjectClassRefType to SchemaEntityRefType. 
- Less specific to DSML
- Avoids loaded term "objclass".

2) Say that ObjectClassRefType must have "exactly one" of 
objectclassname (String) or elementName (QName)?
- It'd be weird to have both and useless to have neither.

3) Rename instances of PSOIdentifierType to "psoId"
- Avoids confusion with instances of IdentifierType
- Shorter.

4) Change PSOType#container to be an instance of PSOIdentifierType
- Parent could be another PSO.
- Currently, IdentifierType limits container to target itself.

5) Change LookupRequestType to extend SpmlResponseType
- 'lookup' should not be Batchabl

6) Define batch as a separate capability
- Like 'search' batch requires complexity
  -- onError=exit|continue
  -- processing=sequential|parallel
  -- poster child for async
- Not truly a CORE operation
   -- not a bootstrap operation (like 'listTargets')
   -- not a basic operation (like 'add', 'mod', 'lookup', 'delete')
   -- lets you group a bunch of basic operations into a single request.

7) Provider returns the requestID for an operation that executes 
asynchronously
   - easier for the provider to generate a value that is unique to the 
provider
   - provider acknowledges each request with a synchronous response.
      -- if operation is excecuted asynchronously,
          response will contain requestID and
          response will contain result="pending".

8a) ANY operation can be requested asynchronously
     (except 'cancel' and 'status')
     - disallow cancel and status in order to prevent "loops"
       (e.g., canceling a cancel operation that cancels a modify operation)
     - a provider that does NOT support asynchronous execution
      will not support the Async capability (see 7c below)

8b) A provider may convert ANY operation to asynchronous 
      (unless the requestor specifies "execution='synchronous'")
      - this is necessary when an add, modify, or delete requires workflow
        (especially if workflow requires an approval).

8c) Define a Capability for asynchronous execution
      - there is not a separate operation for 'async';
         in this sense the capability is merely a "marker interface"
      - the async capability defines 'cancel' and 'status'
         since these operations are useful ONLY when a provider supports 
async exec'n

gpc