ddailey ha scritto:
There are lots of times in which I've needed to examine one document by use of a script that resides inside another. Using lists of attributes to do that has been rather important, though if those lists were accessible as properties of objects rather than as nodes themselves (as in some sort of multinary relation rather than as a tree structure) that would be fine as well.
Well, attributes shouldn't be accessible as descendants of an Element in a tree structure, but rather as items of a NamedNodeMap, or directly through Element.getAttribute()/Element.getAttributeNS(), passing a string representing the attribute name and getting the value as a string. Thus, they don't need to be instances of Node (that's about redefining Attr and a related listing interface to simplify the UA handling of attributes, which currently are node but should be handled as if they weren't). Any interface replacing Attr, for such purpose, should take care of namespaces and prefixes (which is currently done in DOM3 Node interface). Dropping the list of attributes as objects would require to query each attribute by name, but a list of attributes seems to be needed in some use cases; a DOMStringMap might be considered, to represent attributes as a list of string couples of names and values, but such couldn't handle namespaces, though it might be derived to add such capability, nor it could solve the problem to define an interface to give access to a tuple of (name, value, namespace) by colling, e.g., an item() method, or the alike. Otherwise, if no better alternative can be found, Attrs will continue to be Nodes...
Learners of this stuff seem to have trouble with the fact that lists cannot be indexed through array notation -- i.e., that nodes[1] cannot be used in place of nodes.item(i) in some namespaces, but apparently can in HTML.
I guess that's a matter of idl bindings, in part at least, so it might be solved with clearer specific bindings, as needed. For instance, all properties (attributes and methods) of a collection-like interface can be declared [DontEnum], despite of them being defined on the idl or being created at runtime (i.e. by listing an item as a named property of the object), with the exception of indexed items: this way, a collection-like object would always behave as an Array-like object. Similarly, the collection might work as an associative array for named items (i.e., the_id = attributes["id"] might work as the_id = attributes.getNamedItem("id") ), but the binding for such might be more complex, involving a redefinition of the bracket property accessor in order to look for properties inside an internal list (when it comes to implementations, such complexity may disappear or be reduced, for instance, in C++ such might involve an "easy" overload of the 'operator[]' function).
Though I have only played a little with compound documents or with document fragments, it seems like viewing all nodes as accessible through getElementById is awfully dependent on how one finds the "document" associated with the appropriate segment of a mixed NS document. In SVG nestled inside HTML, for example, implementations have differed in terms of how that document is retrieved as a function of browser, and the type of tag (object, iframe, frame, or embed) in which the svg is placed. The ability to "root" one's search directly at a certain level in the parent DOM, might help in cases where mixed name spaces could lead to conflicts of the assumption of unique id's.
Perhaps, what you're asking for is something like Document.getNSElementById(in DOMString namespaceUri, in DOMString elementId), to get access to the first element, in a document, whose tag name has a prefix corresponding to the queried namespace, or is descendant of an element whose tagname is the root element tag name for the queried namespace (perhapse suitable for HTML 5 embedding <svg> or <math> elements without prefixes). Anyway, you'd have to reach the correct document first (but you'd have to do so to get the nested content root element even with a getElementById(elementId, rootElement) ). Such method would involve a separate management of ids, one to ensure uniqueness in the whole document (i.e. to return the first match for getElementById despite of the element namespace), another to deal with each element (either prefixed or just embedded) coming from the same namespace as if they were in a separate document where to look for unique ids (not to be implemented necessarily this way, just managing a global map of unique IDs for all the elements in a document and zero or more secondary maps for all the elements corresponding to a particular namespace - different from that of the nesting document). Such might add some complexity to the user agent, and perhaps won't get consensus from implementors, I guess.
Regards, Alex. -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Dalla top ten al tuo cellulare. Scarica le superhit! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8268&d=9-12
