[XML-SIG] Package borderlines and overlap (and versions)

[Martin v. Loewis]

Dinu Gherman <gherman@darwin.in-berlin.de> writes:

> It's about the borderlines and overlap of these packages:
> 
>   1. the XML tools in the Python standard library
>   2. the pyXML extensions
>   3. the 4Suite extensions
> 
> What is not quite clear to me, admittedly not yet a Python/XML
> "power user", is if and which parts of entry N above do really
> replace/overwrite parts in N-i (0<i<N)?

2 replaces 1 (extending it). The relation between 3 and 2 depends on
the specific releases, and has changed over time. Some releases of 3
replaced/incorporated/overwrote 2, some releases of 3 mandated
presence of 2, some releases of 2 had overlap with prior releases of
3.

> If I do this:
> 
>   >>> import xml
>   >>> xml.__version__
>   '0.7'
> 
> I obviously get the version number of pyXML, but if I use Python
> 2.3a0 without any additional XML packages I get this:
> 
>   >>> import xml
>   >>> xml.__version__
>   '1.11'

Correct.

>   1. does is make any sense to speak of versions for the 
>      XML tools in the stdlib? (I did that above, but maybe
>      that's plain nonsense. Is the XML stuff in the stdlib
>      further developped, BTW?)

No. Just speak of Python 2.1, 2.2, etc.

>   2. what is the canonical way to determine programmatically
>      which versions of the XML tools in the stdlib, pyXML
>      and 4Suite one is using and/or if they are installed
>      at all?

stdlib: check sys.version_info
  Note: some Linux distributions don't install, by default,
  the xml package when installing Python 2.x. Please report this
  as a bug to the distributors.

PyXML: check for presence of xml.dom.ext.

4Suite: check for presence of Ft.

This is rather ad-hoc than canonical, but I believe it will still work
with all past and most future releases (the PyXML test will only work
since 0.6; just ignore all prior PyXML releases).

>   3. is there a way/document/figure to explain (easily) how 
>      all these components interact and how they overlap if 
>      they do overlap?

Not that I know of. Notice that such a document would be hard to
maintain.

>   4. is there a "road map" for some other way of structuring,
>      packaging and/or distributing all these modules and/or
>      is it planned to gradually shift modules from N to 
>      N-i (0<i<N) in my first list above?

Depends on whom you ask; also, such a list is also in constant flux,
given that some of the shifts are implemented, while others turn out
not be such a good idea.

Here is my current list:

- move xml.xpath and xml.xslt to PyXML. For that, move 4XPath and 4XSLT
  to the Ft package, allowing for simultaneous installation of the 4Suite
  and the PyXML version of these libraries. This will be implemented
  in 4Suite 0.12 on the 4Suite side, and probably in PyXML 0.7.2 on the
  PyXML side.
- Drop pDomlette in favour of minidom. This is in progress, but no
  specific completion is done.
- Incorporate Expat sources into Python CVS. Done, to be released with
  Python 2.3.

There are a number of suggestions which are wishlist items at the
moment only:
- provide xml.xpath (or some other means of doing XPath) in the
  stdlib.

I'm sure other people have additional agenda items to contribute.

> Please don't get me wrong - I love what is available from the
> XML-SIG and highly appreciate what all of you did! I just have 
> a slight feeling that it could be easier to use -- maybe. But
> then, perhaps it's just my own sillyness...?

You are certainly right: Things could be easier if people invested
time to make them easier. Contributions are welcome.

Regards,
Martin