[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: using schemaLocation to point multiple same namespace sche
Hi Manos, > Thanks for your reply. The spec seams a little contradictive to me, > since it urges me to use > > <p1:root xmlns:p1="NS_URI1" > xsi:schemaLocation="NS_URI1 schemaLocation1" > > to bind a schema (location) to a namespace URI, while allowing > processors to ignore the second URI and try to resolve the schema > using the first one... this does not "degrade well"... I'm fully prepared to agree that the "specification" about how to locate a schema for a particular document is very loose in the W3C XML Schema Recommendation. I'm under the impression that this was intentional, because different applications might want to use different mechanisms for retrieving schemas -- an authoring environment might want to use the xsi:schemaLocation attribute; a DOM-based application might want to hard code the schemas that are used to validate the documents it accepts; an application in a closed environment might want to use a catalog of some kind to locate schemas based on the namespace URI; and so on. But I don't understand what problem you're encountering with the example you gave above. In the above, you're saying that the schema for the namespace NS_URI1 is located at the schema location schemaLocation1. Those processors that use the xsi:schemaLocation attribute should have no problems with this -- they should use the schemaLocation1 as the location of the schema for the NS_URI1 namespace. >> This option implies that if you already have a schema for a given >> namespace then there is no need to find another one. > > True but different practices collide (see above). > > What about the case of: > > <p1:root xmlns:p1="URI1" xmlns:p2="URI2" > xsi:schemaLocation="URI1 schemaLocation1 URI2 schemaLocation2" Here, you're saying that the schema for the namespace URI1 is at schemaLocation1 and the schema for the namespace URI2 is at schemaLocation2. Again, I don't think that there's any problem here. Schema validators that use the xsi:schemaLocation attribute will locate the schemas at schemaLocation1 (to validate nodes in the URI1 namespace) and at schemaLocation2 (to validate nodes in the URI2 namespace), and combine them to create the schema against which the document will be validated. The issue I thought we were discussing was when you have: <p1:root xmlns:p1="URI1" xsi:schemaLocation="URI1 schemaLocation1 URI1 schemaLocation2" /> Here, I'm saying that the schema for the namespace URI1 is at schemaLocation1. I'm also saying that the schema for the namespace URI1 is at schemaLocation2. There are two locations for the schema for the namespace URI1. As I said, in these situations, a processor is within its rights, according to the spec, to ignore schemaLocation2 and only use the schema from schemaLocation1. By the time it comes across the definition that says that the schema for the namespace URI1 is at schemaLocation2, it already has a schema for that namespace -- the one it found at schemaLocation1. (If it didn't manage to retrieve a schema from schemaLocation1, I think it should try to retrieve one from schemaLocation2, such that if you do specify multiple schema locations for a particular namespace URI then they should be alternative locations.) Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|