I am pleased to see this issue of language discussed in this group.
I come back to Betty's example where <Purchase Order> or <PO> or <George>
has the same influence on the processing of data since the software does not
care about the meaning of the tag but simply process it as it is supposed
to do.
With humans, it is different.
What will happen in the future if e-commerce B to B is developped
internationally which is undoubtely a desirable situation since our
companies are trading at this international level ?
Humans from all countries will send and receive messages and there is no
doubt that - even if
these messages are capable to go from an application in company A to another
one in a
different company B - humans will at least supervise and monitor the whole
process.
These humans will not be top managers, but operational persons in
wharehouses, plants, and so forth.
They will speak their national language and will be far from being fluent in
english. I remember being lost at 11 p.m. in the Netherlands asking for my
way in a country where I thought everybody was fluent in english. The
reality was quite different.
In conclusion, my own opinion is that standardisation bodies can have
english as a working language, in order to develop agreed terms (nouns,
verbs). The
question is then " why not having these english wordings as tags ? "
My answer is that humans - when looking at a transaction set (for an example
an Order which cannot be fulfilled as the client would like it to be, which
is a critical situation regarding the satisfaction of this client) - need
not only see the values of the fields but also the names of these fields,
i.e. the tags OR an equivalent of the tag IN THEIR OWN LANGUAGE..
The reality of EDIFACT when examined at the national level is that tags
(NAD, MOA etc..) have not been translated but that each of them has a
developped version <NAD = Name and Address> <MOA = Monetary Amount> and that
each EDIFACT message has a national language version. The user interface
will not be
(in France for example) <Name and Address> but preferably <Nom et Adresse>.
For more details about the way to cope with language translations using
XML/XSL see the CEN ISSS deliverable which deals with this subject (XMLEDI
workshop). It explains how a Transportation Firm Booking message can be
presenting to the receiver either
in english or in finnish according to predefined couples <person-language
spoken>.
Once there is an agreement on semantics, it can be left to each country to
produce a national version of the fields names and of the fields values. No
matter what the tag is for purchase order. What will be presented to the end
user
will be Purchase Order for an english speaking person, Commande for a french
speaking person and so on.
In fact tags could be purely abstract (XYZ for Name and Address, WXB for
Monetary amount etc or anything else). But why should we loose the
possibility to get information using tag suggesting what is the tagged
element. Personnally, as a french, I prefer meaningfull tags
even if they are based on english, as long as these tags see their influence
limited to data processing by software, not by humans.
----- Message d'origine -----
De : Armin Osterholzer <[EMAIL PROTECTED]>
� : Betty L. Harvey <[EMAIL PROTECTED]>
Cc : Bob Haugen <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Envoy� : vendredi 25 f�vrier 2000 02:52
Objet : Re: Article: Future of XML and EDI?
> Betty,
>
> in a little side note you are raising a very good point:
> "It is arrogant to automatically assume that the tags
> will be in English"
> Could you or anyone else on the list shed some light on
> how the various XML activities intend to cater for non-English
> in tags. What is the situation regarding transmission of Asian
> language (2-byte letters), e.g. Mandarine, Kanji, etc.. via XML?
>
> Maybe I misunderstand and this is a "non-issue", however with
> "traditional" EDI (ANSI, EDIFACT) we continue to have difficulty
> in that area.
>
> Again, thanks for any inputs on this subject.
> --
>
> Best regards,
> Armin
> Motorola Semiconductor Products Sector
> Information Technology - Europe, Middle East and Africa
> Email: [EMAIL PROTECTED]
> =========================================================================
>
> Betty L. Harvey wrote:
> >
> > On Thu, 24 Feb 2000, Bob Haugen wrote:
> >
> > > Betty Harvey replied:
> > > >I agree. I am a firm believer that the XML/EDI standardization
efforts
> > > >should be back in the industry standards organizations, ATA, TCIF,
RIF, etc.
> > >
> > > Do you think a "middle way" is possible here?
> > >
> > > Not grandiose projects to model every detail of the whole business
universe,
> > > but two modest and interconnected efforts:
> > >
> > > 1. Something like the ebXML Core Components project, to
> > > define a set of small objects and relationships
> > > with minimal assumptions that could be used
> > > to model maybe not all but most business processes;
> >
> > The core components group of ebXML is going to be really tough.
> > The real problems aren't going to be technical but are going
> > to be philosphical. It is really hard to get consensus on
> > a model or name of a tag within a small company, let alone globally.
> >
> > What organizations call things is very very personal. I will give
> > you an example. I recently completed DTDs for the U.S. Code and
> > Congressional Conference Reports and Committee Reports.
> > Committee Reports have a section which describes where the
> > proposed legislation would result in a change in the law. The
> > Senate calls this section the 'Cordon' and the House of
> > Representatives calls this section the 'Ramseyer'. The structure
> > of each is exactly the same. We resolved the problem by creating
> > a generic element <changes-in-law> which branches to <cordon>
> > or <ramseyer>.
> >
> > There some basic barriers that are necessary to overcome:
> >
> > 1. Naming - How are the elements named? It is arrogant to
automatically
> > assume that the tags will be in English. It is difficult to
> > understand a neutral tag like BSR. Is there are compromise?
> > Possibly.
> >
> > I believe that with Architectural Forms (which is still being
> > debated in the XML community) that we can solve this problem.
> > XML doesn't have any semantics. Element names are useful
> > to the human but the computer doesn't care if the element is
> > named <PurchaseOrder>, <PO> or <George>. With the right
> > software, it is very easy to have the element <George> be
> > represented as <PurchaseOrder> without doing transformation.
> >
> > 2. Information models - How is the information modeled? This is
> > also difficult. I think this is doable at a low level, i.e.,
> > address, organization, person, etc. When start expanding these
> > models out, you can run into problems. If you create the model
> > too tight you are guaranteed problems.
> >
> > >
> > > 2. Define skeleton process flows for multi-company collaboration -
> > > focusing on the external relationships, not the internal processes.
> > >
> >
> > I think you can do this. In the SGML world, DTDs were defined in
> > the industry standards organization. Most organizations that I
> > have worked with, i.e., airplane manufacturers, telecommunications,
> > railroad, etc. they took the industry standard and modified it for their
> > own internal processes. The railroad industry adopted the ATA
> > model for their electronic parts catalog. The ATA standard was
> > modified to meet the requirements of the railroad. They used
> > the 'best of breed' approach. They used the CALS 1840 specification
> > as their packaging standard.
> >
> > > (This is not to deny that special features will be
> > > required for special cases, and that the special
> > > cases would require lots of effort. Of course
> > > many of the special cases have already been
> > > modeled in EDI groups so maybe those could be
> >
> > Thats why we have rules so we can make exceptions to the rule |-).
> >
> > >
> > > Am I making any sense at all?
> >
> > I think a lot of sense.
> >
> > Betty
> >
> > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> > Betty Harvey | Phone: 301-540-8251 FAX: 4268
> > Electronic Commerce Connection, Inc. |
> > 13017 Wisteria Drive, P.O. Box 333 |
> > Germantown, Md. 20874 |
> > [EMAIL PROTECTED] | Washington,DC SGML/XML Users Grp
> > URL: http://www.eccnet.com | http://www.eccnet.com/xmlug/
> > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
> >
> > ==========================================
> > XML/EDI Group members-only discussion list
> > Homepage = http://www.xmledi.com
> >
> > Brought to you by: Online Technologies Corporation
> > Home of BizServe - www.bizserve.com
> >
> > TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
> > Leave the subject blank, and
> > In the body of the message, enter ONLY: unsubscribe
> >
> > Questions/requests should be sent to: [EMAIL PROTECTED]
> > To join the XML/EDI Group complete the form located at:
> > http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
>
>
> ==========================================
> XML/EDI Group members-only discussion list
> Homepage = http://www.xmledi.com
>
> Brought to you by: Online Technologies Corporation
> Home of BizServe - www.bizserve.com
>
> TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
> Leave the subject blank, and
> In the body of the message, enter ONLY: unsubscribe
>
> Questions/requests should be sent to: [EMAIL PROTECTED]
> To join the XML/EDI Group complete the form located at:
> http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
>
>
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
