Re: ACTION: REVIEW - ebxml Messaging Services spec v 0.2

[Tim McGrath <tmcgrath@tedis.com.au>]

Last week, the Transport, Routing, & Packaging team submitted "Messaging Service Spec v0-2" to the Quality Review team for review. Today (Monday, Sept. 18) is the end of the five business-day period for QR team review.

Attached below is a summary of all comments prepared by Joe Baran on behalf of the QR Team

 
It appears that the consensus of all who have commented is that the document should be forwarded to the Executive Committee with a recommendation that it be released for the first period of review by the full ebXML membership.
 
 
 

P.S.

In the meantime, there has been continuing discussion and comment on the referenced document on the TR&P list, including the posting of a minor revision (v0-21). I have reviewed the "deltas" between v0-2 and v0-21 (by using a "Compare Document" on the Word versions), and they appear to be minor editorial corrections. I expect that the TR&P team would actually like to release v0-21. The QR Team has no objection, but the idea of setting a precedent of "submit one version for QR review and then promote the next version for public comment" needs to be monitored.

Rik Drummond wrote:

for QR's review.

Please Note: the spec is NOT in the new ebxml document format yet. the
editor doing it is on vacation. everything else is ready for your
review.....
thanks, Rik
 

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142
 

Title: Messaging Service spec v0-2 QR summary

Item

Reference

No.

Submitter

Line

Email

Comment

1

Tim McGrath

110-115

14/09/00

This section has some ambiguities.  What is the rationale behind putting the Message Service Specification as one document when it is clearly incomplete? This does not seem to be an umbrella specification with place holders for the missing sections.  Why not have the security, extensibility, service interface, reliability, and versioning  as separate documents (as I think they once were)?

2

Tim McGrath

114-115

14/09/00

lines 114-115 appear to contradict lines 130-133. It is not clearly stated that Message security, extensibility, service interface, reliability, and versioning are  not yet in this document but will be later.

3

Tim McGrath

130,137

14/09/00

more importantly, line 130 also appears to contradict line 137 - is "behavior of the messaging service software" the same as "Messaging Service Interface Specification "?

4

Tim McGrath

(general)

14/09/00

There are some issues of  style for naming, the TA team have been discussing this (I.e., "upper-camel-case" vs. "lower-camel-case" etc.)  Duane has subsequently put this issue on the TA Team agenda.  I suggest we ask the TRP Team to adopt the TA Team recommended conventions.

5

Tim McGrath

211-215;261-268

14/09/00

Both claim to be "The charset attribute is used to identify the character set used to create the message" and yet propose different  values. I think it means the outer  and inner encoding methods but if so it should not use the same first sentence.

6

Tim McGrath

409-423

14/09/00

We should make note that these elements are a context of the Core Component known as 'Party'.  As such there may be alignment issues when the Core Components are defined.  TRP needs to confer with CC on an interim solution which allows future compatibility.

7

Tim McGrath

424-440

14/09/00

I am not familiar with the TPA team's strategy but the same argument as for 'Party' may apply here too.

8

Tim McGrath

455-456

14/09/00

I am not sure if this is too technical for our review but I don't see why we need to mandate that previous MessageIDs must be valid.  How would that work in practice? no-one is going to control this except the trading partners and then it forms part of their agreement.

9

Tim McGrath

463-475

14/09/00

If reliable messaging is still to be defined is it wise to put this element in now? This raises an important issue about proposed method for extensibility of the Header.

10

Tim McGrath

(general)

14/09/00

"compliance statement' - should this document have one?

11

Nagwa Abdelghfour

(general)

15/09/00

I think this spec is in a good shape to pass. I know that the spec does not yet include security and reliability as these are being worked separately, but I think we just need to note that in our report.

12

Bob Glushko

(general)

17/09/00

I didn't see anything in the messaging spec that warrants us not letting it out for general review, except for the point already amply made that  the metainformation that security and reliability considerations were explicitly deferred should be prominent in any call for review. Otherwise these are too obvious omissions and will attract comments that aren't relevant to this round.

13

Joe Baran

(general)

18/09/00

I agree that there are no issues serious enough to warrant delay of progress of this spec. I agree that the "to be determined" parts on Reliability, Security, etc. should be at least indicated with placeholders (if they are indeed to become part of this spec), or referenced in section 1.2 (if they are to be separate documents).

14

Joe Baran

(general)

18/09/00

While it is true that the requirements have evolved since the publication of the TR&P Overview & Requirements (v 0-96, 26-May-2000), I think it is important that the requirements and the current document plan be aligned. Either that, or scrap the TR&P Overview & Requirements document (clearly, the former is a more desirable approach!)

Messaging Service spec v0-2 QR summary.xls

begin:vcard 
n:McGrath;Tim
tel;pager:+61(0)299633829
tel;cell:+61 (0)438352228
tel;fax:+61(0)893352142
tel;work:+61(0)893352228
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:tmcgrath@tedis.com.au 
x-mozilla-cpt:;-19376
fn:tim mcgrath
end:vcard