Michael Smith wrote:
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.
And now imagine user who is not XML hacker. How he/she will able to decide?
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.
I see this as a big limitation. XML files should be self-descriptive, but namespace is not always sufficient to identify document type if you are using languages that have several profiles in the same namespace. Some languages provide its internal means for it (version attribute). But other languages like XHTML doesn't provide such mechanism.
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).
I agree with you that in general locating-rules are better approach for schema associations. But locating-rules can't solve some problems (like interchanging documents, changing their locations) in a way that would be sufficiently friendly from user's point of view. And by users I don't mean you or me, but XML BFUs (no ofense meant) -- they simply will not understand questions about selecting schemas, they will not be able to edit locating rules file even with some sophisticated UI, ... But simple PI used in cases where schema is not registered inside editor would help.
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.
I think that you are expecting too much from users here :-)
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.
From users perspective it is easier to cope with one file than with more than one file.
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 Idon't think the proposed PI is the right solution for doing it.
Having something like locating rules standardized and portable between different tools would be really great and I would be for such activity. But it still doesn't solve all the ad-hoc problems that can be easily solved by PI.
-- ------------------------------------------------------------------ Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz ------------------------------------------------------------------ Profesionální školení a poradenství v oblasti technologií XML. Podívejte se na náš nově spuštěný web http://DocBook.cz Podrobný přehled školení http://xmlguru.cz/skoleni/ ------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
