Comments on Technical Architecture Specification Draft v 0.6

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Duane Nickull has invited all ebXML participants to examine the
Technical Architecture Specification Draft v 0.6 at
http://www.ebxml.org/working/project_teams/technical_arch/.

To be honest, I'm no expert on writing technical architectures.
Nonetheless, I'm not stupid, yet I still have no idea what comprises
ebXML's architecture even after reading this document.  I hate to be
critical, but keep in mind that I love you all and am on your side;  the
outside world will be far more critical if we can't explain what this is
all about. Or even worse: they will ignore us.

For example, the goals at line 252 are fine, but nowhere in the document
are most of the items addressed. I'd love to see some high-level
discussion on how ad-hoc trading relationships would be established, but
none is forthcoming.  How did Open-EDI address this, if at all?  Is
TPAML to be used for this?

And why so much stuff about the Registry and Repository (in Section 2)?
Isn't this within the bailiwick of the RegRep group?  Is it consistent
with ebXML Registry and Repository Part 1: Business Domains (the one
with all the stick figures)? Surely, the Registry and Repository can't
be the centerpiece of ebXML:  why discuss at the expense of explaining
the architecture of ebXML itself?

For example, I'd expect processes to be explained and illustrated, the
role of acknowledgments covered,  and an explanation given on how XML
and related standards allows whatever we want to do to be done easier
than with EDIFACT.

Doesn't 2.3 Modeling Data Elements belong to Core-Components?  It still
reads much as before (in TechArch V0.5).  My comments at
http://www.xml.org/archives/ebxml-architecture/2000/04/0044.html seem to
have been ignored altogether, even if this stuff belonged in
Architecture rather than Core Components.  And section 3 seems to
contain requirements for TRP (which should have been covered in the
Requirements spec);  why is that here at all?

Other than these major concerns, I have a list of minor problems:

Line 94: The ebXML (electronic business Extensible Markup Language) is a
United Nations CEFACT/OASIS sponsored initiative. The ebXML has ...

United Nations CEFACT needn't be spelled out: use UN/CEFACT instead.
Remove definite article in "The ebXML ..." or change to "The
initiative..." or "The ebXML initiative..." in this and all subsequent
places throughout the document.

Line 102: Figure 1.0 Notations such as "BP" and "TRP" are defined
nowhere in the document.   "Technical Content"  within "Message" box
maybe should read "Implementation Content" or something like that to use
the same terminology as TMWG.  Anyway, I'm suspicious of diagrams with
too many geegaws and arrows;  can a few English paragraphs be used to
explain the diagram?

Line 145: Are SMEs equipped to use UML?  Not necessarily -because they
will use shrink wrapped or ASP solutions which will have ebXML embedded
within. Don't even pretend that a mom-and-pop third world company is
going to bother with ebXML and repositories and registries.

Line 164: Meet the real needs of businesses in terms of legal,
functional and equitable architecture.  Legal and functional I can guess
at (i.e., privacy issues addressed by signatures and encryption, and
legal acceptances based on application acknowledgments), but whatever
does "equitable" mean in this context?  Is this another PC term?

Line 167: "Specify an easy on ramp and quick learning curve for
companies in developing nations. Provide companies in developing nations
an easy on ramp and quick learning curve."  Don't the two sentences say
the same thing?   "on ramp" should be "on-ramp".  And anyway, this is
condescending: companies in the third-world are no more stupid than
those in Christendom.  No small company anywhere really wants to jack
around with the stuff described in this document.  If ebXML doesn't make
the production of shrink-wrapped interoperability solutions any easier
than EDI does, then we may be wasting our time.

Line 180: "Facilitate multi-lingual (multi-byte character set) support."
Multi-lingual is not the same thing as multi-byte.  Maybe "Facilitate
multi-lingual support using a multi-byte character set."

Line 230: "A message that is conformant to the ebXML specifications but
does not claim to be an ebXML compliant message is not considered within
scope."  Define "conformant".  Is an X12 or EDIFACT message which can be
carried in the TRP framework "conformant" (though not compliant)?

Line 242: "...ebXML should make use of the 20+ years experience gained
from EDI particularly the ability to define real world business
processes in electronic semantics."  What are "electronic" semantics? Is
there a better adjective?

Line 287: "Standard conventions of major.minor as defined by ISO [Ed.
Note - INSERT 287 STANDARD HERE] shall be applied (e.g., version=
“1.17”)."  I don't think there's such an ISO standard, though there very
well may be an general IETF RFC along the lines of  RFC 2145 (Use and
Interpretation of HTTP Version Numbers).

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"