Re: [provision] Draft 11 of the XSDs...

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

And one more:

Issue#31 also applies to SearchQueryType.
    SearchQueryType should offer CHOICE of targetId or psoId.

Gary P Cole wrote:

> One more nit:
>
> Issue#28:
>    Rename ErrorCode#unsupportedExecutionType to 
> 'unsupportedExecutionMode'.
>
> Gary P Cole wrote:
>
>> Thanks, Jeff, this is great.  You've fixed almost everything.
>> I'll attach the complete list of issues (because the number of items 
>> you've closed is pretty impressive), but here is a (much shorter) 
>> summary of six issues still outstanding:
>>
>> Issue#16 (CancelResultsType):
>>    Still OPEN (you wanted to think about it).
>>
>> Issue#30 (Element ref won't work):
>>    -- BatchResponseType still specifies ref to spml:response (should 
>> use OCM).
>>    -- BatchRequestType still needs annotation re: nestedRequest(s).
>>    -- BatchResponseType still needs annotation re: nestedResponse(s).
>>    -- StatusResponseType still needs annotation re: nestedResponse(s).
>>        --- if asyncRequestID is specified, contains zero or one 
>> nestedResponse
>>        --- if asyncRequestID is not specified, contains any number of 
>> nestedResponses
>>
>> Issue#32 (statusAll):
>>    -- attribute asyncRequestID should be optional in StatusRequestType
>>    -- attribute asyncRequestID should be optional in StatusResponseType
>>
>> Issue#34 (rename SchemaEntityRefType#supports to 
>> "supportedSchemaEntity")
>>
>> Issue#40 (containment)
>>    -- Draft 11 adds SchemaRefType#isContainer and 
>> ErrorCode#invalidContainment
>>    -- OPEN because you wanted to think more about it.
>>
>> Issue#43 (should modify return entire pso):
>>    -- Draft 11 adds "returns" attribute to lookup, add, and to search.
>>    -- ModifyRequestType still needs "returns" attribute.
>>
>> gpc
>>
>> Jeff Bohren wrote:
>>
>>> Attached is draft 11 of the XSDs. This incorporates the changes from 
>>> the F2F on Mon and Tue. Let me know if I missed anything.
>>>
>> ------------------------------------------------------------------------
>>
>>
>> |*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.)
>> |20041201 - Sent email: "Draft 9 Item 12: 
>> SchemaEntityRefType#objectClassName and #elementName."
>> |20041206 - Gerry Woods suggests that a single URI-valued or 
>> string-valued attribute
>> |        (e.g., 'entityName') could replace both objectClassName and 
>> elementName.
>> |20041207 - Agreed with 'entityName'.
>> |Draft 11 - FIXED. Replaced 'objectClassName' and 'elementName' with 
>> 'entityName'
>>
>>
>> |*15. Remove (optional) requestID from SpmlRequestType
>> |     and add (required) requestID to CancelRequestType
>> |     and add (required) requestID to StatusRequestType
>> |DISPUTED.
>> |20041201 - email: "Issue 15, request IDs for synchronous requests."
>> |20041206 - Leave 'requestID' as-is and add 'asyncOperationID' to 
>> cancel and status?
>> |Draft 10 - Still need 'asyncRequestID' in spml:ResponseType.
>> |20041207 - DO NOT need 'asyncRequestID' in spml:ResponseType.
>> |         Instead, requestor specifies original requestID |        as 
>> 'asyncRequestID' in a cancelRequest or a statusRequest.
>> |Draft 11 - FIXED (Perhaps fixed in Draft 10).
>> |
>>
>>
>> *16. Don't need CancelResultsType; ResultCode and ErrorCode should 
>> suffice.
>> DISPUTED.
>> 20041201 - email: "Issue 16, cancel results..."
>> 20041207 - Left OPEN.  Jeff Bohren wants to think about it, and his 
>>         proposal to remove async from the core could also affect this.
>>
>>
>> |*17. Replace "statusReturns" with optional boolean attribute 
>> "returnOutput".
>> |DISPUTED.
>> |20041201 - email: "Issue 17, statusReturns..."
>> |20041205 - Rename ResultCode to StatusCode and rename attribute 
>> result to status
>> |        and let the optional boolean attribute be named 
>> "returnResults".
>> |20041207 - Agreed at F2F.
>> |Draft 11 - FIXED.
>> |
>>
>> ----------------------
>>
>> |*25. The "active" attribute of ActiveResponse should be optional.
>> |     (In case of error, any value of "active" could be misleading.)
>> |OK? - Optional, but having an element seems like overkill. Suggest 
>> attribute.
>> |20041130 - sent email: "Draft 9: ActiveResponseType#active."
>> |20041207 - Agreed with attribute at F2F.
>> |Draft 11 - FIXED: attribute "active" is optional in ActiveResponseType.
>> |
>>
>> | 25. SelectionType#path and #namespace.
>> |    Draft 9 adds namespace mapping but removes required <namespace> 
>> element.
>> |    I thought we needed this to know the query language of the 
>> "path" value.
>> |20041201 - Sent email: "Draft 9: SelectionType#path and #namespace."
>> |20041206 - Gerry says that we must ask Jeff.
>> |20041207 - Agreed to keep as attribute 'namespaceURI'.
>> |Draft 11 - FIXED. SelectType requires "namespaceURI".
>> |
>>
>> | 26. PSOType#psoId and #data. (FIXED in Draft 10).
>> |    <psoId> and <data> are *optional* sub-elements of PSOType.
>> |    I think these should be required.
>> |20041201 - Sent email: "Draft 9: PSOType#psoId and #data."
>> |20041206 - Rami made the same point during face-to-face review.
>> |Draft 10 - FIXED.
>> |
>>
>> | 27. Rename ChangeType to ModificationModeType.
>> |20041201 - Sent email: "Draft 9: Rename ChangeType to 
>> ModificationModeType."
>> |20041206 - Accepted in face-to-face review.
>> |20041207 - Agreed F2F.
>> |Draft 11 - FIXED.
>> |
>>
>> | 28. Rename ExecutionType to ExecutionModeType.
>> |20041201 - Sent email: "Draft 9: Rename ExecutionType to 
>> ExecutionModeType."
>> |20041206 - Accepted in face-to-face review.
>> |20041207 - Agreed F2F.
>> |Draft 11 - FIXED.
>> |
>>
>>
>> | 29. Camel-case "objectclassName" and "elementName" in 
>> SchemaEntityRefType.
>> |20041206 - Accepted in face-to-face review.
>> |20041207 - superseded by 'entityName' per issue #12.
>> |
>>
>> 30. Element ref won't work.
>> 20041201 - send email "element ref won't work".
>>    StatusResponseType must nest 1+ response derived from 
>> SpmlResponseType.
>>    BatchRequestType must nest 1+ requests derived from 
>> BatchableRequestType.
>>    BatchResponseType must nest 0+ responses derived from 
>> SpmlResponseType.
>>     Options:
>>     1) CHOICE of AddRequestType|ModifyRequestType|DeleteRequestType.
>>        pro: xsd validation
>>        con: not extensible
>>     2) WRAPPER: similar to <data> and <capabilityData>
>>        pro: open; xsd validation as to minOccurs, maxOccurs; know 
>> where to look
>>        con: cannot validate "payload" of wrapper
>>     3) XSI-TYPE: XSD specifies base type, instance specifies derived 
>> type.
>>        pro: intuitive; easy to specify; recommended in XML Schema Primer
>>        con: fancy?
>>     4) OPEN CONTENT: 1-N requests appear as open content of 
>> batchRequest.
>>        pro: open
>>        con: no xsd validation whatsoever; no indication as to location;
>>           specified behavior left as open content;           
>> inconsistent with <data> and <capabilityData>
>>     5) CHOICE+OPEN CONTENT: Choice for core and open content for 
>> capabilities
>> 20041207 - Agreed F2F on OPEN CONTENT + ANNOTATION.
>> Draft 11 - StatusResponseType still needs annotation re: 
>> nestedResponse(s).
>>         - if asyncRequestID is specified, contains zero or one 
>> nestedResponse
>>         - if asyncRequestID is not specified, contains any number of 
>> nestedResponses
>> Draft 11 - BatchResponseType still specifies ref to spml:response 
>> (should use OCM).
>> Draft 11 - BatchRequestType still needs annotation re: nestedRequest(s).
>> Draft 11 - BatchResponseType still needs annotation re: 
>> nestedResponse(s).
>>
>>
>> | 31. AddRequestType#container won't work. (FIXED in Draft 10)
>> |20041202 sent email "AddRequestType#container won't work."
>> |    Options (I like 2 best):
>> |    1) XSI-TYPE: XSD specifies base type, instance specifies derived 
>> type.
>> |    2) CHOICE of IdentifierType | PSOIdentifierType
>> |    3) Use one type for both (with optional containerId/targetId)
>> |20041206 - Face-to-face accepted choice of IdentifierType | 
>> PSOIdentifierType.
>> |Draft 10 - Fixed.
>> |
>>
>> --------------------------
>> From Face-to-Face 20041206 --------------------------
>>
>> 32.    Allow 'status' operation to serve as 'statusAll'
>>     - 'asyncRequestID' becomes optional
>>     - if no 'asyncRequestID', return all
>>     - <nestedResponse minOccurs="0" maxOccurs="unbounded">
>> 20041207 - Agreed.
>> Draft 11 - Not done.  asyncRequestID should be optional in 
>> StatusRequestType, StatusResponseType.
>>
>> | 33.    Requirement 4.4: Multiple Error Messages. (FIXED in Draft 10)
>> |    - leave ErrorCode as-is
>> |    - add <errorMessage minOccurs="0" maxOccurs="unbounded">
>> |Draft 10 - Fixed. |
>>
>> 34.     Rename SchemaEntityRefType#supports to #supportedSchemaEntity
>> 20041207 - Agreed F2F.
>> Draft 11 - Not yet done.  Still called "supports".
>>
>>
>> | 35.    TargetType#targetID should be minOccurs="1" (default).
>> |20041207 - Agreed F2F.
>> |Draft 11 - FIXED.
>> |
>>
>> | 36.    TargetType#capability should be minOccurs="0".
>> |20041207 - Agreed F2F.
>> |Draft 11 - FIXED.
>> |
>>
>> | 37. ListTargetsResponseType#target should be minOccurs="0" (in case 
>> of error).
>> |20041207 - Agreed F2F.
>> |Draft 11 - FIXED.
>> |
>>
>> | 38.    Rename CapabilityType#identifier to #namespace (more specific).
>> |20041207 - Agreed F2F with 'namespaceURI'.
>> |Draft 11 - FIXED.
>> |
>>
>> | 39. Add TargetType#capabilities element to wrap <capability> elements.
>> |20041207 - Agreed F2F.
>> |Draft 11 - FIXED.
>> |
>>
>> 40.    Requestor must "program-by-exception" wrt containment.  Is 
>> this okay?
>>     - nothing tells requestor whether target supports containment.
>>     - nothing tells requestor whether target schema entity supports 
>> containment.
>>     - Do we need a Containment capability to advertise either or both 
>> of these?
>> 20041207 - Left OPEN.  Jeff Bohren wants to consider on this.
>> Draft 11 - Added to SchemaEntityRefType boolean attribute 'isContainer'.
>> Draft 11 - Added to ErrorCode a value of 'invalidContainment'.
>>
>>
>> | 41.    Should a single <modification> contain both <component> and 
>> <capabilityData>?
>> |20041207 - Agreed F2F to leave as-is.  Underlying concern was 
>> granular error reporting.
>> |
>>
>>
>> | 42.    What does an instance of {SelectionType} contain in the SMPL 
>> 1.0 (DSML) Profile?
>> |20041207 - For 'modify', <data> contains DSML attributeModifier 
>> elements.
>> |
>>
>>
>> 43.    Wouldn't it be easier to say that modifyResponse returns 
>> entire <pso>?
>>     What provider wants to calculate all the differences?
>>     What requestor wants to process all the differences?
>>     - optional <psoId> (if changed)
>>     - boolean option returnData (or just always return entire pso)?
>>     - boolean option returnCapabilityData (since this could be huge)?
>> 20041207 - Agreed F2F with 3-level enumeration option to lookup, add, 
>> modify and search:
>>         1=returnId
>>         2=returnIdAndData
>>         3=returnIdDataAndCapabilityData (all)
>>         default=all
>> Draft 11 - Adds "returns" attribute of DataInclusionType to lookup, 
>> add and search.
>> Draft 11 - ModifyRequestType still need "returns" attribute.
>>
>>
>> | 44. Should a <deleteRequest> contain <capabilityData>?
>> |20041207 - Agreed F2F to leave as-is. (Harmless.  Normatively 
>> specify to ignore.)
>>
>>
>> --------------------------
>> From Face-to-Face 20041206 --------------------------
>>
>> | 45. Add to SearchRequestType optional <returnCapabilities> element
>> |    - if element is not present, return all capability data
>> |         - if element is present but is empty, return no capability 
>> data
>> |    - if element is present and contains capability-namespace-URIs,
>> |        return capability data only for named capabilities
>> |Draft 11 - FIXED: string <includeDataForCapability> occurs 0+.
>> |
>>
>> | 46. Add to DeleteRequestType boolean option 'deleteRecursively' (or 
>> deleteContents').
>> |    Normatively specify that provider should otherwise prevent 
>> delete of non-empty container.
>> |Draft 11 - FIXED: boolean attribute "recursive" default=false.
>> |
>>
>>  
>>
>> ------------------------------------------------------------------------
>>
>> 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. 
>>
>>  
>>
>
>
>
> 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. 
>
>