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] | [List Home]

Subject: Associating documents and schemas

In working on my Emacs XML mode, I have had to confront the old chestnut 
of how to find a schema for a document.

At the moment, I provide mechanisms based on the document's filename and 
root element name.  However, I want to add a mechanism that allows the 
user to put something in the document to explicitly indicate what schema 
they want to use for authoring.  The schema to be used cannot always be 
inferred from the root element name alone given that they may be 
document specific customizations or multiple profiles sharing the same 
namespace URI.  It's inconvenient and error-prone to have to put this 
information in a separate file.

I think multiple mechanisms are possible and reasonable. Different 
approaches have different trade-offs.  I don't think it is necessary or 
desirable to fix on one single approach.  However, I think it might be 
useful for each possible, reasonable approach to recommend a single way 
of using that approach. For example, I might well choose to implement a 
processing instruction in my product.  OxygenXML mention on their 
homepage that they are support a processing instruction for specifying 
the RELAX NG schema. There is nothing to be gained by our each doing 
something different. It seems to me it would be helpful for users if we 
recommended a particular target name and syntax for a vendor to use, if 
a vendor decides they want to support a processing instruction. 
Similarly, a vendor might want to allow the schema to be specified using 
a URI in a global attribute on the root element. I think it would be 
useful to recommend a particular attribute name and namespace URI to 
use.  The idea would be not to recommend any particular way to the 
exclusion of others, but simply to improve interoperability amongst 
products that would otherwise invent their own non-interoperable ways to 
do things.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]