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: Possible responses to QR Team

I'd like to suggest that the solution is a *combination* of XMLS and RDFS.
That is the perspective of the DCN -- to have a small set of XML elements,
instances of which point to entries in an RDFS dictionary. The specification
for the DCN has a full section describing the roles of each schema language,
the benefits, and the alternatives.

Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)
360-301-1102 (cell)

For the latest Data Consortium Namespace Specification, please see
http://www.dataconsortium.org/namespace/DCN150.DTD.pdf or
http://www.dataconsortium.org/namespace/DCN150.DTD.doc or

For the latest Data Consortium Dictionary, please see
http://www.dataconsortium.org/namespace/DCD100.pdf or
http://www.dataconsortium.org/namespace/DCD100.xml (IE5)

-----Original Message-----
From: Martin Bryan [mailto:mtbryan@sgml.u-net.com]
Sent: Thursday, March 01, 2001 12:26 AM
To: ebxml-core@lists.ebxml.org
Cc: DHG; DAMSAD Server
Subject: Re: Possible responses to QR Team

I wish to advise you of the following statements made by members of the
sbXML Context group in e-mails over the last few days:

Lauren Wood wrote
>I thought in Vancouver that we were trying to come up with a system whereby
> people can use whichever version of schemas they want, whether DTDs or W3C
> Schemas, and that the XML documents themselves were the things that had to
 > interoperate, not the schema language. Am I missing something here? This
 > would seem to imply that it must be possible to get core components in
 > form (perhaps with added documentation as to datatypes or other
 > as well as W3C Schema form. Or did I misunderstand something?

Eduardo Gutentag wrote:
>There is nothing in the assembly rules that constrains the input type. I
don't believe either
that there should be.

Arafon Gregory wrote:
>The input format will
*probably* be in W3C Schema, but not necessarily. This was one of the points
of using the neutral output format as an option, so that you could get away
from having to bind the semantic definitions to a particular syntax until
the very end.

The gist of these arguments is  that an ebXML repository would need to be
able to store any type of element definition (XML DTD, W3C XML Schema, SOX,
Microsoft XML Schema, etc). This implies that software applying context to
repository content would have to be able to apply the rules irrespective of
the form of input. It also implies that any attempt to assemble components
stored in different repositories using different data formats would have to
be allowed for. I do not believe a) that such tools can be developed or b)
that they can be made available at costs SMEs can afford.

I strongly oppose the statements made above. I believe that a common format
must be used for the type definitions held in ebXML repositories. I believe
that only one of the currently defined formats meets the needs of the EDI
community, and that that format is the W3C XML Schema complex and simple
type definition format. (My reasoning for the above statement is not based
on the XML expression of the language, which is terrible, but on the
functionality of the language, especially in the area of datatype

Martin Bryan

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

[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