[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Associating schema with document
Murata-san raised the issue of whether we want to do this at all. We need to resolve that before we resolve the issue of how to do it. There's one crucial difference between a processing instruction and an attribute: adding a processing instruction cannot change the validity of a document whereas adding an attribute can. This means that if we use a namespaced attribute for this, we are faced with two options, both of which seem very unattractive to me. (a) The namespace of this attribute (let's use a prefix of "xri" for this) is not treated specially by RELAX NG. This means that an instance can use xri:schemaLocation only of the schema explicitly allows it. That's fine except that it means that xri:schemaLocation cannot be used with any schema that is equivalent to an existing XML 1.0 DTD, since all existing XML 1.0 DTDs are "closed" (only allow a fixed set of attributes and elements). Thus, it totally fails to XML 1.0 DTD compatible, which was the main goal of doing this. (b) RELAX NG treats this namespace specially. Attributes with this namespace URI wouldn't show up as attributes in the RELAX NG data model but as something else. They would be like xmlns attributes for the namespace Rec, or like xsi in the W3C XML Schemas Rec. Now, if I have some document type that is defined by some specification independently of RELAX NG, that won't give any special treatment to the xri namespace. If I want to then capture this document type in RELAX NG, I can't do it accurately: the RELAX NG schema will give special treatment to the xri namespace which the document type I'm trying to capture doesn't. It's assuming that RELAX NG is the center of the universe. If I had to pick one feature of W3C Schema that I detest the most, it's a tough choice, but I think I would nominate the special treatment of the xsi namespace. I see no problem in using a processing instruction in a spec that is designed purely for backwards compatibility with XML 1.0 DTDs. Nobody is proposing this as part of the main RELAX NG spec. It is being proposed only as part of RELAX NG DTD Compatibility. James --On 21 September 2001 11:55 -0400 Josh Lubell <lubell@cme.nist.gov> wrote: > David, > > I don't think this issue was ever resolved. > > Josh > > ----- Original Message ----- > From: "David RR Webber - XMLGlobal" <Gnosis_@compuserve.com> > To: "Josh Lubell" <lubell@cme.nist.gov>; "RNG List" > <relax-ng@lists.oasis-open.org> > Sent: Tuesday, September 18, 2001 10:51 PM > Subject: Re: Associating schema with document > > >> Josh, >> >> Trawling back thru old email here. See my thoughts below. >> >> Did we get a resolution on this anyway? >> >> Thanks, DW >> ======================================== >> Message text written by Josh Lubell >> > >> I agree that a processing instruction is the most obvious way to link a >> RELAX NG schema with a document. However, I'm concerned about how this >> would >> sit with the W3C. My understanding is that the use of processing >> instructions is discouraged in W3C standards. >> >> >>>>>>>>> This is an on-again-off-again issue. Seems to me that >> the Pandoras box is open. Another approach is to have a MIMEtype >> of RELAX - so that receiving systems know to invoke the RELAX processor? >> << >> >> If we adopt this approach, could it impact our ability to influence W3C >> XML >> Schema 2.0? Should we care? >> >> >>>>>>>>> This is an interesting question. Are we really trying to >> influence Schema 2.0 - whatever that is? Seems to me we are going >> along a different, and better, path. People who want whatever it is >> they see they desperately need in Schema will continue to use it; >> people who want what we have will continue with us. Hopefully >> our price point is better and we have more users. Applicability >> to ebXML is a key. We're currently doing things in ebXML >> using RELAX that I believe simply cannot be done using >> W3C Schema -I'm hoping to have a white paper out by the >> end of the month on this. >> >> I strongly doubt the W3C will want to thank us any year soon. >> <<< >> >> DW. >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: <http://lists.oasis-open.org/ob/adm.pl> >> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC