[XML-SIG] Pyx

Michael McLay mclay@nist.gov
Tue, 4 Jul 2000 01:00:27 -0400 (EDT)


Greg Stein writes:
 > On Mon, Jul 03, 2000 at 02:41:34PM -0500, Paul Prescod wrote:
 > >...
 > > #2. Let's ignore that and pretend it is not possible. It is entirely
 > > possible to use XML as the interchange format between databases and
 > > applications and so forth and just use Pyx when it is necessary to make
 > > the information available as line-oriented information. Translation to
 > > Pyx can be just the end result of a chain of filters. Therefore you do
 > > not need ODBC->PYX and HTML->PYX and ...->PYX. You need *->XML and XML->
 > > Pyx (which you already have). If you start making Pyx "drivers" for
 > > every data source in the world then you are duplicating all of the work
 > > that has already been done for XML!
 > 
 > What is the problem with that? If somebody chooses to do that work, then why
 > is that a problem with you? It is their choice, after all.
 > 
 > We all work on the things that we believe in, and that we enjoy working on.
 > If Sean is working on PYX, and you don't like the format or its
 > implications, then who says you must work on it?

I agree with Greg.  Also, since there is a book out on using pyxie
with Python it should be included in the standard Python distribution
so that the package works out of the box for someone who picks up the
book and tries to use the examples.  (Battries Included) It doesn't
harm end users to have an alternate tool to use.  Any potential
performance concerns could be documented in the description of the
package.  The description could also point to the book so that people
would understand why the package is included in the distribution.

How about including something like the following as part of the
introduction to the xml package. 

Package xml:

The xml package contains all python modules used to process the xml
syntax.  Some of these modules are based on well known industry
API standards, such as SAX and DOM.  Other modules are here because
books have been written based on the module.  Still others are
included because they provide easy to use APIs for a specific type of
data processing activity.  None of the modules should be considered
more correct than the others.  Read the documentation on each module
and select the module that best matches the problem to be solved.

A release may contain experimental xml modules or packages that are
labled as such.  Please test them and give feedback to the authors,
but don't expect them to remain the same, or even remain in the
permanent library.  If it is marked "EXPERIMENTAL" that is what it
means.  Don't complain later when it changes.