[XML-SIG] Developer's Day position paper

[A.M. Kuchling]

Here's the position paper for the XML-SIG's Developer's Day session.
The issues I'd most like to see resolved are:

    * Should we switch to 4DOM?  Or should I seriously start pushing
on implementing DOM Level 2?  Attendees are encouraged to look at
4DOM's code, so they can form some opinions of its quality.

    * Are there any issues about a SAX2 Python binding that we should
discuss?

    * What about xmllib.py? (I raise this issue with some trepidation :) )

Some things on the list are quite simple; for example, consensus
seemed to be that qp_xml.py should go into the tree.  Greg, you want
to go ahead and check it in?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
    "Don't try anything."
    "It's all right; I won't hurt you."
    -- Unnamed thug and Liz Shaw, in "The Ambassadors of Death"


The XML-SIG has been mostly drifting for the last year, with little
attempt made to push out a 1.0 version.  Part of this stemmed from
external forces (little development on a Python Unicode type, no
namespace support in SAX or DOM), and part stemmed from internal
reasons (my getting distracted, few people having time to work on it).

We need to finish a 1.0 version as soon as possible.  Paul Prescod
listed some standards that should be supported: XML SAX Unicode XPath
XPointer DOM XSLT.  XSLT seems too far afield, but the rest are
probably worthwhile candidates.  (Can we prioritize them?)

Issues remaining:

DOM Level 2 support  
===================

Should we switch to 4Thought's implementations of DOM, XPath, and
XPointer?  Participants should try to at least read through some of
4Thought's code, so they can form an opinion of its quality.

Pros:

* An existing DOM Level 2 implementation.

* Maintainers use it actively for real work; PyDOM maintainer has
  short attention span.

* Has XPath and XSLT tools built on top of it.
  (Paul Prescod wrote a few weeks ago that "Ideally we would have one
  (or at most two!) implementation of each of the major specs: XML,
  SAX, Unicode, XPath, XPointer, XSLT, DOM"; if you take 4DOM + 4XSL +
  4Path, this would mean that Unicode is the only missing piece.)

* Faster than PyDOM

* Potential for CORBA support by adding some extra bits

Cons:

* Does anyone other than the maintainers have any experience with it?
  Any comments?  (If you don't want to slag it off publicly, you can
  send me unfavorable comments privately, and I'll preserve your
  anonymity.)

* Uses Ft.Dom package name, not xml.dom

* Potential incompatibilities with existing code, Sean's book, etc.
  (But probably a bit of glue code will let us smooth over such
  problems.)

* Requires releasing nodes explicitly

* Requires that 4Suite base be added to XML-SIG distribution
  (But the only dependency, at least in the DOM, seems to be on
  Ft.Lib.TraceOut.)


SAX Namespace support 
===================== 
This requires that XML-DEV converges to some consensus on SAX2.  Has
it done so?  Are there issues facing a SAX2 binding that we should
discuss?


Unicode
=======

We've been waiting on the official Python solution.  M.-A. Lemburg is
implementing a proposal
(http://starship.skyport.net/~lemburg/unicode-proposal.txt) but it
hasn't reached the Python CVS tree yet.  Therefore, we still haven't
dropped wstrop.  My inclination is to do this as soon as Unicode is
reasonably stable in the CVS tree.


Adding qp_xml.py
================

To the xml.parser package, presumably?

xmllib.py
=========

A touchy catfight ensued on the xml-sig mailing about xmllib.py's
standards compliance (with or without sgmlop).  Should xmllib.py be
dropped?  Can we do an xmllib.py compatible class on top of Expat?


Glue for Java and COM parsers
=============================
We don't have any particular support for Java-based parsers, or
Microsoft's XML-parsing COM component, but we probably should.
(Still, this is probably a low priority.)