Hey Folks,
>
> Probably top of the list should be the writing of articles, user guides
> and
> documentation.
Ok. No problem. I have already some ideas:
1) Something like the JUnit Cookbook -> DOM4J cookbook. I would provide some
simple example like the Java Documeation does. The Cookbook should also give
the some instructions in Collections, XML, SAX, DOM and a lot of DOM4J. The
Cookbook should also show a complete example of using DOM4J in content of
JaXP (SAXBuilder, DOMBuilder, TrAX and DOM4J). We/I could show the
difference to DOM and JDOM (carefully - not starting a new war with this
community).
2) Describing the Architectures: Some UML diagrams would be nice
(Classdiagrams, maybe some Sequence diagramms or Activity Diagramms).
3) A guide that goes more into deepth of dom4j, explainig who to extend
classes
(builders) and so one.
4) A document of dom4j history would be nice. Indee very nostalic :-D
5) A mozilla like roadmap (looks cool and is easy to paint if the project
management is more clear).
Please tell which format you prefer. XML would be nice but I need schema
that
describes the documenation (and XSLT and even better webserver with running
cocoon). We can also generate UML diagrams from Classes using XMI (and
integrate that in dom4j as well :-) )
I am able to write the documation in LaTeX also, so were able to deliver it
in
HTML, PS and PDF (but LaTeX to HTML is ugly...).
>
> If you fancy helping out with some coding, a gentle introduction might be
> to
> try write some JUnit test cases that try to break the API ;-). I've tried
> to
> write them as I develop but I'm sure there could be many more and the more
> tests, the more robust the software.
JUnit is ok. I use it a lot in my current project. Kent and Gamma written a
quite
intellegent and well desingend tool. I tend to use JUnits pluggable
selector feature
to write test. I/We could combine it with log4j, building a complete test
framework.
I think we should concentrate on xpath first to ensure that this fine
feature (thanks
bob) is reliable. Any futher comments?
>
> If you fancy something a little more heavy duty coding, another area that
> needs attention is the native DOM implementation of the dom4j API in the
> org.dom4j.dom package. It compiles but is some way away from full DOM
> compliance. Thats certainly an area you could dive in and fix if you wish.
> (There's a DOM compliance test here that it would be great to pass one day
> soon:
>
> http://xmlconf.sourceforge.net/
I will look at this and decide later on. :-D
>
> I'm still in the middle of XML Schema Data Type support right now but when
> its finished you could investigate adding full XML Schema support (i.e.
> doing the validation of complex types). Or implementing some other
> validation engines such as Schematron or TREX.
In my current project I use XLST to transform Schemas and generating a empty
tempalte document. Please keep performance in mind when you implement
validiation. Schema support is quite nice because it encouple us form xml
parser.
Apropos Schema:
Brett M. is currently working on zeus to write the missing schema compiler
for java.
I'm very interested to obsolve the evolution of this project. Hopefully it's
ready
before Sun stikes back.
> Another area of research is a DTD aware DocumentFactory implementation -
> maybe knowing about the document structure before parsing begins could
> result in faster & less memory Element / Attribute / DocumentFactory
> impleme
> ntations, or a more clever SAXReader...
Quite intresting. I have to review the code and the architechture and I will
look if I
can help.
>
> Other smaller chunks could be an DocumentFactory & Element implementations
> of the XLink or Xinclude specs.
What about XQL? It's also on the list.
Have a nice day.
--
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
"
