OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Updated spreadsheet


Somehow, these were never considered and rolled into the
comments list. One of the attached emails contains my
comments on version 0.2 which never made it into 0.21.

The other contains comments submitted by Eve Maler (Sun
and member of QR team) which I forwarded with line numbers
transposed to v0.21.

I also found another comment which appears to have been omitted
from the list which should be added for consideration in the
next phase.

I would like to see that these are NOT lost. I have no qualms
about deferring these comments for consideration in phase 2.

I think that what this points out is that we need a better
system for handling comments/feedback than we have had to date.
I realize that we're all busy and also have a day job, and that
we're under tight time constraints, but we should be a bit more
dilligent in this for our future work.



maw2@daimlerchrysler.com wrote:
> Hi,
> Please find attached the updated spreadsheet from yesterday's conference
> call.
> Martha
> (See attached file: Comments on ver 0.21c.xls)
>   ----------------------------------------------------------------------------------------------------
>                                    Name: Comments on ver 0.21c.xls
>    Comments on ver 0.21c.xls       Type: Microsoft Excel Worksheet (application/vnd.ms-excel)
>                                Encoding: BASE64
>                             Description: Excel 2.x Chart

    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903

Here are some comments/edits for the v0.2 MS spec
as we enter the final stage. Most are editorial in



Line	Category	Comment
----	--------	-------------------------
103	1		change "... that describes how to
			securely and reliably exchange ..."
			to "... that enables the secure
			and reliable exchange of ..."

111, general	
	1/2		we seem to use 'enveloping' and
			'packaging' interchangeably. I think
			that we should use a consistent
			term: 'packaging'. That is afterall
			the heading on section 3.

118	1		I think that we should omit the
			version of the Overview & Req'ts doc
			in the text and leave that to the
			reference section

121	2		do we want to add 'and emerging'?

122	2		replace the term "package" with

155/6	1		is this really a convention? I would
			have thought that a convention described
			treatment of the style of the document.
			this seems to reflect a feature of
			the specification

160	2/3		technically, the ebXML message is
			carried by a transport within the
			(optional) protocol specific 'envelope'.
			Thus, technically, the (optional)
			protocol specific envelope is
			NOT part of the ebXML Message.
			Suggest that line 160 be removed

164	1		replace 'optional' with 'zero or one'
			so as not to conflict or be confused
			with OPTIONAL as described in RFC2119

165	1		remove 'if payload is present'. This
			is redundant. 

166	1 		the document might benefit from a 
			BNF description of an ebXML message.

			ebxml-message = ebxml-message-envelope
			ebxml-message-envelope = 

168	1		replace 'Envelope' with 'Container'
			so as to be consistent with line 163

173	1		replace with:
			Normative communication protocol 
			bindings are defined in Appendix E

175	1/2		I think that this is where we should
			point out that MIME headers are case
			insensitive. e.g. 
			Content-Type is equivalent to

199	1		add period after '... of a body part'
			capitalize 'see'.

205/6	2		remove reference to version-less 

208/9	2		strike. If none are defined, we should
			simply omit this concept.

231	1/2		add 'Envelope' as the Header container
			is the first body part WITHIN the
			Envelope, not the first in the
			ebXML Message.

239	1		replace 'enhanced' with 'modified'

240	2		XML DSig may permit modifications
			to the Header document without violating
			the signature. Not sure if we
			want to point this out. Possibly, we 
			should omit this paragraph (239/242)
			in lieu of delivery of the Security
			spec draft.

244	1		change 'header identifies' to:
			'header uniquely identifies'

245	2		do we want to reference RFC 2392 here?

284	1		capitalize MUST NOT

287 	2		do we want to reference RFC 2392 and
			2557 here?

297	2		do we want to permit use of the
			Content-Location header as described
			in RFC 2557. If so, then the text
			should reflect that the Content-Location
			header MAY be present, etc.

311	1		is Content-Type value determined by
			the implementer? I would think that
			a more correct statement would be that
			it is determined by the application
			which creates the message.

336	1		replace 'comprised of' with 'MUST have'

338/9	2		we need to get closure on a namespace
			scheme for ebXML. I have sent email
			to ebxml-architecture for guidance.

343	1		replace 'communication' with 'Message 

345	1		add 'attribute' after MessageType

350	1		replace 'contains' with "MUST have"

356	1		strike this sentence. It is redundant
			of the previous sentence (with the
			suggested edit for line 350).

366	1		capitalize REQUIRED

369	2		do we want to reference RFC 2557
			to describe how CID may be used as
			a URI within the Manifest element?

374	2		there are three possible elements
			not two. Two are REQUIRED, one has a
			cardinality of zero or one.

374	1		capitalize REQUIRED

376	1		replace 'an optional' with 'zero or one'

377	2		is it a code? I would think that this
			might be misconstrued. It could be
			the value of the root element of
			an XML document, it could be a code
			from some context. It is also not
			clear to me that the "purpose" is
			necessarily conveyed. I might send
			a PurchaseOrder with the "purpose" of
			initiating a purchase agreement. I
			might also send it to revise a previous
			agreement. In either case, it is still	
			a PurchaseOrder. The purpose or intent
			is intended to be conveyed with the
			ServiceInterface and/or Action elements
			of the Header.

379	1		replace 2111 with 2392 which obsoletes

379	2		do we want to reference RFC 2557:
			MIME Encapsulation of Aggregate 
			Documents, such as HTML (MHTML). This
			would help in the understanding as
			to how this should be treated by
			a parser.

386	1		need an example which better
			reflects the recommended 
			<authority><local> scheme for 
			generating a globally unique id.
			Note that I could find no reference
			to this in RFC 2392 as suggested
			in some of our discussions. Perhaps
			I have the RFC # incorrect?

390	1		capitalize REQUIRED

	1		change 'ebXMLMessageHeader' to 

392	1		capitalize REQUIRED

450	1		an example MessageId would be useful

454	1		replace 'an optional' with 'a'

510	1		add the following to list of

			Philippe DeSmedt - Viquity
			Gordon van Huizen - Progress
			Jim Hughes - Fujitsu
			Nicholas Kassem - Sun
			Nikola Stojanovic - ebXML Architecture Liason
			Marc Breissinger - webMethods
			Joe Lapp - webMethods

appologies if I've omitted anyone else who feels that
they have contributed. Please feel free to let me, Rik
or David know who you are and we will add your name to
the list of contributors.

                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Enterprise Architect - EMA 
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063      
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903


Eve Maler (a Sun member of QR team) has reviewed the MS 0.2 spec 
and offers the following comments/edits. (Thanks Eve!) I have taken 
the liberty to translate the line numbers (and in certain cases, the 
comment) to 0.21 so that we can focus on that as our base-line for subsequent



line	category	comment
----	--------	-------------------------------
160	1		version 0.2 had the adjective "conditional"
			version 0.21 omits that adjective. Clearly,
			it is conditional because not all communication
			protocols have one. Thus, we need to rephrase
			this and we need to elaborate on what makes it
			(the outer Transport Envelope) "conditional" (whether the
			communication protocol requires or adds one)

194	1		can't reference [XMLMedia] as normative (yet)
			(CBF: should add non-normative reference section)

212/3	1		definition of Content-Length is ambigous
245/6			(CBF: I tried to find a definitive RFC which 
			specifies how Content-Length is to be calculated,
			but came up dry... anyone have a reference we
			can cite?)

260	1		change 'encoding attribute' to 'encoding declaration'

337 + 357	1	suggest use of 'urn:' form instead of 'http://' for
			namespace. (CBF: this seems like a reasonable suggestion
			Suggest that TA be given the task of defining namespace
			syntax and handling. e.g. urn:ebxml.org:namespaces:messageHeader
			instead of http://www.ebxml.org/namespaces/messageHeader)

1288/1300	1	formatting is weird. remove italics.

    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903

Hello all, 

Comments on the latest draft. 

In section 6.7(??wrong sec number??), "General ebXML Design 
Requirements", at the first line, we should mention multi-language 
capability of ebXML spec. clearly here, instead of just saying 
about character encoding.  It should be like this: 

      All partipating components in ebXML MUST facilitate 
    multilingual support.  ebXML specification MUST be 
    compliant with Unicode and ISO/IEC 10646 for character 
    set, and UTF-8 or UTF-16 for character encoding.  

(Note: if any other encodings is permitted in addition to UTF8/16, 
careful consideration should be given on whole ebXML spec, 
for instance, charset parameter in messaging layer, way of 
character set negotiation in tpa, etc...) 

Use of language identification in an element in XML instance should 
be recommended explicitly, since it is often useful for processing 
multilingual XML documents.  Some statements like below needs to 
be here: 

    An attribute "xml:lang" MAY be inserted in an element to 
    specify the language in which the content is written, if
    explicit identification is needed.  The value of attribute
    complies with the section "1.12  Language identification"
    in XML 1.0 specification.  

Section 10.4.2 should be removed.  General ebXML Design Req. 
section covers this. 


Keisuke Kibakura,  FUJITSU LIMITED
e-mail: <kibakura@sysrap.cs.fujitsu.co.jp>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC