Re: Thought on future of XMLC

This is brainstorming session. I want to hear the concern of the 
community before decide on a particular design and implementation.

> I'm slightly confused with the JXPath approach.  Would we still be
> working on a Java class that represents the DOM in Java or would we be
> loading up a document at runtime and running XPath expressions on it?

I probably didn't express this clearly in my previous mail. A Java 
wrapper for the document object will still exists for the DOM object 
for the document. To be more precise, no document specific wrapper 
classes will be generated for a particular document. The wrapper will 
be generic but is necessary to hold meta data for the documents.

The XPath will be run on the DOM object and the wrapper will still 
provide access to the DOM object. Basically, the wrapper object will  
be org.enhydra.xml.xmlc.XMLObject or 
org.enhydra.xml.xmlc.html.HTMLObject which the current document 
specific wrapper derived from.

What's going to be missing from the wrapper is the convenient methods 
for direct element and text access, e.g. getElementFoo() and 
setTextBar().

> If we are loading up the document at runtime, wouldn't this be a
> performance issue?  I'm probably just missing something.  If there is
> no runtime performance issue, then I am all for it.

The loading/parsing will only occur when the document is first request 
(and after updated if reloading is enable). The loading time is 
probably going to be a bit slower than the current class loading since 
it will do parsing and tree walking to process the document. However, 
this performance penalty is onetime.

> However, this
> seems like it would break compatibility with existing programs using
> the convenience accessor methods.  I don't think it would affect me so
> much since I use Barracuda's BTemplate and standard DOM for the most
> part, but I imagine there are plenty of people out there that might be
> concerned about the change.

Well... I thought about this one. The current class generation should 
probably be kept for this legacy support. The most feasible 
implementation will to have two in parallel. However, I want to 
eventually move away from the dependency on the generated classes. If 
the getElement/setText will still be needed in the future, it can 
probably be emulated using Proxy.

> BTW, would these types of changes mean that we are no longer dependent
> on any particular version of Xerces?...or maybe not dependent on
> Xerces at all?

Well... I wish so but moving XMLC toward this direction still won't get 
rid of the dependency on the particular version of Xerces. That's an 
issue I still don't have time to address yet. :(

David