Technical Architecture Specification Dated 31 August 2000

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

Duane Nickull says "we should send [Technical Architecture Specification
Dated 31 August 2000] to the plenary for a wider cross section of
comments."  He goes on to say "This isn't the final version going out
for a final vote.  It is a first draft for the first comment period.
Accordingly, we feel it is necessary to solicit comments from the
plenary."  See ebXML_TA_v0.8.71.PDF in the TA private area at
http://www.ebxml.org/project_teams/technical_arch/private/.

Dear Duane:

I thought we had a process - first it would go to QR, and then it would
be made publicly available for comments on the ebXML listserve.  Is that
what you mean by "plenary"?  If so, that would give it enough chances to
be cleaned up before being presented to the real "plenary" (which is
where people get physically present in Tokyo).  By the time a document
gets to the plenary, it should be all cleaned up.  "We want to solicit
comments from the plenary.  typos .... hardly warrant the spec from not
being circulated."  Typos might be tolerable in a document discussed on
the listserve; it's not for something circulated at the plenary.

Further, you've written: "We need to have this specification out ASAP
becuase no other work can be done without it.  How can you think of
approving other teams' specs when you don't have an architecture to show
what functionality they must provide???"  and "All other work by the QR
team needs to be put on hold.  THis is a point of procedure.  They
cannot approve drafts by other teams without knowing how that work fits
into the ebXML architecture!!!!  Will the work meet the needs of the
ebXML architecture???  HOw can the POC team begin to sanction work
without knowing how that work will sit with the ebXML infrastructure??"

TRP didn't seem to have any problem putting together the MS specs w/o
the TA document.  Maybe we have it backwards - maybe the TA spec should
be written only after we have a pretty good idea of what the other
groups' work products will consist of.  I agree with Murray Maloney:
"the sun will continue to rise while we await an architecture spec."
Work can continue in the other groups, and QR can continue to review
their specs. TR&P will undoubtedly have specs ready by Tokyo, and
perhaps even BP. Core Components will probably not have anything,
whether or not an architecture spec is available.

The reason the TA spec is so important is that it would be the main
document read by technical people evaluating ebXML, who at the same time
don't want to get into the minutiae of the other groups' specifications.

It should be a good overview of ebXML, and should be a pleasure to
read - a (or my) requirement not imposed on the detailed specs.  This
draft is not a pleasure to read.  I feel scolded at every turn with the
SHALLs and MUSTs.  We might consider using the RFC type Requirement
Levels only in the detailed specs, not the Architecture document.
Agreeing with Christopher Ferris, I think it still reads like a
Requirements spec.  A technical person should be able to read this and
say "Eureka!! I think they've got it!!!"  The scales should fall from my
eyes, and I should wonder how or why anyone could or would have used
stinky old EDI.

Nagwa wants high level use cases.  I'll be honest and say I really don't
know what a use case is.  But the detailed "use cases" presented in the
document have mostly to do with the registry and repository.  But this
is not the Reg Rep spec, so why only have use cases for Reg Rep? Krishna
Sankar suggests we have more use cases.  I suggest we have fewer, and
higher level.  It's painful to read stuff like "Success End Condition: A
modification is made to the Core Component" and "Failed End Condition:
No modification is made to the Repository Item."  And it can't be any
fun to write this stuff, either.

Krishna also says the sample files section is good.  All I saw were
example sections with Editor's notes saying that the other groups had to
supply the samples, and that the sample presented was a "placeholder
only to visualize the functionality of the document."  There's really no
need in an architecture document to have detailed examples of XML
documents;  and besides: how would you ever complete the TA if you
depend on detailed XML examples from the other groups - assuming they
need the TA to finish their work?

Having said that, I have a litany of specific questions, complaints and
requests pertaining to the document.

Pg. 1, Line 14: "20/9/2000 and be closed on 4/10/2000."  This weird date
format is neither American nor European.  We all need to get used to the
ISO 8601 Extended Date format for our documentation - e.g., 2000-09-20.
We're supposed to be using international standards.

Pg. 6, Line 27: the Requirements Spec  (approved at the Brussels meeting
12 May 2000) is at http://www.ebxml.org/specdrafts/ReqSpecv1-0.pdf.

Pg. 7, Line 17.  "1. XML v 1.0 specification
(www.w3c.org/xml/TR/021998.html)" The exact name is "Extensible Markup
Language (XML) 1.0 Specification," at http://www.w3.org/TR/REC-xml.

Pg. 7, Line 18. How is ISO 11179 Metadata Repository relevant to the TA?
If it isn't (and it's never referenced in the TA spec), then don't list
it.  Why aren't XMI, UML, ISO 10646 listed, which are actually
referenced in the body of the TA spec?

Pg. 8, Line 2. 4.1 Goals: "shall be used by all ebXML project teams in
determining the areas of responsibility in developing the ebXML 1.0
Standard, and shall guide their efforts in developing the technical
specifications necessary to satisfy their respective requirements."

Since the TA is not yet approved, and by your statement is new since San
Jose, it apparently wasn't used to guide the TR&P MS specs nor the Reg
Rep specs.  Maybe we have the cart before the horse - perhaps the TA
should be done *after* the other specs to bring the entire Framework
into perspective.

Pg. 15, Line 8: will most likely contain only DTDs *and schemas.*  By
the time we're done, I would expect the W3C schemas would be the
preferred and most common means of constraining Documents.

Pg. 15, Line 9: "The entire infrastructure [of the Registry] has been
architected to be *agonistic* to the syntax of the associated meta data
mechanism." "agonistic" or "agnostic"? It can't be Agonistic.  Agnostic
means [God is] unknowable.  But the syntax in this case is certainly
knowable: you're just saying the Registry doesn't care - so use
"neutral" or "independent of...", as Christopher Ferris suggested
earlier.  Each group, including TR&P, should excise the unfortunate
adjective "agnostic" from their vocabulary - it's incorrect as often
used, and could be offensive.

Pg. 15, Line 19:  What provision is there for one to define their own
core components (prior to "official" approval) and place it in a
"private" registry for shared use with anybody the TP desires?  I think
Christopher Ferris already asked this in a more circumspect way.

Pg 25. has the example of the telephone no. Core Component.  This is
confusing, contrived and superfluous, as I noted in Re: TechArch V0.5
Comments, of 29 Apr 2000, at
http://lists.ebxml.org/archives/ebxml-architecture/200004/msg00044.html.

And what's the difference between a Core component and a Common Business
Object?  I get the impression that a CBO is composed of one or more core
components.  But that's not explicitly stated.  And why not simply use
one term, like in OO programming - class or object.  An object is an
instantiation of a particular class, though I'm not going to quibble
over terminology.  Is this Core Components terminology?  The last I
heard, CC doesn't use the term "object" because that's like a "virus."
Whatever the hell that means.

Pg. 19, Line 40: Are these requirements for adding new Business Process
models and core components?  Or for anyone who is going to trade with
another?  If the latter, this is an onerous requirement on TPs who which
to use standardized messages and Business processes - why can't they
just refer to standardized registry BPs, components and TPAs and
commence trading? Why would they ever have to register with a central
authority?

Pg. 31, Line 14: "The current views of Registry and Repository
functionality also violate one of the key rules for architecting ebXML."
Does that mean that the Reg Rep group has it all wrong?  And why would
this statement be an architecture document which is to stand for all
ages?

Pg. 32, Line 1.  "Current Centralized Repository Approach"   Now it's
clear the TA is reproaching Reg Rep for it's supposedly inadequate
design.  And it may very well be inadequate, but we don't need to show
our dirty linen to the world in our Architecture paper.

Pg. 36 Line 31.  GUID defined as "a combination of URN and a CDATA
suffix that SHALL not exceed 8 bytes in length. "  Why not the same kind
of GUID as used in UDDI for its keys? - the 128 Bit Global Unique
IDentifier; e.g. a4f8a400-16b7-11ce-80eb-00aa003d7352. If you didn't
mean the same thing (though I see no reason to be different from
everyone else when it comes to GUIDs or UUIDs), then don't call your
thing a GUID. See
http://msdn.microsoft.com/library/books/inole/S10E8.HTM.

Pg. 38 Line 38. "TRP work"  Don't refer to ephemeral working groups
within ebXML; refer to the product - "Messaging Services" - instead.

Pg. 38. Line 39. "CORBA and DCOM for object oriented operation." The
current Transport, Routing & Packaging Messaging Service Specification
(13-September-2000), ebXML Messaging Service Specification v0-21.doc,
doesn't refer to CORBA nor DCOM.  These are binary procedure-call
mechanisms - whatever do they have to do with transporting MIME
encapsulated payloads?

Pg. 42, Line 20: "Payload agnostic."  Agnostic means [God is]
unknowable.  The payload can be determined - but MS just doesn't care.
So say payload "independent" or "neutral".  All other instances of the
word "agnostic" should be similarly replaced.

Pg. 73.  Line 32. Why not dispense with "a special Logic Engine
component," and just send the entire telephone no. in a standard
International format?  I don't think anyone is confused by my telephone
number +1 614 791-1600.  People in my area code, anywhere in North
America, or anywhere in the world for that matter, would know how to
dial me once they learn the ITU-T Rec. E.123 format.  Eric Brunner
touched on this in RE: on the issue of PartyId, at
http://lists.ebxml.org/archives/ebxml-transport/200009/msg00267.html.

Likewise with a currency - do I need "a special Logic Engine component"
to determine the currency an amount is denominated in? Will I have to
decide based on the location of the seller? The customer?  His bank?
All ambiguity is removed by specifying the unit of currency with a
standard ISO 4217 code: e.g., "AUD",  "USD" or "CAD" as the default
currency (in the message of the TPA) or explicitly include with amounts.

From the ebXML Requirements Specification (12 May 2000), there are a
number of detailed requirements and deliverables missing from the
Technical Architecture specification.  See section 3.4 Technical
Architecture Framework Requirements. For example, I don't think the TA
spec has touched on "design guidelines for ebXML compliant messages,"
and may have even dismissed the concept altogether by "moving away from
a document centric world" in the Introduction.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"