RE: Re: output html as lower case?

I've not seen the DOM4J UI yet but I'm sure it's superior for Java then the
W3C DOM API.
 
The best part is we wouldn't have to battle with the rest of the server over
what version of the Xerces parser to use. ;-).

-----Original Message-----
From: Jacob Kjome [mailto:[email protected]]
Sent: Tuesday, June 24, 2003 9:12 AM
To: XMLC Users List
Subject: Fwd: Re: Xmlc: output html as lower case?


forwarding to the list so others can see it.

Jake



Posted-Date: Tue, 24 Jun 2003 10:41:34 -0500 (CDT)
From: Richard Kunze <[email protected]>
To: Jacob Kjome <[email protected]>
Subject: Re: Xmlc:  output html as lower case?
Date: Tue, 24 Jun 2003 17:41:23 +0200


On Tuesday 24 June 2003 17:15, you wrote:
> Anyway, I know that Xerces2 does not yet have an dom level2 html
> implementation as of yet.  Maybe we can write it and contribute it to the
> Xerces2 project?  Or just let them write it, if they already have plans to
> do so.

I'm not sure want to use Xerces 2 as the basis for the XMLC 3.0 DOM. In
fact, 
I'm pretty sure that I don't want to :-)

Instead, I'd like to base the new XMLC DOM on Dom4J for the follwoing
reasons:

- Dom4J has a clean internal layout that's designed to support derived 
implementations
- The implementation uses interfaces internally to access nodes and elements
- Dom4J has builtin XPath support
- Dom4J supports not only W3C DOM, but provides a different (and much nicer 
IMO), more Java centric interface to the document as well

I think we can take it as a given that we need our own DOM implementation
for 
XMLC in order to optimize for XMLC's typical "one template, many copies" 
usage scenario (main fetaures: Copy-on-write nodes and preformatted text, as

in the LazyDOM), so it's reasonable to build off of a basis that's designed 
with extensions in mind.

The second point is necessary to support type-safe accessor interfaces for 
arbitrary nodes. I plan to implement this with dynamic proxies, and that 
won't work if the DOM implementation uses classes instead of interfaces 
internally (you can't wrap a class in a dynamic proxy, only an interface).

The builtin XPath support comes in handy for implementing advanced DOM
access 
and for binding accessor interfaces to DOM nodes (and is nice to have anyway

of course), and the Dom4J API is very nice to have as well - especially so 
because Dom4J supports both its own and the W3C API on the same document 
instance, so the XMLC users can choose which API they like better.


-- 
Richard Kunze 

[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de <http://www.tivano.de/> , [email protected]