-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
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?
Thanks,
Sunil
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.
-----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.
Quoting Sunil Mishra (smishra@sfmishras.com):
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
IMO that would be worth it if and only if there is at least one other DOM implementation willing to use it.
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.
Hopefully XPath can be implemented based on a simpler interface, something more general than DOM. ISTR that CL-XML uses infoset-like function names.
d.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi David,
David Lichteblau wrote:
Quoting Sunil Mishra (smishra@sfmishras.com):
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
IMO that would be worth it if and only if there is at least one other DOM implementation willing to use it.
Agreed. But there is a chicken-and-egg situation here: without a re-usable DOM API, there will never be another piece of software that re-uses the DOM API.
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.
Hopefully XPath can be implemented based on a simpler interface, something more general than DOM. ISTR that CL-XML uses infoset-like function names.
Well, given that:
1. I can't find the XPath implementation of CL-XML; and 2. My XPath implementation is less than a toy at present
I am not going to pursue this matter any further, other than state an opinion that having a standard API available for multiple pieces of software to use can at least theoretically lead to the development of independent inter-operable modules. There has been *some* success due to this approach in the Java world.
Sunil
-
David Lichteblau -
Sunil Mishra