1.1 comments

["Michael Kass" <michael.kass@nist.gov>]

Jacques and all,

 

 

   Here are my changes regarding your comments about v1.1 of the Test Framework. I also changed the

TestSuite schema to reflect a possible scripting syntax for branching ( basically an IF (TestStep "clause"), ELSEIF (TestStep "clause"), ), THEN (TestStep "clause"), ),

ELSE (TestStep "clause"), )  construct.  "Clauses" are nothing more than associative groupings of Test Steps, connected using an "AND" or "OR" connective predicate.

Comments ( particularly applicability to BPPS testing ) would be appreciated.

 

  I'm rolling this up into a ZIP file for your review.    Please look at the file:  IIC_ebXMLTestFramework_V1.1.doc as your reference.

I'm cruising in Mexico all this week, and will return the day before our next conference call. 

 

Have a great New Year everyone!

Mike

 

 

 

 

 

> - XSL, XUpdate seem to be applied for mutating payloads only.
> 7.1.3 mentions that they apply to that message envelopes as well, but
> the spec does not show that yet.

 

[MIKE] - I modified the wordking slightly to indicate that XSL/XUpdate applies to

message envelopes as well as to message payloads

>  - (7.1.3: PutMessage op) Expression "ebXML Payload" misleading (is that just payloads of any ebMS messages,
> or payloads that are ebXML-structured  e.g. for Reg-Rep?)

 

[MIKE] - I modified the wordking slightly to indicate that XSL/XUpdate applies to

any type of message payload

> - Appendix D (ebXML Store schema) still show a schema that is ebMS dependent.

 

[MIKE] - Fixed that

 

> - Appendix C: also shows ebMS-dependent schemas.

 

[MIKE] - Fixed that

> - Appendix B: "functional.type" simple element should not enforce enumeration values that are dependent on
> ebMS ("reliable Messaging", etc.)

 

[MIKE] - Agreed.  Changed to a "string" data type ( allowing any descriptor )

> - On the Errata sheet, item #6:
> I am still uncomfortable with dissociating COnfigurationGroup from
> the test suite element: how can we enforce the association of a test suite and of a particular CPA?
> I understand this association is not always desired, but i other cases we want to be more prescriptive
> and describe the config(s) that make sense for this suite.

[MIKE] - My view is that where the ConfigurationGroup resides is an implementation detail.  It is defined in the

spec as part of the Test Framework, becase it is necessary information to configure a Test Driver. I do not believe

that an overall "binding document" is necessary ( pointing to a file location/URI ) to link the configuration data

to the test suite.  This sounds more "implementation oriented", as far as how that association is made for the

Test Driver.   I'd be interested in what Drake Certivo, Dr. Cho and other implementers think.

 

> Jacques

 

ebXMLTestFramework1.0errata.ZIP