-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thanks! This sounds great! I'll play with it and let you know if I have any further difficulties with it.
I had another thought concerning the DOM API in cxml. Have you considered creating an independent out of the DOM API, just as there is a separate package in Java that does nothing but create the interface classes for the DOM API? Having such a standard API to program against does make it possible to develop other CL packages (such as an XPath parser) without having to commit to a specific XML parser.
Thanks again,
Sunil
David Lichteblau wrote:
Quoting Sunil Mishra (smishra@sfmishras.com):
I want to be able to refer to the types present in the DOM IDL definitions in the DOM Core2 definitions. However, classes such as element and node are not present in the DOM package, let alone be exported from that package. Is this intentional? Can you recommend a reliable way of defining methods specialized on the different DOM classes?
Oh well, an old topic. I never was quite sure what to do here.
I used to think that exporting these classes would be the wrong thing to do, because it restricts the DOM implementation to use CLOS internally. It would be perfectly possible to implement DOM with structure classes instead, or even some other non-object-oriented data structure, leaving dom:node-type as the only way to distinguish between different nodes for users.
However, the patch I once wrote to use structure classes instead of standard classes did not seem to make DOM faster or anything. Perhaps it is time to revisit this decision.
So. What I done now (checked into cxml CVS) is to add "interface" classes under exported names like dom:node (which rune-dom::node and utf8-dom::node both inherit from). All DOM interfaces are included except DomImplementation and NodeList.
However, I still consider this to be a kind of "undocumented" feature for now...
Please test!
d.