[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Technical Architecture Specification Dated 31 August 2000
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"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC