- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 13 Dec 2005 11:06:58 -0500
- To: Dan Connolly <connolly@w3.org>
- Cc: www-tag@w3.org
Dan Connolly writes: > I would have thought that > <grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"> > was sufficient info to ground the document in the > web and, among other things, find the standard > schema. I think that's one way to do it, but not in all cases the best or only way. I certainly support the convention of publishing RDDL or something similar at the namespace URI, and using it when practical. Here are some of the reasons you might want to use xsi:schemaLocation in addition or instead: * Because xsi:schemaLocation was documented in the Schema Recommendation long before the community moved toward consensus on RDDL, there's a lot of schema-aware software out there that knows how to use xsi:schemaLocation. At least until RDDL-aware parsers become ubiquitous, using the attribute seems reasonable to me. * We know that for versioning and perhaps for other reasons, multiple schema documents describing the same namespace may be published over a period of time. Presumably RDDL purposes or other properties can be developed for designating either all of the versions that have ever been published, or else the latest (if you maintain linear versioning for your NS, which is common but certainly not in general required.) xsi:schemaLocation allows an instance document to say explicitly "this is the version of the schema that was in force at the time I was written." That seems useful to me. Though I don't think it relates to this particular use case, there is another factor relating to namespace descriptions that I think is worth mentioning: * While we were designing the schema language, at least one vendor described implementation experience with a production quality system that by default dereferenced the NS URI to get a schema. They found that in many cases this was impractical, because in fact so many namespaces do not have retreivable representations, and they could not tell in advance which did and which didn't. Network timeouts tend to be quite long on public networks, and typically much longer than the time required to successfully retrieve a representation (especially if that representation is cached.) So, their parsers spent long periods waiting on failed connection attempts. While the same concern applies up to a point for xsi:schemaLocation, at least someone is explicitly warranting that retrieval is a good bet for that one. Maybe over time high speed retrievability of NS representations will become nearly universal, but in the meantime we've had implementation reports suggesting that one wants explicit hints as to which retrievals should be attempted and which not. Noah -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
Received on Tuesday, 13 December 2005 16:07:15 UTC