DOM questions

[keshlam at us.ibm.com]

>Can an attribute have more than one entity reference as a child?

Sure. Consider <foo bar="&this;&that; and &theOther;"/> Note that parsers are
allowed to expand entity references by replacing them with their values, which
makes round-tripping impossible, but makes accessing the content either -- pick
the parser, or parser settings, that suit your needs.

>What should a DOM implementation behave like  if a DOM user appends to
>an Attr node an unexpanded entity reference that contains Element nodes
>as child ? In other words is it true that if an entity
>reference is appended to an Attr node,  it can contain only Text nodes as
>children ?

A parsed entity, in other words. I _think_ the answer is that parsed entities
aren't acceptable as Attr values per XML specs, and while I don't think the DOM
spec explicitly protects you against this I don't think implementations are
required to do anything useful either.

>Can an Attr node have non null  value and, at the same time,
>no Text children?

Sure. <foo bar="&bletch;"/>

>When cloning an Attr node with deep set to false, does the cloned Attr
>node retain the attribute value?

No. The definition of shallow clone is that children are not copied. However,
shallow-cloning an Element node will DEEP-clone the attributes on that element.

(Now, if your question is whether there is such a thing as a shallow clone of an
entity reference... I think that may be implementation dependent. My DOM keeps
references in synch with their definitions, so shallow or deep clone of
EntityReference wind up being the same thing.)

>So, if the original attribute had its value splitted among several Text
>child nodes, the cloned attribute will contain only one text child holding the
attribute value?

If you do a deep clone, you will copy _all_ the children, exactly as they are.
If you do a shallow clone, you will copy _none_ of the children.

There is currently no Attr.normalize() operation. I've lobbied for that to be
introduced in DOM Level 2.

>What should the getOwnerDocument method return for an Entity node
>(or for a Notation or for a DocumentType), as no createX method is
>specified in the Document interface?

DTD support is essentially incomplete in DOM Level 1. Don't expect it to be both
portable and useful until Level 2, if then. Most of us are either advising folks
not to try, providing nonportable extensions to work around the gap (such as the
factory methods which you noticed are missing), or both. As another illustration
of the problem, note that DOM Level 1 specifies the behavior of default
attributes, then provides nowhere to store the information describing those
defaults.

(Basically, the whole DocumentType thing was deferred in the hope that schemas
would appear relatively quickly. They haven't, and there still seems to be some
fear that any stopgap solution written into the spec would be both incompatable
with schemas and impossible to get rid of.)


>Form the DOM specs, the getOwnerDocument method should return null for a
>Document node.

True. Don't Ask. This bounced back and forth; the point-to-self folks lost the
final volley. It's not a big deal either way.

______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)