I believe the documentation is confused -- and possibly the spec on which it is based.
Having a namespace value (null) which causes the the XML to take on some value which cannot be determined except by examining the past program execution trace possibly back all the way to when the document was begin, is crazy. Note very carefully: "no namespace prefix is printed but just the name" is suddenly departing from the realm of semantics, where every other value for the namespace parameter resides, to PURELY COSMETIC SYNTAX -- and leaving the choice of ACTUAL NAMESPACE to the luck of the draw. Every other value there is precisely the reverse: specify the namespace, and leave the cosmetic choice of prefix up to the context in which it is used (including a preceding call to setPrefix()). Any code which supplies null here, and is called by other code, will behave with different semantics, depending on NON-SEMANTIC CHANGES in the calling code. Remember, namespace prefixes DO NOT CONVEY SEMANTIC CONTENT. They are cosmetic. You can replace all the namespace prefixes in an XML document with x0000001: x0000002:, etc., and not change the meaning of the document at all. It is entirely understandable that people are confused by this. It is also entirely necessary that people get clear on it. I will argue that it is HARMFUL to accept null here. I don't know how to weigh that harm against the known harm of breaking code that runs, but it is definitely not "free" to accept null -- and given that it has already broken the code, I argue it should NOT start accepting null again, but rather should be properly documented as offering no direct control over the choice of namespace prefixes in this method (and refer to setPrefix()), and document it as throwing a NullPointerException if either argument is null. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
