Hi Toby-won ;-)
> 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).
Sounds a great idea!
> 2) Describing the Architectures: Some UML diagrams would be nice
> (Classdiagrams, maybe some Sequence diagramms or Activity Diagramms).
I'll try help out with those shortly...
> 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).
Any or all of 1-5 would be a great addition I think. I'll try help all I
can.
> 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).
I'd obviously prefer anything in XML as its easy to work with. Even if you
just used any old HTML editor you've got lying around it is easy to use tidy
(or JTidy) to turn it into valid XML for styling.
> We can also generate UML diagrams from Classes using XMI (and
> integrate that in dom4j as well :-) )
I'm hassling a friend and colleague who's done some cool & wacky stuff in
this area lately to package his stuff up so we can all do UML class diagram
generation (to XML, HTML, JPEG, image map, PDF et al) as part of our javadoc
Ant build process. Hopefully one day soon...
> 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...).
Whichever your prefer. I think I'd rather lowest tech possible - XML / XHTML
or HTML - but whatever you wish.
> 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'm not sure what the 'pluggable selector feature' is ;-)
I've got the JUnit tests run as part of the Ant build process ("test"
target) which is kinda nice.
> 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.
Agreed. I'd increasingly like to have XML based tests so we can test doing
adding, removing, detaching, merging, cloning and such like operations on a
variety of documents and use XML to describe what the output should be like.
I'm sure there's room for more automation though.
> Any futher comments?
An XPath test engine would be really useful. Bob had a go at building one
originally but it was a bit hard to get right. Though now we've got the
NodeComparator, maybe its much easier now to compare document branches for
equality?
<aside>
There's an attempt by Bob, myself and a couple of others to refactor the
werken & dom4j XPath engine into "Jaxon" (current working title, could
change) which would use a shared XPath parser (current working title
"saxpath") such that the same XPath engine could be used across a variety of
models (DOM, dom4j, JDOM, EXML, JavaBeans even, maybe SAX too).
Having an XPath test engine that works on dom4j now, it would also work if
we moved dom4j over to "Jaxon" and could also be useful for testing all
other XPath engines maybe one day. So both as a regression testing tool, so
we know if we break anything, as well as a conformance testing tool, I think
this is a great idea.
</aside>
> > 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.
Agreed. I'd like a pluggable variety of validators supporting all the main
schema validation techniques, XML Schema, TREX/Relax and Schematron.
I'm particularly interested by Schematron since all it really requires is an
XPath engine and a small amount of Java code. From what I've seen of
Schematron its really useful stuff.
> Apropos Schema:
>
> Brett M. is currently working on zeus to write the missing schema compiler
> for java.
Sun is meant to be doing the same. I've used Castor in the past
(http://castor.exolab.org) which I've found pretty good at that kind of
thing. Its been around for quite some time too.
> > Other smaller chunks could be an DocumentFactory & Element
implementations
> > of the XLink or Xinclude specs.
>
> What about XQL? It's also on the list.
Yes I've always wanted an XQL implementation. I think it could be an awesome
branch of XML technology, doing XML based queries across multiple 'sources'.
It does look a fairly big undertaking but yes I'd love to go in that
direction too!
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
