Re: output html as lower case?

On Tuesday 24 June 2003 18:29, Mayhew, Steve wrote:
> I've not seen the DOM4J UI yet but I'm sure it's superior for Java then the
> W3C DOM API.

It's more Java-centric, which makes it a bit easier to use IMO. Other than 
that, the APIs are similar enough to support both on the same document 
instance.

> 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. ;-).

Right - instead we battle the rest of the server over what version of Dom4J to 
use :-)

On a more serious note - we have defused the Xerces issue for XMLC 2.2 by 
moving the "XMLC version" of xerces into its own namespace. If you have 
trouble using XMLC because of Xerces issues, I'd recommend that you upgrade 
to 2.2 beta or the latest CVS version.


> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@xxxxxxxx]
> 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 <kunze@xxxxxxxxx>
> To: Jacob Kjome <hoju@xxxxxxxx>
> 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, kunze@xxxxxxxxx

pgpRN0M2J9HlQ.pgp
Description: signature