RE: Karsten's concerns

[Brian Eisenberg <BrianE@DataChannel.com>]

Jeff et al - 

>>>>Comments below

-----Original Message-----
From: Jeff Suttor [mailto:Jeff.Suttor@eng.sun.com]
Sent: Monday, October 16, 2000 11:26 AM
To: ebxml-architecture@lists.ebxml.org
Subject: Karsten's concerns


------------- Begin Forwarded Message -------------
To the TA list,

In order to get my comments in before this document goes to QR (which I
understand is to happen by end of today), I list here my high level
concerns:

This should be the EBXML ARCHITECTURE document. Other than a brief into,
there
should be only ebXML stuff there, and there should be only architecture
stuff
there.

>>>>There are many different opinions on this matter. I've spoken with some
people who feel that the architecture document will be the first document
that SMEs (and other implementers) will turn to when considering an "ebXML
solution". This scenario underscores the fact that in addition to describing
the overall architecture, we need to at least give a brief introduction to
ebXML, the problems we are solving, and a bit of history precluding the
ebXML effort. I believe that the intro accomplishes this and sufficiently
prepares the reader for the architecture discussion that follows. 

The chapter (9) on open-edi should be moved to a separate whitepaper on the
history of ebXML.

>>>>We use the open-edi section to set the stage for the discussion that
explains the ebXML architecture in terms of the BOV and FSV. This section
also provides some background discussion on how ebXML differs (and draws
upon the successes/failures) of past edi efforts. 

There should be no references to object-oriented technologies. That is not 
the focus of ebXML and ebXML should not dictate one type of implementation.

>>>>
<Duane>
OO has to be included as a cornerstone for the arhchitecture.  
If we delete all references to OO modeling,  we basically have to remove
UML (dependant on use of OO methodology), COre COmponents (ditto) and
the entire Registry/Repository section.  All of these depend on OO
technologies.  Therefore, I strongly assert that it must remain.
</Duane>

Chapter 8 should be simplified. Fewer steps, and they should align exactly
with the summary of the architecture components, and we should show a
picture
of those components. 

>>>>Our goal in this section was not to explain each component in the
architecture, but rather to give an overview on how an "ebXML
system/scenario" might transpire. Our goal was to inform and educate by
example. Also, Section 12 explains the architectural components in more
detail. I somewhat agree that Chapter 8 might benefit by being simplified in
some manner. 

In chapter 11 we should remove all reference to methodology and place it in
the ebXML methodology documents. On figure 3, all the 'artifacts' are
methodology artifacts and should not be shown. The discussion of first
phase,
analysis phase, design phase should be dropped altogether.

>>>>>>>>The only reference I see to methodology is to the "business process
and information modeling methodology" - which is actually a typo...this will
be changed. With respect to the "artifacts" vs. methodology discussion, we
use the term artifacts to highlight the fact that the items in each of the
boxes are instantiated as documents, files, etc. This is a key diagram
because it illustrates the process of taking abstract "business knowledge"
and transforming it into tangible assets (e.g. documents in the form of use
cases, class diagrams, which ultimately make up a buisiness process and
information model. With respect to describing methodologies in the
architecture document, I don't fully agree with this statement. Perhaps for
phase II of ebXML we can generate a separate methodology document, but we
feel that it is important to include some basic methodology as part of the
architecture. We will take this into consideration and will act accordingly.


In chapter 12, the section starting "This XML based business information" is
too detailed for this early place in the document. If UID's are overall
design
principles, they should be in the separate section, as suggested earlier. 

>>>>I generally agree with the first statement that the UID discussion
should be moved to the RegRep section. 

Then starting on page 15, section that says "Implementers will download"
is the start of a whole long methodology discussion that runs on into
chapter
13, 14, 15. I suggest that all of that block, including 13/14/15
belongs in a methodology document, not in an architecture document. 

>>>>See comments w/r/t Chapter 11 above.


--Brian