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: ebXML Entity Classes - Resend



Or put another way, <thank/><you/>

I prefer the second XML representation of 'thank you' to the first, though I
do appreciate the flexibility inherit in the first representation.  Each
form has advantages and disadvantages, which lead to the selection of one
over another in certain applications.

I do not envision so compressed a vocabulary as you provide in your
statistics example.  I have observed that some early attempts to use XML to
convey business documents tried the limited vocabulary approach only to
abandon it in later attempts.  RosettaNet is one such example. It came to me
as no surprise that the restricted vocabulary approach was abandoned.  In my
EDI application experience, the scales are tilted to a rich vocabulary as
the more workable choice.

Most programming languages implement a compressed vocabulary.  They
generally address a broad range of needs which emanate from a few general

Business transactions tend to address very specific needs across a broad
range of end user and context requirements.  

I believe I prefer "<thank/><you/>" to the other construct because
conversation addresses specific needs across a wide context range.  Of
course, it could just be that I'm not fond of typing!  


-----Original Message-----
From: Chris Nelson [mailto:chris@cnelson.demon.co.uk]
Sent: Monday, March 05, 2001 12:04 PM
To: ebxml-core@lists.ebxml.org
Subject: Re: ebXML Entity Classes - Resend

JohnMcClure or Robert Miller (Ican't work out who) wrote

<I envision a future where the X12 and UN/CEFACT dictionaries give way to a
single global encyclopedia of information objects, defined not in teram of
some given syntax, but rather in terms of their semantic meaning,
interrelationships, and defining processes supporting those
interrelationships. I know that dream is a long way from fulfillment.  Yet I
also know our understanding of business processes and the data which drive
and control them has advanced remarkably in the short period of time
represented as the computer generation.  I certainly believe my dream will
be fulfilled in this century, and really expect it to happen within the
first half of this century.  That's still a long time, and well exceeds my
life expectancy.  But it is absolutely a dream that is within reach of those
now entering the profession./>

The statistical domain are working on this right now (and for
multi-dimesional data they solved it 6 years ago).  Consider that we have to
collect data about almost everything and be able to validate it.  We do
this, not with thousands of XML elements, but with a model which has classes
such a "Concept", "Variable", "CodeList" "Structure" etc.  With this, you
can describe most (perhaps all) "documents".  Of course, the domain has to
agree on a vocabulary, so you don't get away without any hard work in the
harmonisation world.  But you do avoid developing a DTD for every document
(or, in statistics case, every questionnaire or multi-dimensional dataset).

Anyway, back to ebXML, and I think you will find that there will be a core
set of comonents types, which will be re-used, extended, and renamed as they
become specific elements in a document.  This is what the core compoent
model says.

Chris Nelson
Dimension EDI

[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