RE: Comments on Technical Architecture Specification Draft v 0.6

["Duane Nickull" <duane@xmlglobal.com>]

>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.

But William,  you are always critical ;-)

Okay - keeping in mind this is a first draft, I have had several people
(both technical and non technical read this document and they all seemed to
understand the general concepts.  The automated process for establishing ad
hoc trading relationships is very clearly defined (IMHO) however,  if you
are having trouble with specific topics, I would be glad to hear the
shortcomings.  I don't think this document should, in itself be the end all
for explaining ebXML to outside people.  This document is to define the
Technical Architecture.  Rachel's group, Marketing etc., will derive a
document meant for explaining it to the general marketplace.

>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?
TPAML is largely the process of Trading partner profiles for discovery.  All
though it is not explicity mentioned,  I believe that TPAML (and eCo) are
invaluable for the discovery of trading partner methods.
The establishment of ad hoc trading relationships is defined in section 4
and a process flow has been documented.


>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?
It is clearly documented that the Registry and Repository are the heart of
ebXML.  The system won't work without this critical piece.  Yes - we may
have gone overboard with the details of Reg Rep and we will wait for Scott's
comments.

>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.
Our goal is not to do a comparison between ebXML and EDIFACT (or any other
data standard).  We have clearly documented what ebXML has to offer that
EDIFACT and other infrastructures can't offer.  If someone wants to compare,
they have the freedom to do so.  I'm sure there will be lots of opinions.  I
just hope they come from people who understand the architecture.

I am Out of the office now for about four hours.  I will answer more later.
Thank you for your comments.  They will be taken into account.

Duane Nickull