[cxml-devel] DOM classes not exported?

Sunil Mishra smishra at sfmishras.com
Mon Aug 21 15:23:00 UTC 2006


-----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 at 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 SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE6c/UjRnqWMAEf1cRArCHAJ4rN4SER6nLiHhZrDYIy/3drtjqTACfYZRl
l10RIABiz39e/oUScsxfsz0=
=ehPL
-----END PGP SIGNATURE-----



More information about the cxml-devel mailing list