OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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.


--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