Re: What do people really expect from ebXML? - spinning mirrors?

[David Lyon <djlyon@one.net.au>]

Sue,

Actually, it's not such a problem for us personally. In my household we
speak between us English, French, Malay, Cantonese and a bit of Tamil. We're
getting rusty on some we have to admit. With the help of friends and inlaws,
we can extend it to Mandarin, Hindi, Telagu and Singalese.

When it all boils down, a lot of business in the countries covered by these
languages do business verbally. They lack the systems of more organised
western countries.

I think that we all would agree that while companies like Commerce One
probably lead the field in their endeavours and wouldn't doubt that they
quite good cross language systems.

However, in Countries like India, it's a privelage to even be able to read,
little own use the "expensive" electronic commerce systems of other
countries. I've seen people in India all sit round the T.V and watch
programs powered not by mains power but by a car battery. I couldn't believe
it, but they sure loved their TV, even if there was nothing on and it was in
black and white.

Also, I've seen businesses with bookcase after bookcase with paper files (in
India).

They think that people are working in the West to make computers affordable
for them. What should we tell them ?

Many of these people speak multiple languages, so certainly fit into this
category.

Take care

David Lyon

----- Original Message -----
From: Probert, Sue <Sue.Probert@commerceone.com>
To: 'David Powell' <david@xactcommerce.com>; <ebxml-core@lists.ebxml.org>
Cc: William J. Kammerer <wkammerer@foresightcorp.com>; David Lyon
<djlyon@one.net.au>
Sent: Wednesday, May 02, 2001 6:06 PM
Subject: RE: What do people really expect from ebXML? - spinning mirrors?


> David
>
> I have a feeling that you don't often come across electronic business
> conducted in countries with a first language other than English!
>
> The simplicity that you suggest is very difficult to sustain when trying
to
> map say Spanish tags against Chinese tags or any other combination. The
> ebXML CC naming conventions have been developed to enable multiple
languages
> to be able to identify uniquely individual pieces of semantic data. The
idea
> is that a universally unique ID number can then be associated with the
well
> defined name and definition and that this ID can then be used within XML
or
> EDIFACT, X12 or whatever syntax data exchanges (even paper via the UN
Layout
> key can join in the party) or specified in message implementation
guidelines
> etc.
>
> The other major and longterm problem that the CC naming and defining rules
> is tackling is to publish unique semantic definitions to overcome the 'I
> call it the same name but mean something completely different' or the 'I
> call it something different but actually semantically it is exactly the
same
> thing' confusion which is widespread between trading partners.
>
> The concept here is that we are fixing semantic anchors which by their use
> can remove all semantic ambuguities no matter what local semantic dialect
is
> used by individual trading partners in whatever language they speak.
>
> regards
>
> Sue
>
> Sue Probert
> Commerce One
> Tel: +44 1332 342080
> www.commerceone.com
>
>
> -----Original Message-----
> From: David Powell [mailto:david@xactcommerce.com]
> Sent: 02 May 2001 06:34
> To: ebxml-core@lists.ebxml.org
> Cc: William J. Kammerer; David Lyon
> Subject: Re: What do people really expect from ebXML? - spinning
> mirrors?
>
>
> I just hate to chime in.. here.. but David and William are of one mind
> here.  And both are equally wrong.  But all is not lost, because at the
> heart of it they both understand the very problems that their proposed
> solutions bring.  And even moreso they offer wonderous words of advise
that
> another direction is possible.
>
> David is pointing to the wonderful power of XML when he writes... "The
> beauty of XML is that companies can add EXTRA fields without stuffing the
> whole thing up for everybody else."
>
> Guys.. let it go.. this idea to fix on the "basic" elements of "basic"
> transactions..cripples ebXML rather than strengthening it.   The necessary
> core is much simpler and at a higher level of abstraction.
>
> William was pointing to this earlier today with his somewhat odious
example
> of data transfers between insurance agents and the State of Ohio.. this
> exchange of information is not supported by any of the "basic"
transactions
> proposed here.. as "inevitible" and "necessary".
>
> Folks using ebXML will naturally gravitate to transactions forms similar
to
> those being proposed by both William Kammer and David Lyons.  However, if
> they have a means of advertising the "transactions" they are prepared to
> handle and the data elements they need or provide.. it is a quick and easy
> thing for an XML coder to map the names they use onto the names offered by
> their trading partner.. especially if this "Language" supports this
> capability as one of its core elements.
>
> Let the XML coders handle this simple task.  Or, even a stupid synonym
> dictionary, for that matter,  for folks who want "point and click"
> possibilites in some future ebXML Rapid XML Development tool.  We either
> have the possibility of mapping data element names or not.  Once you have
> the possibility of adding extra fields which have differing names but the
> same meanings, a path is set.  To support "common names" and "local names"
> then you have to have two structures for managing this communication and a
> big "if statement structure" to sence and switch between them.  Why not be
> more general and less complicated by starting the process of adding extra
> fields at field number one.. not field number seven.  Lets quit trying to
> be data element "name" control freaks.  And while we are at it... lets
> throw out the "transaction name" control idea too..
>
> This is not to say that ebXML cannot propose "example templates".  These
> "examples" are just that.. guidance for the timid and uninitiated.  Lets
> not attempt to "legislate" business process.  Leave this to the EDI crowd.
> This is fool hardy for developing an unbounded language specification..
and
> most folks in this group seem to be saying that the goal of defining the
> "sacred" core of business transactions is like debating the number of
> angels who can stand on a pin head.  Fun, but a waste of time.  But once
> this is agreed, they go right back at it.. because this seems to be
> soothing, or something.  This is a "Language" specification.. lets quit
> trying to specify the allowable variable names.
>
>
> David Powell
> Life & Energy Systems, Inc.
> 700 West Pete Rose Way
> Cincinnati, OH 45203
> 513-721-4055
>
>
>
> "William J. Kammerer" wrote:
>
> > David Lyon was kind enough to give us the minimum required elements
> > within a simple invoice line item, consisting of code (which I take to
> > mean commodity code or vendor part no.), description, comments, unit of
> > [measure], rate (or unit price), quantity, tax and amount.   This has
> > "...been this way since time [immemorial]," and David wants to know "why
> > has [its] understanding suddenly been lost?"
> >
> > I would agree that David's shopping list is probably a minimally
> > sufficient set of Invoice line item components for the typical SME for
> > small dollar transactions.  And as expected, it's probably the same as
> > what you would expect for the converse: a minimally sufficient PO line
> > item.
> >
> > So I hit the jackpot when I selected the model from the Open Buying on
> > the Internet (OBI) Consortium, consisting of almost that exact same set.
> > The only differences are 1) OBI requires a line item number in the PO -
> > a requirement inherited from X12 EDI (though the converse, line item
> > nos. for an invoice, are not required to be returned in the IT1
> > segment), 2) OBI would allow, but not mandate, descriptions and
> > comments, and 3) OBI (and EDI) has no need for David's line amounts.
> > And I would argue that an ebXML abstract "core" line item would have no
> > need for an amount either, since that can easily be calculated by the
> > recipient with a stylesheet or what-not.
> >
> > Given the fairly decent match between David's intuition or experience,
> > and the OBI guideline, perhaps the rest of the PO's core components can
> > be "discovered" from the same document.  Now we can sit an innocent, say
> > Betty Harvey, down with the OBI stuff and she would be able come up with
> > a reasonable set of PO core components  - even though she's rarely
> > sighted one of these critters.
> >
> > Which was the whole point of my spiel about reverse engineering. And I
> > think BP's Catalog of Common Business Processes (bpproc_v0.99.pdf)
> > section on Discovery of Core Components was saying this, also.
> >
> > 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: ebxml-core-request@lists.ebxml.org
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>