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

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

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