- From: Eliot Kimber <ekimber@innodata-isogen.com>
- Date: Wed, 04 May 2005 21:36:46 -0500
- To: xmlschema-dev@w3.org
Biron,Paul V wrote: > > Remember, however, the xsi:schemaLocation [1] is just a hint...schema > processors are not required to honor it. In a similar vein, the > presence of <!DOCTYPE> in an instance does not mean that processors > must perform DTD validation, although most processors do so by > default. Of course I realize this. But in the case where schemaLocation is not respected, you are simply back to the case where there is no schemaLocation, in which case it's up to the processor to select the appropriate schema by whatever means. In practice your documents are almost certainly going to be processed in an environment over which you have enough control to determine exactly how schemaLocation is handled and what happens when there is no explicit schemaLocation. So the fact that schemaLocation is a hint doesn't change the fact that it is the only thing in a schema-based world that is the functional equivalent of public IDs for external DTD subsets, that is, a reference to a specific resource, in which it is appropriate to encode some sort of version-specific information. I think in practice the question comes down to either requiring the use of schemaLocation and ensuring that it is respected for the processing you care about (and can control or influence) or ignoring schemaLocation, if present, and using some external mechanism to bind namespaces to schemas on a case-by-case basis. This binding could be done using per-document XML catalogs, or metadata enbedded in the document (e.g., "myns:schemaVersion='1.x'"), or metadata held in a content management system and provided to the schema-aware XML processor on demand. For example, my toy schema-aware XML content management system, XIRUSS-T (http://xiruss-t.sourceforge.net/), is specifically designed to maintain a name-space-to-schema-document mapping and makes that mapping available through an API. It also provides a general document-level metadata mechanism by which applications could change the namespace-to-schema association for specific documents. Or said another way, because the association between documents and schemas is merely a hyperlink association and not a syntactic inclusion (as for external DTD subsets), once a document is out of your sphere of control, you have no way of knowing what will be done with it so there's no point in worrying about it. So the only case worth talking about is the one where you do in fact control how the document-to-schema assocation is done, in which case schemaLocation is either respected or, if it's not, you've provided an alternative. So in that case, saying "schemaLocation is a hint" is meaningless--in this context it's either a directive(because we've made the choice to always respect it) or it's ignored if specified (because we've made the choice to do something else). There is no meaningful use case in which the treatment of schemaLocation is unpredictable. Or perhaps more accurately: the use cases in which the treatment of schemaLocation is unpredictable are not useful use cases so there's not point in discussing them. Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9390 Research Blvd, #410 Austin, TX 78759 (512) 372-8155 ekimber@innodata-isogen.com www.innodata-isogen.com
Received on Thursday, 5 May 2005 02:35:24 UTC