Hi,
I agree Daniel, Dom4J is really a good project. In my opinion it is a very good designed set of packages for the java community.
It has not all the heavy constraints (mainly due to implicite validation consideration in the DOM model leading to strange limitation in the DOM api) and still offers a nice hierarchical structure that is IMOO more consistent (in an object model point of view) than JDom.
So I join 100% Daniel's comments and hope that :
o James is still in good health :-) (independly from the Dom4J project) o No technical "cul de sac"/dead end arrose since the last release o James is still anthousiastic about his work o We will soon have news about the 1.4 release progress/roadmap
Concerning the project itself. I would like to outline that Dom4j was first meant to provide a simple and efficient way to deal with XML in JAVA. This is almost achieved and the result is really great !!
However my feeling is that the XMLSchema features (e.g. Datatypes) are not really part of XML. I mean that we can think of XMLSchema as an already specific application/extension of XML and thus I think DOM4J's core realease should not become late because of the XMLSchema features.
XML validation is a complicated task and may follow many ways that have all there cons & pros (XML Schema but also DTD,Trex, Schematron, Examplotron, SOX,...). XML core is not dependant on validation nor are the Dom4j core functionalities. Furthermore it is possible to validate XML in java with a lots of apis that do not depend on Dom4j. As you may have guessed, my concerne is about Dom4J loosing its simplicity and maybe its consistency just by trying to implement some XMLSchema features. I know it is not easy to resist to take into account new concepts like DataTypes but since these concepts are not part of the core concept of XML, shouldn't they belong to a separate project. For exemple datatype may be linked to elements and attibutes in many ways that are not necessarely based on an XMLSchema, this binding could be achieved in a interface based framework that is not dédicated to Dom4j but that supports Dom4J documents as an input source and so on...The same feeling appears regarding the XSLT extension in Dom4j. Thus i am affraid that energy on this project is spread over several sub-projects that are not really part of the initial goal of Dom4j and lead to a weaker overall mobilisation. Is it possible to consider some kind of Dom4j core project (Object model + Xpath support + namespace support + I/O) and have a separate release strategy for XMLSchema and XSLT supports? This may help consolidate the core technology faster...
But this is just my own (modest) feeling (exposed in a quick & dirty way), I would be glad to read other people opinions about these concerns
In any cases Dom4J is a very nice project, thank you James for this great work!
Thierry
---
[EMAIL PROTECTED] wrote:
> I've been using dom4j for a little more than 6 months now,
> as part of a professional project.
> I managed to convice the hierarchy that dom4j/jaxen was worth considering
> instead of the typical W3C DOM Xerces/Xalan pair,
> saying that dom4j was faster, easier to use, while being "compatible" with
> the W3C model, and that is was "maintained and updated frequently"...
...
---
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dom4j-user
