- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Mon, 28 Jun 2004 10:34:45 -0400
- To: www-tag@w3.org
- Message-id: <871xjzn43e.fsf@nwalsh.com>
Here is the text. I propose that it be inserted after the first normative paragraph in section 4.2.2 (the one that ends "...for users of the format.") For almost all applications, changing the namespace name of an element completely changes the element name. If "a" and "b" are bound to two different URIs, a:element and b:element are as distinct as a:eieio and a:xyzzy. Practically speaking, this means that all deployed applications will have to be upgraded before they will recognize the new language. If you've written a successful application that is widely used on the web, this upgrade cost may be exorbitant. It follows that there are significant tradeoffs to be considered when deciding on a namespace change policy. If your existing vocabulary has no extensibility points (if it does not allow elements or attributes From foreign namespaces or have a mechanism for dealing with unrecognized names from the same namespace), it may be absolutely necessary to change the namespace name. But to the extent that you can design a language that allows some form of extensibility without needing to change the namespace name, it will be easier to move forward in an evolutionary manner. Be seeing you, norm -- Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc. NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Received on Monday, 28 June 2004 10:34:54 UTC