Re[2]: Thought on future of XMLC

Hello David,

I believe DOM4J provides some functionality similar to LazyDOM:

http://www.dom4j.org/faq.html#How%20does%20dom4j%20handle%20very%20large%20XML%20documents?

Jake

Wednesday, November 20, 2002, 11:51:22 AM, you wrote:

DL> Chris,

DL>    LazyDOM can still be used as in-memory DOM. The current Java wrapper 
DL> basically wrap around the DOM document which can either be Xerces DOM 
DL> or LazyDOM.

DL> David

DL> On Thursday, Nov 21, 2002, at 01:44 Asia/Shanghai, Chris Webb wrote:

>> David,
>>
>> If we lose the Java wrapper will we lose LazyDOM support or will that 
>> functionality be encorporated the evolved form of XMLC?
>>
>> Chris
>>
>> David Li wrote:
>>
>>> Hi,
>>>
>>>   Working on the next release of XMLC, I come to think about where to 
>>> go with XMLC in the future. The current reloading works by reparsing 
>>> the HTML/*ML documents, by passing the Java class 
>>> creating/compiling/reloading in the previous version. With this in 
>>> place, the next question is whether or not the Java wrapper of the 
>>> *ML documents are needed at all.
>>>
>>>   Currently, the Java wrapper of the document provides the following:
>>>
>>> 1. Generate convenient methods to manipulate simple text field using 
>>> span tag, e.g. providing setText* method for a given text tags with 
>>> particular ID.
>>>
>>> 2. Generate convenient methods for the element access, e.g. 
>>> getElement* for elements in the documents.
>>>
>>> However, for most non-trivial HTML programming, we go into heavy DOM 
>>> programming to access the documents mixing with these convenient 
>>> methods. In some case, totally forgo these methods and do everything 
>>> using the DOM interfaces.
>>>
>>> DOM API is low level and was originally defined in IDL for cross 
>>> language portability. It's tedious to use and anyone who has tried to 
>>> populate a table using DOM API could testify this.
>>>
>>> The new XMLC reloading has open up the possibility to get rid of the 
>>> Java classes and enable to dynamically add new documents into XMLC 
>>> system without source generation and compilation. However, with this 
>>> approach, we won't have the convenient methods for the XMLC class and 
>>> will have to deal with generic DOM.
>>>
>>> There are two possible solutions to provide a new programming 
>>> interface on top of the XMLC: a Document centric approaches using 
>>> XPath or a Java centric approaches using either JDOM or DOM4J. Both 
>>> can probably be provided together and give the choice to the users to 
>>> pick their favorites.
>>>
>>> I have been experimenting with XPath for a while using a package 
>>> called JXPath from Jakarta project. It uses XPath to address the 
>>> elements in DOM and can be use to replace the convenient methods 
>>> generated by the currently XMLC implementation quite easily.
>>>
>>> for setting text,
>>>
>>>   documentContext.setValue("id(foo)/text()", "New value");
>>>
>>> Just some random thought on the future of XMLC. I'd like to hear what 
>>> the community feel about the features needed to make XMLC a better 
>>> tools.
>>>
>>> David
>>>
>>> _______________________________________________
>>> XMLC mailing list
>>> XMLC@xxxxxxxxxxx
>>> http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>>
>>
>> -- 
>> Chris Webb
>> Voxsurf Ltd.
>> 3rd Floor
>> Elme House
>> 133 Long Acre
>> London WC2E 9DT
>>
>> Tel. +44 (0) 20 7240 3621   x 206
>> Mob. +44 (0) 77 8639 2359
>> Fax. +44 (0) 20 7379 7573
>> e-mail : chris.webb@xxxxxxxxxxx
>> Voice Demo. +44 (0) 870 744 7223 http://www.voxsurf.com
>>
>> Email disclaimer: This can be viewed at 
>> http://www.voxsurf.com/disclaimer.html
>>
>>
>> _______________________________________________
>> XMLC mailing list
>> XMLC@xxxxxxxxxxx
>> http://www.enhydra.org/mailman/listinfo.cgi/xmlc

DL> _______________________________________________
DL> XMLC mailing list
DL> XMLC@xxxxxxxxxxx
DL> http://www.enhydra.org/mailman/listinfo.cgi/xmlc



-- 
Best regards,
 Jacob                            mailto:hoju@xxxxxxxx