Re: [ebxml-iic-msg] comments on MS TestSuite (2)

[Matthew MacKenzie <matt@xmlglobal.com>]

The requirements document you sent was corrupted, at least it was when I 
go it, so I've attached a copy that I just generated.

Regards,

Matt

Title: OASIS ebxml-iic TC -> Requirements

OASIS ebxml-iic TC: Messaging Conformance Requirements

ID	Name	Function	Specification Ref	Condition	Assertion
r0.1	Global Requirements for All Tests	other	ebMS-2#1.3
r0.1.1	Schema Validation		ebMS-2#1.3		REQUIRED:Supports all mandatory syntax defined in Core plus Additional Features
r1.1	Packaging Specification	packaging	ebMS-2#2
r1.1.1	SOAP 1.1 Conformance		ebMS-2#2.1.1		REQUIRED:All generated ebXML messages conform to SOAP 1.1 and the SOAP Messages with Attachments specification.
r1.1.2	SwA MIME Headers		ebMS-2#2.1.2		REQUIRED:All MIME headers generated for each Message Package are in conformance with the SOAP Messages with Attachments Specification.
r1.1.3	Message Package Content-Type		ebMS-2#2.1.2		REQUIRED:The Content-Type MIME header in the Message Package contains a type attribute of "text/xml".
r1.1.4	Content-ID "start" attribute		ebMS-2#2.1.2		RECOMMENDED:The Content-ID MIME header in any generated Message Package contains a start attribute identifying the first MIME part.
r1.1.5	Non-Multipart Messages		ebMS-2#2.1.2		REQUIRED:Non-Multipart SOAP messages are supported in instances where there are no payload sections.
r1.1.6	SOAP Message Content Type		ebMS-2#2.1.3.1		REQUIRED:The MIME Content-Type header for each generated SOAP Message has the value "text/xml".
r1.1.7	SOAP Message Character set		ebMS-2#2.1.3.1		OPTIONAL:The MIME Content-Type header of each generated SOAP Message specifies the character set used to generate the message.
r1.1.8	Suggested Character set		ebMS-2#2.1.3.2		RECOMMENDED:The UTF-8 character set is used by default when encoding each SOAP Message.
r1.1.9	No Application Payload		ebMS-2#2.1.4	( If there are no application payloads identified in the message header manifest” )	REQUIRED:There must not be any payload MIME parts
r1.1.10	Manifest		ebMS-2#2.1.4		REQUIRED:The contents of each payload MIME part are identified in the Manifest element within any generated SOAP body
r1.1.11	Unrecognized MIME headers		ebMS-2#2.1.5		REQUIRED:Unrecognized MIME headers in any incoming MIME part are ignored
r1.1.13	Version in XML Prolog		ebMS-2#2.2.1	( XML Prolog exists in the SOAP message )	REQUIRED:XML version is declared
r1.1.14	Encoding matches Prolog declaration		ebMS-2#2.2.2	( XML Prolog exists in SOAP message AND Encoding is declared in the XML Prolog AND charset attribute is present in SOAP header container )	REQUIRED:The encoding declaration matches the charset attribute of the Content-Type MIME header in the Header Container.
r1.1.15	Namespace qualification of ebXML extension elements		ebMS-2#2.3		REQUIRED:All ebXML extension elements included within generated SOAP Envelope, Header and Body elements are namespace qualified to: "http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
r1.1.16	Envelope schema location		ebMS-2#2.3.2		RECOMMENDED:Generated SOAP Envelope elements include the XMLSchema-instance namespace qualified schemaLocation attribute indicating the extended ebXML envelope schema: "http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd"
r1.1.17	SOAP Header and body namespace		ebMS-2#2.3.2		RECOMMENDED:Generated SOAP Header and Body attributes both include a XMLSchema-instance namespace qualified schemaLocation attribute indicating the extended ebXML Msg Header schema "http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
r1.1.18	SOAP Header element namespace		ebMS-2#2.3.3		REQUIRED:A generated SOAP Header element is namespace qualified as per the SOAP namespace declaration in the SOAP Envelope element.
r1.1.19	SOAP Body element namespace		ebMS-2#2.3.4		REQUIRED:A generated SOAP Body element is namespace qualified as per the SOAP namespace declaration in the SOAP Envelope element.
r1.1.20	SOAP header contains a MessageHeader element		ebMS-2#2.3.5.1		REQUIRED:A generated SOAP Header element always contains one ebXML MessageHeader element.
r1.1.21	Namespace of foreign elements		ebMS-2#2.3.6		REQUIRED:Any foreign namespace qualified elements present within generated ebXML extension elements are namespace qualified with a namespace that is not "http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd".
r1.1.22	XML ID attribute		ebMS-2#2.3.7		OPTIONAL:An XML ID attribute is supplied for each generated ebXML element (to assist with such tasks as specifying elements included in a digital signature).
r1.1.23	MessageHeader@version value		ebXML-2#2.3.8		RECOMMENDED:A generated ebXML MessageHeader element always contains a version attribute with a value of "2.0"
r1.1.24	SOAP mustUnderstand attribute & ebXML extensions		ebMS-2#2.3.9		REQUIRED:All ebXML extensions of the SOAP Header element (MessageHeader, SyncReply, MessageOrder, ...) contain the mustUnderstand attribute namespace qualified to the SOAP namespace (http://schemas.xmlsoap.org/soap/envelope).
r1.1.24-a1	Message Rejection		ebMS-2#2.3.9		REQUIRED:Any SOAP Header extension with a mustUnderstand attribute set to "1" that is not understood by the MSH will result in the message being rejected.
r1.2	Core Extension Elements	packaging	ebMS-2#3
r1.2.1	From & To element presence		ebMS-2#3.1.1		REQUIRED:From and To elements are always present as the children of a generated MessageHeader element and identify the parties that originated/are-intended-to-receive the message respectively.
r1.2.3	Handling of multiple PartyId elements in To or From		ebMS-2#3.1.1	( When generated From or To elements contain multiple PartyId elements the PartyId values )	REQUIRED: The values are treated as identifying the same organization.
r1.2.5	Error in PartyId content		ebMS-2#3.1.1.1	( PartyId does not contain a type attribute AND PartyId text node is not a URI )	STRONGLY RECOMMENDED:MSH responds with an error (Inconsistent/Error)
r1.2.6	CPA resolution error		ebMS-2#3.1.2	( If value of the CPAId element on an inbound message cannot be resolved )	REQUIRED:The MSH responds with an error (NotRecognized/Error).
r1.2.7	CPA / Message disagreement		ebMS-2#3.2.1	( If the receiving MSH detects an inconsistency between an incoming message and the relevant CPA )	REQUIRED: It responds with an error (Inconsistent/Error)
r1.2.9	ConversationId value presence and consistency		ebMS-2#3.1.3		REQUIRED:The generated ConversationId will be present in all messages pertaining to the given conversation.
r1.2.10	Service element content		ebMS-2#3.1.4.1	( If the "type" attribute is not set. AND If the content is not a URI. )	REQUIRED:MSH Responds with an error (Inconsistent/Error)
r1.2.11	Unrecognized Service and/or Action		ebMS-2#3.1.5	( If the receiving MSH does not recognize both the Service and Action values of an incoming message )	REQUIRED: It responds with an error (NotRecognised/Error).
r1.2.14	RefToMessageId content		ebMS-2#3.1.6.3	( If the RefToMessageId element within the MessageData element is present )	REQUIRED: It contains the MessageId value of an earlier ebXML Message to which this message relates.
r1.2.15	RefToMessageId existence		ebMS-2#3.1.6.3	( If there is no earlier related message )	REQUIRED:The RefToMessageId element is never present.
r1.2.16	RefToMessageId existence in error messages		ebMS-2#3.1.6.3	( If a previous message generated and error )	REQUIRED:The RefToMessageId element is always present with a value indicating the message in error.
r1.2.18	TTL validation by To Party		ebMS-2#3.1.6.4	( If the MSH receives a message for which it is the To Party MSH and the TimeToLive is greater than the time of the internal clock (adjusted for UTC) )	REQUIRED:An error message is returned to the To Party MSH (TimeToLiveExpired/Error).
r1.2.19	Duplicate Elimination		ebMS-2#3.1.7	( If the DuplicateElimination element is present within the MessageHeader of an inbound message )	REQUIRED:The MSH eliminates duplicate messages.
r1.2.20	DuplicateElimiation element must not be present in a message		ebMS-2#3.1.7	( If CPA specifies a DuplicationElimination value of never )	REQUIRED:The DuplicateElimination element must not be present.
r1.2.21	xml:lang is set in Description element		ebMS-2#3.1.8		RECOMMENDED:No two Description elements must have the same xml:lang attribute value
r1.2.22	Payload/Application data in SOAP:Body or ebXML:Manifest		ebMS-2#3.2		RECOMMENDED:No payload/application data is present in generated SOAP Body / ebXML Manifest elements.
r1.2.23	MIME parts required when Manifest/Reference refers to a content id.		ebMS-2#3.2.2	( If there is not a matching payload for the xlink:href element of a generated Manidfest/Reference element )	REQUIRED:An error message is directed to the From Party MSH (MimeProblem/Error).
r1.2.24	Error reporting of bad href in Manifest/Reference		ebMS-2#3.2.2	( If the xlink:href element of a Manifest/Reference element on an inbound message specifies a URI that is not a content id (not "cid:"), and that cannot be resolved )	OPTIONAL:The MSH reports an error to the From Party MSH (MimeProblem/Error)
r1.2.25	Unreferenced payloads should be discarded		ebMS-2#3.2.2	( If a MIME payload part exists on an incoming message that is not referenced by a Manifest/Reference element )	STRONGLY RECOMMENDED:It is discarded.
r1.4	Error Handling	other	ebMS-2#4.2
r1.4.1	SOAP Faults from downstream processor.		ebMS-2#4.2		REQUIRED:The MSH can accept and process SOAP Fault values from a downstream SOAP processor.
r1.4.2	SOAP Faults comply with SOAP specification.		ebMS-2#4.2	( If an MSH returns a SOAP Fault message to the sender of a SOAP message )	REQUIRED:The returned message conforms to the SOAP specification guidelines for SOAP Fault values.
r1.4.3	Errors with highestSeverity of Warning shouldn't use SOAP Fault.		ebMS-2#4.2	( When an ebXML message is reporting an error with a highestSeverity value of 'Warning' )	STRONGLY RECOMMENDED: It is not reported or returned as a SOAP Fault.
r1.4.4	Data communication errors use native reporting methods.		ebMS-2#4.2.2		STRONGLY RECOMMENDED:Errors associated with data communications protocols are detected and reported using the standard mechanisms supported by that protocol and do not use ebXML reporting mechanisms.
r1.4.5	ErrorList presence.		ebMS-2#4.2.3		REQUIRED:The ErrorList extension element of the SOAP Header element is never present if there are no errors to be reported.
r1.4.6	ErrorList@highestSeverity contains the highest severity value of all enclosed Error elements.		ebMS-2#4.2.3.1		REQUIRED:The highestSeverity attribute contains the highest severity of any Error elements generated in an outbound message.
r1.4.7	Error@codeContext is always a URI.		ebMS-2#4.2.3.2.2		REQUIRED:The codeContext attribute of any generated Error element is always a URI.
r1.4.8	Namespace/scheme for codeContext values.		ebMS-2#4.2.3.2.2		RECOMMENDED:The namespace/scheme specified by codeContext for identifying errorCodes is the default value of urn:oasis:names:tc:ebxml-msg:service:errors.
r1.4.9	Error@errorCode presence.		ebMS-2#4.2.3.2.3		REQUIRED:For each Error element the errorCode attribute is present and indicates the nature of the error.
r1.4.10	Error@severity content.		ebMS-2#4.2.3.2.4		REQUIRED:For each Error element generated the severity attribute has the value of Warning or Error indicating the severity of the error.
r1.4.11	XPointer use for pinpointing message errors.		ebMS-2#4.2.3.2.5	( If an error exists in an ebXML element )	REQUIRED:The location attribute of the Error element is an XPointer to the erroneous element.
r1.4.12	Referencing an error with a MIME part.		ebMS-2#4.2.3.2.5	( If an error exists in a payload MIME part )	REQUIRED:The location attribute of the generated Error element contains the content-id (via "cid:") of the erroroneous MIME part.
r1.4.13	Short Description text for an error code presence.		ebMS-2#4.2.3.4		REQUIRED:The "Long Description" text for each error code provided by the Message Service Specification appears in any relevant Error element.
r1.4.14	Error reporting to message origin.		ebMS-2#4.2.4.1	( When an MSH detects an error in a message )	RECOMMENDED: The error is reported to the MSH that sent the original message in error.
r1.4.15	No error reporting location, or ErrorList@highestSeverity == "Error" action.		ebMS-2#4.2.4.1	( If the error reporting location cannot be found or the message in error has an ErrorList element with highestSeverity set to Error )	RECOMMENDED: The error is: Logged; Resolved by other means; and, No further action is taken.
r1.4.16	CPP/A#ErrorURI use.		ebMS-2#4.2.4.2	( If the ErrorURI is implied in the relevant CPA )	OPTIONAL:Then this is used as the Error Reporting Location.
r1.4.17	If CPP/A#ErrorURI is undefined.		ebMS-2#4.2.4.2	( If the ErrorURI is unavailable in the relevant CPA )	OPTIONAL:A URI specified in the From Party of the message is used as the Error Reporting Location.
r1.4.18	ErrorList sent as a result of message processing.		ebMS-2#4.2.4.3	( If an ErrorList is included as part of a message being sent as a result of processing an earlier message AND The Service and Action values are set as specified by the service enacted )	REQUIRED: The highestSeverity will not be Error.
r1.4.19	Independent ErrorList messages, service and action definition.		ebMS-2#4.2.4.3	( If an ErrorList is included as part of an independent message )	REQUIRED:The values of Service and Action are; Service: urn:oasis:names:tc:ebxml-msg:service Action: MessageError
r1.5	SynchReply	other	ebMS-24.3
r1.5.1	General effect of SyncReply presence.		ebMS-2#4.3.1	( If a SyncReply element is present in a message received over a synchronous communications protocol )	OPTIONAL:That connection is kept open in expectation of the response message using the same connection.
r1.5.3	SyncReply element conflict with CPA triggers an error.		ebMS-2#4.3.1	( If the CPA syncReplyMode is set to none AND SyncReply element is present in an inbound message )	OPTIONAL:The MSH issues an error (Inconsistent/Error).

On Thursday, May 2, 2002, at 02:16  PM, Michael Kass wrote:

> Jacques and all,
>
>
>
>   Here are further comments, and action items I am doing based upon 
> discussion on this topic.
> The main points are that I am proceeding to update schemas and instance 
> documents reflecting ideas
> presented here.
>
>   Also, I present my position on how I view the ebXMLRequirements.xml 
> document used as data input
> to a driver for conformance testing.
>
>   A second attachment, showing the latest version of requirements for 
> core conformance testing is attached for
> comments by all.  It is available in source (XML) form ( along with 
> schemas and stylesheets ) at:
>
> http://geek.ca/jcvslet/JCVSlet/list/ebxml-iic-msg/ebxml-iic-msg
>
>   The one outstanding issue regarding this document is the issue of 
> requirements 1.1.1 and 1.1.2, describing testing
> requirements for SOAP and MIME conformance.  I agree with the Drummong 
> Group folks that conformance testing of
> SOAP and MIME is beyond the scope of ebXML testing.  The requirement 
> statements do however,  appear in the specification.
> Conformance testing of other normative specifications is generally not 
> done.  Assumptions are made that those technologies
> work.
>   However, I also find references within the ebXML MS specification 
> that refer to SOAP/MIME attributes and their values in relation to
> ebXML MS attributes and their values. This is not SOAP/MIME conformance 
> testing, but reflects specification conformance
> requirements, and I believe that those specification requirement should 
> be tested.
>   I would like to remove the two requirements that refer to conformance 
> to SOAP and MIME from the document, as they are
> beyond the scope of ebXML MS testing. However other IIC members may 
> feel differently.  We need to resolve this issue.
>  
>
> Regards,
> Mike
>   
>
>
--
Matthew MacKenzie
XML Global R&D
PGP Key available upon request.