[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Comments on Technical Architecture Specification Draft v 0.6
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"
Powered by eList eXpress LLC