OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Summary of XML Datatypes as required for B2B applications



From ebxml@eccnet.eccnet.com Mon Apr 17 09:22:57 2000
Newsgroups: 
Date: Mon, 17 Apr 2000 09:22:57 -1000 (HST)
From: Betty Harvey <ebxml@eccnet.eccnet.com>
To: Tim McGrath <tmcgrath@tedis.com.au>
cc: Samuel L Matzen <smatzen@slm.com>, Ian Galbraith <ian@oms-services.com>, 
    "'ebXML Core Components (E-mail)'" <ebxml-core@lists.oasis-open.org>, 
    "William J. Kammerer" <wkammerer@foresightcorp.com>, 
    David <realtime@anywhere.co.uk>, 
    "XML/EDI Group (E-mail)" <xmledi-list@lists.bizserve.com>
Subject: Re: Summary of XML Datatypes as required for B2B applications
Fcc: sent-mail
In-Reply-To: <38FA87AC.82754477@tedis.com.au>
Message-ID: <Pine.LNX.4.10.10004170904550.19508@eccnet.eccnet.com>
X-Reply-UID: (2 > )(1 946053745 2090)/var/spool/mail/ebxml
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Finally - voices in the wilderness. I feel like I have been yelling in the
wind.  I have been concerned about XML/EDI efforts (not just ebXML)
reinventing YAS (yet another standard) without taking advantage of what
has been accomplished in the past.

I have worked on deriving XML DTDs from both X12 and EDIFACT dictionaries.
If we don't take advantage of the 'data analysis' that has been done
by the EDI standards group, we are doing ourselves a big disservice.
Basically, the data dictionaries are the hard part - this is where the
main effort of analyzing the business requirements take place.  Not
taking advantage of this great body of work is -- JUST PLAIN STUPID.

ebXML is a unique organization.  We have EDI people and XML people
coming together to create a common standard.  We each have a understanding
of our perspective environments.  There is good from both standards.
The data dictionaries from EDI are good (definately all inclusive -
more than most people will need).  XML can take the EDI dictionaries
and make the easy to use and easy to understand to both implementors,
users and computers.

Betty

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Betty Harvey                         | Phone: 301-540-8251 FAX: 4268
Electronic Commerce Connection, Inc. |        410-787-9200
13017 Wisteria Drive, P.O. Box 333   | 
Germantown, Md.  20874               |
harvey@eccnet.com                    | Washington,DC SGML/XML Users Grp
URL:  http://www.eccnet.com          | http://www.eccnet.com/xmlug/
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/  

On Mon, 17 Apr 2000, Tim McGrath wrote:

> Well!  we thought it was only us.
> 
> Coincidentally, I have recently been asked by the ebXML sub-Group of the
> Australian CEFACT Management Committee to voice similar concerns.
> 
> Whilst i understand the thread under discussion originates from the XML/EDI
> Group List, it has some application to the processes within ebXML as well.
> 
> As yet, it has been unclear from the core components group how or when the
> semantic knowledge of 'heritage' EDI methods (e.g. EDIFACT) will be incorporated
> into this initiative.
> 
> I suspect, there are a considerable number of persons with appropriate knowledge
> and experience in solving many of the semantic and structural issues facing the
> group who are wondering how to contribute to this process.
> 
> The statement in the Core Componenents section of the ebXML Requirements
> Specification is:
> 
> > ? Use semantics solutions that accommodate currently defined accredited EDI semantics where they add value
> >
> 
> - are there processes in place to bring this about?
> 
> 
> Samuel L Matzen wrote:
> 
> > Ian,
> >
> > I think you have voiced my concerns here.  But what I suspect will happen is
> > that most of the "new" efforts being started now are primarily through
> > ignorance of the value of traditional EDI dictionary content.  These new
> > efforts will recreate and remodel until they find that their efforts fall
> > short of the universal need, then they will have no choice but to look at
> > the real world of EDI and integrate the EDIFACT and other data dictionaries
> > into their models.
> >
> > IMHO: What is happening here is that most of these efforts are trying to
> > differentiate themselves from traditional EDI rather than integrating
> > themselves into the vast effort already expended to create the standards
> > already in place.  Then by manipulating the statistics, making the
> > e-commerce community believe they have a solution.  Their solutions may work
> > for a small part of the total EDI picture, but every time I take a look at
> > them, find them lacking many of the requirements for real-world, universal
> > EDI.  But I could be wrong.
> >
> > Samuel L Matzen
> > smatzen@slm.com
> >
> > -----Original Message-----
> > From: owner-xmledi-list@lists.bizserve.com
> > [mailto:owner-xmledi-list@lists.bizserve.com]On Behalf Of Ian Galbraith
> > Sent: Sunday, April 16, 2000 10:34 AM
> > To: 'ebXML Core Components (E-mail)'; William J. Kammerer
> > Cc: David; XML/EDI Group (E-mail)
> > Subject: Re: Summary of XML Datatypes as required for B2B applications
> >
> > Oh William, how right you are!  The EDIFACT dictionaries (and the rest) have
> > evolved through years of consideration of real user needs; it is not a big
> > deal to convert the essential semantic content of these dictionaries into a
> > different syntactic environment.  This was exactly the intent behind EDML.
> > The EDML proof of concept work demonstrated a means of transferring semantic
> > content (ie data dictionaries) developed for one syntactic message structure
> > into a quite different syntactic structure.  So to my mind an obvious way to
> > accelerate the development of XML-based ecommerce would be to exploit the
> > EDIFACT (and other) data dictionaries. But right now I don't have much
> > confidence that the good bits of EDIFACT, X12, HL7, etc will actually be
> > exploited.  It seems perhaps, that in rejecting the syntactic structures of
> > "traditional" EDI the semantic baby is being thrown out with the bathwater.
> >
> > Best regards
> >
> > Ian
> >
> > -----Original Message-----
> > From: William J. Kammerer <wkammerer@foresightcorp.com>
> > To: 'ebXML Core Components (E-mail)' <ebxml-core@lists.oasis-open.org>
> > Cc: XML/EDI Group (E-mail) <xmledi-list@lists.bizserve.com>
> > Date: 15 April 2000 15:12
> > Subject: Summary of XML Datatypes as required for B2B applications
> >
> > >There's an interesting thread entitled "Summary of XML Datatypes as
> > >required for B2B applications," started by Martin Bryan, with commentary
> > >by Messrs. Kotok, Folkerts, and Haugen, on the XML-EDI mailing list. See
> > >http://www.mail-archive.com/xmledi-list%40lists.bizserve.com/ for the
> > >archives.
> > >
> > >Note that EDIFACT is being re-invented all over again, especially the
> > >MEA, CUX and DTM segments. Bob Haugen says:
> > >
> > >   I think all of your other suggestions are essential to business
> > >   communications.  One thought:  if you left the timestamp off
> > >   the currency and put it on the business event (which needs it
> > >   anyway), then your measurements and currencies
> > >   would have the same structure ( amount and unit).  This could
> > >   mean one structure for measurements of all resources.
> > >
> > >Absolutely brilliant!  Can't argue with this - building up semantic
> > >meaning from lego blocks.  EDIFACT does this already with the standard
> > >CUX (Currencies) - DTM (Date/time/period) segment group.  X12 does also,
> > >to some extent, but tends to overload its segments semantically (e.g.,
> > >the X12 CUR segment includes the date and time itself, and does not
> > >rely on a separate segment to convey the exchange period).
> > >
> > >EDIFACT has been around for over a decade, and apparently is too complex
> > >to use (because of the semantic building block concept?).  Otherwise we
> > >wouldn't be all scrounging around trying to reincarnate EDI in XML
> > >syntax.
> > >
> > >But I do like the concept of semantic building blocks or core
> > >components.  So why re-invent them from scratch?  Just take a look at
> > >the EDIFACT directories and dictionaries, and all of the core components
> > >for ebXML can be effortlessly extracted.
> > >
> > >Or, why don't we just use EDIFACT for ebXML: warts, delimiters, and all,
> > >and save ourselves a heck of a lot of time and trouble?
> > >
> > >William J. Kammerer
> > >FORESIGHT Corp.
> > >4950 Blazer Memorial Pkwy.
> > >Dublin, OH USA 43017-3305
> > >(614) 791-1600
> > >
> > >Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> > >"Commerce for a New World"
> > >
> > >
> > >
> > >==========================================
> > >XML/EDI Group members-only discussion list
> > >Homepage =  http://www.xmledi.org
> > >
> > >Brought to you by: Online Technologies Corporation
> > >                  Home of BizServe - www.bizserve.com
> > >
> > >TO UNSUBSCRIBE: Send email to <xmledi-list-request@lists.bizserve.com>
> > >               Leave the subject blank, and
> > >               In the body of the message, enter ONLY: unsubscribe
> > >
> > >Questions/requests should be sent to: owner-xmledi-list@bizserve.com
> > >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.org
> >
> > Brought to you by: Online Technologies Corporation
> >                   Home of BizServe - www.bizserve.com
> >
> > TO UNSUBSCRIBE: Send email to <xmledi-list-request@lists.bizserve.com>
> >                Leave the subject blank, and
> >                In the body of the message, enter ONLY: unsubscribe
> >
> > Questions/requests should be sent to: owner-xmledi-list@bizserve.com
> > To join the XML/EDI Group complete the form located at:
> > http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
> 
> --
> regards
> tim mcgrath
> TEDIS   fremantle  western australia 6160
> phone: +618 93352228  fax: +618 93352142
> 
> 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC