[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: QR Report of Collaboration-Protocol Profile and AgreementSpecificationVersion 0.911
Martin W Sachs wrote:
Tim,you are correct. The TRP team were considering idnetifying all the MUST and SHOULD features and using them as a minimum compliance model. however, given the timing i suggest you conisder how this was done for the TA specification.I am starting to work on the QR comments. I have some further questions.
"Compliance to this specification...is not formally stated":
I have assumed that compliance with this specification is accomplished
by obeying all the SHALLs and MUSTS. Can you send me a sample of a
compliance section?
the TA specification (section 9) deals with conformance - for ebXML
overall and for its own specification. the section which you may
wish to think about reads....
9.3 Conformance to the Technical Architecture Specification This section details the conformance requirements for claiming conformance to the Technical Architecture specification. In order to conform to this specification, each ebXML technical specification: a) SHALL support all the functional and Interface requirements defined in this specification that are applicable to that technical specification; b) SHALL NOT specify any requirements that would contradict or cause non-conformance to ebXML or any of its components; c) MAY contain a conformance clause that adds requirements that are more specific and limited in scope than the requirements in this specification; d) SHALL only contain requirements that are testable. A conforming implementation SHALL satisfy the conformance requirements of the applicable parts of this specification and the appropriate technical specification(s).
Our issue is not whether run-time support be automated or not - just whether run-time support was mandatory. i think we all agree it would be nice to have runtime support, but can you be CPP/CPA compliant without it? the sections mentioned make assumptions it will be there, so the reader may believe it to be a requirement.
Regarding "Clarification of the role of the CPA at runtime": The main
worth of the CPA, as we have said repeatedly, is to provide parameters for
the B2B run-time middleware. That requires it to be somehow fed into the
runtime and the information used by the runtime. Figure 4 does not
preclude manually typing in the information, though we hope that vendors
will provide much more functionality. A statement that nothing in
specification requires any run-time support for the CPA would be tantamount
to saying that it is no more than a paper TPA. I am sure that you don't
want anything like that in the specification. Regarding the specific places
mentioned:
Lines 204-205 are non-normative and suggest an important signal that
should be provided between the business process and the runtime support.Line 219-222 say that information from the CPA is installed in the
runtime system but say nothing about automated installation. Typing in
the information from a keyboard is not excluded by that statement.Lines 1305-1306 are a normative statement about processing a
conversation. As I pointed out above, some level of runtime support is
necessary for the CPA to be worth anything at all.So my question is, what would the QR team like to see on this subject and I
hope that it will be more positive than removing all mentions of run-time
support. A new section on run-time support should not be necessary since
it is adequately covered in section 6, especially 6.4.
would that we could
"Table of contents. Disclaimer in section 10 does not line up with
References in section 9": This is apparently a bug in Word. There is
nothing I can do about it.
i agree on editorial comments - they are just an aid not a mandatory requirement on you !
Tim, I hope I will be credited with some judgment in handling the long list
of editorial comments. I do not want to have to spend the month of April
arguing about the ones that in my best judgment should be left alone.
--
Regards,
Marty*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************Tim McGrath <tmcgrath@tedis.com.au> on 03/05/2001 01:36:20 AM
Please respond to tmcgrath@tedis.com.au
To: Robert S Sutor/Watson/IBM@IBMUS, Bill Smith <bill.smith@sun.com>, Ray
Walker <raywalker@attglobal.net>, knaujok <knaujok@home.com>, knaujok
<knaujok@attglobal.net>, "'ebXML Coordination'"
<ebxml-coord@lists.ebxml.org>, ebxml-tp@lists.ebxml.org,
ebxml-stc@lists.ebxml.org
cc:
Subject: QR Report of Collaboration-Protocol Profile and Agreement
Specification Version 0.911The Quality Review team have completed their review of the
Collaboration-Protocol Profile and Agreement Specification Version 0.91
as submitted by the Trading-Partners team on Feb 16th 2001.We recommend that this document be released for public review
immediately.At the request of the Quality Review team, the editors have made some
non-substantive edits to document headers and footers and removed
markers and references to the Quality Review team. Hence, the version
for public review has a later version number and release date.Once again, we would like to commend the Trading Partners team for a
most professional and cohesive document. The overall quality level is
something all ebXML specifications should aspire to.Please find attached the complete report from the Quality Review Team.
--
regards
tim mcgrath
TEDIS fremantle western australia 6160
phone: +618 93352228 fax: +618 93352142
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC