RE: Possible responses to QR Team

[John McClure <hypergrove@olympus.net>]

Martin,
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.
Regards,
John

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
http://www.dataconsortium.org/namespace/DCN150.DTD.htm

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
DTD
 > form (perhaps with added documentation as to datatypes or other
constraints)
 > 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
definition.)

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