RE: [provision] SPML draft documents - issues

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

An "unrecognized operation" indeed should never happen. It may happen,
however, given that enforcement of restricted behavior is outside the scope
of SPML. Therefore the inclusion of 'unrecognized'-like codes might not be
redundant and costs very little.

As for the Provider-specific error codes, why does this necessarily
translate to another extensibility mechanism? In fact, addressing the
possible need of each provider to sport various non-common codes by
implementing a concept already pervasive in the spec seems quite logical.

With regard to the last point - I believe that modification of the current
schema to address supporting extended request for
different providers is more elegant then implementing a multiple schema
solution.


Rami Elron
BMC Software Ltd. 

-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com]
Sent: Monday, March 31, 2003 6:34 PM
To: Elron, Rami; provision@lists.oasis-open.org
Subject: RE: [provision] SPML draft documents - issues



Some comments:

1. I believe that this was fixed in the latest revision (see core 13).

2. An "unrecognized operation" should never happen. The WSDL definition,
if enforced, should disallow it. Enforcement of the SPML XML schema and
service specific WSDL definitions should be considered outside the scope
of SPML. If it does happen, it should be considered a malformed request,
and we already have an error code for that. 

Note that this is already addressed in section 2.1.1.1 of the SPML
Bindings document.

As far as provider specific error codes are concerned, I am still not
convinced that we need them. By definition the semantics of such error
codes would be outside the SPML specification. Why could we not use
Operational Attributes for this instead of defining yet another
extensibility mechanism of top of the one we have already?

3. This is an error and should get fixed in the next revision.

4. We can already support defining different extended requests for
different providers. Simply put each extended request that has a
different provider in a different schema. Note that a provisioning
service can support multiple schemas and in practice probably will.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 

-----Original Message-----
From: Elron, Rami [mailto:rami_elron@bmc.com] 
Sent: Monday, March 31, 2003 10:02 AM
To: provision@lists.oasis-open.org
Subject: [provision] SPML draft documents - issues

	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.