Re: [ebxml-msg-comment] Comments on ebXML Messaging Services 3.0Conformance Profiles Public Review 01

Two additional comments.

[7] 

Is this one normative or not? It apparently is not per the abstract, 
Perhaps the mixed tables are
intended as the conformance information, but there still needs to be a
simple set of conformance clauses.

Thinking more about Conformance Profiles version 1.0 and the AS4
profile, I'm concerned
that without rationale that one set of profiles is non-normative, and
the other one one is? Why the difference? This should be clear in both
documents, and
conformance sections included.

[8] Editorial Major

I am puzzled that the editorial look-and-feel is very different between
this and AS4 PRofile Version 1.0. Perhaps they could be better
aligned, or if there's a convention that I'm missing, create a
Typographical Conventions section is 1. (see SCA Assembly for one
example, though an imperfect one).

Thanks!

bill

--

William Cox

Email: 

Web: http://www.CoxSoftwareArchitects.com

+1 862 485 3696 mobile

+1 908 277 3460 fax

William Cox wrote:
I'm offering these comments on your specification as a
member of the
OASIS Technical Advisory Board.

  

Comment numbers in square brackets. References are to the PDF.

  

[1] Technical Lines 30 and references

  

I'm confused by normative references in a non-normative supplement.
This could be explained better in the abstract and the introduction.

  

[2] Minor Editorial

  

Line 177 last characters are "RM V23" which should be "RM V2/3" to be
consistent with the rest.

Line 178 change "excepts" to "except".

Line 228 delete "to be considered"

Line 237 delete "an already pervasive"

Table after line 253 Security, no bullet at second line.

Line 279 change "Fore" to "For".

Line 360 keep table heading with table.

Line 400 table V2 Reliability and others - why does font change in
middle? I presume this is to match some format in another document, but
it's confusing.

  

[3] Technical lines 201-203ff

  

The keyword MUST is used in ordinary text; also a normative requirement
in a non-normative specification is confusing. RFC2119 does not require
that the case be all upper. See lines 269, 411, and do a global search.

  

The nature of the apparent requirement e.g. Reliability in table after
line 253 is diminished by not making clear the normative and required
nature in keeping with the terminology. In the Security section of that
table, bullet four, "attachments required." is also inconsistent with
typical statements.

  

[4] Technical Line 412ff

  

This is well chosen - good job.

  

[5] Technical line 450-456

Spacing is strange; a URI is generally done in one of the shaded
format.  AFter Line 455 add "but such profile is not defined here."

  

[6] Appendix A Table after 482

  

There is no guidance on how to define mandatory, optional etc. Should
this have a reference?  If not, it should be better described as to
what values and content.

  

  
-- 

  William Cox
  

Email: 
  

Web: http://www.CoxSoftwareArchitects.com
  

+1 862 485 3696 mobile
  

+1 908 277 3460 fax