[XML-SIG] Developer's Day

[Paul Prescod]

"Andrew M. Kuchling" wrote:
> 
> Huh?  There's obviously a good deal of stuff in there, some of it
> perhaps too esoteric, but I don't see where there's overlap.  

Well, there are several parsers and parser wrappers. How is a user
supposed to choose? And there is PyDOM, Minidom and qp_dom.

> Or are
> you talking about Python tools in general, where there are 3 DOM
> implementations?  (PyDOM, 4DOM, and ZDOM hiding inside Zope.)

That too.

> I lean against shoveling more stuff into 1.6; better to get the
> Distutils widely used, which makes it easier to install *all* Python
> extensions.

I don't think that XML is any more of an "add-on" to a modern scripting
language than URL support or regular expression support. I'm in the
"batteries included" camp for this and several other reasons: 

	* standard Python libraries may soon need XML support. If WebDAV takes
off then there should be a libWebDAV right alongside libftp and libhttp.
And libWebDAV will require XML

	* there is a difference between theory and practice. In theory,
distutils will be done soon and everything will be easy. In practice, it
is the end of 1999 and at every conference I have to install the XML sig
package on the machines of several people who haven't been able to get
it going themselves. In practice, we can't wait for distutils because
people are choosing their XML tools now.

> >Ideally we would have one (or at most two!) implementation of each of
> >the major specs:
> >XML    >SAX   >Unicode    >XPath    >XPointer   >XSLT    >DOM
> 
> Do you mean "one implementation of each in a single package", or "one
> implementation existing for Python, distributed separately"?

With the possible exception of XSLT, one implementation of each *in
Python 1.6*.

> We need to come up with a position paper for developer's day, stating
> what needs to be discussed.  Suggestions?  I'd propose focusing on
> getting the XML-SIG package to 1.0, but that's just an idea.

I don't see how the XML-SIG package can ever get to 1.0. Anybody can
contribute code at anytime and thus far we've been totally flexible
about putting it in. I think that's great. It just won't ever lead to a
stable, carefully maintained, tightly interoperable package. Some of the
maintainers of the individual pieces have probably lost interest and
there is probably nobody that understands it all enough to integrate it
nicely.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things to be wary of: A new kid in his prime
A man who knows the answers, and code that runs first time
http://www.geezjan.org/humor/computers/threes.html