Subject: RE: Fantasies
I actually was trying to make three points. Identification of the location of the SWIFT document was important, but more importantly, I was eager to hear Kris's response to the 11 issues I raised. I'm still waiting. I also wanted to once again make the point that we lost sight of in ebXML - we need a standard XML vocabulary, consistent set of Schema design rules, and standard schema's to support using XML in B2B environments.
WRT your question "are we in trouble?", I think we can't answer that until the 11th of May. If Core Components can deliver technical specifications that 1) clearly establish a definition of a core component that can be agreed to by both the business experts and the modeler's, 2) a proven methodology that ensures consistent discovery and development of core, aggregate, and family (or whatever the latest word for this is) components, 3) a methodology for storing the core as both XML and object representations, 4) and methodologies for converting the core, aggregate, and family into XML, EDI, or object messages, then we are not in trouble.
Can it be done? Only the folks involved can answer that for sure. The joint EWG/X12 Core Component initiative is ready to aggressively step forward and use those specifications to a) validate the ebXML core library and discover/develop additional ones. We have already had several meetings, are developing policy and procedures for how we will operate, and anticipate moving forward once ebXML finishes. If the specifications are not finished, or not satisfactory, then we are ready to finish that work as well.
We are also ready to take the lead, in a standards environment, to develop the XML piece that is still missing. To that end, both EWG and X12 are pursuing the possibility of an arrangement with XML vendors to leverage the core components into a standard XML vocabulary and build schema's predicated on consistent design rules. Unfortunately, the longer we have to take to actually develop the specifications to ensure consistent core component methodologies, the more we delay that effort! With all due respect to our ebXML brethren in the technical project teams, they are creating interconnectivity - not interoperability. The interoperability piece will only come with standardization of the payload, not the wrapper and means for exchanging it.
Research Fellow - XML Lead
Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177 Fax (703) 917-7518
Wireless (703) 655-4810
"Opportunity is what you make of it"
> -----Original Message-----
> From: William J. Kammerer [mailto:email@example.com]
> Sent: Thursday, April 05, 2001 7:02 PM
> To: 'ebXML Core' (E-mail)
> Subject: Re: Fantasies
> Mark Crawford asked Kris Ketels for the "SWIFT draft design rules for
> this 'automatic' mapping between UML and XML."
> Stuart Campbell was kind enough to attach an e-mail
> describing where to
> find the "swiftML design rules Technical Specification;" see
> Basically, you go to http://www.swift.com/, and under "Products &
> Services," select "swiftML" on the left.
> So now I'm convinced that some people can go from UML models
> to schemas.
> That's nice, and I never doubted that it could be done. But that
> doesn't address the main point I was making regarding the fantasy of
> auto-conversion between syntaxes, e.g., UN/EDIFACT and ebXML Core
> Components. And after all this time, we still don't have an
> approach to building Core Components; nay, we don't even
> agree on what
> a core component is! Are we in trouble?
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: firstname.lastname@example.org
Powered by eList eXpress LLC