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: English Language Tags


Semantics dictates syntax.  Semantics is the horse, syntax the cart.  

RDF (and RDF Schema)is a semantic definition tool.  To imbed RDF in an XML
Schema is to put the cart before the horse.  RDF is not needed to realize
information exchange in a production environment.  Rather, its use precedes
the establishment of a production environment.  From a rich RDF definition
set, one might derive a number of syntactic constraint definitions,
including XML DTD and XML Schema among them. 

XML Schema is a syntax definition tool.  The content of a given XML Schema
is a result of the need to express constraints dictated by the semantics of
the information to be exchanged.  A schema should provide some reference to
the semantic information from which it derives, so that the semantic intent
of an information exchange instance can be determined. And a schema must
provide sufficient syntactic control of the expression of information
exchange instances that the intent of the information exchange instance can
be realized in a production environment.  Lack of such control may result in
a level of processing errors that impedes its use in production. 

If there were one and only one source of semantic information for all of the
elements defined in an XML Schema, that source could be referenced just once
in the Schema, and there would be no need for UID's on each element.  But
that's not the way of the world.  Semantic information is distributed across
many entities.  In the business world, some semantics is culled from global
standards organizations, some from industry groups, some from governments,
some from individual business relationships, and on and on.  

The EDI Standards X12 and UN/CEFACT do produce documents which are
referenced just once in a message instance. However, these doucments contain
imbedded references to other documents, and even accounting for these
referneces provide only a minimal semantic definition of the messages.
Implementation of EDI messages is a difficult task, in part because of the
inability to locate needed semantic information.  An intent of ebXML is to
provide a framework in which detailed semantic information can be located
for all elements of a message.    

The UID provides a minimal reference within an XML Schema to the semantic
definitions required to provide understanding of information. So John
McClure's approach provides, in my opinion, the 'normal way' to define a
schema.  Perhaps Martin uses 'normal' in the sense of 'prevalent' as opposed
to the sense of 'standard'.

Cheers,
        Bob Miller 

-----Original Message-----
From: Martin Bryan [mailto:mtbryan@sgml.u-net.com]
Sent: Friday, February 02, 2001 1:58 AM
To: John McClure; ebXML Core
Subject: Re: English Language Tags



John wrote


> Martin writes:
> |A better approach is to use an namespaced element within an appinfo
> |component of the element's annotation, e.g.
>
> Fine, but see below.
>
> and
> |If you really must force RDF on the scenario then put the RDF statement
> |within an adjacent appinfo statement within the same annotation.
>
> That would cerainly work, if you want such information put into the XML
> Schema document in the first place.  In the DCN, such metadata as 'process
> specification' are placed into the RDFS dictionary(*).

Thats the normal way, but it introduces a secondary processor. As you will
see in other messages today, I am against relying on the presence of any
tools other than those available in every web browser.

> So here's the key question: what is the element-type of the ancestor(s) of
> the <appinfo> element you mention?
The definition of the element or attribute that is being defined is always
"one of the ancestors" - not the immediate parent as its always wrapped in
an annotation element, and may be part of a complexType defintion

> If it is an element-type definition,
> then some may be concerned that too many element-types will be defined,
and
> programming would be an expensive nightmare. It is that scenario -- in
> particular -- that the DCN endevours to avoid and, as a result, 'only' 15
> XML element-types are defined in the DCN's DTD, and 'only' 15 RDF Schema
> class-types are defined in the DCN's dictionary.

You can bet your bottom dollar that for ebXML the number will eventually run
into thousands, However, this is beside the point. They are all defined
using the element set defined in W3C XML Schemas, some 30 odd elements.

Martin


[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