When a XML editor finishes messing with DTD’s, the next thing which comes to mind is entity references (&foo;). In the case of Mozilla code, these entity references don’t exist: the XML parsing code replaces the entity ref with the appropriate source code from the DTD. So the DOM in Mozilla never actually sees entity references.

This is a major problem for Verbosio

. As a XML editor, it must know where a XML document uses entity references. With that knowledge, Verbosio can then provide a user-interface which guides people to editing the DTD entity underneath the entity ref.

What makes it more interesting is that Mozilla really has no effective code for entity references in DOM. Try var foo = document.createEntityReference("bar");. You’ll find out that, even if there is no declared <!ENTITY bar "...">, no error will be thrown; instead, foo is null.

How can Verbosio work around this? At present, I have an imperfect solution, a XML “entity manager”. Read on if you have any interest.

I’ve already checked in a first-draft entity manager component (with XPIDL interface). Currently it’s only minimally functional, with several bugs I need to track down.

Entities contain fragments of XML markup, which (in many, but not all) cases comprise full DOM nodes which could fit into a document fragment or a XML element “wrapper”. So what I have been doing is taking the contents of each entity and parsing them into little XML documents inside a specially constructed wrapper. Then I compare the nodes in each entity’s DOM fragment against the nodes of the document.

Note I cannot use isEqualNode() on any of these, because in the entity fragments I have no way of knowing which namespaces to associate with each element and attribute in the entity declaration.

The problem is a little more complex, because some entities are for attributes-only, and others are for XML fragments. So there are really two different types of entity references: those inside an attribute’s value, and those which could span several (non-attribute!) nodes. The first type can only contain CharacterData nodes; the second can contain almost any types of nodes.

When the entity manager finds a match of the second type, it currently surrounds the matching DOM nodes in the document with a <markup:entity-ref/> element. This is a really hackish way to take care of business, but in theory it should work. In practice, it means document viewers (like the Inspector view and the source code view) will have to work a little harder than is nice.

I also tried to move the new contents of this entity-ref element into the element’s anonymous content. (The idea is that all the user sees in the source code is the entity ref itself, and not its contents – but in a rendered view, the contents are visible.) Unfortunately, to do so you need to add a binding to the entity-ref element, and that doesn’t work for DOMParser-created documents. So that’s a dead end.

It’s also worth noting that currently, attribute nodes in Mozilla can’t have entity references for children. (If you can’t create them, you can’t insert them.)

Ultimately, it’s enough of a quagmire that, even once I get all the algorithms for my entity manager fixed and operational, I’ll still think it’s not right. It would be far better to actually implement entity reference classes natively in Gecko, and to use them to simplify the DOM of the document. Verbosio’s entity manager would take care of inserting the entity references, but the references themselves would belong to the core DOM. That would make the proposed <markup:entity-ref/> element obsolete and (fortunately) easy to replace.

Oh, by the way, Mozilla’s doctypes return null when you ask for their entities property. Another nice quirk of the Mozilla DOM.

Personally, I don’t think we’ll see native entity references or entity nodes in Mozilla DOM anytime soon. It’s a lot of work for admittedly little gain. Sure, Verbosio would benefit… but not Firefox, Thunderbird, or Songbird, I’d think. That’s why these not-so-little hacks are (for now) necessary.