[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: CSG Answers to Mark Crawford's Questions regarding the UN/CEFACT Position Statement on ebXML
Todd:
I don't disagree with you or try to counter your argumentation. I am just speaking from a pure technical perspective.
I have been talking about "highly connected systems" since 1999. I think we are there today: almost anything can be connected to anything with "enough" bandwidth. The web as a first generation of "highly connected system" (Browser to web server) worked well because it relied semantically poor standards (easy to design and consume) and semantically tolerant consumers.
I think that the technology to manage massively connected systems (with minimal user involvement) still needs to be invented. It is not so much setting up a massively connected system that is impossible to do, it is rather that it is impossible to maintain over time (therefore making its value less appealing), unless we crack the semantic problem: i.e. enough semantic over the wire and enough tolerance on the consumer. From a pure infrastructure problem we are there, SOA (this is what ebXML is BTW), but this alone will not get us very far.
Most standards of the WS stack are carefully eluding the semantic problem and the flexibility that will be needed to run these kinds of systems. Again, here ebXML is leading with CC. I mean it is appalling that an organization claims that it is building THE business process standard and does not have the concept of a user/organization within it! It does not even have the possibility to select activity performers (i.e. web services) from a group based on some rules, even my dad's workflow engine could do that with users. It can't even have a "consumer centric" point of view and allow the engine to transform the data into what an activity performer will need. In these conditions, if this insanity continues, I don't see any point in time where the simple vision you guys are articulating will ever come true.
Jean-Jacques
tel: 425-649-6584
Cell: 508-333-7634
-----Original Message-----
From: Todd Boyle [mailto:tboyle@rosehill.net]
Sent: Wednesday, November 05, 2003 10:24 AM
To: rachel@rfa-edi.com; ebxml-dev@lists.ebxml.org
Subject: RE: CSG Answers to Mark Crawford's Questions regarding the UN/CEFACT Position Statement on ebXML
I completely agree with Rachel's observation. It is amazing
to be sitting here in 2003 with no way to send and receive the most elementary business information in machine-readable format. Orders, invoices, ship notices, remittance documents.
The invisible hand of the market might have worked pretty well for beans and pork bellies but it does NOT work for information systems, media, or telecoms. What the market manifests is an infrastructure which most effectively captures gains for the information intermediaries. The software and services are incapable of measuring the economic value of information to society as a whole (i.e. externalities). The market incents Microsoft and Intuit to maximize their own advantage, inflicting $100 of harms on the economy for the sake of $1 of revenue for themselves. Don't you see how crazy this is? The sheer waste of labor, fuel, facilities. Whole districts full of office blocks, banks, and registries of all kinds, and freeways choked with commuters in neckties, driving to their control panels on their desktop.
Ray Walker said, the waste is in the $Trillions of dollars. http://www.google.com/search?num=30&hl=en&q=ray+walker+cefact+trillion
A possible answer may be in changing IP laws, removing protections from that component of the software whose value derives from its mere adoption as a standard. Phaseout all protections when more than 10% of the base population employs the software. Regardless of its "innovativeness" etc. If laws don't change then outcomes won't change. Clearly, corporate behavior is not going to change globally, and, clearly the current outcome in software and technical standards is unacceptable.
Todd Boyle CPA 9745-128th Ave NE, Kirkland WA 98033
At 08:56 PM 11/4/2003, Rachel Foerster wrote:
>Steve, I completely concur with your assertion that it's the solution
>vendor that has to keep the complexity under the hood and transparent
>to the end user, whether an SME or not. I guess I'm just a bit weary
>that I as an SME can't yet use Quicken to send an electronic invoice to
>my customers or to receive an electronic purchase order from them. What
>I have to do is print the invoice to a .pdf file and then attach the
>.pdf to an email message. So far it's working reasonably well, but this
>is not in the spirit of electronic business, now is it?
>
>I believe that solutions have hit the market place already in Australia
>and in parts of Asia, and perhaps even Europe, but I haven't yet become
>aware of any in the U.S. Hope springs eternal in my breast that I will
>stay in business long enough and live long enough to truly see this
>vision realized across a critical mass of SMEs and that I can purchase
>these solutions at Office Depot or Best Buy or even - gasp (!!!) -
>download them via the Internet.
>
>Rachel
>
>Rachel Foerster
>Rachel Foerster & Associates, Ltd.
>Voice: 847-872-8070
>email: rachel@rfa-edi.com
>
>
>
>-----Original Message-----
>From: Steve Capell [mailto:steve.capell@redwahoo.com]
>Sent: Tuesday, November 04, 2003 5:43 PM
>To: rachel@rfa-edi.com; ebxml-dev@lists.ebxml.org
>Subject: RE: CSG Answers to Mark Crawford's Questions regarding the
>UN/CEFACT Position Statement on ebXML
>
>
>Rachel,
>
>Whilst supportive of the objective of ebXML - to make B2B easier for
>SMEs, I would point out that I don't see any relationship between the
>complexity of a technical specification and the complexity of the final
>user experience. ebXML is a complex set of specifications. For that
>matter, the extended WS stack specifications (WSDL, UDDI, WS-BPEL,
>WS-Security, WS-Policy, WS-RM, WS-xx, etc) are potentially even more
>complex (although still a bit immature). These specifications are
>necessarily complex so that those B2B integration configuration steps
>that were previously manual and proprietary can be automated via open
>standards. The SME just knows that he wants to send an order to ACME
>Inc - and thanks to a rich and complex set of underlying technical
>standards, that's virtually all he has to know. It is the software
>vendor that needs to manage the complexity, not the SME.
>
>Regards,
>
>Steve Capell
>RedWahoo
>Sydney, Australia
>Tel : +61 410 437854
>This email message and any accompanying attachments may contain
>information that is confidential and is subject to legal privilege. If
>you are not the intended recipient, do not read, use, disseminate,
>distribute or copy this message or attachments. If you have received
>this message in error, please notify the sender immediately, and delete
>this message. Any views expressed in this message are those of the
>individual sender, except where the sender expressly, and with
>authority, states them to be the views of Red Wahoo Pty. Ltd. Before
>opening any attachments, please check them for viruses and defects. We
>do not accept any liability for loss or damage which may arise from
>your receipt of this e-mail.
>
>
>
>-----Original Message-----
>From: Rachel Foerster [mailto:rachel@rfa-edi.com]
>Sent: Wednesday, 5 November 2003 3:02 AM
>To: ebxml-dev@lists.ebxml.org
>Subject: RE: CSG Answers to Mark Crawford's Questions regarding the
>UN/CEFACT Position Statement on ebXML
>
>
>Jon, I appreciate your very clear and concise reporting of events, etc.
>And I think you'll recall a statement I made publicly at the Brussels
>meeting where I was a co-lead of the ebXML Education & Marketing Team,
>that if the ebXML initiative didn't achieve the enablement of small
>businesses in the world of electronic messaging, it will have failed in
>its mission. I still believe that that mission was the appropriate one
>and one that is still very much needed to be realized..
>
>Quite frankly, I have been personally dismayed over the intervening
>months/years since the Tokyo meeting to see much of the ebXML effort
>spiral into such a complexity that only the largest of enterprises
>could have the resources and expertise to even understand much of it
>let along implement it such that the smallest of businesses can
>participate in this brave new (?) world of electronic business. I
>continue to believe and to assert that until/unless small businesses
>are enabled with affordable capabilities, the big enterprises will lose
>as well.
>
>I trust/hope that this vision/mission of truly enabling the small
>businesses to effectively participate with each other and large
>businesses using the ebXML family of specifications will be realized.
>My casual observation is that this is taking place around the globe.
>
>Thanks for your clearheaded and objective reportage.
>
>Rachel
>Rachel Foerster
>Rachel Foerster & Associates, Ltd.
>39432 North Avenue
>Beach Park, IL 60099
>Voice: 847-872-8070
>email: rachel@rfa-edi.com
>http://www.rfa-edi.com
>
>
>-----Original Message-----
>From: jon.bosak@sun.com [mailto:jon.bosak@sun.com]
>Sent: Monday, November 03, 2003 8:46 PM
>To: uncefact-tmg-general@listman.disa.org; ebxml-dev@lists.ebxml.org
>Subject: Re: CSG Answers to Mark Crawford's Questions regarding the
>UN/CEFACT Position Statement on ebXML
>
>
>The following passage appeared in a message posted a few days ago on
>the uncefact-tmg-general, ebxml-dev, cefact-atg, and cefact-tbg
>lists:
>
>[Klaus-Dieter Naujok <knaujok@attglobal.net>, Mon, 27 Oct 2003:]
>|
>| All three BCF principals could have been easily aligned from the
>| beginning of the ebXML project, which was first envisioned by
>| UN/CEFACT but due to the objections by OASIS, especially Sun during
>| the Tokyo ebXML meeting, we were all forced to make ebXML a loosely
>| coupled set of technical specifications and remove business
>| requirements modeling as an ebXML requirement. It is evident today
>| that this forced ebXML to be just technical infrastructure.
>
>This generated a follow-up discussion on the uncefact-tmg-general list
>that included the following:
>
>[David RR Webber <Gnosis_@compuserve.com>, Mon, 27 Oct 2003:]
>|
>| I must say it was not just Sun, and certainly not OASIS. This was
>| voted on by the Plenary and agreed as part of the ebXML Requirements.
>|
>| The decision was to not MANDATE the use of UML/UMM, but rather to
>| suggest the use of UML/UMM.
>|
>| There were a number of attempts made to retroactively undermine this
>| decision - but each time people (not just Sun!) stood firm and
>| re-endorsed the original design decision.
>|
>| I see it as a great strength that ebXML is neutral to modelling
>| technology - thereby making it easier for people to adopt and use
>| ebXML without having to use IT specific software engineering
>| technology.
>
>[Klaus-Dieter Naujok <knaujok@attglobal.net>, Mon, 27 Oct 2003:]
>|
>| David,
>|
>| I am sorry to say you don't know what you talking about since your
>| were not part of the discussion. I spend (wasted) 3 days on this
>| subject during the Tokyo meeting at which OASIS, represented by 3 Sun
>| members, made it perfectly clear that they disagreed with UN/CEFACT's
>| approach and would NOT support it as part of ebXML. I was NOT a bad
>| dream. If anyone is trying to adjust history it is those who where
>| not
>
>| present during that closed meeting of the executives.
>
>[Klaus-Dieter Naujok <knaujok@attglobal.net>, Tue, 28 Oct 2003:]
>|
>| Due to some extended travel over the last 24 hours I was not able to
>| respond to David's and Duane's postings. However, Paul and Jim did
>| take care of it so that we can move on. I like to thank them both not
>| only for addressing those questions/comments but also in confirming
>| that my statement about the Tokyo Executive meeting were accurate.
>| This last point is very important since I have been accused privately
>| that my "comments are not reflective of the facts".
>
>Having defamed several of us on a number of mailing lists, Klaus now
>desires to "move on." Unfortunately, I feel compelled to respond.
>
>I say "unfortunately" because this is a level of discussion I try
>assiduously to avoid, and with 30 people to host at the UBL TC meeting
>in San Francisco this week, replying in this thread is the last thing I
>want to be doing right now. My current job as chair of the UBL TC, and
>particularly the efforts we are making to work closely with the
>business experts in UN/CEFACT, puts me in an especially difficult
>position from which to respond to political attacks. But misleading
>statements were made about Sun's involvement in an ebXML Executive
>Committee meeting that occurred three years ago, and those statements
>need to be corrected. The three people from Sun who attended the
>November 2000 meeting in Tokyo referred to by Klaus -- and by Jim Clark
>and Paul Levine in other messages in this thread -- were Karsten Riemer
>(by invitation of the Executive Committee), myself (by invitation of
>the Executive Committee), and Bill Smith, then the President of OASIS.
>Karsten (lucky man!) is now retired, which leaves just Bill and me to
>tell the tale. Guess who drew the short straw.
>
>Let me start by correcting the inference that any person who didn't
>know him would draw from Klaus's statement that OASIS was "represented
>by 3 Sun members." The obvious implication is that Sun had three
>people on the ebXML Executive Committee. That this is the conclusion
>one would be led to is demonstrated by David Webber in his postings to
>the uncefact-tmg-general list 27 Oct 2003, where he does in fact draw
>just that conclusion. Klaus, Jim, and Paul seem happy to allow David to
>believe this, but I'm not.
>
>The fact is that the ebXML Executive Committee consisted of just four
>people, two of them representing UN/CEFACT and two representing OASIS.
>The UN/CEFACT representatives were Ray Walker and Klaus-Dieter Naujok;
>the OASIS representatives were Bob Sutor of IBM, Chair of the OASIS
>Board of Directors, and Bill Smith, President of OASIS. Neither Bob nor
>Bill were participating in the EC as vendor representatives. Rather,
>they were participating as elected officers of OASIS. Both were there
>as representatives of the entire OASIS membership, and both, as far as
>I know, were scrupulous in their discharge of that obligation. So the
>mere suggestion that either of them were pushing corporate agendas,
>either in the Tokyo meeting (which Bob did not attend) or at any other
>time during the course of the ebXML initiative, constitutes a
>completely unwarranted attack on their integrity as individuals.
>
>Klaus's assertion that "OASIS... made it perfectly clear that they
>disagreed with UN/CEFACT's approach and would NOT support it as part of
>ebXML" glosses over an essential and little-known fact about the ebXML
>partnership between UN/CEFACT and OASIS that must be taken into account
>in understanding what really happened.
>
>Those of us coming from OASIS naively thought that a project called
>"ebusiness XML" was going to be about ebusiness and XML. UN/CEFACT had
>come to OASIS seeking help with an initiative to drive the benefits of
>EDI to SMEs and countries with economies in transition. Our
>understanding was that UN/CEFACT and X12 members would provide the
>business expertise, and OASIS would provide the XML expertise, and when
>we were done, we would have basically a standard, cross-industry
>version of RosettaNet that would extend the known benefits of EDI to
>small and medium-size businesses. This was a concept that had been
>discussed for well over a year prior to ebXML under the generic heading
>of "XML EDI," and that's what we thought ebXML would look like -- an
>XML version of EDI that would improve on 20 years of implementation
>experience with standardized XML formats for the messages, standardized
>XML machine-readable formats for the business process specifications
>and trading partner agreements, and a standardized XML
>registry/repository for registration and discovery. This is what we
>signed up for.
>
>In an internal memo dated 28 August 2000, Karsten summed up Sun's
>understanding of what ebXML was doing as follows:
>
> Main goal is to provide the process context around the messages
> that EDI has always been missing. BP team is developing a
> metamodel for business process definition, as well as for the
> relationship of business process to business message structure,
> and to trading partner agreements. This metamodel takes the
> form of a UML profile. It will be possible to define processes
> in UML based tools and have them translated into XML for
> storage in the repository.
>
> Business Processes will provide the contextual reference that
> is needed to compose a multitude of process specific message
> structures using the same pool of core components, i.e.
> re-useable data elements. Trading partner agreements can be
> thought of as the functional and technical agreement on what
> the software on either end of the transport must be able to do
> (and not do) in order for the business process to be executed
> as agreed.
>
> We will demo the relationship between business process
> definition, message definition, and trading partner definition
> in the Tokyo meeting.
>
> A significant contribution has been made by University of
> Michigan to incorporate an micro-economic model into the BP
> metamodel, so that you can describe contract formation, and
> execution against the formed contracts.
>
> The ebXML metamodel is likely to become fully aligned with the
> metamodel underneath RosettaNet, the edifecs business
> collaboration metamodel. This will ensure full interoperability
> between any process defined in terms of RosettaNet PIPs and
> processes defined in ebXML.
>
> The metamodel will be firmed up by the November ebXML meeting
> in Tokyo, but a full, formal specification may not be available
> until February meeting in Vancouver.
>
>Given the implication in the recent tmg-general thread that Sun was
>somehow pursuing a self-serving agenda here, I will point out that Sun
>had zero product interest in pushing this architecture. Like most other
>ebXML participants, we were just trying to deliver the fairly
>straightforward return on investment people would get by putting their
>paper and fax-based business processes online in an incremental and
>therefore believable way. No one saw this as the ultimate solution,
>just as the obvious next step, a recognition that we should tackle
>first the parts that an ordinary human being might hope to understand
>without having to buy into a solution based on vendor-controlled
>middleware.
>
>A similar view of the objectives of the ebXML effort at that time was
>contained in the draft of the BP part of the ebXML architecture
>document that was submitted to the ebXML Technical Architecture team in
>early October
>2000:
>
> A business process can be seen as a series of actions on
> entities within an enterprise, interleaved with a set of
> communications with parties outside the enterprise. The
> communication between the parties is the shared part of the
> business process. This is the focus of ebXML.
>
> The entities within an enterprise are called business entities,
> and their data structure can be represented by business
> objects.
>
> The communication with parties outside the enterprise takes
> place through an exchange of business messages.
>
> Both business objects and business messages are composed from
> core components, re-useable low level data structures. The
> exact composition of a business object or a business message is
> guided by a set of contexts derived from (among other sources)
> the business process.
>
>This was the view of ebXML shared by the majority of the ebXML
>participants, as demonstrated by the fact that this is the view that
>they -- through a Plenary vote -- ultimately decided to approve. It was
>not until a controversy over the meaning of "business objects" arose in
>late September 2000 that people from the OASIS side began to realize
>that a different agenda was at work here.
>
>Instead of constructing the XML business documents to be exchanged in a
>trading relationship based on data modeling, with the idea that these
>would then be referenced by XML process specifications based on process
>modeling, this alternative attempted to specify a very non-EDI-like
>technology that started by capturing customer requirements in UML use
>case diagrams, then identifying the process, identifying its required
>data structures at a high level, recursively defining lower and lower
>levels of the data structures, and finally designing the system to use
>those generated data structures.
>
>This was an approach that might have worked if we had had no legacy
>systems to deal with, were designing for one industry only, and had an
>almost unlimited amount of time, but this wasn't the environment we had
>been assuming. Our assumption was that we were designing business
>messages to integrate today's legacy today. When objections were made
>to this substitute position, the UN/CEFACT representatives to the
>Executive Committee responded that this was "the UN/CEFACT vision" and
>that this vision was nonnegotiable as far as UN/CEFACT was concerned.
>
>People tend to think I'm exaggerating when I tell them that the
>"UN/CEFACT vision" was one in which the business documents themselves
>were supposed to be generated directly from the process diagrams. And
>indeed, for anyone familiar with either XML document design or existing
>systems of electronic commerce, this is a pretty strange vision. I
>might not have believed it myself if Klaus had not sent Karsten the
>relevant documents and generously copied them to me so that I would
>finally learn, almost a year after the ebXML project had begun, just
>what he had in mind. Since I know of no other source for "the UN/CEFACT
>vision," I've appended that message below so that anyone who's
>interested can see what we were permitted to learn one month before the
>November 2000 meeting in Tokyo.
>
>I leave it to others to judge the technical merits of "the UN/CEFACT
>vision" as it was explained to us in September 2000 and will simply
>content myself with the observation that this was not what we had been
>led to believe was our mission. At the time this message was sent, we
>had to take "the UN/CEFACT vision" described in these materials at face
>value as the official position of UN/CEFACT as a whole; it was not
>until later, after I became aware of the years-long struggle between
>UN/CEFACT TMWG and the rest of the organization, that I came to realize
>that in fact "the UN/CEFACT vision" did not, and does not, represent
>the majority view even of the UN/CEFACT membership, let alone the much
>larger group that had gathered to create ebXML.
>
>When it became clear that there was a fundamental disconnect between
>what we had been led to believe and what was actually intended by the
>UN/CEFACT leadership (meaning the UN/CEFACT TMWG, which had effectively
>taken control of the organization through its domination of the
>UN/CEFACT Steering Group), various attempts were made to find some way
>of proceeding that would preserve the remarkable achievements of the
>ebXML effort. It had become obvious to everyone that the "UN/CEFACT
>vision," or whatever it was that the UN/CEFACT side of the Executive
>Committee was driving, was in direct conflict with the work of the
>large number of people engaged in the CC part of the ebXML effort. I
>was willing to believe that "the UN/CEFACT vision" might someday become
>a workable solution, so in a message to Klaus dated 28 October 2000, on
>the eve of the Tokyo meeting, I made the following
>suggestion:
>
> It's my observation that what we're seeing reflects the
> existence of two groups of people with different but not
> necessarily antithetical agendas. One group is focused on how
> we can completely automate electronic trade; the other is
> focused on how we can enable small businesses to engage in
> electronic trade and how we can help businesses of all sizes
> make the transition from legacy systems. I believe that both
> of these agendas can be accomplished if we recognize that
> complete automation is a long-term goal, whereas getting the
> small businesses online and beginning the transition from
> legacy systems is a short-term one. If this distinction is
> observed, then I think that we can achieve consensus on the TA
> spec fairly simply.
>
> I think that the people who have a vision for the long-term
> goal should describe the long-term solution in a separate white
> paper. This would accomplish several objectives.
>
> 1. It would put the long-term vision firmly on record and
> give everyone a chance to see where this is all heading.
>
> 2. It would make clear the requirements for the long term so
> that they can be taken into account in the Phase 1
> architecture.
>
> 3. It would allow the TA spec to clearly describe the
> minimum, largely unautomated solution that we need to
> have in place for the short term.
>
> 4. It would avoid a public collision between people who
> think that the role of XML in ebXML is to transmit
> objects with methods and the people who think (in line
> with our official policy) that the role of XML is to
> convey the information needed to effect business
> transactions.
>
> 5. If done quickly and thoroughly, this separation would
> allow the reduced TA spec to gain approval in Vancouver.
> I don't think it's realistic to expect it to gain the
> necessary level of agreement in its present form.
>
> A messier but workable alternative strategy is the one
> suggested by the QR team: hold a session of the Steering
> Committee in Tokyo that will allow the QR team to explain their
> objections to the current draft, and resolve those objections
> on the spot.
>
> But I think it would be easier and cleaner for you to suggest
> that the controversial parts of the TA spec be moved to a
> separate vision document.
>
>We entered the Tokyo meeting with the issue unresolved.
>
>At some point during the week in Tokyo -- I can't remember which day
>now
>-- the ebXML Executive Committee decided to invite some people in to discuss
>this issue. This was a fairly small meeting; I remember it as including
>about eight or nine people, all of them there by invitation of the EC. None
>of the attendees had been invited on the basis of company affiliation. Of
>the people from Sun, Bill Smith was there because he was President of OASIS;
>Karsten was there because of his role in the BP team; and I was there to
>represent the ebXML Advisory Board, a body created by the EC of which I
>happened to be the only member. It was a good discussion. I learned a lot,
>and I got to deliver the suggestion I had earlier made in email to Klaus.
>
>The idea of publishing "the UN/CEFACT vision" as a separate paper was
>never adopted, but we left that meeting with what appeared to be a
>consensus that the distinction between "short term" and "long term"
>objectives might offer us a way out of the dilemma in which we found
>ourselves. This was not quite the same as the distinction between
>"phase 1" and "phase 2" -- people had been using those terms for a
>while by that time -- but I guess it was close enough to get us over
>the hump.
>
>The thing I do remember quite clearly about the Tokyo meeting is that
>the group assembled by the EC to discuss the problem had absolutely no
>formal role in the process that led to the ebXML specifications as they
>were finally published. I like to believe that the discussion in Tokyo
>helped find a way forward, but all the actual decisions were made by
>the ebXML plenary, exactly as David Webber has said. It has been widely
>noted that ebXML had literally thousands of participants. Typical
>meetings were attended by upwards of two hundred people, and the
>majority of them came from UN/CEFACT, X12, and other centers of
>business expertise, not from OASIS. The characterization of any of the
>decisions made in ebXML as driven by OASIS or by any one company is not
>only inaccurate but is also disrespectful of the membership that
>created the ebXML specifications.
>
>In closing, I'd like to say how sad I am that vendor politics has been
>retroactively injected into the ebXML initiative at this late date. The
>ebXML initiative was remarkably free from the kind of partisan
>posturing we've been seeing over the last week. Perhaps it's just
>because vendor participation back then was considerably different from
>what it is now, but most of us shared a common understanding of what
>electronic commerce needed next, and all of us set aside corporate
>agendas to pursue a goal that we believed would benefit everyone.
>
>The good news is that almost all the pieces of the original majority
>ebXML vision -- all except Core Components -- are now in an
>organization whose process encourages publicly accountable, open
>consultation and discourages formation of the kind of centralized
>control structures that can be hijacked by small groups with special
>agendas. Fostered by a loose but effective collegiality that builds on
>the modular structure of the ebXML architecture, the OASIS ebXML
>Business Process TC, ebXML CPP/A TC, ebXML Implementation TC, ebXML
>Messaging TC, and ebXML Registry TC continue to evolve and strengthen
>the majority ebXML vision forged by the ebXML participants themselves.
>In combination with related OASIS TCs
>-- UBL, eGovernment, BPEL, Customer Information Quality, and others -- ebXML
>is delivering on its promise to become the sensible and vendor-neutral next
>step for the world's electronic businesses, large and small.
>
>Jon
>
>==================================================================
>
>Date: Thu, 28 Sep 2000 15:49:03 -0700
>From: Klaus-Dieter Naujok <knaujok@pacbell.net>
>Subject: Fwd: Re: Meta Model
>To: Jon Bosak <bosak@boethius.eng.sun.com>
>
>F.Y.I.
>
>==================BEGIN FORWARDED MESSAGE==================
> >From: "Klaus-Dieter Naujok" <knaujok@pacbell.net>
> >To: "Karsten Riemer" <Karsten.Riemer@East.Sun.COM>
> >Date: Thu, 28 Sep 2000 15:35:02 -0700
> >Subject: Re: Meta Model
> >
>
>On Thu, 28 Sep 2000 17:00:29 -0400 (Eastern Daylight Time), Karsten
>Riemer
>wrote:
>
> >can you point me to the UN/CEFACT vision, I couldn't locate it on
> >ebXML.org
>
>Karsten it is not a ebXML document, but a UN/CEFACT one. If will spare
>you the tasks of finding it on the UN side since it has much more than
>just what we are relating to. I am sending you the material that Ray
>(chair of UN/CEFACT Steering Committee - CSG) is using as he addresses
>this topic related to UN/CEFACT.
>
>UN/CEFACT's Direction Paper - Prepared by two CSG members on request of
>Ray for the ebXML Executive.
>
>ebXML BP2XML - Prepared by Ray and myself taking material from SWIFT
>and GCI presentations given 2 weeks ago, as well as the TMWG BP
>example.
>
>The Road to ebXML - Background how we we got here. A revised version
>from my paper I made available during the last TMWG session. This
>version is from my book I am writing :-)
>
>Let me know if you need more. BTW, my working hours are M-F,
>07:00-18:00 Pacific Time in case you want to call. Next week I am in
>Tokyo.
>
>Klaus
>
>--
>Klaus-Dieter Naujok NextERA Interactive
>Antioch, CA USA +1.925.759.1670
>
>PGP Finger: 6A4B 1683 CD99 E7BE F855 CC2F 4569 6BD8 76BD 1117
>
>===================END FORWARDED MESSAGE===================
>
>--
>Klaus-Dieter Naujok NextERA Interactive
>Antioch, CA USA +1.925.759.1670
>
>PGP Finger: 6A4B 1683 CD99 E7BE F855 CC2F 4569 6BD8 76BD 1117
>
>
>---
>You are currently subscribed to the uncefact-tmg-general listserve. To
>unsubscribe send an email to lyris@listman.disa.org with the following
>subject: Unsubscribe uncefact-tmg-general
>If you do not receive confirmation of your unsubscribe request please
>notify postmaster@disa.org to report the problem.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC