Hi there,

Stefan Behnel wrote:

But there is another area where help is appreciated. A very important area in fact: *documentation*. While there is quite a bit of documentation both on ElementTree and lxml, there are certainly places where lxml's API and its way of doing XML are hard to access, especially for new users and those who have a fixed (should I say: Java-ish?) mindset on XML. If you want to contribute, helping out in this area is warmly appreciated. Here are a few ideas that would be truely helpful for lxml's user base.

I think the lxml documentation project is a great initiative and I encourage everybody to join in!

Besides the topics Stefan mentioned, I think we should consider creating complete API documentation for lxml looking similar to what's on www.python.org for the core library.

I think this should include both the ElementTree API and the lxml extensions in one place. lxml extensions to the API should be marked in the docs. I think having a clear overview of the API will help people find and use the numerous somewhat hidden treasures that exist in lxml.

So, API volunteers, you don't already need to be an expert on the lxml API. Writing a bit of API doc would be a good way to *become* an expert, though.

I will be happy to help get any API docs volunteers on their way, so if you start this, you won't be on your own.

I'm excited about this documentation project and I'm hoping we'll get a few great new contributors!

Regards,

Martijn

Hi Stefan, hi all,

lxml 1.3 is nearing completion. There were some major changes under the hood,

Is there a planned release date? Do you plan to get the xsi:type="xsd:<type>" thingie into 1.3? I'd love to have this in and I might be able to contribute if needed, but would have to know how much time left until the final 1.3 release; because I certainly will not be able to do so until the end of next week.

[...] But there is another area where help is appreciated. A very important area in fact: *documentation*. While there is quite a bit of documentation both on ElementTree and lxml, there are certainly places where lxml's API and its way of doing XML are hard to access, especially for new users and those who have a fixed (should I say: Java-ish?) mindset on XML. If you want to contribute, helping out in this area is warmly appreciated. Here are a few ideas that would be truely helpful for lxml's user base.

• I would love to see lxml's own tutorial that gets the main ideas and the

most useful features across without caring too much about ElementTree (which already has a tutorial).

I do have kind of a tutorial introduction to lxml.objectify, but we tend to wrap some of the entry points into our custom API, and we use some extensions (namely datetime and decimal, so this does currently not match 1-to-1 to out-of-the-box objectify. As the official objectify documentation is kind of tutorial-like itself, maybe I could check where I could add enhancements to that.

Regarding API documentation I vote for some reference doc that is actually generated from docstrings or source code documentation. What about pydoc?

• Some statistics: what /are/ the most useful features of lxml? What do

people like or use most? What parts of lxml should be more accessible? Which parts are so well done that people grasp their usage immediately (and should therefore be promoted as an eye-catcher)?

For me, that's 1. standards-compliance by intelligently building on libxml2/libxslt 2. feature-richness: covers extremely convenient XML handling plus Schema/RelaxNG validation and XSLT 3. stability and maturity 4. extensibility 5. performance

• We could benefit from a Wiki where users could contribute code examples,

best practices, work-arounds or tool snippets. We should also start linking to external pages, blogs, presentations on lxml or ElementTree that others might find interesting.

A wiki would be nice.

I really think lxml has the potential to be THE python XML toolkit. The only thing users might keep from it sometimes is the dependency on the massive libxml2, which can be addressed by a good build/dependency system. And, as said, building on libxml2 is of course also lxml's biggest advantage.

Btw I for one don't like eggs; I like to package libraries in my platform package format. Anyone know about a tool to convert an egg to a Sun package?

Keep up the superb work, Holger