Re[2]: ebXML Requirements Specification Draft

["Mark CRAWFORD"<mcrawfor@lmi.org>]

Mike,

    William is correct in that I left off the acknowledgements section.  A minor
add on Monday once we agree on who the contributors were.

William,

    WRT Mime, just as the requirements document has had to go through two review
cycles, so will the TRP document.  There are many that are opposed to just using
MIME and my guess is they will be more vocal during that review cycle.

    Mark
Mark Crawford
Research Fellow
______
LMI Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177   Fax (703) 917-7518
mcrawfor@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"



____________________Reply Separator____________________
Subject:    Re: ebXML Requirements Specification Draft 
Author: <rawlins@metronet.com>
Date:       5/2/00 9:28 PM

William,

Thanks for your comments.  Unfortunately, there is no comment
period/revision cycle on this version, since we have already had the two
periods.  We have an up or down vote on the document as is at the plenary.
If you feel your objections are major enough, then vote against the document
and we'll go through another revision.   However, in the spirit of consensus
and keeping things moving, I hope you can support the document as is.

Regards,

Mike

"William J. Kammerer" wrote:

> Mike Rawlins has invited us to review the final version of the ebXML
> Requirements Specification which will be submitted for approval at the
> plenary May 8.  See http://www.ebxml.org/specindex.htm.  Since the
> comment period on this version starts May 2, and closes May 8, I guess I
> can make some observations:
>
> (1) Front piece says "See acknowledgements" for authors.  There is no
> "acknowledgements" section.
>
> (2)  There's no problem statement; i.e., what problem are we attempting
> to solve?  What was wrong with EDI, EDIFACT or X12?  Section 1.2.2 -
> ebXML Scope - barely touches on one of the purported problems with EDI,
> in that SMEs can't or won't participate in EDI, perhaps because of
> complexity and expense.
>
> But are we serious that ebXML will "[deliver] specifications that will
> be used by all trading partners interested in maximizing XML
> interoperability within and across trading partner communities"?  The
> emphasis should be on producing a standard which can be incorporated in
> shrink-wrapped or packaged solutions, a point not made until section
> 2.2 - Conducting Electronic Business using ebXML.
>
> Another supposed problem with EDI is that it requires extensive trading
> partner negotiation up front.  This isn't mentioned (parenthetically)
> until Section 3.4 - Technical Architecture.
>
> (3) Section 2.3 - Globalization says "all ebXML technical specifications
> [in English] will be translatable into the other official UN languages-
> French and Russian. Translation into languages other than French or
> Russian is the responsibility of the intended user..."  This is
> superfluous.  Of course, English can be translated into French and
> Russian.  But are we making a promise that the UN will do so?  This was
> never done within UN/CEFACT for UN/EDIFACT directories or any other
> documents, excepting a very few in French.  I'd suggest taking out the
> entire clause about the specifications being "translatable," as it only
> detracts from the very important points that (a) we're going to work in
> English and that (b) the ebXML Repository should support alternate
> languages.
>
> Again, repeating my note from Saturday, the statement that "in keeping
> with the requirements of XML 1.0, all work will shall be compliant with
> Unicode and ISO/IEC 10646 for characters, Internet RFC 1766 for language
> identification tags, ISO 639 for language name codes, and ISO 3166 for
> country name codes" should be clarified or softened.  XML 1.0 itself has
> some requirements to use these standards (for well-formed and valid
> documents), but the business data contained within may very well depend
> on other standards (such as FIPS 10-4, instead of ISO 3166, for
> identifying countries).
>
> (4) All references to CEFACT should read "UN/CEFACT".  "insure" should
> be "ensure" in Section 3.5 -  Core Components.
>
> (5) Section 2.5.2 - Transport, Routing, & Packaging says the messaging
> system is required "to Realize reliable secure sending and receiving of
> messages over any network capable of carrying XML."  Since XML is text,
> presumably any network can "carry XML."   Since TR&P has settled on MIME
> packaging, perhaps some verbiage about "capable of carrying MIME encoded
> packaging."
>
> (6) Section 4 - ebXML Organizational and Procedural Requirements -
> should not mention private corporations or their own proprietary
> initiatives, such as BizTalk and CommerceOne, unless in an explanatory
> non-normative note to explain what we mean by "private initiative."
> Private, for-profit corporations, or their respective products and
> trademarks, should not be mentioned in the normative text.
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Memorial Pkwy.
> Dublin, OH USA 43017-3305
> (614) 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "Commerce for a New World"

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/