Re: Messaging Service spec v0-2 COMMENTS

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

In no particular order of significance my first pass is....

* line 37-38   good to reference the Glossary!
NB we appear to have two appendix Ds - the latter should be F (but we dont want to get into this level)
 

Purpose and Scope

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)?
This leads to the confusion as in ...
* 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.
* more importantly, line 130 also appears to contradict line 137 - is "behavior of the messaging service software" the same as "Messaging Service Interface Specification "?
 
 
 

Packaging Specification

* There are some issues of  style for naming, the TA team have been discussing this.  David Webber wrote to Duane and myself...

> >  I "think" the convention we are following is that we always start with
> an
> > upper case, unless the element/attribute begins with "ebXML".
>
> Unless the TA team comes up with a recommendation as to style,
> we'll have to go with upper-camel-case since that's what we started
> with (despite my preference for lower-camel-case;-)
>
> <<<<<<<<<<<<<<<<<
>
> Note to: TA / Coord:
>
> Duane / Tim,
>
> Has anything been decided on this?  This is one we should
> take care of from coordination side.  The RegRep interface
> we are working on is using lower-camel-case, and eb: as the
> namespace.
>
> Some guidelines here would be handy.
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.

* lines 211-215 and then 261-268  (charsets)
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.
 

ebXML Header Document

* lines 409-423 From and To
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.

* lines 424 -444  TPAInfo
i am not familiar with the TPA team's strategy but the same argument as for 'Party' may apply here too.

* line 455-456  i am not sure if this is too technical for our review but i dont 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.

*line 463 - 475 if reliable messaging is still to be defined is it wise to put this element in now?
This raises an important issue about propsoed method for extensibility of the Header.

* last (but not least) is Bob's favourite issue "compliance statement' - should this document have one?
 

I may add some more when i have gotten through the Appendixes.
 

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

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