ACTION NW 2004/05/14: Propose text on tradeoffs for section 4.2.2.

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.