Re: two little DOM2 questions...
Stefan Haustein wrote: > Hello, > > can anybody explain to me why in DOM2 both > > public Attr setAttributeNodeNS(Attr newAttr); > and > public Attr setAttributeNode(Attr newAttr); > > exist, but only one remove method > > public Attr removeAttributeNode(Attr oldAttr); Off the top of my head, I believe it is an omission. > Also, the current DOM2 spec says that mixing > simple and namespace-aware methods should be > avoided and will result in unpredictable behavior. > > There are five methods in DOM2.Element that I > would normally expect to default to the element > namespace if available: > > public String getAttribute(String name); > public void setAttribute(String name, String value); > public void removeAttribute(String name); > public Attr getAttributeNode(String name); > public NodeList getElementsByTagName(String name); > > What is the reason for leaving the semantics open to the > implementation instead of reusing them as convenience > methods? Perhaps the word "unpredictable" might be replaced with "suprising" or "undesirable". Level 1 methods preserve level 1 behavior, including where colon may be used as a non-namespace-delimiting character. Intermixing level 1 methods with level 2 methods can produce quite unexpected results, which are nonetheless strictly predictable from the spec, I believe. There are some simple cases where I believe intermixing does work, including: 1. If there are no nodes in your hierarchy which use namespaces (or level 1 names with colons in them). 2. If a level 2 parser produces a level 2 DOM hierarchy, always setting the prefixes in addition to the namespaceURIs, which is then exclusively traversed and manipulated by a level 1 application. But where a level 2 application starts freely modifying the tree, the simple model required by the level 1 methods may be destroyed. This is because the URI, rather than the optional prefix, is used for the unique key. If this were not the case, the addition of level 2 namespace functionality seems rather pointless to me. There are a wide variety of interesting situations including obvious and non-obvious cases -- not failures of the spec to predict what will happen, but failure of the user to produce a desirable result if calls are intermixed. The namespace and non-namespace model are different enough that intermixing the distinct models as though they were the same will cause unexpected collisions or match failures. Some cases work, others fail, and it may not be obvious to a user not steeped in the model how the mixture caused the failure. It is easier to point out that by sticking to one set of methods or the other -- not intermixing -- you can get good desirable results. Ray Whitmer ray@x... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format