Jirka Kosek <[EMAIL PROTECTED]> writes: > Michael Smith wrote: > > >I use both the locating-rules and ARX mechanisms, and I cannot > >think of a use-case I could not deal with well by adding > >information to a locating-rules file or ARX config file. > > There is one. Suppose that you have created microformat which is a > subset of XHTML and you have defined RNC schema for it. Because this new > format is based on XHTML it lives in http://www.w3.org/1999/xhtml > namespace.
If the editor you're using understands locating-rule files, perhaps you might put the following in a locating-rules file: <namespace ns="http://www.w3.org/1999/xhtml"; typeId="XHTML"/> <namespace ns="http://www.w3.org/1999/xhtml"; typeId="XHTML Micoformat1"/> <namespace ns="http://www.w3.org/1999/xhtml"; typeId="XHTML Micoformat2"/> That is, multiple associations for the same namespace (or same file extension, or same document element...). The locating-rules schema does not prevent you from having multiple instances of a namespace element with the same value for the "ns" attribute. Then, when you opened up the file in the editor, it would display a list of the schema choices and ask you to choose one. Emacs/nXML currently just uses the first association match it finds, and ignores the rest. But it could be changed to behave differently. It or any other application that had locating-rules support could to look check for all matches and then say, "Found multiple schemas that could be associated with this document. Which one do you want to use for this session?" And your editor could also prompt you with "Always associate this schema with this document?" If you say Yes, it writes something like the following to a (local) locating-rules file: <uri resource="/home/msmith/foo.html" typeId="XHTML Micoformat1"/> So the association becomes persistent. Every time you open up that file in your editor, it automatically uses the schema you want. As long as you don't move the file. But that is not an uncommon limitation. If, for example, you are managing a document in a version control system, it loses its association with the system once you move it to another location in your local filesystem. > If you will try to edit this document in XML editor with default > setup you will be offered by full list of XHTML elements. You > need some easy way (from user perspective) to override default > schema bound to this namespace and use the restricted one. I think it would be much better for the editor to provide a user-friendly front end to managing data in the locating-rules file (or whatever similar config file it might use). > If you will store schema association sideway into a some config file, > users will lost this file when interchanging document. OK, I can agree about that being a problematic case. But even then it seems to me that the information in the schema-association PI is necessary to such users exactly one time: When they first receive or obtain the document, so they know the location of a schema that they can use to do validated editing of the document. After they know a schema, they are IMHO much better off configuring their editor(s) to automatically associate that schema with the document or document type, making it unnecessary to specify the association per-document. I think that in general, if users receive or obtain XML documents and expect to do something with them, the context in which they obtain or receive them will likely be such that they already have at least some small clue about what type of document it is and where they might be able to find a schema to use for doing validated editing of it. The only case in which I could see the PI being of any value is when a user obtains or receives an XML document without having any idea at all about what kind of document it is. I think that is probably a very rare case, and that is it much more likely that users will get documents from somewhere or someone with knowledge about a schema with which to associate the document. They may in fact just get the schema along with the document. Maybe even along with a config file that follows some kind of standard (locating-rules format or whatever) that they can "plug into" any editor that complies with the standard. And note that all would only be necessary for the "ad hoc" problem you have described. Which I have been taking to mean the case where you are distributing a document instance of an ad-hoc schema (or private schema or whatever you want to call it) and you want to provide some easy way for users to associate that instance with a schema. In the case of industry-standard schemas such as DocBook and TEI and XHTML (including any subsets of those schemas), IMHO, the proposed PI is absolutely the wrong way to deal with automatic schema association. Vendors and tool developers and distro packagers should instead use some means of configuring their applications and systems to handle default associations for those automatically, and for users to deviate from the defaults -- per-session and/or persistently -- without the need for users to specify a PI in their individual document instances. Hopefully we can find a way to do that in a standard way. But I don't think the proposed PI is the right solution for doing it. --Mike
smime.p7s
Description: S/MIME cryptographic signature
