SPML draft documents - issues

["Elron, Rami" <rami_elron@bmc.com>]

	Hi all,

	Following a review of the current drafts, I wish to raise several
issues:


	1. In the next excerpt from draft_pstc_schema_core_12, the ErrorID
is required in every response. If so - what 'error' code is designated for a
success message?

		<xsd:complexType name="SpmlResponse">
	 		<xsd:sequence>
	 			<xsd:element name="operationalAttributes"
type="spml:Attributes" minOccurs="0" maxOccurs="1"/>
	 			<xsd:element name="errorMessage"
type="xsd:string" minOccurs="0"/>
	 		</xsd:sequence>
	  		<xsd:attribute name="results" type="spml:ResultCode"
use="required"/>
	 		<xsd:attribute name="requestID"
type="dsml:RequestID" use="optional"/>
	 		<xsd:attribute name="error" type="spml:ErrorCode"
use="required"/>
	 	</xsd:complexType>


	2. The next excerpt from the draft_pstc_schema_core_12 file
specifies several error codes:

		<xsd:simpleType name="ErrorCode">
	 		<xsd:restriction base="xsd:string">
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#malformedRequest"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unsupportedOperation"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unsupportedIdentifierType"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#noSuchIdentifier"/>
	 		</xsd:restriction>
	 	</xsd:simpleType>

		Given that there is a difference between 'unsupported' and
'unrecognized' I think that the spec should support (no pun intended) both
aspects. Such a list should 	therefore be generally modified to better
reflect correspondence to a given request's parts - including at least the
following:

		<xsd:simpleType name="ErrorCode">
	 		<xsd:restriction base="xsd:string">
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unrecognizedRequestFormat"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unrecognizedExecution"/>
				<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unrecognizedOperation"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unsupportedOperation"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unrecognizedID"/>
	 		</xsd:restriction>
	 	</xsd:simpleType>


		Moreover, the error coding should exhibit more breadth by
supporting each ProviderID's specific codes. 
		Following is one possible way to accomplish this:

		<xsd:complexType name="SpmlResponse">
	 		<xsd:sequence>
	 			<xsd:element name="operationalAttributes"
type="spml:Attributes" minOccurs="0" maxOccurs="1"/>
	 			<xsd:element name="errorMessage"
type="xsd:string" minOccurs="0"/>
	 		</xsd:sequence>
	  		<xsd:attribute name="results" type="spml:ResultCode"
use="required"/>
	 		<xsd:attribute name="requestID"
type="dsml:RequestID" use="optional"/>
	 		<xsd:attribute name="error" type="spml:ErrorCode"
use="required"/>
	 	</xsd:complexType>
		
		<xsd:simpleType name="ErrorCode">
			<xsd:sequence>
	 			<xsd:element name="providerIdentifier"
type="spml:ProviderIdentifier" minOccurs="1" maxOccurs="1" />
	 			<xsd:element name="ErrorIdentifier"
type="spml:ErrorCodes" minOccurs="1" maxOccurs="1"/>
	 			<xsd:element name="ErrorDescription"
type="xsd:string" minOccurs="0" maxOccurs="1"/> 
	 		</xsd:sequence>
	 	</xsd:simpleType>

		- and the Provider-specific variety of Error Codes could be
implemented by:

		<xsd:simpleType name="ErrorCodes">
	 		<xsd:restriction base="xsd:string">
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unrecognizedRequestFormat"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unrecognizedExecution"/>
				<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unrecognizedOperation"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unsupportedOperation"/>
	 			<xsd:enumeration
value="urn:oasis:names:tc:SPML:1.0:core#unrecognizedID"/>
	 		</xsd:restriction>
	 	</xsd:simpleType>


	3. The following excerpt from draft_pstc_schema_core_12  states that
ModifyResponse should be based on spml:Request in lieu of spml:Response:


		<xsd:complexType name="ModifyResponse">
	 		<xsd:complexContent>
	 			<xsd:extension base="spml:SpmlRequest">
	 				<xsd:sequence>
	 					<xsd:element
name="modifications" type="spml:Modifications" minOccurs="0"
maxOccurs="unbounded"/>
	 				</xsd:sequence>
	 			</xsd:extension>
	 		</xsd:complexContent>
	 	</xsd:complexType>

	4. The following excerpt from draft_pstc_schema_schema_05 has no
provision for implementation of ExtendedRequests created originally by
another ProviderID. 

		<xsd:complexType name="ExtendedRequestDefinition">
	  		<xsd:sequence>
	 			<xsd:element name="operationIdentifier"
type="spml:OperationIdentifier" minOccurs="1" maxOccurs="1" />
	 			<xsd:element name="properties"
type="Properties" minOccurs="0" maxOccurs="1"/>
	 			<xsd:element name="parameters"
type="AttributeDefinitionReferences" minOccurs="0" maxOccurs="1"/>
	 			<xsd:element name="returnValues"
type="AttributeDefinitionReferences" minOccurs="0" maxOccurs="1"/>
	 		</xsd:sequence>
	  		<xsd:attribute name="description" type="xsd:string"
use="optional"/>
	  	</xsd:complexType>

	IMO the spec should support the use of ExtendedRequests implemented
by a different ProviderID. 
	While its relevance might not be obvious at the moment, support of
alternative ProviderID ExtendedRequests might assist to achieve
interoperability in the long run. 
	The modified schema excerpt should therefore look like this:

		<xsd:complexType name="ExtendedRequestDefinition">
	  		<xsd:sequence>
				<xsd:element name="providerIdentifier"
type="spml:ProviderIdentifier" minOccurs="1" maxOccurs="1" />
	 			<xsd:element name="operationIdentifier"
type="spml:OperationIdentifier" minOccurs="1" maxOccurs="1" />
	 			<xsd:element name="properties"
type="Properties" minOccurs="0" maxOccurs="1"/>
	 			<xsd:element name="parameters"
type="AttributeDefinitionReferences" minOccurs="0" maxOccurs="1"/>
	 			<xsd:element name="returnValues"
type="AttributeDefinitionReferences" minOccurs="0" maxOccurs="1"/>
	 		</xsd:sequence>
	  		<xsd:attribute name="description" type="xsd:string"
use="optional"/>
	  	</xsd:complexType>





	Rami Elron
	BMC Software Ltd.