[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 exchanged. 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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC