[Fwd: comments on version 0.7]

[Christopher Ferris <chris.ferris@east.sun.com>]

-------- Original Message --------
Subject: comments on version 0.7
Date: Fri, 21 Jul 2000 17:15:51 -0400
From: Christopher Ferris <chris.ferris@east.sun.com>
Organization: SunIT - EMA Applications Architecture
To: "'ebxml-architecture@lists.ebxml.org'" <ebxml-architecture@lists.ebxml.org>
CC: Christopher Ferris <chris.ferris@east.sun.com>
References: <25D0DF2980A7D311AB1C00508B91BD2AF296D6@belmail1.datachannel.com>

Some comments on the latest draft. In general, I like the
direction that the document seems to be taking. Some of the
comments in my previous posting (16 July) still apply.

Cheers,

Chris

- line 180 - seems out of scope as written. Would prefer
something along these lines instead:
"Provide a framework which facilitates the ability to
coalesce the structure and content of divergent XML vocabularies"

I don't believe that any of the specifications will actually
specify the coalesced vocabularies.

- line 191 - nice!

- line 195 - I also like the sentiment here, but think that it 
could (and should) go further to stipulate an architectural principle 
that:

ebXML "components" (TR&P, RR, CC, BP) shall be designed such
that they are loosely coupled, yet highly aligned to enable
trading partners a gradual adoption of the framework components
of the ebXML infrastructure. 
 
- line 215 - seems somewhat incomplete

- line 218 - would prefer:

Transport Routing and Packaging Specification: specifies a
platform neutral protocol for the packaging of messages
and the secure, reliable exchange of messages between trading 
partners.

- line 225 - I think that this needs to be settled once and for all. 
It is not clear to me that CC is going to actually deliver any components,
only the framework (metamodel, etc.) and possible methodology for 
defining and deriving them in a context-sensitive manner.

- line 235 - please refer to my previous comments on this item.
What exactly *is* an ebXML message? Is an EDIFACT or X12 payload carried
in an ebXML MIME multipart/related envelope, with an ebXMLHeader
an ebXML message? If not, why not? 

- line 239 - please refer to my previous comments on this item
in my email of 16 July. This also seems to be in conflict with
1.1.i (line 191).

- line 982 - now we're cooking!

- line 987 - strike 'or application'. I would also recommend that
the three items be reordered B, C, A so that A has context of B and C
(the cart is before the horse here).

- line 1004 - it isn't clear to me that we can make this claim.
I am assuming that by application, you mean business system,
but it is clear to me that this needs to be clarified as it is
far too broad a statement.

- line 1007 - this belongs at the begining of the document and
I still think that it should reflect a reference to RFC2119.

- line 1019 - is an implementation a whole, or can it be a part?
I can certainly conceive of having independent components in which
case they could not possibly implement *all* of the reqired interfaces
in 'this'(?) specification. I think that this needs to be scoped
such that an implementation shall implement all of the required
interfaces of the applicable specifications. 

- line 1031 - I think that this needs to be clarified. It is a bit
vague. Something like:

ebXML implementations which add extensions beyond the ebXML specified
interfaces and functional requirements shall not impose use of
these extension features on other ebXML compliant implementations.
These extension features must be optional.

- lines 1151 & 1157 should precede this section (again, cart before
horse). They probably belong in section 5.3.


-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903