[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Updated spreadsheet
All, 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. Thanks, Chris 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
- From: Chris Ferris - Sun East Coast IR Development <chris.ferris@east.sun.com>
- To: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
- Date: Tue, 12 Sep 2000 14:15:28 -0400
Here are some comments/edits for the v0.2 MS spec as we enter the final stage. Most are editorial in nature. Cheers, Chris 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 "exchange" 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 content-type. 199 1 add period after '... of a body part' capitalize 'see'. 205/6 2 remove reference to version-less envelope 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 Service' 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 2111 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 360,364,369,391,401,417,464 1 change 'ebXMLMessageHeader' to 'ebXMLHeader' 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 contributors: 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
- From: Christopher Ferris <chris.ferris@east.sun.com>
- To: ebxml transport <ebxml-transport@lists.ebxml.org>,"Eve.Maler@east.sun.com" <Eve.Maler@east.sun.com>
- Date: Thu, 14 Sep 2000 19:30:38 -0400
All, 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 revision. Cheers, Chris 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
- From: Keisuke Kibakura <kibakura@sysrap.cs.fujitsu.co.jp>
- To: ebxml-architecture@lists.ebxml.org
- Date: Thu, 07 Sep 2000 22:47:35 +0900
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. Regards, -- 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]
Powered by eList eXpress LLC