SAX/DOM bugs

Hi.

I just recently found this bug in Allegro's XML package:

CG-USER(1): (require :sax)
; Fast loading C:\Program Files\acl81-express\code\SAX.fasl
;   Fast loading from bundle code\EF-E-ANYNL.fasl.
T
CG-USER(2): (find-symbol "PROCESSING-INSTRUCTION" :net.xml.sax)
NET.XML.SAX::PROCESSING-INSTRUCTION
:INTERNAL

The symbol is not exported, and as such SAX parsers/handlers outside that
package will not be fired for processing instructions, like the
net.xml.dom:dom-parser. I hacked a bit and added the net.xml.dom method in the
net.xml.sax generic method and the DOM parser now correctly generates the PI
nodes.


But then, dom-print doesn't print PI's correctly. In fact, it seems like a
format ~a, it shoots a hash #<...>. The dom-print has another major flaw, it
does not escape or replace invalid XML characters with the respective entities.
Not having a serializer is quite a drawback.


There could be a DOM to SAX mapping, and a SAX handler that writes XML (with
xref:get-relation, I've seen that this is not what dom-print does). LXML to SAX
would be nice as well, so you could reuse the SAX writer or any other SAX
handler.


Another thing, the DOM parser keeps the document child nodes in an inverse
order. That is the parse-to-dom (or file-to-dom) of the following excerpt:

<!--a-->
<?tg b?>
<root/>
<!--c-->

will produce a document with child nodes in inverse order. Note, this happens
in the document object, elements are ok. I didn't test other node types
(attributes are not really child nodes and order doesn't matter anyway).


Appending two elements in a document should raise an error.


Well, I decided to report a few bugs in the sleeve as well. Is there any
expectation that these problems are ever going to be corrected (the last SAX
patch is more than a year old)? Are you planning support for DOM Level 2
(because of namespaces)?

Regards,

Juan Vista