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

Thank you for sharing this, Martin.

My belief was that the format stored in the repository would be 
chosen, and that it would be W3C XML schema.  I don't see how this
all works well if we are not consistent. 

As for syntax neutrality, wearing my X12 hat, I think that's it
the critical point for the business community.  Some of us have to
be able to develop 'messages' in several formats, from the stored
schema.  Whether we do that with a tool, or by some manual means,
is not as important to me as is consistency in the business data

Mary Kay

-----Original Message-----
From: Martin Bryan [mailto:mtbryan@sgml.u-net.com]
Sent: Thursday, March 01, 2001 3: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