Alan Kotok wrote:
> Let me try to answer your questions as best I can. You will forgive my not
> providing a point-by-point response.
Alan,
I am sorry, but No. I took the time to asked those questions and was
really hoping for some solid answers. Your wiping them aside is not
appreciated and not forgiven.
> I highly recommend you visit the
> ebXML Web site that has draft specifications open to anyone. But let me
> make a few points which I believe addresses the theme of your questions ...
This is what always happens when the nitty gritty of the real problems
is posed to anyone involved in the "XML EDI effort". One gets fobbed off
to some web site or other and no answers are forthcoming.
To me, this is equivalent to "I don't know the answer" or "there is no
answer".
No, Alan, that web site does NOT address the questions asked, that's why
I asked them. If there are real answers and you know what they are, I
would genuinely appreciate the information.
> The ebXML initiative has a number of features that build on the EDI
> experience but make it more accessible to smaller companies. One of those
> features is the electronic trading partner agreement or TPA.
Let me try again on this new claim you have made. How does a TPA make
"it" more accessible to small companies than EDI?
What are the other "features" which achieve the benefits for small users
you claim? This is the point of the questions I'm asking. Surely you
(DISA?) have some justification for claiming things like this?
> As you note
> TPAs as they now exist require a lot of up-front work. Electronic TPAs
> will reduce that workload significantly.
How do electronic TPAs reduce the workload. The "work" is all supposed
to be done by computers. How does that make it any easier for small
organisations to use ebXML when they don't have the resources to adopt
EDI?
Has a TPA anything at all to do with the automated interoperation
problems? If so, how does it relate?
> An important feature of ebXML is the use of registries and repositories
> that store the industry business processes, message formats, and
> vocabularies. Business processes are stored as metamodels that generate
> the basic message formats and data. The vocabularies will include
> industry-specific terms (the word 'signature' in printing means something
> very different from the same use of the word in finance) as well as terms
> that are used across industries.
Please show me how these help solve the problems I asked.
Where can I examine these "registeries and repositories"?
Does the small user (the 20-employee printer you cited) have to get
involved with all this knowledge of meta models and generating basic
message formats and data to adopt ebXML? Why is that any easier or
cheaper than EDI?
> One of the goals of the ebXML initiative is to ease the transition from
> EDI. The core components team plans to express these items in a neutral
> syntax so they can be mapped to their equivalents in current EDI
> transactions and messages.
Am I interpreting that correctly when I read it as "we hope to be able
to ease the transition one day but we are not close to it yet"?
Who has to do all this "mapping" - the small 20-employee organisation
you referenced as the beneficiary of ebXML?
> In fact, X12 plans to start developing
> accredited cross-industry XML standards, working with the business process
> models and core components in ebXML (and coordinate this work with the
> UN/EDIFACT Work Group).
Won't they have exactly the same problems, costs and difficulty of
adoption as EDI? If not, where is the benefit and how will it help the
small organisations adopt ebXML?
> Your questions represent the very issues that ebXML is addressing. The
> specifications are there for anyone to read or comment on.
The "specifications" don't go any distance at all to answering my
questions. In fact, examining those "specifications", it appears ebXML
will just add another level of complexity on top of EDI without
producing any benefit.
That is why I am asking for answers as to why you are claiming easier
adoption of ebXML by small organisations, when the "specifications"
appear to make it more difficult for even the large organisations.
Why was the claim of "milestone" and "proof of concept" made in the
initial posting to this list and on the web site referenced?
In particular, what is the justification for your statement to the list
earlier today:
"That demonstration will use a supply chain
scenario in the printing industry. In the
U.S., the median size of printing companies
is 20 employees. Only the largest printers
of magazines and catalogs can afford to use
traditional EDI. Something like ebXML
offers these small companies the opportunity
to benefit from business data exchange, where
before it was well beyond their resources."
That was the central issue I was trying to examine and why I asked all
those questions: Why does ebXML offer these small companies any more
opportunity to benefit from business data exchange then EDI does? Your
web references would indicate otherwise.
> As mentioned
> in my earlier message, ebXML is still a work in progress, but it is taking
> shape quickly. Best regards.
Should I take that to mean "we haven't any answers to those questions,
but we are hoping to some day"?
If so, might I suggest you (ebXML, DISA?) go a bit easier about making
claims like that I've quoted you on above?
It looked like there might have been some answers to the real problems
and I was getting quite interested. However, it now looks like it's just
the same old stuff jazzed up with a lot of unsubstantiated promises,
claims, hopes and hype. :-(.
Regards,
Ken
--
Ken Steel
ICARIS Services Amsterdam and Melbourne
Research results: http://www.icaris.net/
Email: [EMAIL PROTECTED]; [EMAIL PROTECTED]
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
