- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Mon, 16 Sep 2002 11:06:07 -0400
- To: www-tag@w3.org
/ "Anthony B. Coates" <abcoates@TheOffice.net> was heard to say: |> To those applications, if you change the namespace name, you haven't |> changed the namespace of the vocabulary, you've *changed the |> vocabulary* by definition. | | You change the definition in principle, but not necessarily in practice. Not | that I would argue for versioned namespace URIs, but from an application | developer's point of view, detecting the versioned namespace URI and loading the | appropriate module for processing that version is no different to dealing with | other versioning situations. I think it is different. You can't develop an application that will know what the "next version" URI will be, so your application of today can't be programmed to "do the right thing" with some future version. Take XSL again as an example. XSLT 1.0 processors know what to do with an XSLT stylesheet that is marked "version='2.0'" (or version='10.0' for that matter). They can be programmed with this behavior because the namespace name of the elements isn't going to change (they'll still recognize xsl:stylesheet). I suppose you could do this with namespace names, if you introduced some structured convention for the URIs. But I think that would be wrong. (Because it would require applications to have another microparser and structured attribute values are wrong.) | so it should not be | assumed that namespace versioning will die out via a process of natural | selection. No, I don't think that at all. And I think for some applications and some sorts of version changes (as Noah has suggested), changing the URI may be exactly the right choice. But it's a pretty disruptive choice; more disruptive than necessary in many cases, I expect. Be seeing you, norm -- Norman.Walsh@Sun.COM | Waste no more time arguing what a good man XML Standards Architect | should be. Be one.--Marcus Aurelius Sun Microsystems, Inc. |
Received on Monday, 16 September 2002 11:07:01 UTC