- 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