From m.favas@per.dem.csiro.au  Fri Sep  1 01:49:17 2000
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Fri, 01 Sep 2000 08:49:17 +0800
Subject: [XML-SIG] [Fwd: Namespace collision between lib/xml and site-packages/xml]
Message-ID: <39AEFD0D.9AE67104@per.dem.csiro.au>

This is a multi-part message in MIME format.
--------------52DF9690B2074B5895C6673A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[copy of message sent to python-dev]
-- 
Email  - m.favas@per.dem.csiro.au        Mark C Favas
Phone  - +61 8 9333 6268, 0418 926 074   CSIRO Exploration & Mining
Fax    - +61 8 9383 9891                 Private Bag No 5, Wembley
WGS84  - 31.95 S, 115.80 E               Western Australia 6913
--------------52DF9690B2074B5895C6673A
Content-Type: message/rfc822
Content-Disposition: inline

Message-ID: <39AEDC5B.333F737E@per.dem.csiro.au>
Date: Fri, 01 Sep 2000 06:29:47 +0800
From: Mark Favas <m.favas@per.dem.csiro.au>
Organization: CSIRO Exploration & Mining
X-Mailer: Mozilla 4.75 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: python-dev@python.org, xml-sg@python.org
Subject: Namespace collision between lib/xml and site-packages/xml
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On July 26 I reported that the new xml package in the standard library
collides with and overrides the xml package from the xml-sig that may be
installed in site-packages. This is still the case. The new package does
not have the same functionality as the one in site-packages, and hence
my application (and others relying on similar functionality) gets an
import error. I understood that it was planned that the new library xml
package would check for the site-package version, and transparently hand
over to it if it existed. It's not really an option to remove/rename the
xml package in the std lib, or to break existing xml-based code...

Of course, this might be fixed by 2.0b1, or is it a feature that will be
frozen out <wry smile>?

Fred's response was:
"  I expect we'll be making the package in site-packages an extension
provider for the xml package in the standard library.  I'm planning to
discuss this issue at today's PythonLabs meeting." 
-- 
Mark

--------------52DF9690B2074B5895C6673A--



From guido@beopen.com  Fri Sep  1 05:00:37 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 31 Aug 2000 23:00:37 -0500
Subject: [XML-SIG] Re: [Python-Dev] Namespace collision between lib/xml and site-packages/xml
In-Reply-To: Your message of "Fri, 01 Sep 2000 06:29:47 +0800."
 <39AEDC5B.333F737E@per.dem.csiro.au>
References: <39AEDC5B.333F737E@per.dem.csiro.au>
Message-ID: <200009010400.XAA30273@cj20424-a.reston1.va.home.com>

> On July 26 I reported that the new xml package in the standard library
> collides with and overrides the xml package from the xml-sig that may be
> installed in site-packages. This is still the case. The new package does
> not have the same functionality as the one in site-packages, and hence
> my application (and others relying on similar functionality) gets an
> import error. I understood that it was planned that the new library xml
> package would check for the site-package version, and transparently hand
> over to it if it existed. It's not really an option to remove/rename the
> xml package in the std lib, or to break existing xml-based code...
> 
> Of course, this might be fixed by 2.0b1, or is it a feature that will be
> frozen out <wry smile>?
> 
> Fred's response was:
> "  I expect we'll be making the package in site-packages an extension
> provider for the xml package in the standard library.  I'm planning to
> discuss this issue at today's PythonLabs meeting." 

I remember our group discussion about this.  What's currently
implemented is what we decided there, based upon (Fred's
representation of) what the XML-sig wanted.  So you don't like this
either, right?

I believe there are two conflicting desires here: (1) the standard XML
package by the core should be named simply "xml"; (2) you want the old
XML-sig code (which lives in a package named "xml" but installed in
site-packages) to override the core xml package.

I don't think that's possible -- at least not without a hack that's
too ugly to accept.

You might be able to get the old XML-sig code to override the core xml
package by creating a symlink named _xmlplus to it in site-packages
though.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)


From Mark.Favas@per.dem.csiro.au  Fri Sep  1 08:31:57 2000
From: Mark.Favas@per.dem.csiro.au (Favas, Mark (EM, Floreat))
Date: Fri, 1 Sep 2000 15:31:57 +0800
Subject: [XML-SIG] RE: [Python-Dev] Namespace collision between lib/xml and site-pac
 kages/xml
Message-ID: <C03F68DA202BD411B00700B0D022B09E1AD950@martok.wa.CSIRO.AU>

Guido wrote:
>I remember our group discussion about this.  What's currently
>implemented is what we decided there, based upon (Fred's
>representation of) what the XML-sig wanted.  So you don't like this
>either, right?

Hey - not so. I saw the original problem, asked about it, was told it would
be discussed, heard nothing of the results of the disccussion, saw that I
still had the same problem close to the release of 2.0b1, thought maybe it
had slipped through the cracks, and asked again in an effort to help. I
apologise if it came across in any other way.

>I believe there are two conflicting desires here: (1) the standard XML
>package by the core should be named simply "xml"; (2) you want the old
>XML-sig code (which lives in a package named "xml" but installed in
>site-packages) to override the core xml package.

I'm happy with (1) being the standard XML package - I thought from Fred's
original post that there might be some way of having both work together. 

>I don't think that's possible -- at least not without a hack that's
>too ugly to accept.

Glad to have this clarified.

>You might be able to get the old XML-sig code to override the core xml
>package by creating a symlink named _xmlplus to it in site-packages
>though.

Thanks for the suggestion - I'll try it. Since my code has to run on Windows
as well, probably the best thing I can do is bundle up the xml-sig stuff in
my distribution, call it something else, and get around it all that way.

Mark


From neeloy_saha@infy.com  Fri Sep  1 12:12:47 2000
From: neeloy_saha@infy.com (neeloy_saha)
Date: Fri, 1 Sep 2000 16:42:47 +0530
Subject: [XML-SIG] Compiling the PyXML package for winnt
Message-ID: <8EE756E49A17D21194860008C7F49AFE045290A4@TWRMSG01>

Hi all,

Can soembody give me a step by step instruction for compiling the PYXML
package for winnt.

-neeloy


From e.kinley@calian.com  Fri Sep  1 19:07:09 2000
From: e.kinley@calian.com (Eileen Kinley)
Date: Fri, 1 Sep 2000 14:07:09 -0400
Subject: [XML-SIG] Problems installing XML package v 0.5.2
Message-ID: <8E18B2208544D411A52400508BD68CF54463B2@mailserver.calian.ca>

Environment: Windows 98
Python version: 1.5.2

Questions and a problem report wrt installation.

python setup.py build/install fail due to problems compiling sgmlop (see
problem report below)

I went ahead and ran setup.py install --skip-build, and it copied the
hierarchy (generated by my earlier attempts) into my python directory.

I noticed that there is a precompiled version of sgmlop available, however
it (and several other DLLs) did not get copied.  

Question: Do I simply need to put these dll's in a directory that is in my
search path?  

 c:/Program Files/PyXML-0.5.5.1/windows:
  total 142
  drwxrwxrwx   2 kinley   123             0 Sep  1 10:06 .
  drwxrwxrwx   2 kinley   123             0 Sep  1 10:02 ..
  -rw-rw-rw-   1 kinley   123          8704 Aug 15  1999 pyexpat.dll
  -rw-rw-rw-   1 kinley   123         12800 Aug 15  1999 sgmlop.dll
  -rw-rw-rw-   1 kinley   123           386 Jul 31  1998 sgmlop.mak
  -rw-rw-rw-   1 kinley   123         49152 May 29  1999 xmlparse.dll
  -rw-rw-rw-   1 kinley   123         73728 May 29  1999 xmltok.dll

Next question:

To save my colleagues having to step through this, can I simply zip up the
python/xml subdirectory that has been created and ship that?

=============================

Installation problem report

Some additional documentation might help this one (the readme says to simply
run setup.py)

Caveat: I'm not a C programmer! I recently installed the cygwin utilities,
so do have gcc available...

python setup.py build fails with the following error:


building 'sgmlop' extension
cl.exe /c /nologo /Ox /MD /W3 /GX "-IC:\PROGRAM FILES\PYTHON\Include"
/Tcextensions/sgmlop.c /Fobuild\temp.win32\Release\extensions/sgmlop.obj
warning: build_py: package init file 'xml\parsers\xmlproc\__init__.py' not
found (or not a regular file)
warning: build_ext: old-style (ext_name, build_info) tuple found in
ext_modules for extension 'sgmlop'-- please convert to Extension instance
warning: build_ext: old-style (ext_name, build_info) tuple found in
ext_modules for extension 'xml.unicode.wstrop'-- please convert to Extension
instance
warning: build_ext: old-style (ext_name, build_info) tuple found in
ext_modules for extension 'xml.parsers.pyexpat'-- please convert to
Extension instance
error: command 'cl.exe' failed: No such file or directory

"cl" doesn't exist on my machine.  

I recently installed the cygwin utilities, so seem to have gcc available;
however I'm not sure how to compile/link sgmlop.

TIA,

Eileen

Eileen Kinley
Calian



From frank63@ms5.hinet.net  Sat Sep  2 07:11:04 2000
From: frank63@ms5.hinet.net (Frank J.S. Chen)
Date: Sat, 2 Sep 2000 06:11:04 -0000
Subject: [XML-SIG] Suggestion
Message-ID: <200009012155.FAA09863@ms5.hinet.net>

It's better to include the installation procedure with released PyXML
package on the Web pages.

~~Frank


From china@thewrittenword.com  Sun Sep  3 00:33:12 2000
From: china@thewrittenword.com (Albert Chin-A-Young)
Date: Sat, 2 Sep 2000 18:33:12 -0500
Subject: [XML-SIG] PyXML 0.5.5.1 and HP-UX
Message-ID: <20000902183311.A6333@postal.il.thewrittenword.com>

The shared library extension on HP-UX is 'sl', not 'so'. Because of
this, the following code in setup.py breaks:
    # Copy the C extensions into the build directory
    for filename in ['pyexpat.so', 'sgmlop.so']:
        shutil.copy('extensions/' + filename, 'build/xml/parsers/')

    shutil.copy('extensions/wstrop.so', 'build/xml/unicode/')

I can easy create an if statement for HP-UX but want to know if there
is a dynamic way to determine, via some Config module, what the shared
library suffix is. Perl has Config.pm for this. Does Python have
something similar?

-- 
albert chin (china@thewrittenword.com)


From china@thewrittenword.com  Sun Sep  3 01:40:33 2000
From: china@thewrittenword.com (Albert Chin-A-Young)
Date: Sat, 2 Sep 2000 19:40:33 -0500
Subject: [XML-SIG] PyXML 0.5.5.1 extensions/pyexpat.c not ANSI C
Message-ID: <20000902194032.A21842@postal.il.thewrittenword.com>

In PyXML 0.5.5.1, extensions/pyexpat.c contains:
 staticforward struct HandlerInfo handler_info[];

This is not valid ANSI C. gcc -pedantic complains with:
  array size missing

The Digital UNIX and IRIX C compilers failed to compile pyexpat.c
because of this. The following patch fixes things. What do you think?

-- 
albert chin (china@thewrittenword.com)

-- snip snip
--- extensions/pyexpat.c.orig	Sat Sep  2 19:35:15 2000
+++ extensions/pyexpat.c	Sat Sep  2 19:35:28 2000
@@ -59,6 +59,17 @@
 
 /* ----------------------------------------------------- */
 
+/* Prototypes */
+
+void pyxml_SetEndCdataSection( XML_Parser *, void * );
+void pyxml_SetEndElementHandler( XML_Parser *, void * );
+void pyxml_SetEndNamespaceDeclHandler( XML_Parser *, void * );
+void pyxml_SetStartCdataSection( XML_Parser *, void * );
+void pyxml_SetStartElementHandler( XML_Parser *, void * );
+void pyxml_SetStartNamespaceDeclHandler( XML_Parser *, void * );
+
+/* ----------------------------------------------------- */
+
 /* Declarations for objects of type xmlparser */
 
 typedef struct {
@@ -79,8 +90,6 @@
         xmlhandler handler;
 };
 
-staticforward struct HandlerInfo handler_info[];
-
 static PyObject *conv_atts( XML_Char **atts){
         PyObject *attrs_obj=NULL;
         XML_Char **attrs_p, **attrs_k;
@@ -122,6 +131,8 @@
         clear_handlers(self);
 }
 
+#define RC_HANDLER_PROTO( RC, NAME, PARAMS ) \
+static RC my_##NAME##Handler PARAMS;
 #define RC_HANDLER( RC, NAME, PARAMS, INIT, PARAM_FORMAT, CONVERSION, \
                 RETURN, GETUSERDATA) \
 \
@@ -149,15 +160,106 @@
 
 #define NOTHING /**/
 
+#define VOID_HANDLER_PROTO( NAME, PARAMS ) \
+	RC_HANDLER_PROTO( void, NAME, PARAMS )
 #define VOID_HANDLER( NAME, PARAMS, PARAM_FORMAT ) \
         RC_HANDLER( void, NAME, PARAMS, NOTHING, PARAM_FORMAT, NOTHING, NOTHING,\
         (xmlparseobject *)userData )
 
+#define INT_HANDLER_PROTO( NAME, PARAMS ) \
+	RC_HANDLER_PROTO( int, NAME, PARAMS )
 #define INT_HANDLER( NAME, PARAMS, PARAM_FORMAT )\
         RC_HANDLER( int, NAME, PARAMS, int rc=0;, PARAM_FORMAT,  \
                         rc = PyInt_AsLong( rv );, rc, \
         (xmlparseobject *)userData )
 
+/* Prototypes for all handler functions */
+VOID_HANDLER_PROTO( StartElement,
+		(void *, const XML_Char *, const XML_Char **) )
+VOID_HANDLER_PROTO( EndElement,
+		(void *, const XML_Char *) )
+VOID_HANDLER_PROTO( ProcessingInstruction,
+		(void *, const XML_Char *, const XML_Char *) )
+VOID_HANDLER_PROTO( CharacterData, 
+                (void *, const XML_Char *, int) )
+VOID_HANDLER_PROTO( UnparsedEntityDecl,
+                (void *, const XML_Char *, const XML_Char *,
+		const XML_Char *, const XML_Char *, const XML_Char *) )
+VOID_HANDLER_PROTO( NotationDecl, 
+		(void *, const XML_Char *, const XML_Char *,
+		const XML_Char *, const XML_Char *) )
+VOID_HANDLER_PROTO( StartNamespaceDecl,
+		(void *, const XML_Char *, const XML_Char *) )
+VOID_HANDLER_PROTO( EndNamespaceDecl,
+		(void *, const XML_Char *) )
+VOID_HANDLER_PROTO( Comment,
+		(void *, const XML_Char *) )
+VOID_HANDLER_PROTO( StartCdataSection,
+		(void *) )
+VOID_HANDLER_PROTO( EndCdataSection,
+               (void *) )
+VOID_HANDLER_PROTO( Default,
+                (void *,  const XML_Char *, int) )
+VOID_HANDLER_PROTO( DefaultHandlerExpand,
+                (void *,  const XML_Char *, int) )
+INT_HANDLER_PROTO( NotStandalone,
+                (void *) )
+RC_HANDLER_PROTO( int, ExternalEntityRef,
+		(XML_Parser, const XML_Char *, const XML_Char *,
+		const XML_Char *, const XML_Char *) )
+
+static struct HandlerInfo handler_info[]=
+{{"StartElementHandler", 
+        pyxml_SetStartElementHandler, 
+        my_StartElementHandler},
+{"EndElementHandler", 
+        pyxml_SetEndElementHandler, 
+        my_EndElementHandler},
+{"ProcessingInstructionHandler", 
+        (xmlhandlersetter)XML_SetProcessingInstructionHandler,
+        my_ProcessingInstructionHandler},
+{"CharacterDataHandler", 
+        (xmlhandlersetter)XML_SetCharacterDataHandler,
+        my_CharacterDataHandler},
+{"UnparsedEntityDeclHandler", 
+        (xmlhandlersetter)XML_SetUnparsedEntityDeclHandler,
+        my_UnparsedEntityDeclHandler },
+{"NotationDeclHandler", 
+        (xmlhandlersetter)XML_SetNotationDeclHandler,
+        my_NotationDeclHandler },
+{"StartNamespaceDeclHandler", 
+        pyxml_SetStartNamespaceDeclHandler,
+        my_StartNamespaceDeclHandler },
+{"EndNamespaceDeclHandler", 
+        pyxml_SetEndNamespaceDeclHandler,
+        my_EndNamespaceDeclHandler },
+{"CommentHandler",
+        (xmlhandlersetter)XML_SetCommentHandler,
+        my_CommentHandler},
+{"StartCdataSectionHandler",
+        pyxml_SetStartCdataSection,
+        my_StartCdataSectionHandler},
+{"EndCdataSectionHandler",
+        pyxml_SetEndCdataSection,
+        my_EndCdataSectionHandler},
+{"DefaultHandler",
+        (xmlhandlersetter)XML_SetDefaultHandler,
+        my_DefaultHandler},
+{"DefaultHandlerExpand",
+        (xmlhandlersetter)XML_SetDefaultHandlerExpand,
+        my_DefaultHandlerExpandHandler},
+{"NotStandaloneHandler",
+        (xmlhandlersetter)XML_SetNotStandaloneHandler,
+        my_NotStandaloneHandler},
+{"ExternalEntityRefHandler",
+        (xmlhandlersetter)XML_SetExternalEntityRefHandler,
+        my_ExternalEntityRefHandler },
+
+{NULL, NULL, NULL } /* sentinel */
+};
+
+/* Handler functions */
+
 VOID_HANDLER( StartElement, 
                 (void *userData, const XML_Char *name, const XML_Char **atts ), 
                 ("(sO&)", name, conv_atts, atts ) )
@@ -827,55 +929,4 @@
                 StartCdataSection, EndCdataSection, 
                 (pairsetter)XML_SetCdataSectionHandler);
 }
-
-static struct HandlerInfo handler_info[]=
-{{"StartElementHandler", 
-        pyxml_SetStartElementHandler, 
-        my_StartElementHandler},
-{"EndElementHandler", 
-        pyxml_SetEndElementHandler, 
-        my_EndElementHandler},
-{"ProcessingInstructionHandler", 
-        (xmlhandlersetter)XML_SetProcessingInstructionHandler,
-        my_ProcessingInstructionHandler},
-{"CharacterDataHandler", 
-        (xmlhandlersetter)XML_SetCharacterDataHandler,
-        my_CharacterDataHandler},
-{"UnparsedEntityDeclHandler", 
-        (xmlhandlersetter)XML_SetUnparsedEntityDeclHandler,
-        my_UnparsedEntityDeclHandler },
-{"NotationDeclHandler", 
-        (xmlhandlersetter)XML_SetNotationDeclHandler,
-        my_NotationDeclHandler },
-{"StartNamespaceDeclHandler", 
-        pyxml_SetStartNamespaceDeclHandler,
-        my_StartNamespaceDeclHandler },
-{"EndNamespaceDeclHandler", 
-        pyxml_SetEndNamespaceDeclHandler,
-        my_EndNamespaceDeclHandler },
-{"CommentHandler",
-        (xmlhandlersetter)XML_SetCommentHandler,
-        my_CommentHandler},
-{"StartCdataSectionHandler",
-        pyxml_SetStartCdataSection,
-        my_StartCdataSectionHandler},
-{"EndCdataSectionHandler",
-        pyxml_SetEndCdataSection,
-        my_EndCdataSectionHandler},
-{"DefaultHandler",
-        (xmlhandlersetter)XML_SetDefaultHandler,
-        my_DefaultHandler},
-{"DefaultHandlerExpand",
-        (xmlhandlersetter)XML_SetDefaultHandlerExpand,
-        my_DefaultHandlerExpandHandler},
-{"NotStandaloneHandler",
-        (xmlhandlersetter)XML_SetNotStandaloneHandler,
-        my_NotStandaloneHandler},
-{"ExternalEntityRefHandler",
-        (xmlhandlersetter)XML_SetExternalEntityRefHandler,
-        my_ExternalEntityRefHandler },
-
-{NULL, NULL, NULL } /* sentinel */
-};
-
 


From china@thewrittenword.com  Sun Sep  3 01:53:02 2000
From: china@thewrittenword.com (Albert Chin-A-Young)
Date: Sat, 2 Sep 2000 19:53:02 -0500
Subject: [XML-SIG] PyXML 0.5.5.1 extensions/wstrop.c conversion warnings
Message-ID: <20000902195302.B21842@postal.il.thewrittenword.com>

The following patch fixes some problems assigning char * to unsigned
char * and vice versa.

-- 
albert chin (china@thewrittenword.com)

-- snip snip
--- extensions/wstrop.c.orig	Sat Sep  2 19:44:05 2000
+++ extensions/wstrop.c	Sat Sep  2 19:44:15 2000
@@ -89,7 +89,7 @@
 /* Converts a single wide character to a sequence of utf8 bytes.
    Returns the number of bytes, or 0 on error. */
 static int
-to_utf8(unicode_t c,unsigned char* buf)
+to_utf8(unicode_t c,char* buf)
 {
   if(c<0x80){
     if(buf)buf[0]=c;
@@ -148,7 +148,7 @@
 /* Decodes a sequence of utf8 bytes into a single wide character.
    Returns the number of bytes consumed, or 0 on error */
 static int
-from_utf8(const unsigned char* str,unicode_t *c)
+from_utf8(const char* str,unicode_t *c)
 {
   int l=0,i;
   if(*str<0x80){
@@ -265,7 +265,7 @@
    Returns the length of the UTF-7 string, or -1 on error.
    If the destination buffer is 0, it only counts the length. */
 static int
-ucs2_to_utf7(char* utf7,unsigned char* ucs2,int len2,enum utf7_type optionals)
+ucs2_to_utf7(char* utf7,char* ucs2,int len2,enum utf7_type optionals)
 {
   int len7=0;
   int carry=0,ccount=0;
@@ -331,7 +331,7 @@
    Returns the length of the UCS-2 string in shorts.
    On error, raises exception and returns -1. */
 static int
-utf7_to_ucs2(unsigned char* ucs2,unsigned char* utf7,int len2,int flags)
+utf7_to_ucs2(char* ucs2,unsigned char* utf7,int len2,int flags)
 {
   int quoted=0;
   int len=0;
@@ -883,7 +883,7 @@
 {
   int flags=0;
   PyObject* result;
-  unsigned char *s;
+  char *s;
   int i;
   /* this flags are ignored, anyways */
   if(!PyArg_ParseTuple(args,"|i",&flags))return 0;


From m.favas@per.dem.csiro.au  Sun Sep  3 03:05:03 2000
From: m.favas@per.dem.csiro.au (Mark Favas)
Date: Sun, 03 Sep 2000 10:05:03 +0800
Subject: [XML-SIG] Re: [Python-Dev] Namespace collision between lib/xml and
 site-packages/xml
References: <200009010400.XAA30273@cj20424-a.reston1.va.home.com>
Message-ID: <39B1B1CF.572955FC@per.dem.csiro.au>

Guido van Rossum wrote:
> 
> You might be able to get the old XML-sig code to override the core xml
> package by creating a symlink named _xmlplus to it in site-packages
> though.

Nope - doing this allows the imports to succeed where before they were
failing, but I get a "SAXException: No parsers found" failure now. No
big deal - I'll probably rename the xml-sig stuff and include it in my
app.

-- 
Mark


From joachim.werner@iuveno.de  Mon Sep  4 11:30:02 2000
From: joachim.werner@iuveno.de (Joachim Werner)
Date: Mon, 4 Sep 2000 12:30:02 +0200
Subject: [XML-SIG] Don't get the PyXML package installed
Message-ID: <00090412402700.01141@speedy>

Hello!

I don't succeed in compiling the PyXML package on SuSE 6.4. This is the output
of the setup.py script:


zope@promotor:~/PyXML-0.5.5 > python setup.py build

Executing 'build' action...

Running command: make -f Makefile.pre.in boot
rm -f *.o *~
rm -f `find . -name '*.pyc'`
rm -f `find . -name '*.o'`
rm -f `find . -name '*~'`
cd expat ; make clean
make[1]: Entering directory `/home/zope/PyXML-0.5.5/extensions/expat'
rm -f xmltok/xmltok.o xmltok/xmlrole.o xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlparse/xmlparse.o xmlparse/hashtable.o xmlwf/unixfilem
ap.o xmlwf/xmlwf
make[1]: Leaving directory `/home/zope/PyXML-0.5.5/extensions/expat'
rm -f *.a tags TAGS config.c Makefile.pre python sedscript
rm -f *.so *.sl so_locations
cd expat ; make clobber
make[1]: Entering directory `/home/zope/PyXML-0.5.5/extensions/expat'
rm -f xmltok/xmltok.o xmltok/xmlrole.o xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlparse/xmlparse.o xmlparse/hashtable.o xmlwf/unixfilem
ap.o xmlwf/xmlwf
rm -f libexpat.a
make[1]: Leaving directory `/home/zope/PyXML-0.5.5/extensions/expat'
VERSION=`python -c "import sys; print sys.version[:3]"`; \
installdir=`python -c "import sys; print sys.prefix"`; \
exec_installdir=`python -c "import sys; print sys.exec_prefix"`; \
make -f ./Makefile.pre.in VPATH=. srcdir=. \
        VERSION=$VERSION \
        installdir=$installdir \
        exec_installdir=$exec_installdir \
        Makefile
make[1]: Entering directory `/home/zope/PyXML-0.5.5/extensions'
sed -n \
 -e '1s/.*/1i\\/p' \
 -e '2s%.*%# Generated automatically from Makefile.pre.in by sedscript.%p' \
 -e '/^VERSION=/s/^VERSION=[    ]*\(.*\)/s%@VERSION[@]%\1%/p' \
 -e '/^CC=/s/^CC=[      ]*\(.*\)/s%@CC[@]%\1%/p' \
 -e '/^CCC=/s/^CCC=[    ]*\(.*\)/s%#@SET_CCC[@]%CCC=\1%/p' \
 -e '/^LINKCC=/s/^LINKCC=[      ]*\(.*\)/s%@LINKCC[@]%\1%/p' \
 -e '/^SGI_ABI=/s/^SGI_ABI=[    ]*\(.*\)/s%@SGI_ABI[@]%\1%/p' \
 -e '/^OPT=/s/^OPT=[    ]*\(.*\)/s%@OPT[@]%\1%/p' \
 -e '/^LDFLAGS=/s/^LDFLAGS=[    ]*\(.*\)/s%@LDFLAGS[@]%\1%/p' \
 -e '/^LDLAST=/s/^LDLAST=[      ]*\(.*\)/s%@LDLAST[@]%\1%/p' \
 -e '/^DEFS=/s/^DEFS=[  ]*\(.*\)/s%@DEFS[@]%\1%/p' \
 -e '/^LIBS=/s/^LIBS=[  ]*\(.*\)/s%@LIBS[@]%\1%/p' \
 -e '/^LIBM=/s/^LIBM=[  ]*\(.*\)/s%@LIBM[@]%\1%/p' \
 -e '/^LIBC=/s/^LIBC=[  ]*\(.*\)/s%@LIBC[@]%\1%/p' \
 -e '/^RANLIB=/s/^RANLIB=[      ]*\(.*\)/s%@RANLIB[@]%\1%/p' \
 -e '/^MACHDEP=/s/^MACHDEP=[    ]*\(.*\)/s%@MACHDEP[@]%\1%/p' \
 -e '/^SO=/s/^SO=[      ]*\(.*\)/s%@SO[@]%\1%/p' \
 -e '/^LDSHARED=/s/^LDSHARED=[  ]*\(.*\)/s%@LDSHARED[@]%\1%/p' \
 -e '/^prefix=/s/^prefix=\(.*\)/s%^prefix=.*%prefix=\1%/p' \
 -e '/^exec_prefix=/s/^exec_prefix=\(.*\)/s%^exec_prefix=.*%exec_prefix=\1%/p' \
 /usr/local/lib/python1.5/config/Makefile >sedscript
echo "/^#@SET_CCC@/d" >>sedscript
echo "/^installdir=/s%=.*%=     /usr/local%" >>sedscript
echo "/^exec_installdir=/s%=.*%=/usr/local%" >>sedscript
echo "/^srcdir=/s%=.*%=         .%" >>sedscript
echo "/^VPATH=/s%=.*%=          .%" >>sedscript
echo "/^LINKPATH=/s%=.*%=       %" >>sedscript
echo "/^BASELIB=/s%=.*%=        %" >>sedscript
echo "/^BASESETUP=/s%=.*%=      %" >>sedscript
sed -f sedscript ./Makefile.pre.in >Makefile.pre
cp ./Setup.in Setup
/usr/local/lib/python1.5/config/makesetup \
         -m Makefile.pre -c /usr/local/lib/python1.5/config/config.c.in Setup -n  /usr/local/lib/python1.5/config/Setup
make -f Makefile do-it-again
make[2]: Entering directory `/home/zope/PyXML-0.5.5/extensions'
/usr/local/lib/python1.5/config/makesetup \
         -m Makefile.pre -c /usr/local/lib/python1.5/config/config.c.in Setup -n  /usr/local/lib/python1.5/config/Setup
make[2]: Leaving directory `/home/zope/PyXML-0.5.5/extensions'
make[1]: Leaving directory `/home/zope/PyXML-0.5.5/extensions'
 
Running command: make
gcc -fpic  -Iexpat/xmlparse -g -O2 -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./pyexpat.c
In file included from /usr/include/errno.h:36,
                 from /usr/local/include/python1.5/Python.h:59,
                 from ./pyexpat.c:32:
/usr/include/bits/errno.h:25: linux/errno.h: Datei oder Verzeichnis nicht gefunden
In file included from /usr/include/bits/posix1_lim.h:126,
                 from /usr/include/limits.h:30,
                 from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/limits.h:117,
                 from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/syslimits.h:7,
                 from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/limits.h:11,
                 from /usr/local/include/python1.5/longobject.h:58,
                 from /usr/local/include/python1.5/Python.h:76,
                 from ./pyexpat.c:32:
/usr/include/bits/local_lim.h:27: linux/limits.h: Datei oder Verzeichnis nicht gefunden
make: *** [pyexpat.o] Error 1
Traceback (innermost last):
  File "setup.py", line 185, in ?
    func()
  File "setup.py", line 155, in build_unix
    shutil.copy('extensions/' + filename, 'build/xml/parsers/')
  File "/usr/local/lib/python1.5/shutil.py", line 52, in copy
    copyfile(src, dst)
  File "/usr/local/lib/python1.5/shutil.py", line 17, in copyfile
    fsrc = open(src, 'rb')
IOError: [Errno 2] Datei oder Verzeichnis nicht gefunden: 'extensions/pyexpat.so'    


I suppose that some stuff in the /usr/include/bits directory is missing, but I
don't know enough about Linux/gcc to fix it myself. These are the critical
lines from the above output:

/usr/include/bits/errno.h:25: linux/errno.h: Datei oder Verzeichnis nicht
gefunden

/usr/include/bits/local_lim.h:27: linux/limits.h: Datei oder Verzeichnis nicht gefunden


Could you please give me a hint? A hint where I can find a working binary of
PyXML would be cool, too (I need it for a Zope product called "NewsCenter"!)

Thanks!

Joachim.


-- 
Iuveno - Smart Communication


Joachim Werner


_________________________________________

Marie-Curie-Straße 6
85055 Ingolstadt

Tel.: +49 841/90 14-325 (Fax -322)
Mobil: +49 179/39 60 327
E-Mail: joachim.werner@iuveno.de/joachim.werner@iuveno-net.de
WWW: www.iuveno.de/www.iuveno-net.de




From peterson@psycrow.raznick.com  Mon Sep  4 17:30:14 2000
From: peterson@psycrow.raznick.com (George Peterson)
Date: Mon, 4 Sep 2000 11:30:14 -0500 (CDT)
Subject: [XML-SIG] sgmlop Doesn't Appear to Build
Message-ID: <Pine.BSO.4.21.0009041123020.11194-100000@psycrow.raznick.com>

I am trying to build the XML package, but it doesn't appear that
"sgmlop.c" is being compiled.  It doesn't have an entry in "setup.py" like
"pyexpat" does, so this is probably not surprising.  Unfortunately, the
software I am attempting to use needs "drv_sgmlop" and it attempts to
import "sgmlop".

This is on a RedHat 6.2 system with Python 1.6b1 installed.  I have tried
the following versions of PyXML:

	- PyXML-0.5.4
	- PyXML-0.5.5.1
	- The most recent version checked into CVS at SourceForge

Any help on this would be greatly appreciated.

-Peterson



From pr1@club-internet.fr  Tue Sep  5 12:01:57 2000
From: pr1@club-internet.fr (Philippe de Rochambeau)
Date: Tue, 05 Sep 2000 13:01:57 +0200
Subject: [XML-SIG] Problem with Macintosh version of PyExpat
Message-ID: <39B4D2A4.15AC05D8@club-internet.fr>

Il s'agit d'un message multivolet au format MIME.
--------------EBB05EB85A82A484EE846130
Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 8bit

Hello,

I am having problems compiling PyExpat for Macintosh.

First, I converted and opened the Code Warrior project file
"pyexpat.prj" with CodeWarrior 5. Here are the error messages which I
got:

The following access path in target “pyexpat.CFM68K” cannot be found:
{Project}::::CWGUSI:

The following access path in target “pyexpat.ppc” cannot be found:
{Project}::::CWGUSI:

Could not find subproject “libexpat.prj” in target “pyexpat.CFM68K”

Could not find subproject “libexpat.prj” in target “pyexpat.ppc”

I then dropped the "expat" folder located in the "extensions" folder, on
the CW Project Window and got many more errors which you will find
listed in the enclosed text file.

Since I am only a beginning C/C++ programmer, could you please help me
compiling PyExpat for Mac?

Many thanks.

Philippe de Rochambeau



--------------EBB05EB85A82A484EE846130
Content-Type: application/zip; x-mac-type="5A495020"; x-mac-creator="495A6970";
 name="errors-txt.zip"
Content-Transfer-Encoding: base64
Content-Description: Unknown Document
Content-Disposition: inline;
 filename="errors-txt.zip"

UEsDBBQAAAAIAM1mJSmQH+tJORQAAEWAAAAKAEwAZXJyb3JzLnR4dFVUCQAF4tC0Oc/QtDlN
MzsAQAAAAAEAVEVYVFIqY2gIAGADOG5jYJRhbGBigIMGOCt/7q2tTUAMYivIIDADQ2pRUX5R
sV5JRQkDAwDFXety20ay3j/5k6q8w8SuSKBMyyR4tyOfoilIZoUiuSLlKMcnhYLIoYQ1CPAA
oCVtkpfc1L7Pdg8AEpchNbgo66pUKBDzTU93T9/mwukdJQvLMKx73bwl2mxGHYesNPeO6CZx
NfuWuuRfq0f6AM+Oe2cXzfZPf5KZZpqWS26w6dqcv/3u29/GtvUPOnP/eAv/ej+fX0368PS7
b6dp4FerWRrsnrU25gRfXujmnDjrm5X3IvmXod/4kPY//twzkrwwSDFi/O0k8W8Dbf7bRw5g
F7pBt9hEmi2WzfaX0vFAv/nz+Klm40f3zjJ7lk29dxXbtmxCyFviIqvxncPlPbW/OOrKWN/q
pjqzzIV+e3x3GGKttaImnX/3bTCOGTF0k5IqAL05yv5vF0Ee0UIk1GRo+1I3Z8Z6TsmLoOWL
KPThu0MCzYAtHIhGG95xXM3VZ2T8OLph3Dtijb0/3qUAa7bgneuLgTrWbIfaRHcdaixiCHM6
MzQbOrRM4jyarvZAKH6ZREPStjQd3Wnm3KC2kxmvA+//QR6WxgrJs3jDEwZrVTd8W1j2vWbP
gdTp44r65F77vbjwKGsfbTnRh+Paa0D/6LGiby4s4rNF1eGPz7/G+vIGiUrl0XVIbDqnMFU4
0mvXeaoAM+KrqrmuIzHJ9u40G2SBD0q/RfsCA+QhE31OTVdf6KACh/Cm7ahAx2Gyw0ZEwJs3
T4ZXg0FsINDQBnP4NM+avgpuCQXQVXnz8UtWYNRt3XSJB2NQ853I8O2vnHFHFdv+KoS0h5Gd
CtK2kIi0eYmcQA+n+sxVh/ReKpXIyQlBtpISEe8MBsnpDLUS9FHavHNSKftcWUG3qBrvUnSy
4nRRg1aB6FIwhweFSu1/++pVeSu9V69KJIUC81nRYHwnW1b8IAui8vSig7prfz0ZP05cG0IA
9cy2lt5HKeBG6R0R4i0Xv+WT+z30kmr0fK3z1Fg9VXqXytlW9Uq51bmzkdkOa5AaslqphTHL
4nBfeGCoVNIMLMxRKTArZcbTH0klt1msVhrPxNhqpZmNszxtqlY6ETJh+Cno47G1ij6VGg71
Sfxykt4E8MddRYHZ1F3b5nb48cimtCeyqVZxsF8tfU5mBtVsNQhGpFg8QY4w5CFxVuwHl6sB
+MLQblXmgHYBx7RLNwx6qxlksTZnLKJgrNHxI6cfNN0x+hE1Tm2IrXuIxhn1Rw5qmgjgKgZd
Qm9+REMkxoajNYSPp5qrlQnEH44b8uimtqTJpywgAd/2G59rJ0SKPy9hFyli2yoLbr/x4yNG
5fJRVcx5lgGkpxSxSA5mtxizMXiEr4Vp9VK45PM5vP2szG7xmI19a/A+I1Z4DHP2FCM38M8p
iM7BbBaERohwHh2XLvvzJHmr9Y2hz3jfQO7HkoQhKMyzMpvFSHFmD/3eTyFbEdftEMnJb280
h/OUsSY7s+UKBr/OSpvRVKRC1L/QH5LP17b+nMyWmXPnmBFkWdZRpCQ4D7M7vHlpLVNZwExE
+yYwnlnsZ3a1xiF3AlbN7aFZmNB95jArgaGM1r7Nw+zqDo/zl9F+MkzDbBbFxMk9pQttbYjr
hpPFVG+GkIPZMsvlODQr8Jo5/ysGkIrZ4YmIHXomG3TbnGuGZdJnVgzIHHIwu442mz5wIos9
PmKv+9wzrm+kI58JRyWJvWCX4lWQVNR3trU/gkngpmOv7qmqc2umqp9/hb7Tx9Uyq6+8kHCO
k89l3QE6NOPXEnlNGDqOneCXL/KMoMEr9aVIWWRWq4iOm5+xlGOqQ0p56MaSw8xTiXjOkgqn
4xfznGQdLw1QjQUfCKQ7ZygnEHklF17Vx0sUBUV0p8aqHKzCM37s2reeXKbrlUEl5H2ZvHBe
/q6/KJMDB/+DwcP/fNJLpRT2p1YJZdScMkK6QTdY3Qt4t1k7YGnp6/feAkKZALUesQGtmZjT
9Kuk40doqY5ms7Vt07lUgqQ6w0StVVr7WSCE0eYk0UINO0GtBMWNzAPNS9T0hJcaatUKK+Yg
Y84se6m5UmgNCPTmh2MItJ233ts/6GiIjfXShI8vyinsRo3VeFDMrIFf3GQPzqnLnvWseVT8
IJ90Xch+FwHiAB4P18sbakdx06HWYqg9xgAebqL6IyTR6hMzSgijkVSnFDoQUujxo/phrRvz
T5qxptILtBnJAp8YTTwVT2MeWNWK2USqzXVw/5LnAW7WCy/Wgg+qo/+Thl3Nkrp3eWplNVbe
irguXrk0HWQ9Annz6FInP2h0Ec1x7fyQTZ/hHOcoInG5HXghiY2RrUX1TZetZwwsmPCBxEpx
pyOG39l6uaglT+XCaluTN6HuEGJmCf56mKnK6IxhZFL3Ghq4W8u1CAvcjMdMIHJyzuw3T7X6
huegqikZ0Qi3ZdJiMQNbOqwmZZRGl2rNJ9iRCsxfceoP2YoDU65sQgo0KBgpKEAfMgwcf5lU
ysSDZss5OehlaU5eXajLG+nA5GbS8Sa72gNI76OE5q5MmORzEVwrguCtOm1WMnt3dPZFwu0L
JCeFRepTHfUJF7A3dJ4rU3XS/1/FJzXNKk6t3mFJlW3OVo8SYd5pg9t1/FAHvi+Vsc9kkJCG
8oZnu9Rrf/GNS246RLRbPk/fZpB6Q94GDxn9RiPnilKtEUprOYn5mW7kTM5rjSZLznGnVqEZ
ea3ReTojz7JpDThgRnes5ce8paa5dLWbonGpt5LmRHHJ9E53IPEjjr4EUw1cXGINyI9orQW5
s+4J2IM1SMLjqddiZVu3trbMT9ad5tzBaA1a9HgD7Swad24YS03fK/bdSUGsMfPfH0ajAfm5
P+yO++TUMC7ge+ljd3g6UMhdH2RRJleD0fCcrA0VYnTHMtWFZaszMCVlMhh/GvVPibG6pA61
v9L53tAk3jtmJPEonjdP4+3aW2M0vbxSRKxRHKKTNEYvX74k7K+3pGctV7rhMVC7sWyAIJpL
qDlHlWQSg7cL0RHbehbVc60vz4Oq4jzdBx11o7xG1SADGYNz619LDvTlrzKVJK8ErAx7o9M+
KN0RNWdBXdhLDFeuHX0AUimL6j+XHFTDMOCRSR/cqfVlDN48F3A7qd8pEYJIFgZNvj9BBUxR
BeIhypUgfOt97F6qF91p76MykRiXGWcPXx+W8vaBahFiIjhjgBbeJ8uFDMUfWKaZjn6CPOFT
d9A/zYfLCUpSImBqhuJ5dUIu+sMP4x4yUyhv4cJhkHN/h1Nzn9DF8dhmhXvdnd0R6cMvU0Wd
/jJWNvJOilocma1fzjRwzB+m6kDpnspvmWahlXzNWPIjkUtxqY27l9N+d6Ci+r1j738jVZAM
ciSF5h2uWCF973ZJnfxBVlkpZ+sMPuEgs6uJSEjMRQrmp5TUALYpF2W3zyPyQFnlgs+1rFrF
yhZIZ5pJL44uPwcXasVzof6U7XvPY8O+QJ/bTUPA/IkT3RS1fOKQrZSZGBekzRsleVWEEWTR
WWzMvdHFhTKcZoVkxRqRpRhuY5w+NxD8xo8XiCPgFJl7Ow/ixiYt51kZpziPU6/nHhxnXUK8
cTNP4yI0ud4u3NLUOenF03Fxo56Mi3G/WDFBsTDxrM4iFg+LYwaHE1BvM3qERvFy8uoyzxEd
NStFxRjN6nbYvIQpIDZqesvI4jIJSS4rj5pyaCSDyd8/5LVfbGf4M3mOZj2pI73R8FSdKL2p
Ohorw8zIjRAbhheT6eU0s0SbIaiPynVuhrYKdQjsZGYuh8DOYhbk7VqVIqOpVjWpHzmjqdaT
q3ncVrVi87xW/bksWSus+GPlsjfMrPitZsgLROZ7Vp/QaiXlmdMntPb7hCjdOfjaDnuIydvN
x97l9vPg7O0TrE87ndoitRnxMQiXZcQh0y4TcUEaQrzN20uzUF5yVPlU6Q1yea12uNSRz2u1
O8V6LXasuTiv1cmdo3UKzNE63BgnM2WcqCbnNOvkydk6vJwtNYuKN90dzma0J12xvNmV60fX
M9zNMNan7HRc1tyLAR653KQpJadkb98v4K1XK2qn3YTMRUSF8qnzN+Yy9vczct479xQt/n4f
mdZHtbS+Xa6EKl/VzIS1Et58pHYnvX6/gNhIrmzM6+HDYUbD6p26ymO55OomlDi8TpCRVjfY
Ht5A0zLznW3TzTeo2m5zLIxRL0CFeNtuxRs3i/Ry3qGxZ1Pn6ladl5nVuZpbneWtOl/kVme5
EHWWc6uzXIA6y3vUOceKvhnZkxP3d8OJdL00zql75S7afdOltqkZijmz5rp5W5J2ODe8GYnT
AbJxx/qKP66vuCUdLxjDQ11vGDF4rt2y38xp8HEjfU4PoWWjA9ORdJ9gdQ3UqzQg+xg+7b37
KoHbfII11WZe3vB2wxTLm7A5PJLCIUvpwCT/E2WYobuuQeUoz4CmyEs3+q28l6vBFVUB0yJX
VCUJ7PC5HPTglNjWPqE7WHD7jlndEHfI00Y0NDie2LtsIGK3yDgzXd/fR9XvI/qqeBcRxeX2
IPs9JFVcqIOIDLkd1PwOktIuqIN6vg7iqsrtoxHImqfXBUmiuVMSuNVxOFJBq8nRm2hndNcd
ZUl8tty1d9ty0h4GZxhhGqGjnIAbGNuWYd3+RXutQqRs3UvujVYhVI5PSdM85DAC/kgRk1Mm
PqP6w/5U3XKrxNjFDjVejgajc3Uy7U4VfytBjtWXEG11wXw21KSVFHfPAnNd1N46QcrbwqIW
A6xX8oupNxpOleG0eDmx/QHp5FSvbeUEMUQfhrSNG2IjWJUTPhFFN44LC+8eylBrCBHV8InS
wcne0g1FfTCHDxKDz8afoO6vY53/avjTcPTzEAcoUhMIwYQqRllKICEkVM+Ay2p/eKpcSyu2
5ww5WdLzgWMQs3r9XvdkeoyrtSa1nc9xU4GhTNIq5+qbnRzZ1XdE/2OdBzYiX+/VaO/r1Vxz
6dhyWAPoEL+4ijzM15/s9edNBoJLSPghHyar3G4QD6TteLIpfyNjDSKEwCtApBvU1hxH4mq8
VXlrdjK5h1wGh+1tYFA368XnoGf1onsdv+o2Ja4c4B7hpaUAng8uMNZxw5AizmA7E8DSYxYN
k+0rtV2vZHOw9UMHYOlX5BUJM4K8JtVsitcMarKh9eV0KW+zKHvLdigwUSRwxIYSnDmGLJf+
/0yX2Pm7F1fTs9fV5osSOTjAqf/6/VI3P+DZzjG12QUy4G3kfAoa2omYTG7TYbGdDFzPCqPJ
JuJWsK83n2NtyXsELUZIKIqO5ut6YiaLAaYPfVstjpFL5nYphRYPZHG2ZhpQJwaUNbT29g2E
Q+sbbT7OSFU7kZKBYcJUNDOgHAcMdIHdGpgJssaR6wY2G2Sw0/LI2VyplSktaYdM5NxiB0bB
xuOmTSnuXrMRytI555xCEKcZU8hTFGjlPmYDQ13mTAixxiyqzagVbK0/q8J7K/vZdZyt6+dU
a7aen1uT2Tp+LsUNrvYKdDaTbeUt3/8XDj8CG+hKuy389CNeJINtltpKDNp5dN5gTd4RxmOV
rM1Pc/wYAni/rxM8AS7eh5zow2u/swtxFq1N/aFIFnHwMrJoudR2/DoKr48ki7z2GaXA66Im
JgV+xXimzee26h5yoVnwhjGxf39hCWhfSZLfplQpQ7ir/5PCR5NdWFIm48vRVL1UuqdC5eqL
7lgdX/Y/QbK/gwBkH7511h8ov4deL5MFZCOStVggHWIXv+8fKjqP5dqMDBCSHZN7yUsWjb7X
zZqcSqVdjE/EwVgNa6sIfuuYFkQjVC5M6CYIJnb20opljX4CPsXTaaAOe+v8POxGsJHJfx7F
M5NeSwCS+U6kUzpa2Rb+ZpVlB5UCT23LxNPSoDLgd1f2v8Zba3a7ukP42lsSxESaUaE5JPiL
aA4QuYAwksVqoFumdc/51uvpcMcQasEQGC2iCTwXCv238FIDFwH9t3+5gvhPJ3GRmlukZT4k
jDFPfx5dnjJJ5sNqR7A+ihdMeGisPISXvPbAP7rshhfJ+4WAc2WoXPZ7njEkaL/UCaid4j/A
O9LKBDfOqsp1fzKFlEHIZDKgs0H3XJ0of79Shuyk8qTXHe7QLVZn2tnIoyM+j1OyILjzc4EZ
vr/pU/XkrsIfV8q+7T6HSesCM6n01IxT1YVhaS5e8eFP/lBb3iQMN8CpKh0fH5d28QwnUZgu
4XUFLlojZemCCyJ6BpHbmG3JAmUHPT2nLirpBP6SFngHK5sD2Qe3KXsxeIgU2NQqva6mO6XM
xe4UKYZWpQAxtDjLaKnHxYKagGcf9RRXWXDRcPpJB9+AgsMXzmf5V5EyARepXgSHOCsBTzvx
ViumRsmrZNOzOfTLgqFyzwwmweH/VQ5z2TwWLW6iDelgxi7t8ww/uvA0VVgePqug9QzL8a9R
l8Sqr1yo0HkyocUdLoicw/yw6tgy4iMvtNUKb6NbBI5w3D33PONoOPiFMbPC903ivQZXKSyD
n57Lr1Ls0M6TFik1arM4Ye9bfxYGEb0Tmtu446eMIOJPOr0fLVhMtPRDIEzhvADIE3EidRPu
qBNcE7QqTr6sjle4fFl1LyzfZX7IWmEq0ynC6vPO6jxt9VmVb2tFV16eFrGjaX4mgdsFTogr
zOpDyrjKz/928SLtFCbSaiUU62S2+dXKk3uG+M3qQTa7s3Dg7F3846M2koltah57vz/o3wjI
WXIXZ00Qr3h31V+AAmu3VDobXV50p+qFMpmgP+sOBqNed6qoH67OzpRL8juJvXB2ObpQJ79M
psqFSK2dTwqqYiVPMOP9kCIkBgPN8a6Wl/ZfTc8FYSd8Lro/KYPu8Lx/KuH/1KFyNb3sgn+f
XH1gD06Vs+7VYJrAf1oB2KEfaTCeTqaXJXKAy+tZWcZO/lSyN0fjyxxOztDd+1nIfbF7WrzG
U7lA6hnDTgcNLMibz2xKhfcB8LE4d+GkHWGnqGzHu2fwv7/G9LA0sEnRS0wAe79Igv7tu2//
A1BLAwQUAAAACADNZiUpVZBDHQQBAACuBQAAFwBMAFh0cmFTdHVmLm1hYy9lcnJvcnMudHh0
VVQJAAXi0LQ5z9C0OU0zOwBAAAAAAABURVhUUipjaAgAYAM4bmNglGFsYGKAgwY4K3/ura1N
QAxiK8ggMANDalFRflGxXklFCQMDAGNgYGRgYGDNYGBgAWIGN4aRBzwYOH3z8xKT8xk4OmyZ
OTo6GDSWBoAkmP55/wHyDwCZbAwsDDoMZkyhTPdh9NZbc5sYGKpfQzDzJlA4skgEaSVnMDQx
8IDN9QCZwqzF5PD/4//vzJZMnlpMrBXM90AqGXUYdUCyvPqcCeAoSAGKMYJZQIY6P5SFFfw/
9P8Wby5nGwMHhiJGNqhXRizgBGIWTo/UnLLUkszkxIF2zsAAHuf8vLTMlNS8kszEnIF2zEAB
RnCOYmhgQMUMsIwGzoYMHngyGrWdg1TOMv3z/cB8CsiSAZa5jL4BwUFAtpCTU3AIkJZjfvv/
P1xjA5jtw/TPxwMAUEsBAhcHFAAAAAgAzWYlKZAf60k5FAAARYAAAAoAGwAAAAAAAQAAALaB
AAAAAGVycm9ycy50eHRVVAUABeLQtDlNMw4AQAAAAAEAVEVYVFIqY2hQSwECFwcUAAAACADN
ZiUpVZBDHQQBAACuBQAAFwAbAAAAAAAAAAAAtoGtFAAAWHRyYVN0dWYubWFjL2Vycm9ycy50
eHRVVAUABeLQtDlNMw4AQAAAAAAAVEVYVFIqY2hQSwUGAAAAAAIAAgCzAAAAMhYAAAAA
--------------EBB05EB85A82A484EE846130--




From jack@oratrix.nl  Wed Sep  6 13:25:48 2000
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 06 Sep 2000 14:25:48 +0200
Subject: [XML-SIG] Problem with Macintosh version of PyExpat
In-Reply-To: Message by Philippe de Rochambeau <pr1@club-internet.fr> ,
 Tue, 05 Sep 2000 13:01:57 +0200 , <39B4D2A4.15AC05D8@club-internet.fr>
Message-ID: <20000906122548.2FA76303181@snelboot.oratrix.nl>

If you can wait a few weeks: MacPython 2.0 will come with pyexpat in the 
standard distribution.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From martin@loewis.home.cs.tu-berlin.de  Thu Sep  7 09:24:52 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 7 Sep 2000 10:24:52 +0200
Subject: [XML-SIG] Re: Namespace collision between lib/xml and site-packages/xml
Message-ID: <200009070824.KAA01422@loewis.home.cs.tu-berlin.de>

I have a patch on SF that fixes the problem of "no parsers found" in
the current CVS. It is at

http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473

Regards,
Martin


From 5pluempe@informatik.uni-hamburg.de  Thu Sep  7 17:47:56 2000
From: 5pluempe@informatik.uni-hamburg.de (Thomas =?iso-8859-1?Q?Pl=FCmpe?=)
Date: Thu, 07 Sep 2000 18:47:56 +0200
Subject: [XML-SIG] Problems installing PyXML-0.5.5.1
Message-ID: <39B7C6BC.D133EB30@informatik.uni-hamburg.de>

Hi there,

I am having problems installing the current pyxml-
distribution. What I tried is this:
	python setup.py build
from the dir E:\PyXML-0.5.5.1 on a WinNT system.

Part of the output is:
creating build\temp.win32\Release\extensions
cl.exe /c /nologo /Ox /MD /W3 /GX \
	-IE:\Programme\Python\Include \
	/Tcextensions/sgmlop.c /Fobuild\temp \
	.win32\Release\extensions/sgmlop.obj
error: command 'cl.exe' failed: No such file or directory

This is obviously true, because the only c compiler
I have is gcc which came with the cygwin tools.

Do you have any idea on what I can do in order to get
the pyxml-distribution to work on my system?

Thanks, Thomas


PS: The complete output (there were some warnings, I
thought this might be of interest):
running build
running build_py
creating build
creating build\lib.win32
creating build\lib.win32\xml
copying xml\__init__.py -> build\lib.win32\xml
copying xml\_checkversion.py -> build\lib.win32\xml
creating build\lib.win32\xml\dom
copying xml\dom\__init__.py -> build\lib.win32\xml\dom
copying xml\dom\builder.py -> build\lib.win32\xml\dom
copying xml\dom\core.py -> build\lib.win32\xml\dom
copying xml\dom\esis_builder.py -> build\lib.win32\xml\dom
copying xml\dom\html_builder.py -> build\lib.win32\xml\dom
copying xml\dom\sax_builder.py -> build\lib.win32\xml\dom
copying xml\dom\transform.py -> build\lib.win32\xml\dom
copying xml\dom\transformer.py -> build\lib.win32\xml\dom
copying xml\dom\utils.py -> build\lib.win32\xml\dom
copying xml\dom\walker.py -> build\lib.win32\xml\dom
copying xml\dom\writer.py -> build\lib.win32\xml\dom
creating build\lib.win32\xml\marshal
copying xml\marshal\__init__.py -> build\lib.win32\xml\marshal
copying xml\marshal\generic.py -> build\lib.win32\xml\marshal
copying xml\marshal\wddx.py -> build\lib.win32\xml\marshal
copying xml\marshal\xmlrpc.py -> build\lib.win32\xml\marshal
creating build\lib.win32\xml\parsers
copying xml\parsers\__init__.py -> build\lib.win32\xml\parsers
copying xml\parsers\sgmllib.py -> build\lib.win32\xml\parsers
warning: build_py: package init file 'xml\parsers\xmlproc\__init__.py' not found (or not a regular file)
creating build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\catalog.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\charconv.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\dtdparser.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\errors.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\namespace.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\xcatalog.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\xmlapp.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\xmldtd.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\xmlproc.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\xmlutils.py -> build\lib.win32\xml\parsers\xmlproc
copying xml\parsers\xmlproc\xmlval.py -> build\lib.win32\xml\parsers\xmlproc
creating build\lib.win32\xml\sax
copying xml\sax\__init__.py -> build\lib.win32\xml\sax
copying xml\sax\saxexts.py -> build\lib.win32\xml\sax
copying xml\sax\saxlib.py -> build\lib.win32\xml\sax
copying xml\sax\saxutils.py -> build\lib.win32\xml\sax
copying xml\sax\writer.py -> build\lib.win32\xml\sax
creating build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\__init__.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_htmllib.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_ltdriver.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_ltdriver_val.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_pyexpat.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_sgmllib.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_sgmlop.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_xmldc.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_xmllib.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_xmlproc.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_xmlproc_val.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\drv_xmltoolkit.py -> build\lib.win32\xml\sax\drivers
copying xml\sax\drivers\pylibs.py -> build\lib.win32\xml\sax\drivers
creating build\lib.win32\xml\unicode
copying xml\unicode\__init__.py -> build\lib.win32\xml\unicode
copying xml\unicode\iso8859.py -> build\lib.win32\xml\unicode
copying xml\unicode\wstremul.py -> build\lib.win32\xml\unicode
copying xml\unicode\wstring.py -> build\lib.win32\xml\unicode
creating build\lib.win32\xml\utils
copying xml\utils\__init__.py -> build\lib.win32\xml\utils
copying xml\utils\iso8601.py -> build\lib.win32\xml\utils
copying xml\utils\qp_xml.py -> build\lib.win32\xml\utils
running build_ext
warning: build_ext: old-style (ext_name, build_info) tuple found in ext_modules for extension 'sgmlop'-- please convert to Extension instance
warning: build_ext: old-style (ext_name, build_info) tuple found in ext_modules for extension 'xml.unicode.wstrop'-- please convert to Extension instance
warning: build_ext: old-style (ext_name, build_info) tuple found in ext_modules for extension 'xml.parsers.pyexpat'-- please convert to Extension instance
building 'sgmlop' extension
creating build\temp.win32
creating build\temp.win32\Release
creating build\temp.win32\Release\extensions
cl.exe /c /nologo /Ox /MD /W3 /GX -IE:\Programme\Python\Include /Tcextensions/sgmlop.c /Fobuild\temp.win32\Release\extensions/sgmlop.obj
error: command 'cl.exe' failed: No such file or directory

E:\PyXML-0.5.5.1>


From martin@loewis.home.cs.tu-berlin.de  Fri Sep  8 07:23:31 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 8 Sep 2000 08:23:31 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
Message-ID: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de>

I just noticed that it appears to be very difficult to write code that
works both with the Python 2.0 XML package and with the PyXML CVS code.

For example, in CVS, to find create a SAX parser, you do

import xml.sax.saxexts
p = xml.sax.saxexts.make_parser()

In Python 2.0, saxexts is not supported. Instead, you have to know
that the expatreader is there, so you write

import xml.sax.expatreader
p = xml.sax.expatreader.ExpatParser()

That, in turn, won't work in PyXML, as it does not have the
expatreader module.

Alternatively, in Python 2.0, you can write

import xml.sax
xml.sax.parse(file, MyHandler())

Again, that won't work in PyXML: xml.sax does not have the parse
function.

Same goes for dom. To create a DOM tree with the current CVS, you
write

from xml.dom.ext.reader import Sax
doc = Sax.FromXmlStream(file)

That won't work with Python 2. Instead, there you write

import xml.dom.minidom
doc = xml.dom.minidom.parse(file)

Is there hope that there can be a common API that works with both
Python 2.0 and PyXML?

Regards,
Martin



From uche.ogbuji@fourthought.com  Fri Sep  8 18:02:37 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Fri, 08 Sep 2000 11:02:37 -0600
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: Message from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
 of "Fri, 08 Sep 2000 08:23:31 +0200." <200009080623.IAA00857@loewis.home.cs.tu-berlin.de>
Message-ID: <200009081702.LAA08275@localhost.localdomain>

> Same goes for dom. To create a DOM tree with the current CVS, you
> write
> 
> from xml.dom.ext.reader import Sax
> doc = Sax.FromXmlStream(file)
> 
> That won't work with Python 2. Instead, there you write
> 
> import xml.dom.minidom
> doc = xml.dom.minidom.parse(file)
> 
> Is there hope that there can be a common API that works with both
> Python 2.0 and PyXML?

Actually, 4DOM (which comes with PyXML) is just minidom's "big brother".  It 
is a conscious decision to migrate.  minidom probably isn't yet in the PyXML 
CVS because Paul has been busy with the Python 2.0 work.  It should go into 
the PyXML distro soon so that people can use minidom in all cases, and can 
migrate to 4DOM if they need to.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From prescod@prescod.net  Fri Sep  8 18:49:04 2000
From: prescod@prescod.net (Paul)
Date: Fri, 8 Sep 2000 12:49:04 -0500 (CDT)
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <200009081702.LAA08275@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0009081236020.16116-100000@amati.techno.com>

On Fri, 8 Sep 2000 uche.ogbuji@fourthought.com wrote:
> ...
> Actually, 4DOM (which comes with PyXML) is just minidom's "big brother".  It 
> is a conscious decision to migrate.  minidom probably isn't yet in the PyXML 
> CVS because Paul has been busy with the Python 2.0 work.

Actually, it turns out that I've been more busy with a new job, a move
across the country (yes, U-Haul is a moving adventure!), and a new
edition of a book. Python 2 hasn't got enough attention either: I hope to
fix that this weekend. I have some known bugs that I need to fix and test
suites to write so that we won't have any more in the future.

>  It should go into 
> the PyXML distro soon so that people can use minidom in all cases, and can 
> migrate to 4DOM if they need to.

I'll think about this. If you need Python to use PyXML, what's the point
of putting minidom in both places?

 Paul Prescod




From uche.ogbuji@fourthought.com  Fri Sep  8 18:59:36 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Fri, 08 Sep 2000 11:59:36 -0600
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: Message from Paul <prescod@prescod.net>
 of "Fri, 08 Sep 2000 12:49:04 CDT." <Pine.LNX.4.21.0009081236020.16116-100000@amati.techno.com>
Message-ID: <200009081759.LAA08467@localhost.localdomain>

> >  It should go into 
> > the PyXML distro soon so that people can use minidom in all cases, and can 
> > migrate to 4DOM if they need to.
> 
> I'll think about this. If you need Python to use PyXML, what's the point
> of putting minidom in both places?

Only for support of Python 1.5 and 1.6.  Or does 1.6 have minidom built in as 
well?

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From bbum@codefab.com  Fri Sep  8 19:35:38 2000
From: bbum@codefab.com (Bill Bumgarner)
Date: Fri, 8 Sep 2000 14:35:38 -0400
Subject: [XML-SIG] 1.6 vs. PyXML build question
Message-ID: <200009081838.e88IcwM25356@bjork.codefab.com>

Hi!

	I'm building PyXML on Mac OS X Server against Python 1.6 with dynamic  
loading enabled.

	Unfortunately, the pyexpat.so includes the symbol _main which  
conflicts with the _main symbol in the python executable.   It appears that the  
symbol in pyexpat.so is coming from xmlwf.c in that the XML_UNICODE #define is  
not defined.

	Maybe it shouldn't be, but one of the side effects is that xmlwf  
defines a main() function if that IS NOT defined.... causing the dynamic link  
error later.  I redefined main() to wmain() by hand and the system appears to  
work as expected.

	b.bum


	


From fdrake@beopen.com  Fri Sep  8 21:09:53 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 8 Sep 2000 16:09:53 -0400 (EDT)
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <Pine.LNX.4.21.0009081236020.16116-100000@amati.techno.com>
References: <200009081702.LAA08275@localhost.localdomain>
 <Pine.LNX.4.21.0009081236020.16116-100000@amati.techno.com>
Message-ID: <14777.18321.457342.757978@cj42289-a.reston1.va.home.com>

Paul writes:
 > I'll think about this. If you need Python to use PyXML, what's the point
 > of putting minidom in both places?

  The current plan is for the PyXML package to *replace* the "stock"
XML support delivered with Python (possibly excepting pyexpat).
(xmllib is not included in this; only the xml package.)
  Thhe purpose of this is to allow the PyXML package to fix any bugs
and avoid versioning issues within the xml.* namespace.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Fri Sep  8 21:11:34 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 8 Sep 2000 16:11:34 -0400 (EDT)
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <200009081759.LAA08467@localhost.localdomain>
References: <prescod@prescod.net>
 <Pine.LNX.4.21.0009081236020.16116-100000@amati.techno.com>
 <200009081759.LAA08467@localhost.localdomain>
Message-ID: <14777.18422.874657.856188@cj42289-a.reston1.va.home.com>

uche.ogbuji@fourthought.com writes:
 > Only for support of Python 1.5 and 1.6.  Or does 1.6 have minidom
 > built in as well?

  Python 1.6 only has xmllib and pyexpat.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From martin@loewis.home.cs.tu-berlin.de  Fri Sep  8 23:54:26 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 9 Sep 2000 00:54:26 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <200009081702.LAA08275@localhost.localdomain>
 (uche.ogbuji@fourthought.com)
References: <200009081702.LAA08275@localhost.localdomain>
Message-ID: <200009082254.AAA00971@loewis.home.cs.tu-berlin.de>

> Actually, 4DOM (which comes with PyXML) is just minidom's "big brother".  It 
> is a conscious decision to migrate.  minidom probably isn't yet in the PyXML 
> CVS because Paul has been busy with the Python 2.0 work.  It should go into 
> the PyXML distro soon so that people can use minidom in all cases, and can 
> migrate to 4DOM if they need to.

That sounds very good. The other question is then about a consistent
SAX API.

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Fri Sep  8 23:55:31 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 9 Sep 2000 00:55:31 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <Pine.LNX.4.21.0009081236020.16116-100000@amati.techno.com>
 (message from Paul on Fri, 8 Sep 2000 12:49:04 -0500 (CDT))
References: <Pine.LNX.4.21.0009081236020.16116-100000@amati.techno.com>
Message-ID: <200009082255.AAA00972@loewis.home.cs.tu-berlin.de>

> I'll think about this. If you need Python to use PyXML, what's the point
> of putting minidom in both places?

Applications using 4DOM don't need minidom, of course. However, on the
same system, applications built with minidom will stop working when
PyXML is installed.

Regards,
Martin



From uche.ogbuji@fourthought.com  Mon Sep 11 09:26:31 2000
From: uche.ogbuji@fourthought.com (Uche Ogbuji)
Date: Mon, 11 Sep 2000 02:26:31 -0600
Subject: [XML-SIG] Re: [4suite] Output encodings again
References: <871yzla17z.fsf@psyche.evansnet>
Message-ID: <39BC9737.C302C19C@fourthought.com>

Bet you thought we forgot, eh?

Carey Evans wrote:

> At least for XML output where we can expect some consistency among
> parsers, as few characters should be encoded as &#xxx; as possible.
> It should only be necessary to do this if the character doesn't exist
> in the output encoding.

Thanks again for all the bug-reports.  I've devoted several hours to
your comments alongside Tony Graham's Unicode book, the C code for the
Python wstrop module and the 4Suite code.

I think I've addressed the core bug you uncovered, but I need a bit of
help to go the rest of the way.

Currently, on output to XML (and HTML), we first convert the UTF-8 that
the DOM uses into Martin von Lowis's wchar type.  Then we use wstring to
convert from wchar to, say, ISO-8859-2.  The problem is that if there
are characters in the DOM that have no ISO-8859-2 representation, wstrop
only gives us two choices: throw an exception without any data about
where the offending character was, or skip it entirely.

So I'm rather at a loss as to how to efficiently escape such characters
for XML output.  I know I want to render them as &#???;, but every
method I see for doing so is rather wasteful.

Of course with Python 2.0 we can just use Python's unicode type for the
DOMString so hopefully this problem would tend to go away, no?

Does anyone on xml-sig catch my drift?  Am I missing some capabilities
of wstrop?  Should I just hang on a few more months for Python 2.0?


> For HTML it may be necessary to escape some characters, given web
> browsers' tendency to try to guess encodings.  I guess this is what
> the text at the bottom of TextWriter.py is talking about.

I think I've made the writers much smarter for HTML.  4Suite will now
respect most encodings, besides the problem I mention above, and turn
characters from &#160; to &#255; into the equivalent HTML entities (e.g.
&#160; -> &nbsp).

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python


From alf@logilab.com  Mon Sep 11 08:56:35 2000
From: alf@logilab.com (Alexandre Fayolle)
Date: Mon, 11 Sep 2000 09:56:35 +0200 (CEST)
Subject: [XML-SIG] Sax2.FromXml 'feature'
Message-ID: <Pine.LNX.4.21.0009110947140.10407-100000@leo.logilab.fr>

Hi there,

I'm experiencing what I think is a weird behaviour of Sax2.FromXml(). If
you consider the following :

from xml.dom.ext.reader import Sax2

document = Sax2.FromXml('<doc/>')
fragment = Sax2.FromXml('<frag/>',document)

In the previous example, fragment is a document fragment that has document
as ownerDocument.

Now if I change the last line of the previous example to:

fragment = Sax2.FromXml('<frag/><frag/>',document)

I get an SAXParseException: Elements not allowed outside root element at 
Unknown:1:12

Am I missing something ? How can I get a document fragment from some xml
text ?



-- 
Alexandre Fayolle
Logilab



From larsga@garshol.priv.no  Mon Sep 11 09:52:20 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 11 Sep 2000 10:52:20 +0200
Subject: [XML-SIG] Sax2.FromXml 'feature'
In-Reply-To: <Pine.LNX.4.21.0009110947140.10407-100000@leo.logilab.fr>
References: <Pine.LNX.4.21.0009110947140.10407-100000@leo.logilab.fr>
Message-ID: <m3vgw3payj.fsf@lambda.garshol.priv.no>

* Alexandre Fayolle
| 
| Now if I change the last line of the previous example to:
| 
| fragment = Sax2.FromXml('<frag/><frag/>',document)
| 
| I get an SAXParseException: Elements not allowed outside root element at 
| Unknown:1:12

As far as I can tell, this causes the DOM builder to hand the string
to xmlproc for parsing, and xmlproc correctly complains that this XML
document (it has no idea it is parsing only a fragment) contains
markup outside the root element (the first element). 

It would be very easy to add an option to xmlproc that would allow
clients to tell it that it is parsing XML document fragments. We could
also add this as a SAX 2.0 feature. However, this might open to abuse
and parsing of strings that are not well-formed XML. 

An alternative might be for this function to add a fake container
element around the string to avoid this problem. Opinions, anyone?

--Lars M.



From Jacco.van.Ossenbruggen@cwi.nl  Mon Sep 11 12:25:01 2000
From: Jacco.van.Ossenbruggen@cwi.nl (J.R. van Ossenbruggen)
Date: Mon, 11 Sep 2000 13:25:01 +0200
Subject: [XML-SIG] Q: minidom and iso-8859-1
Message-ID: <200009111125.NAA24547@mast.cwi.nl>

I used minidom/pyexpat/python 2.0b1 to parse an xml file that starts
with:

     <?xml version="1.0" encoding='iso-8859-1'?>

When I try to print the nodeValues that contain non-ascii chars, I get:

     UnicodeError: ASCII encoding error: ordinal not in range(128)

Explicitly converting the value using value.encode('iso-8859-1')
before printing seems to do the trick.  But how can I, in general,
find out what the original encoding of the XML file was?  E.g. what if
I want to use the same program for XML files that use different
encodings?

BTW, I expected that converting to UTF-8 would also print the right
result, but it didn't.  What am I missing here?

Thanks,

-- Jacco 


From Mike.Olson@fourthought.com  Mon Sep 11 17:52:42 2000
From: Mike.Olson@fourthought.com (Mike Olson)
Date: Mon, 11 Sep 2000 10:52:42 -0600
Subject: [XML-SIG] Sax2.FromXml 'feature'
References: <Pine.LNX.4.21.0009110947140.10407-100000@leo.logilab.fr> <m3vgw3payj.fsf@lambda.garshol.priv.no>
Message-ID: <39BD0DDA.BE5A1036@FourThought.com>

Lars Marius Garshol wrote:
> 
> * Alexandre Fayolle
> |
> | Now if I change the last line of the previous example to:
> |
> | fragment = Sax2.FromXml('<frag/><frag/>',document)
> |
> | I get an SAXParseException: Elements not allowed outside root element at
> | Unknown:1:12
> 
> As far as I can tell, this causes the DOM builder to hand the string
> to xmlproc for parsing, and xmlproc correctly complains that this XML
> document (it has no idea it is parsing only a fragment) contains
> markup outside the root element (the first element).
> 
> It would be very easy to add an option to xmlproc that would allow
> clients to tell it that it is parsing XML document fragments. We could
> also add this as a SAX 2.0 feature. However, this might open to abuse
> and parsing of strings that are not well-formed XML.
> 
> An alternative might be for this function to add a fake container
> element around the string to avoid this problem. Opinions, anyone?

I like the fake container idea.  If a user passes in a document, the
reader will wrap it with a container and unwrap it on output.

Mike

> 
> --Lars M.
> 
> _______________________________________________
> XML-SIG maillist  -  XML-SIG@python.org
> http://www.python.org/mailman/listinfo/xml-sig

-- 
Mike Olson				 Principal Consultant
mike.olson@fourthought.com               (303)583-9900 x 102
Fourthought, Inc.                         http://Fourthought.com 
Software-engineering, knowledge-management, XML, CORBA, Linux, Python


From michael.easter@excite.com  Mon Sep 11 17:27:54 2000
From: michael.easter@excite.com (michael.easter@excite.com)
Date: Mon, 11 Sep 2000 09:27:54 -0700 (PDT)
Subject: [XML-SIG] consolidation?
Message-ID: <19260148.968689674819.JavaMail.imail@digger.excite.com>

Hi there,

I have recently discovered Python and am really enjoying it (it is
amazing!).  Having an interest in XML as well, I'm naturally interested in
the combination of the two.

However, from the outside, there seems to be a _lot_ of different XML tools
for Python.  I can't help but wonder if there is too much overlap in some of
the projects.  Is this just me, or does anyone else feel the same way?

On a related note, is there any talk of having a Python wrapper around
Xerces?

thanks,
Mike

ps. Please note that I don't mean to criticize the good work that has been
done.  I also don't mean to seem ungrateful for the _free_ tools that have
been created through the hard work of others. This note is just an
observation in trying to help world domination.





_______________________________________________________
Say Bye to Slow Internet!
http://www.home.com/xinbox/signup.html



From martin@loewis.home.cs.tu-berlin.de  Mon Sep 11 23:49:07 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 12 Sep 2000 00:49:07 +0200
Subject: [XML-SIG] Q: minidom and iso-8859-1
In-Reply-To: <200009111125.NAA24547@mast.cwi.nl>
 (Jacco.van.Ossenbruggen@cwi.nl)
References: <200009111125.NAA24547@mast.cwi.nl>
Message-ID: <200009112249.AAA00802@loewis.home.cs.tu-berlin.de>

> BTW, I expected that converting to UTF-8 would also print the right
> result, but it didn't.  What am I missing here?

Hard to say. Converting to UTF-8 will print the right result, which
result did you get?

Regards,
Martin



From martin@loewis.home.cs.tu-berlin.de  Mon Sep 11 23:48:15 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 12 Sep 2000 00:48:15 +0200
Subject: [XML-SIG] Re: [4suite] Output encodings again
In-Reply-To: <39BC9737.C302C19C@fourthought.com> (message from Uche Ogbuji on
 Mon, 11 Sep 2000 02:26:31 -0600)
References: <871yzla17z.fsf@psyche.evansnet> <39BC9737.C302C19C@fourthought.com>
Message-ID: <200009112248.AAA00801@loewis.home.cs.tu-berlin.de>

[for i18n readers: the issue is to convert u"\u000A9\u01A9" to latin-1,
 so that it comes out as "\251&#1A9;"]

> Currently, on output to XML (and HTML), we first convert the UTF-8 that
> the DOM uses into Martin von Lowis's wchar type.  

It may be the time to slowly retire this type. It is still needed for
1.5 installations, but the 1.6/2.0 type has a comparable feature set
yet an interface that is here to stay; plus it offers quite some
additional feature.

Still, I believe it shares this problem with my type.

> So I'm rather at a loss as to how to efficiently escape such characters
> for XML output.  I know I want to render them as &#???;, but every
> method I see for doing so is rather wasteful.

In principle, the approach should be introduce new encodings. That is,
you get latin-1-xml, latin-2-xml, koi-8r-xml, utf-8-xml, and so on.

These encodings are the same as the original ones, except that they
have different error handling. This approach is possible both with my
type and with the 2.0 type - however, implementing these encodings is
quite some effort.

I'm sure you've thought of the approach to catch the exception, then
retry with a smaller string. That may not be too bad - it requires a
binary search to work efficiently. E.g.

def latin1_xml(str):
    try:
        result = result + str.encode("latin-1")
    except UnicodeError:
        if len(str)==1:
            return "&%x;" % ord(str)
        m = len(str)/2
        return latin1_xml(str[:m]) + latin1_xml(str[m:])

It could be implemented more efficiently if the UnicodeError told at
what offset exactly the problem occured, or at least what character
was causing the problem, e.g.

def latin1_xml(str):
    try:
        result = result + str.encode("latin-1")
    except UnicodeError,e:
        if len(str)==1:
            return "&%x;" % ord(str)
        m = str.find(e.bad_char)
	r = "&%x;" % e.bad_char
        return latin1_xml(str[:m-1]) + r + % e.bad_charlatin1_xml(str[m+1:])

I think such an advanced error reporting could be useful; it is
questionable whether it could go into 2.0 if implemented. In any case,
it would probably be reasonable not to require a bad_char attribute in
every UnicodeError instance - perhaps UnicodeError must be further
subclassed:

def latin1_xml(str):
    try:
        result = result + str.encode("latin-1")
    except ConversionError,e:
        m = e.offset
	r = "&%x;" % e.bad_char
        return latin1_xml(str[:m-1]) + r + % e.bad_charlatin1_xml(str[m+1:])
    except UnicodeError,e:
        if len(str)==1:
            return "&%x;" % ord(str)
        m = len(str)/2
        return latin1_xml(str[:m]) + latin1_xml(str[m:])

Regards,
Martin


From frank63@ms5.hinet.net  Tue Sep 12 12:17:14 2000
From: frank63@ms5.hinet.net (Frank J.S. Chen)
Date: Tue, 12 Sep 2000 11:17:14 -0000
Subject: Fw: [XML-SIG] consolidation?
Message-ID: <200009120317.LAA19649@ms5.hinet.net>

> 
> However, from the outside, there seems to be a _lot_ of different XML
tools
> for Python.  I can't help but wonder if there is too much overlap in some
of
> the projects.  Is this just me, or does anyone else feel the same way?
> 
> On a related note, is there any talk of having a Python wrapper around
> Xerces?

You can use JPython as a wrapper to use Xerces' jar class, 
but the performance is still a matter.

'A lot of tools' is a good thing I think, but the question is where it can
go far.



From Jacco.van.Ossenbruggen@cwi.nl  Tue Sep 12 09:11:45 2000
From: Jacco.van.Ossenbruggen@cwi.nl (J.R. van Ossenbruggen)
Date: Tue, 12 Sep 2000 10:11:45 +0200
Subject: [XML-SIG] Q: minidom and iso-8859-1
In-Reply-To: Your message of "Tue, 12 Sep 2000 00:49:07 +0200."
 <200009112249.AAA00802@loewis.home.cs.tu-berlin.de>
Message-ID: <200009120811.KAA02382@mast.cwi.nl>

On Tue, Sep 12 2000 "Martin v. Loewis" wrote:
> > BTW, I expected that converting to UTF-8 would also print the right
> > result, but it didn't.  What am I missing here?
> 
> Hard to say. Converting to UTF-8 will print the right result, which
> result did you get?

# Input file test.xml:
#
#  <?xml version="1.0" encoding='iso-8859-1'?>
#  <test>Grønbæck</test>"""

import sys
import xml.dom.minidom
p=xml.dom.minidom.parse('test.xml')

print p.documentElement.childNodes[0].nodeValue.encode('UTF-8')
# wrong; prints: Grønbæck

print p.documentElement.childNodes[0].nodeValue.encode('iso-8859-1')
# right; prints: Grønbæck

-- Jacco 


From Jacco.van.Ossenbruggen@cwi.nl  Tue Sep 12 09:37:00 2000
From: Jacco.van.Ossenbruggen@cwi.nl (J.R. van Ossenbruggen)
Date: Tue, 12 Sep 2000 10:37:00 +0200
Subject: [XML-SIG] Q: minidom and iso-8859-1
In-Reply-To: Your message of "Tue, 12 Sep 2000 10:11:45 +0200."
Message-ID: <200009120837.KAA02473@mast.cwi.nl>

On Tue, Sep 12 2000 "J.R. van Ossenbruggen" wrote:
> On Tue, Sep 12 2000 "Martin v. Loewis" wrote:
> > > BTW, I expected that converting to UTF-8 would also print the right
> > > result, but it didn't.  What am I missing here?
> > 
> > Hard to say. Converting to UTF-8 will print the right result, which
> > result did you get?
>
> # Input file test.xml:
> #
> #  <?xml version="1.0" encoding='iso-8859-1'?>
> #  <test>Grønbæck</test>"""
> 
> import sys
> import xml.dom.minidom
> p=xml.dom.minidom.parse('test.xml')
> 
> print p.documentElement.childNodes[0].nodeValue.encode('UTF-8')
> # wrong; prints: Grønbæck

Oops, I think I begin to understand what is going on.  The UTF-8
indeed prints the right result, it was just not the result I (encoding
newbie) expected.

I think I just asked myself the wrong question (how was the original
XML encoded) while I should have asked myself in what encoding I want
to have the output in.

Jacco


From Jacco.van.Ossenbruggen@cwi.nl  Tue Sep 12 13:47:39 2000
From: Jacco.van.Ossenbruggen@cwi.nl (J.R. van Ossenbruggen)
Date: Tue, 12 Sep 2000 14:47:39 +0200
Subject: [XML-SIG] another python2 xml Q: minidom thinks pi is doc element?
Message-ID: <200009121247.OAA04454@mast.cwi.nl>

Hi,

It seems that minidom does not recognize my processing instruction.
(I need PIs because I want to process my XML files in Cocoon too...)

Note the error comes from minidom, not expat.

	Jacco

s="""<?xml version='1.0'?><?pi-foobar?><test></test>"""

import xml.dom.minidom
p=xml.dom.minidom.parseString(s)

stack_trace="""
Traceback (most recent call last):
  File "test.py", line 6, in ?
    p=xml.dom.minidom.parseString(s)
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 45
2, in parseString
    return _doparse( pulldom.parseString, args, kwargs )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 44
3, in _doparse
    events.expandNode( rootNode )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/pulldom.py", line 14
2, in expandNode
    cur_node.parentNode.appendChild( cur_node )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 40
0, in appendChild
    raise TypeError, "Two document elements disallowed"
TypeError: Two document elements disallowed
"""



From mal@lemburg.com  Tue Sep 12 13:30:36 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 12 Sep 2000 14:30:36 +0200
Subject: [XML-SIG] Re: [4suite] Output encodings again
References: <871yzla17z.fsf@psyche.evansnet> <39BC9737.C302C19C@fourthought.com> <200009112248.AAA00801@loewis.home.cs.tu-berlin.de>
Message-ID: <39BE21EB.842A066F@lemburg.com>

"Martin v. Loewis" wrote:
> 
> [for i18n readers: the issue is to convert u"\u000A9\u01A9" to latin-1,
>  so that it comes out as "\251&#1A9;"]
> 
> > Currently, on output to XML (and HTML), we first convert the UTF-8 that
> > the DOM uses into Martin von Lowis's wchar type.
> 
> It may be the time to slowly retire this type. It is still needed for
> 1.5 installations, but the 1.6/2.0 type has a comparable feature set
> yet an interface that is here to stay; plus it offers quite some
> additional feature.
> 
> Still, I believe it shares this problem with my type.
> 
> > So I'm rather at a loss as to how to efficiently escape such characters
> > for XML output.  I know I want to render them as &#???;, but every
> > method I see for doing so is rather wasteful.
> 
> In principle, the approach should be introduce new encodings. That is,
> you get latin-1-xml, latin-2-xml, koi-8r-xml, utf-8-xml, and so on.
> 
> These encodings are the same as the original ones, except that they
> have different error handling. This approach is possible both with my
> type and with the 2.0 type - however, implementing these encodings is
> quite some effort.

It's not really all that hard to write codecs for Python 2.0.

You'll have to do two things:
1. write the codec by subclassing the base classes in codecs.py
2. write a search function which returns the needed constructors
   and functions.

You will then have to register the search function using the APIs
in codecs.py. After having done that, the codec will be accessible via
the usual 2.0 methods, e.g. .encode() and unicode().

Documentation is available in codecs.py itself, the various codecs
in the encodings/ package directory and Misc/unicode.txt.

For a good pure-Python implementation built using these techniques
have a look at the Japanese codecs which were recently announced
on the i18n sig-list.

-- 
Marc-Andre Lemburg
________________________________________________________________________
Business:                                        http://www.lemburg.com/
Python Pages:                             http://www.lemburg.com/python/



From andorxor@gmx.de  Tue Sep 12 17:26:34 2000
From: andorxor@gmx.de (Stephan Tolksdorf)
Date: Tue, 12 Sep 2000 18:26:34 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
Message-ID: <935085382.20000912182634@email.com>

Hello,

could someone please explain the status of the sax-code in python2.
I just tried to parse a simple xml-file with expatreader and I
had to modify the source just to get the parsing started...
and I didn't succeed.
Is the code in python2-cvs thought to be usable and what's the
relation to the code on http://www.garshol.priv.no/download/
software/saxlib/sax2/.

Have I missed something?

Best regards,
  Stephan Tolksdorf




From paul@prescod.net  Tue Sep 12 18:43:04 2000
From: paul@prescod.net (Paul Prescod)
Date: Tue, 12 Sep 2000 10:43:04 -0700
Subject: [XML-SIG] consolidation?
References: <19260148.968689674819.JavaMail.imail@digger.excite.com>
Message-ID: <39BE6B28.B44F96DB@prescod.net>

michael.easter@excite.com wrote:
> 
> Hi there,
> 
> I have recently discovered Python and am really enjoying it (it is
> amazing!).  Having an interest in XML as well, I'm naturally interested in
> the combination of the two.
> 
> However, from the outside, there seems to be a _lot_ of different XML tools
> for Python.  I can't help but wonder if there is too much overlap in some of
> the projects.  Is this just me, or does anyone else feel the same way?

I think that for a beginner trying to find their way through it is
probably intimidating. Nevertheless it is just the way things happen in
open source communities. Java and Perl have the same problems even
worse. I suggest that any language that does not have that problem
probably does not have an enthusiastic user community. People think
about XML processing in so many different ways that the last time I
tried to merge two projects we simply didn't have any success
communicating with each other.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From akuchlin@mems-exchange.org  Tue Sep 12 19:05:05 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 12 Sep 2000 14:05:05 -0400
Subject: [XML-SIG] consolidation?
In-Reply-To: <39BE6B28.B44F96DB@prescod.net>; from paul@prescod.net on Tue, Sep 12, 2000 at 10:43:04AM -0700
References: <19260148.968689674819.JavaMail.imail@digger.excite.com> <39BE6B28.B44F96DB@prescod.net>
Message-ID: <20000912140505.A17994@kronos.cnri.reston.va.us>

On Tue, Sep 12, 2000 at 10:43:04AM -0700, Paul Prescod wrote:
>probably does not have an enthusiastic user community. People think
>about XML processing in so many different ways that the last time I
>tried to merge two projects we simply didn't have any success
>communicating with each other.

On the other hand, integration work on the PyXML package has stalled;
I don't have time to do it, and this situation seems unlikely to
change for a while to come.  No one else has stepped forward to do
anything about this, either; it's a sad situation, but there seems
little that can be done about it.

--amk


From fdrake@beopen.com  Tue Sep 12 19:24:03 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 12 Sep 2000 14:24:03 -0400 (EDT)
Subject: [XML-SIG] consolidation?
In-Reply-To: <20000912140505.A17994@kronos.cnri.reston.va.us>
References: <19260148.968689674819.JavaMail.imail@digger.excite.com>
 <39BE6B28.B44F96DB@prescod.net>
 <20000912140505.A17994@kronos.cnri.reston.va.us>
Message-ID: <14782.29891.720158.635671@cj42289-a.reston1.va.home.com>

Andrew Kuchling writes:
 > On the other hand, integration work on the PyXML package has stalled;
 > I don't have time to do it, and this situation seems unlikely to
 > change for a while to come.  No one else has stepped forward to do
 > anything about this, either; it's a sad situation, but there seems
 > little that can be done about it.

  I plan to take a look at it, but it won't be until next week.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From frank63@ms5.hinet.net  Wed Sep 13 14:39:22 2000
From: frank63@ms5.hinet.net (Frank J.S. Chen)
Date: Wed, 13 Sep 2000 13:39:22 -0000
Subject: Fw: [XML-SIG] consolidation?
Message-ID: <200009130539.NAA26841@ms5.hinet.net>

> 
> 
> Andrew Kuchling writes:
>  > On the other hand, integration work on the PyXML package has stalled;
>  > I don't have time to do it, and this situation seems unlikely to
>  > change for a while to come.  No one else has stepped forward to do
>  > anything about this, either; it's a sad situation, but there seems
>  > little that can be done about it.
> 
>   I plan to take a look at it, but it won't be until next week.

And another problem...

PyXML doesn't conform to the specifications. Xmlproc's methods and
mechanisms 
for SAX parsing don't follow the SAX standard and this will be a problem
for people 
who want to use Python as a XML solution. Because one has to re-learn all
the 
methodology that xmlproc offers. I cannot write an application for parsing
with just the 
knowledge of the core Python language and the SAX standard.We can use
drv_xmlproc
or drv_pyexpat as a top-layer to solve this problem, though, but this will
still stop people 
who want to use both Java and Python to write XML-aware applications; they
will choose
Java first and even JPython.

The DOM implementation has the same problem:the method has its special
name.
As I write applications with it, I have to reference its code all the time.

These are, truely, all great works in PyXML package, but as for longevity,
I think it better
to follow and keep with the standard. Microsofts wanted to break the law,
but they 
failed in law.

Frank Chen



From larsga@garshol.priv.no  Wed Sep 13 08:39:06 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 13 Sep 2000 09:39:06 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <935085382.20000912182634@email.com>
References: <935085382.20000912182634@email.com>
Message-ID: <m3u2bkoi5h.fsf@lambda.garshol.priv.no>

* Stephan Tolksdorf
| 
| could someone please explain the status of the sax-code in python2.

It is on the verge of being updated and finalized, but so far it has
not been.  I've done quite a bit of work on it that hasn't been
checked in yet, but this is all marooned on my home computer whose
monitor has given up the ghost.  I will hopefully get this fixed soon,
and then the SAX 2.0 code in the Python 2.0 distribution should be
updated fairly soon after that.

| Is the code in python2-cvs thought to be usable 

No, not really.

| and what's the relation to the code on
| http://www.garshol.priv.no/download/ software/saxlib/sax2/.

This is an earlier version, from before the decision to include SAX
2.0 in the Python 2.0 distribution.
 
--Lars M.



From larsga@garshol.priv.no  Wed Sep 13 08:44:57 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 13 Sep 2000 09:44:57 +0200
Subject: [XML-SIG] consolidation?
In-Reply-To: <200009130539.NAA26841@ms5.hinet.net>
References: <200009130539.NAA26841@ms5.hinet.net>
Message-ID: <m3snr4ohvq.fsf@lambda.garshol.priv.no>

* Frank J. S. Chen
| 
| PyXML doesn't conform to the specifications. Xmlproc's methods and
| mechanisms for SAX parsing don't follow the SAX standard and this
| will be a problem for people who want to use Python as a XML
| solution. 

There are two reasons for this, the most important being that xmlproc
is older than SAX, and so obviously could not start out with a SAX
interface. Secondly, the xmlproc APIs still offer a lot of
functionality that SAX does not, although once SAX 2.0 is finalized it
could conceivably start using a SAX 2.0 interface. 

The problem is that there are a quite a few users out there that use
the old interface, and I don't want to break their applications by
changing my interfaces. Nor do I see much of a need, since SAX
provides a SAX-based interface to xmlproc.

| I cannot write an application for parsing with just the knowledge of
| the core Python language and the SAX standard. We can use
| drv_xmlproc or drv_pyexpat as a top-layer to solve this problem,
| though, but this will still stop people who want to use both Java
| and Python to write XML-aware applications; they will choose Java
| first and even JPython.

Why do you think so?  Once you know SAX there is no reason to even
discover that xmlproc and pyexpat have different interfaces.
 
--Lars M.



From alf@logilab.com  Wed Sep 13 08:48:18 2000
From: alf@logilab.com (Alexandre Fayolle)
Date: Wed, 13 Sep 2000 09:48:18 +0200 (CEST)
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: <200009130539.NAA26841@ms5.hinet.net>
Message-ID: <Pine.LNX.4.21.0009130942310.12619-100000@leo.logilab.fr>

On Wed, 13 Sep 2000, Frank J.S. Chen wrote:

> The DOM implementation has the same problem:the method has its special
> name.
> As I write applications with it, I have to reference its code all the time.

Which method ? I've been using 4DOM for several months now, using the API
spec from the W3C as a documentation, and never encountered any method in
the spec that was not defined in 4DOM. The only trick I found is that
there is no DocumentTraversal class, because everything already is in
Docuement. 

On the other hand, I've been mainly using DOM core and DOM traversal, so
maybe there are issues I have not been able to notice ?


 -- 
Alexandre Fayolle
http://www.logilab.com - "Mais où est donc Ornicar ?" - 
LOGILAB, Paris (France).



From uche.ogbuji@fourthought.com  Wed Sep 13 09:00:37 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 13 Sep 2000 02:00:37 -0600
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: Message from "Frank J.S. Chen" <frank63@ms5.hinet.net>
 of "Wed, 13 Sep 2000 13:39:22 -0000." <200009130539.NAA26841@ms5.hinet.net>
Message-ID: <200009130800.CAA05909@localhost.localdomain>

I'm sorry, but I'm sure I don't have a clue what you're on about.

> And another problem...
> 
> PyXML doesn't conform to the specifications. Xmlproc's methods and
> mechanisms 
> for SAX parsing don't follow the SAX standard and this will be a problem
> for people 
> who want to use Python as a XML solution. Because one has to re-learn all
> the 
> methodology that xmlproc offers.

Almost no parser on earth, whether in Python, Perl, Java, C, C++, TCL or 
Sanskrit follows SAX.  Rather, they provide SAX interfaces in addition to 
their native interfaces.  xmlproc is no exception.  If you want to use SAX, 
well, just use SAX!  saxlib works just fine for Python.

There is nothing to re-learn.

Remember that SAX does not provide some things that are very important to some 
XML programmers.  It rather goes for the 80% of use.  Good for most users, but 
a good reason to keep native interfaces around.

> I cannot write an application for parsing
> with just the 
> knowledge of the core Python language and the SAX standard.We can use
> drv_xmlproc
> or drv_pyexpat as a top-layer to solve this problem, though, but this will
> still stop people 
> who want to use both Java and Python to write XML-aware applications; they
> will choose
> Java first and even JPython.

Uh, how does useing a SAX layer "stop" anyone?  See above.  All the Java 
parsers I know of provide native interfaces under SAX.  xmlproc is not unique.

> The DOM implementation has the same problem:the method has its special
> name.
> As I write applications with it, I have to reference its code all the time.

Again, I don't see what you're saying.  The DOM in PyXML (4DOM) is fully DOM 
Level 2 compliant.  We _add_ some functionality, as _every_ DOM library out 
there does, but it's all either flagged with _4dom_ prefixes or tucked away in 
the ext subdirectory.

Note that if we didn't provide a way to at least parse a document into DOM 
(which is not ter standardized by the DOM WG), it would not be much use, would 
it?

> These are, truely, all great works in PyXML package, but as for longevity,
> I think it better
> to follow and keep with the standard. Microsofts wanted to break the law,
> but they 
> failed in law.

OK, not the PyXML developers are compared to Microsoft.  I think that 
effectively ends the argument.

If you have a particular problem, I assure you you will get a lot of help from 
this list.  But you'll want to be careful about making so many odd accusations.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From uche.ogbuji@fourthought.com  Wed Sep 13 09:03:45 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 13 Sep 2000 02:03:45 -0600
Subject: [XML-SIG] consolidation?
In-Reply-To: Message from Lars Marius Garshol <larsga@garshol.priv.no>
 of "13 Sep 2000 09:44:57 +0200." <m3snr4ohvq.fsf@lambda.garshol.priv.no>
Message-ID: <200009130803.CAA05922@localhost.localdomain>

> | PyXML doesn't conform to the specifications. Xmlproc's methods and
> | mechanisms for SAX parsing don't follow the SAX standard and this
> | will be a problem for people who want to use Python as a XML
> | solution. 
> 
> There are two reasons for this, the most important being that xmlproc
> is older than SAX, and so obviously could not start out with a SAX
> interface. Secondly, the xmlproc APIs still offer a lot of
> functionality that SAX does not, although once SAX 2.0 is finalized it
> could conceivably start using a SAX 2.0 interface. 

Please do _not_ by any means eliminate the native xmlproc interface.  As you 
said it provides much that SAX (even SAX2 doesn't).

Of course, xmlproc is usually pointed out as an excellent library for DTD 
parsing routines, even by non-pythoneers on XML-DEV, which I think should be 
enough testimonial that it ain't broke right now.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From uche.ogbuji@fourthought.com  Wed Sep 13 09:09:25 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 13 Sep 2000 02:09:25 -0600
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: Message from Alexandre Fayolle <alf@logilab.com>
 of "Wed, 13 Sep 2000 09:48:18 +0200." <Pine.LNX.4.21.0009130942310.12619-100000@leo.logilab.fr>
Message-ID: <200009130809.CAA05955@localhost.localdomain>

> On Wed, 13 Sep 2000, Frank J.S. Chen wrote:
> =

> > The DOM implementation has the same problem:the method has its specia=
l
> > name.
> > As I write applications with it, I have to reference its code all the=
 time.
> =

> Which method ? I've been using 4DOM for several months now, using the A=
PI
> spec from the W3C as a documentation, and never encountered any method =
in
> the spec that was not defined in 4DOM. The only trick I found is that
> there is no DocumentTraversal class, because everything already is in
> Docuement. =


Ah, but note that DOML2 does not mandate a DocumentTraversal class but a =

DocumentTraversal _interface_.

We just happen to implement that interface on a class that also implement=
s the =

Document interface (and others).  This is perfectly legal DOM and quite c=
ommon =

OO practice.

I tend to think it makes life easier for implementing and usage.

> On the other hand, I've been mainly using DOM core and DOM traversal, s=
o
> maybe there are issues I have not been able to notice ?

We treat DOML2 incompatabilities as bugs.  There are a few minor compatab=
ility =

bugs here and there.  For instance we use Python's string which is not re=
ally =

conformant to the DOMString interface because it does not have clean unic=
ode =

manipulation.  This should hopefully be addressed when we mobe to Python =
2.

We're happy to know of any other bugs.


-- =

Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com =

4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From larsga@garshol.priv.no  Wed Sep 13 09:18:06 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 13 Sep 2000 10:18:06 +0200
Subject: [XML-SIG] consolidation?
In-Reply-To: <200009130803.CAA05922@localhost.localdomain>
References: <200009130803.CAA05922@localhost.localdomain>
Message-ID: <m3pum8ogch.fsf@lambda.garshol.priv.no>

* Lars Marius Garshol
|
| There are two reasons for this, the most important being that
| xmlproc is older than SAX, and so obviously could not start out with
| a SAX interface. Secondly, the xmlproc APIs still offer a lot of
| functionality that SAX does not, although once SAX 2.0 is finalized
| it could conceivably start using a SAX 2.0 interface.

* uche ogbuji
| 
| Please do _not_ by any means eliminate the native xmlproc interface.
| As you said it provides much that SAX (even SAX2 doesn't).

Don't worry: the native interface is there to stay and will be
developed further.  However, I plan to make as much of its
functionality as possible available through the SAX 2 driver.
 
Thanks for the support, BTW. :-)

--Lars M.



From alf@logilab.com  Wed Sep 13 09:21:33 2000
From: alf@logilab.com (Alexandre Fayolle)
Date: Wed, 13 Sep 2000 10:21:33 +0200 (CEST)
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: <200009130809.CAA05955@localhost.localdomain>
Message-ID: <Pine.LNX.4.21.0009131012520.12659-100000@leo.logilab.fr>

On Wed, 13 Sep 2000 uche.ogbuji@fourthought.com wrote:

> > the spec that was not defined in 4DOM. The only trick I found is that
> > there is no DocumentTraversal class, because everything already is in
> > Docuement. 
> 
> Ah, but note that DOML2 does not mandate a DocumentTraversal class but a 
> DocumentTraversal _interface_.

You're right. 
 
> We just happen to implement that interface on a class that also implements the 
> Document interface (and others).  This is perfectly legal DOM and quite common 
> OO practice.
> 
> I tend to think it makes life easier for implementing and usage.

I could not agree more on that. Since Python knows nothin about casts,
this was indeed the best choice you could make.

And then, I can't help thinkink you're teasing me, because you perfectly
know how happy we are with 4DOM at Logilab ;o) [BtW, you can register on
our web site to be informed when we release our product]


> > On the other hand, I've been mainly using DOM core and DOM traversal, so
> > maybe there are issues I have not been able to notice ?
> 
> We treat DOML2 incompatabilities as bugs.  There are a few minor compatability 
> bugs here and there.  For instance we use Python's string which is not really 
> conformant to the DOMString interface because it does not have clean unicode 
> manipulation.  This should hopefully be addressed when we mobe to Python 2.

I'd like to add that all the known minor incompatibilities are documented
in the distribution, so there are no surprises. 

> We're happy to know of any other bugs.

Be assured that we'll let you know if we manage to find some. 

-- 
Alexandre Fayolle
http://www.logilab.com - "Mais où est donc Ornicar ?" - 
LOGILAB, Paris (France).



From martin@loewis.home.cs.tu-berlin.de  Wed Sep 13 12:03:14 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 13 Sep 2000 13:03:14 +0200
Subject: [XML-SIG] Q: minidom and iso-8859-1
In-Reply-To: <200009120837.KAA02473@mast.cwi.nl>
 (Jacco.van.Ossenbruggen@cwi.nl)
References: <200009120837.KAA02473@mast.cwi.nl>
Message-ID: <200009131103.NAA00883@loewis.home.cs.tu-berlin.de>

> Oops, I think I begin to understand what is going on.  The UTF-8
> indeed prints the right result, it was just not the result I (encoding
> newbie) expected.

Hi Jacco,

This is what I suspected. I'm surprised though as to what your
expectation was.

> I think I just asked myself the wrong question (how was the original
> XML encoded) while I should have asked myself in what encoding I
> want to have the output in.

I thought you'd expect that UTF-8 would reproduce latin-1 characters
in a single byte - which of course cannot work, as latin-1 would then
consume all possible bit combinations. In any case, that seems to be
resolved - now the next question is: How do you get the original
encoding of the document.

It appears that the DOM itself does not provide any mechanism for
that. It may be that the reader passes this information to the DOM
builder, so you may need to hook into the parser. However, it also
appears that SAX does not generate an event for the <?xml header, so
you could only use a specific parser with some extended interface.

I know xmllib invokes handle_xml for that; I don't know whether expat
gives access to that information, it appears as if the default handler
would be invoked when <?xml is seen, with the encoding as a parameter.

Regards,
Martin



From martin@loewis.home.cs.tu-berlin.de  Wed Sep 13 12:11:08 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 13 Sep 2000 13:11:08 +0200
Subject: [XML-SIG] Re: [4suite] Output encodings again
In-Reply-To: <39BE21EB.842A066F@lemburg.com> (mal@lemburg.com)
References: <871yzla17z.fsf@psyche.evansnet> <39BC9737.C302C19C@fourthought.com> <200009112248.AAA00801@loewis.home.cs.tu-berlin.de> <39BE21EB.842A066F@lemburg.com>
Message-ID: <200009131111.NAA00929@loewis.home.cs.tu-berlin.de>

> It's not really all that hard to write codecs for Python 2.0.
> 
> You'll have to do two things:
> 1. write the codec by subclassing the base classes in codecs.py
> 2. write a search function which returns the needed constructors
>    and functions.

So how would I write a codec that converts all characters to Latin-1,
and converts those out of latin-1 to &#xxx; (instead of the
replacement character)? I'd need knowledge about what character are in
Latin-1, and I'd need to do conversion on a character-by-character
basis, right? And I can't possible use any of the _codecs helper
functions?

This is certainly feasible if I want it for a single character set,
but now if I want to do it wholesale for the entire set of character
sets supported by Python 2.0.

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 13 12:21:46 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 13 Sep 2000 13:21:46 +0200
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: <200009130539.NAA26841@ms5.hinet.net> (frank63@ms5.hinet.net)
References: <200009130539.NAA26841@ms5.hinet.net>
Message-ID: <200009131121.NAA00980@loewis.home.cs.tu-berlin.de>

> PyXML doesn't conform to the specifications. Xmlproc's methods and
> mechanisms for SAX parsing don't follow the SAX standard and this
> will be a problem for people who want to use Python as a XML
> solution.

Can you give a specific example where xmlproc deviates from the SAX
API? What is wrong with

xml.sax.saxexts.make_parser("xml.sax.drivers.drv_xmlproc")

if you insist on creating a SAX reader using xmlproc, or with

xml.sax.saxexts.XMLValParserFactory.make_parser()

if you just want a validating parser, which happens to be
xmlproc-based.

I would not recommend anybody to use the raw xmlproc API... As far as
I can tell, the resulting parsers slavishly follow SAX.

> Because one has to re-learn all the methodology that xmlproc
> offers. I cannot write an application for parsing with just the
> knowledge of the core Python language and the SAX standard.

Again, please elaborate. How should it work, and why doesn't it work
that way?

> We can use drv_xmlproc or drv_pyexpat as a top-layer to solve this
> problem, though, but this will still stop people who want to use
> both Java and Python to write XML-aware applications; they will
> choose Java first and even JPython.

Why is that? Nobody even needs to know that we have a driver called
pyexpat, and one called xmlproc.

> The DOM implementation has the same problem:the method has its
> special name.

Again, please elaborate. Which method has which name?

Regards,
Martin


From frank63@ms5.hinet.net  Wed Sep 13 21:27:11 2000
From: frank63@ms5.hinet.net (Frank J.S. Chen)
Date: Wed, 13 Sep 2000 20:27:11 -0000
Subject: Fw: [XML-SIG] consolidation?
Message-ID: <200009131234.UAA13955@ms5.hinet.net>

> 
> Which method ? I've been using 4DOM for several months now, using the API
> spec from the W3C as a documentation, and never encountered any method in
> the spec that was not defined in 4DOM. The only trick I found is that
> there is no DocumentTraversal class, because everything already is in
> Docuement. 
> 
> On the other hand, I've been mainly using DOM core and DOM traversal, so
> maybe there are issues I have not been able to notice ?

But I mean the underlying "core.py", not 4DOM, I know 4DOM has full
features defined
in DOM Level One&Two, but 4DOM is more complicated than core.py, so I think
I
need to realize
core.py first. As I read and used the code, I found this problem, and
stopped for a good while.

By the way, 4DOM has RedHat .rpm and Windows versions, but there seems no
..tgz version,
I can use Windows version, like 4XSLT, but not on Slackware.

PS.4XSLT cannot deal with XML documents with multiple-bytes encoding?

Frank



From frank63@ms5.hinet.net  Wed Sep 13 21:31:39 2000
From: frank63@ms5.hinet.net (Frank J.S. Chen)
Date: Wed, 13 Sep 2000 20:31:39 -0000
Subject: [XML-SIG] consolidation?
Message-ID: <200009131234.UAA13964@ms5.hinet.net>

> 
> There are two reasons for this, the most important being that xmlproc
> is older than SAX, and so obviously could not start out with a SAX
> interface. Secondly, the xmlproc APIs still offer a lot of
> functionality that SAX does not, although once SAX 2.0 is finalized it
> could conceivably start using a SAX 2.0 interface. 
> 
> The problem is that there are a quite a few users out there that use
> the old interface, and I don't want to break their applications by
> changing my interfaces. Nor do I see much of a need, since SAX
> provides a SAX-based interface to xmlproc.
> 

I don't know the history of xmlproc. I apologize for commenting on this 
subject without considering the historical backgrounds and the community
tastes.

But from an outside user perspective, "standard" is an approach to judge
the
usability of many tools. 


Frank Chen




 


From gstein@lyra.org  Wed Sep 13 13:38:13 2000
From: gstein@lyra.org (Greg Stein)
Date: Wed, 13 Sep 2000 05:38:13 -0700
Subject: [XML-SIG] consolidation?
In-Reply-To: <200009131234.UAA13964@ms5.hinet.net>; from frank63@ms5.hinet.net on Wed, Sep 13, 2000 at 08:31:39PM -0000
References: <200009131234.UAA13964@ms5.hinet.net>
Message-ID: <20000913053812.Y3278@lyra.org>

On Wed, Sep 13, 2000 at 08:31:39PM -0000, Frank J.S. Chen wrote:
> > There are two reasons for this, the most important being that xmlproc
> > is older than SAX, and so obviously could not start out with a SAX
> > interface. Secondly, the xmlproc APIs still offer a lot of
> > functionality that SAX does not, although once SAX 2.0 is finalized it
> > could conceivably start using a SAX 2.0 interface. 
> > 
> > The problem is that there are a quite a few users out there that use
> > the old interface, and I don't want to break their applications by
> > changing my interfaces. Nor do I see much of a need, since SAX
> > provides a SAX-based interface to xmlproc.
> > 
> 
> I don't know the history of xmlproc. I apologize for commenting on this 
> subject without considering the historical backgrounds and the community
> tastes.
> 
> But from an outside user perspective, "standard" is an approach to judge
> the
> usability of many tools. 

You don't seem to be getting it:

*) xmlproc's interface is NOT supposed to be SAX.
*) if you want SAX, then use the provided SAX tools; xmlproc will plug in
   underneath it and you don't have to worry about it

It is *perfectly* acceptable for xmlproc not to have a SAX interface, and
any suggestion that that is somehow "wrong" is just misguided.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


From ht@cogsci.ed.ac.uk  Wed Sep 13 13:40:05 2000
From: ht@cogsci.ed.ac.uk (Henry S. Thompson)
Date: 13 Sep 2000 13:40:05 +0100
Subject: [XML-SIG] Python embedding of LTXML, a C-based validating XML parser, released
In-Reply-To: Alexandre Fayolle's message of "Wed, 13 Sep 2000 10:21:33 +0200 (CEST)"
Message-ID: <f5b3dj4zcre.fsf@cogsci.ed.ac.uk>

I've finally got the licensing sorted out.  PyLTXML is now available [1]
in both source and Win32 binary forms, under the GPL (i.e. you can use 
the binary, but not distribute it unless you get and distribute the
sources as well).  Both 8- and 16-bit versions are available:  16-bit
only known to work with 1.6a1 and later, should work with 2.0 but not
tried yet.

The API is a combination of low-level and tree-based, allowing fast
scanning of large files for hotspots you care about without the
overhead of structure-building until you hit the part(s) you care
about.

XED [2] and XSV [3] are both built in Python on top of this technology.

ht

[1] http://www.ltg.ed.ac.uk/software/xml/
[2] http://www.ltg.ed.ac.uk/~ht/xed.html
[3] http://www.ltg.ed.ac.uk/~ht/xsv-status.html
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/


From jeremy@beopen.com  Wed Sep 13 14:01:05 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 13 Sep 2000 09:01:05 -0400 (EDT)
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <m3u2bkoi5h.fsf@lambda.garshol.priv.no>
References: <935085382.20000912182634@email.com>
 <m3u2bkoi5h.fsf@lambda.garshol.priv.no>
Message-ID: <14783.31377.63536.118426@bitdiddle.concentric.net>

>>>>> "LMG" == Lars Marius Garshol <larsga@garshol.priv.no> writes:

  > could someone please explain the status of the sax-code in
  > python2. 

  LMG> It is on the verge of being updated and finalized, but so far
  LMG> it has not been.  I've done quite a bit of work on it that
  LMG> hasn't been checked in yet, but this is all marooned on my home
  LMG> computer whose monitor has given up the ghost.  I will
  LMG> hopefully get this fixed soon, and then the SAX 2.0 code in the
  LMG> Python 2.0 distribution should be updated fairly soon after
  LMG> that.

  > Is the code in python2-cvs thought to be usable

  LMG> No, not really.

Were we premature to include the XML package in the standard library?
I have not used either that code or the XML package, so I'm not
qualified to judge.  But I have heard a lot of complaints about the
xml package and few people have said they are happy that it is there.

Jeremy


From frank63@ms5.hinet.net  Wed Sep 13 23:39:11 2000
From: frank63@ms5.hinet.net (Frank J.S. Chen)
Date: Wed, 13 Sep 2000 22:39:11 -0000
Subject: Fw: [XML-SIG] consolidation?
Message-ID: <200009131439.WAA13927@ms5.hinet.net>

> 
> Can you give a specific example where xmlproc deviates from the SAX
> API? What is wrong with
> xml.sax.saxexts.make_parser("xml.sax.drivers.drv_xmlproc")
> if you insist on creating a SAX reader using xmlproc, or with
> xml.sax.saxexts.XMLValParserFactory.make_parser()
> if you just want a validating parser, which happens to be
> xmlproc-based.
> I would not recommend anybody to use the raw xmlproc API... As far as
> I can tell, the resulting parsers slavishly follow SAX.

I can create applications for parsing in Java, JPython and Python with
saxlib.
I mean to write my own callbacks to control content handler, error handler,
and
DTD handler, to decide what to display and what to do.

But when I found the same procedure cannot apply to xmlproc directly(you
said 
"raw xmlproc API"), I was a bit little depressed, and then thought about 
sticking to standards. That's why I said "re-learn".

As for DOM, I meant the original DOM, not 4DOM. I remembered that
core.py had different method names from spec one month ago. Were those 
changed?

Frank Chen


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 13 19:43:17 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 13 Sep 2000 20:43:17 +0200
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: <200009131439.WAA13927@ms5.hinet.net> (frank63@ms5.hinet.net)
References: <200009131439.WAA13927@ms5.hinet.net>
Message-ID: <200009131843.UAA01454@loewis.home.cs.tu-berlin.de>

> I can create applications for parsing in Java, JPython and Python with
> saxlib.
> I mean to write my own callbacks to control content handler, error
> handler, and DTD handler, to decide what to display and what to do.

That is my point.

> But when I found the same procedure cannot apply to xmlproc
> directly(you said "raw xmlproc API"), I was a bit little depressed,
> and then thought about sticking to standards. That's why I said
> "re-learn".

If you don't want to learn xmlproc, then just don't. I just completed
writing a book on Python that also talks about XML, and I did not
mention the xmlproc API with a single line of text - I claim there
only is SAX and DOM in Python.

> As for DOM, I meant the original DOM, not 4DOM. I remembered that
> core.py had different method names from spec one month ago. Were
> those changed?

core.py is not part of the PyXML CVS anymore; 4DOM now is. In
addition, Python 2.0 includes minidom, which also appears to be fully
compatible.

In any case: What was your specific complaint about core.py?

Regards,
Martin



From martin@loewis.home.cs.tu-berlin.de  Wed Sep 13 19:55:40 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 13 Sep 2000 20:55:40 +0200
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: <200009131234.UAA13955@ms5.hinet.net> (frank63@ms5.hinet.net)
References: <200009131234.UAA13955@ms5.hinet.net>
Message-ID: <200009131855.UAA01502@loewis.home.cs.tu-berlin.de>

> But I mean the underlying "core.py", not 4DOM, I know 4DOM has full
> features defined in DOM Level One&Two, but 4DOM is more complicated
> than core.py, so I think I need to realize core.py first.

The DOM is the DOM is the DOM. Any code that works with core.py should
literally work with 4DOM as well, except for the instantiation of the
parser. So you can ignore all 4DOM functions that you don't need
(e.g. level 2), and just use it as if it were simple - it really is.

Regards,
Martin




From martin@loewis.home.cs.tu-berlin.de  Wed Sep 13 19:53:34 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 13 Sep 2000 20:53:34 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <14783.31377.63536.118426@bitdiddle.concentric.net> (message from
 Jeremy Hylton on Wed, 13 Sep 2000 09:01:05 -0400 (EDT))
References: <935085382.20000912182634@email.com>
 <m3u2bkoi5h.fsf@lambda.garshol.priv.no> <14783.31377.63536.118426@bitdiddle.concentric.net>
Message-ID: <200009131853.UAA01501@loewis.home.cs.tu-berlin.de>

> Were we premature to include the XML package in the standard library?
> I have not used either that code or the XML package, so I'm not
> qualified to judge.  But I have heard a lot of complaints about the
> xml package and few people have said they are happy that it is there.

I haven't used this much. However, I feel all is fine if the interface
is right - the implementation itself may be terrible, but that can be
fixed in future versions.

As for the interface, the xml package of Python 2 has:

- a SAX library (SAX2, right?)
- a DOM library
- functions to create SAX and DOM parsers

The SAX and DOM APIs themselves are agreed-upon in the XML community,
so there is nothing dangerous in providing them.

Creation of parsers is the weak point right now - especially as the
PyXML package does not provide the same interfaces. I think that must
be fixed by updating PyXML to provide the same interface.

The Python XML code suffers from great instability of the interface
over the years. IMO, this partially caused by authors of that code
having no concern about backwards compatibility. I hope committing to
an API, as will be done for Python 2, will provide greater stability.
I believe the API is not inherently bad. 

  > Is the code in python2-cvs thought to be usable

  LMG> No, not really.

Lars, can you please elaborate? What is it that does not work? Or,
what essential features are missing?

Regards,
Martin


From uche.ogbuji@fourthought.com  Wed Sep 13 21:00:09 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 13 Sep 2000 14:00:09 -0600
Subject: [XML-SIG] Q: minidom and iso-8859-1
In-Reply-To: Message from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
 of "Wed, 13 Sep 2000 13:03:14 +0200." <200009131103.NAA00883@loewis.home.cs.tu-berlin.de>
Message-ID: <200009132000.OAA07674@localhost.localdomain>

> How do you get the original encoding of the document.
> 
> It appears that the DOM itself does not provide any mechanism for
> that. It may be that the reader passes this information to the DOM
> builder, so you may need to hook into the parser. However, it also
> appears that SAX does not generate an event for the <?xml header, so
> you could only use a specific parser with some extended interface.

SAX2 does, and 4DOM translates it to a processing instruction (this should 
raise some eyebrows since the XML declaration is not a processing instruction, 
but we've checked: DOM seems to allow this and som of the gurus on the DOM 
lust have said it's not incorrect to do so.)

The problem, of course, is that the migration of PyXML to sax2 is not yet 
complete so there's no easy way to get this info right now.

It's too bad that we're all so terribly busy in xml-sig, because we really 
should be sorting such things out, but barring a UN declaration of an 
additional four hours per day, it might be a while before we can get it all 
done.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From uche.ogbuji@fourthought.com  Wed Sep 13 21:08:35 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 13 Sep 2000 14:08:35 -0600
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: Message from "Frank J.S. Chen" <frank63@ms5.hinet.net>
 of "Wed, 13 Sep 2000 20:27:11 -0000." <200009131234.UAA13955@ms5.hinet.net>
Message-ID: <200009132008.OAA07699@localhost.localdomain>

> > 
> > Which method ? I've been using 4DOM for several months now, using the API
> > spec from the W3C as a documentation, and never encountered any method in
> > the spec that was not defined in 4DOM. The only trick I found is that
> > there is no DocumentTraversal class, because everything already is in
> > Docuement. 
> > 
> > On the other hand, I've been mainly using DOM core and DOM traversal, so
> > maybe there are issues I have not been able to notice ?
> 
> But I mean the underlying "core.py", not 4DOM, I know 4DOM has full
> features defined
> in DOM Level One&Two, but 4DOM is more complicated than core.py, so I think
> I
> need to realize
> core.py first. As I read and used the code, I found this problem, and
> stopped for a good while.

What is core.py?


> By the way, 4DOM has RedHat .rpm and Windows versions, but there seems no
> ..tgz version,
> I can use Windows version, like 4XSLT, but not on Slackware.

There is.  See ftp://ftp.fourthought.com/pub/4Suite/

All the tgzs are right in that dir, as well as the 20000727 bug-fix patch.

We're closing in hard on a new release, using distutils and consolidating the 
various packages.  Fingers crossed for release today.

> PS.4XSLT cannot deal with XML documents with multiple-bytes encoding?

What problem do you see?  We use expat for parting, so it has to come in as 
UTF-8 or ISO-8859.  The same for output, using the PyXML wstring tools.  So we 
don't support Shift-JIS or anything like that, but you should be able to do 
whatever you need through UTF-8.

Is UTF-8 not working for you?  We do have some output encoding bugs we've 
fixed for the upcoming release.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From akuchlin@mems-exchange.org  Wed Sep 13 21:27:01 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Wed, 13 Sep 2000 16:27:01 -0400
Subject: Fw: [XML-SIG] consolidation?
In-Reply-To: <200009132008.OAA07699@localhost.localdomain>; from uche.ogbuji@fourthought.com on Wed, Sep 13, 2000 at 02:08:35PM -0600
References: <frank63@ms5.hinet.net> <200009132008.OAA07699@localhost.localdomain>
Message-ID: <20000913162701.C12579@kronos.cnri.reston.va.us>

On Wed, Sep 13, 2000 at 02:08:35PM -0600, uche.ogbuji@fourthought.com wrote:
>What is core.py?

The heart of the old PyDOM implementation.

--amk


From mal@lemburg.com  Wed Sep 13 18:57:07 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 13 Sep 2000 19:57:07 +0200
Subject: [XML-SIG] Re: [4suite] Output encodings again
References: <871yzla17z.fsf@psyche.evansnet> <39BC9737.C302C19C@fourthought.com> <200009112248.AAA00801@loewis.home.cs.tu-berlin.de> <39BE21EB.842A066F@lemburg.com> <200009131111.NAA00929@loewis.home.cs.tu-berlin.de>
Message-ID: <39BFBFF3.C7BDD1F4@lemburg.com>

"Martin v. Loewis" wrote:
> 
> > It's not really all that hard to write codecs for Python 2.0.
> >
> > You'll have to do two things:
> > 1. write the codec by subclassing the base classes in codecs.py
> > 2. write a search function which returns the needed constructors
> >    and functions.
> 
> So how would I write a codec that converts all characters to Latin-1,
> and converts those out of latin-1 to &#xxx; (instead of the
> replacement character)? I'd need knowledge about what character are in
> Latin-1, and I'd need to do conversion on a character-by-character
> basis, right?

Right.

> And I can't possible use any of the _codecs helper
> functions?

You could play some tricks with the character mapping codec
which is used by all code page codecs.

You will achieve better performance with a native codec written
in C though.

> This is certainly feasible if I want it for a single character set,
> but now if I want to do it wholesale for the entire set of character
> sets supported by Python 2.0.

This is probably not possible since there's no way to have the
codecs use e.g. a callback function to handle error situations.

But the situation is not all that bad: most codecs rely on the
character mapping codec and you could simply implement a new
version of it which does the XML escaping instead of raising
errors.

-- 
Marc-Andre Lemburg
________________________________________________________________________
Business:                                        http://www.lemburg.com/
Python Pages:                             http://www.lemburg.com/python/



From jeremy@beopen.com  Thu Sep 14 03:24:42 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 13 Sep 2000 22:24:42 -0400 (EDT)
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <200009131853.UAA01501@loewis.home.cs.tu-berlin.de>
References: <935085382.20000912182634@email.com>
 <m3u2bkoi5h.fsf@lambda.garshol.priv.no>
 <14783.31377.63536.118426@bitdiddle.concentric.net>
 <200009131853.UAA01501@loewis.home.cs.tu-berlin.de>
Message-ID: <14784.14058.523463.456333@bitdiddle.concentric.net>

>>>>> "MvL" == Martin v Loewis <martin@loewis.home.cs.tu-berlin.de> writes:

  >> Were we premature to include the XML package in the standard
  >> library?  I have not used either that code or the XML package, so
  >> I'm not qualified to judge.  But I have heard a lot of complaints
  >> about the xml package and few people have said they are happy
  >> that it is there.

  MvL> I haven't used this much. However, I feel all is fine if the
  MvL> interface is right - the implementation itself may be terrible,
  MvL> but that can be fixed in future versions.

The implementation needs to work, too!  Let's optimistically say we
have a Python 2.1 release nine months after a 2.0 release.  That means
that every new Python during that time will try to use the builtin XML
libraries and have problems.  We could make a lot of people think
Python is a lousy language for XML processing in that time.

It may be straightforward to find the XML SIG's package and install it
on top of the standard library, but I expect most people won't go to
that trouble until after they are fairly familiar with Python.

Jeremy


From frank63@ms5.hinet.net  Thu Sep 14 12:01:09 2000
From: frank63@ms5.hinet.net (Frank J.S. Chen)
Date: Thu, 14 Sep 2000 11:01:09 -0000
Subject: Fw: [XML-SIG] consolidation?
Message-ID: <200009140306.LAA25455@ms5.hinet.net>


> 
> If you don't want to learn xmlproc, then just don't. I just completed
> writing a book on Python that also talks about XML, and I did not
> mention the xmlproc API with a single line of text - I claim there
> only is SAX and DOM in Python.
> 

That's the point too. I am planning to write a Chinese book to intruduce
XML processing with Python, but xmlproc is a very important parser
in PyXML package, and cannot leave it just alone. But if I describe
the original xmlproc API, readers will get confused because its not
being consistent with SAX 2.0. So I have such an opinion in xmlproc.
The only way to do is omit the xmlproc specific APIs and focus
on drivers layers, just like you did. "To learn or Not to learn" will not
be my point:-).

> core.py is not part of the PyXML CVS anymore; 4DOM now is. In
> addition, Python 2.0 includes minidom, which also appears to be fully
> compatible. 
> In any case: What was your specific complaint about core.py?

I am out-of-dated!
It doesn't matter anymore.

Frank Chen




From frank63@ms5.hinet.net  Thu Sep 14 12:05:38 2000
From: frank63@ms5.hinet.net (Frank J.S. Chen)
Date: Thu, 14 Sep 2000 11:05:38 -0000
Subject: Fw: [XML-SIG] consolidation?
Message-ID: <200009140306.LAA25467@ms5.hinet.net>

> 
> What problem do you see?  We use expat for parting, so it has to come in
as 
> UTF-8 or ISO-8859.  The same for output, using the PyXML wstring tools. 
So we 
> don't support Shift-JIS or anything like that, but you should be able to
do 
> whatever you need through UTF-8.
> 
> Is UTF-8 not working for you?  We do have some output encoding bugs we've

> fixed for the upcoming release.

When I get the released version, I'll try it. 
If anything wrong, I will inform to the mailing-list.

Frank Chen





From paul@prescod.net  Thu Sep 14 07:13:43 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 13 Sep 2000 23:13:43 -0700
Subject: [XML-SIG] SAX2 in python20b1 usable?
References: <935085382.20000912182634@email.com>
 <m3u2bkoi5h.fsf@lambda.garshol.priv.no>
 <14783.31377.63536.118426@bitdiddle.concentric.net>
 <200009131853.UAA01501@loewis.home.cs.tu-berlin.de> <14784.14058.523463.456333@bitdiddle.concentric.net>
Message-ID: <39C06C97.245CB6A@prescod.net>

Jeremy Hylton wrote:
> 
> ...
> 
> The implementation needs to work, too!  Let's optimistically say we
> have a Python 2.1 release nine months after a 2.0 release.  That means
> that every new Python during that time will try to use the builtin XML
> libraries and have problems.  

What problems are you referring to? The fourthought guys just went
through a pretty thorough review of minidom and found only a few minor
bugs. In the modules and libraries sections of sourceforge's bug tracker
I see only one listed bug. Expat has hardly changed from the expat that
people have been using productively for years. I don't know of PyExpat
bugs.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 07:19:09 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 13 Sep 2000 23:19:09 -0700
Subject: [XML-SIG] Sax2.FromXml 'feature'
References: <Pine.LNX.4.21.0009110947140.10407-100000@leo.logilab.fr> <m3vgw3payj.fsf@lambda.garshol.priv.no>
Message-ID: <39C06DDD.4AEE91AD@prescod.net>

Lars Marius Garshol wrote:
> 
>...
> 
> An alternative might be for this function to add a fake container
> element around the string to avoid this problem. Opinions, anyone?

That's the standard approach. There wouldn't be anything wrong with a
FromXmlFrag method but I don't remember seeing that elsewhere and it
feels like featureitis to me.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 07:23:07 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 13 Sep 2000 23:23:07 -0700
Subject: [XML-SIG] Q: minidom and iso-8859-1
References: <200009120837.KAA02473@mast.cwi.nl> <200009131103.NAA00883@loewis.home.cs.tu-berlin.de>
Message-ID: <39C06ECB.CCE1BBE6@prescod.net>

"Martin v. Loewis" wrote:
> 
>...
> 
> It appears that the DOM itself does not provide any mechanism for
> that. It may be that the reader passes this information to the DOM
> builder, so you may need to hook into the parser. However, it also
> appears that SAX does not generate an event for the <?xml header, so
> you could only use a specific parser with some extended interface.
> 
> I know xmllib invokes handle_xml for that; I don't know whether expat
> gives access to that information, it appears as if the default handler
> would be invoked when <?xml is seen, with the encoding as a parameter.

That's true. I'm not going to go out and implement a feature to sniff
the original encoding declaration but if someone wants to add it to
pyexpat and pysax they are welcome to. The DOM still doesn't provide a
standard way of reporting it and I would be reluctant to add a
non-standard way to minidom.

Anyhow, am I right that this perceived bug turned out not to be one?

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 07:24:02 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 13 Sep 2000 23:24:02 -0700
Subject: [XML-SIG] consolidation?
References: <19260148.968689674819.JavaMail.imail@digger.excite.com>
Message-ID: <39C06F02.205DF136@prescod.net>

michael.easter@excite.com wrote:
> 
> ...
> 
> However, from the outside, there seems to be a _lot_ of different XML tools
> for Python.  I can't help but wonder if there is too much overlap in some of
> the projects.  Is this just me, or does anyone else feel the same way?
> 
> On a related note, is there any talk of having a Python wrapper around
> Xerces?

Wouldn't that be just another competing tool???

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 07:27:49 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 13 Sep 2000 23:27:49 -0700
Subject: [XML-SIG] SAX2 in python20b1 usable?
References: <935085382.20000912182634@email.com>
Message-ID: <39C06FE5.155AEC29@prescod.net>

Stephan Tolksdorf wrote:
> 
> Hello,
> 
> could someone please explain the status of the sax-code in python2.
> I just tried to parse a simple xml-file with expatreader and I
> had to modify the source just to get the parsing started...
> and I didn't succeed.
> Is the code in python2-cvs thought to be usable and what's the
> relation to the code on http://www.garshol.priv.no/download/
> software/saxlib/sax2/.

I've parsed many files with that code. I checked it out of CVS just
today and had no problem. Perhaps you could show your code and sample
file.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From martin@loewis.home.cs.tu-berlin.de  Thu Sep 14 07:37:20 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 14 Sep 2000 08:37:20 +0200
Subject: [XML-SIG] Q: minidom and iso-8859-1
In-Reply-To: <39C06ECB.CCE1BBE6@prescod.net> (message from Paul Prescod on
 Wed, 13 Sep 2000 23:23:07 -0700)
References: <200009120837.KAA02473@mast.cwi.nl> <200009131103.NAA00883@loewis.home.cs.tu-berlin.de> <39C06ECB.CCE1BBE6@prescod.net>
Message-ID: <200009140637.IAA00835@loewis.home.cs.tu-berlin.de>

> Anyhow, am I right that this perceived bug turned out not to be one?

Yes, it turned out to be a missing feature, and not of minidom, but of
DOM per se.

Regards,
Martin


From paul@prescod.net  Thu Sep 14 07:48:35 2000
From: paul@prescod.net (Paul Prescod)
Date: Wed, 13 Sep 2000 23:48:35 -0700
Subject: [XML-SIG] Uniform interface with Python 2.0
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de>
Message-ID: <39C074C3.94809D07@prescod.net>

"Martin v. Loewis" wrote:
> 
> ...
> 
> In Python 2.0, saxexts is not supported. Instead, you have to know
> that the expatreader is there, so you write

No, that's not the usual way to do it. You don't need to know anything
about Expat to use SAX.

> Alternatively, in Python 2.0, you can write
> 
> import xml.sax
> xml.sax.parse(file, MyHandler())

Right. That's the better way to do it.

> Again, that won't work in PyXML: xml.sax does not have the parse
> function.

I believe the plan is to have PyXML merely add things to the Python 2
XML module without removing anything, but PyXML has not been made 2.0
compatible yet.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 08:13:55 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 14 Sep 2000 00:13:55 -0700
Subject: [XML-SIG] XML for Python 2
Message-ID: <39C07AB3.92549BCD@prescod.net>

If XML support is going to be cleaned up for Python 2 then we need a
list of what's to be done and who is to do it. Here is my list in terms
of priorities:

SAX API finalized
SAX implementation finalized
SAX test suite checked in
minidom bugfixes
decision on whether to document pulldom
overall documentation
PyXML integration

Much of this can be done in parallel. Rather than duplicating work, we
should decide who intends to work on what. Lars says he has already done
work on SAX but his situation is also slightly dangerous because we
don't know when his computer will be fixed. I will do the minidom fixes
and a bunch of the documentation.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From martin@loewis.home.cs.tu-berlin.de  Thu Sep 14 08:27:58 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 14 Sep 2000 09:27:58 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <39C074C3.94809D07@prescod.net> (message from Paul Prescod on
 Wed, 13 Sep 2000 23:48:35 -0700)
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net>
Message-ID: <200009140727.JAA02687@loewis.home.cs.tu-berlin.de>

> > Alternatively, in Python 2.0, you can write
> > 
> > import xml.sax
> > xml.sax.parse(file, MyHandler())
> 
> Right. That's the better way to do it.

It's not SAX compatible, though, is it? In SAX, I'd expect to create a
reader object using some out-of-scope operation, then invoke
setContentHandler() on this object. I think that should be supported
somehow.

What was wrong with sax2utils.make_parser() to not include it in
Python 2?

> I believe the plan is to have PyXML merely add things to the Python 2
> XML module without removing anything, but PyXML has not been made 2.0
> compatible yet.

Sounds good.

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Thu Sep 14 08:35:25 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 14 Sep 2000 09:35:25 +0200
Subject: [XML-SIG] XML for Python 2
In-Reply-To: <39C07AB3.92549BCD@prescod.net> (message from Paul Prescod on
 Thu, 14 Sep 2000 00:13:55 -0700)
References: <39C07AB3.92549BCD@prescod.net>
Message-ID: <200009140735.JAA02787@loewis.home.cs.tu-berlin.de>

> PyXML integration

I'd like to look into updating PyXML so it gets compatible with Python
2. That may not be essential for Python 2.0 itself, but it will serve
as a proof-of-concept that the _xmlplus approach really works.

Regards,
Martin


From larsga@garshol.priv.no  Thu Sep 14 08:57:32 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 14 Sep 2000 09:57:32 +0200
Subject: [XML-SIG] consolidation?
In-Reply-To: <200009140306.LAA25455@ms5.hinet.net>
References: <200009140306.LAA25455@ms5.hinet.net>
Message-ID: <m3vgvzmmmr.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
|
| If you don't want to learn xmlproc, then just don't. I just
| completed writing a book on Python that also talks about XML, and I
| did not mention the xmlproc API with a single line of text - I claim
| there only is SAX and DOM in Python.

* Frank J. S. Chen
| 
| That's the point too. I am planning to write a Chinese book to
| intruduce XML processing with Python, but xmlproc is a very
| important parser in PyXML package, and cannot leave it just
| alone. But if I describe the original xmlproc API, readers will get
| confused because its not being consistent with SAX 2.0. So I have
| such an opinion in xmlproc.  The only way to do is omit the xmlproc
| specific APIs and focus on drivers layers, just like you did.

As it happens, I am also writing a book about XML processing with
Python, and I have to confess that I don't understand these concerns
at all. My book divides the developer's options into event-based,
tree-based, declarative and miscellaneous.

In the event-based category, I describe the options as being a choice
between SAX and the native APIs of the various parsers. This is the
situation in Python, just as it is in Java, and I believe that this is
by far the best way to do it, since it doesn't leave the reader
confused as to what parsers and SAX really are and what the
relationship between them is.

So I cover SAX, but I also describe the xmllib, pyexpat, xmlproc and
even XP (JPython) APIs, and so far not one of my reviewers has
complained that this is in any way confusing.

--Lars M.




From larsga@garshol.priv.no  Thu Sep 14 09:01:27 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 14 Sep 2000 10:01:27 +0200
Subject: [XML-SIG] XML for Python 2
In-Reply-To: <39C07AB3.92549BCD@prescod.net>
References: <39C07AB3.92549BCD@prescod.net>
Message-ID: <m3u2bjmmg8.fsf@lambda.garshol.priv.no>

* Paul Prescod
|
| SAX API finalized
| SAX implementation finalized
| SAX test suite checked in

I've thought about it and decided that I can do all of these within
two weeks.  If it takes more than a couple of days to fix my monitor I
will just physically remove the drive and mount it on my Linux box at
work to get hold of the files.

If someone else could do the SAX documentation I think that would be
useful as a combined test of common understanding and sanity check.
I can of course do it if nobody else can, but it might be better if
someone else does it.

--Lars M.



From larsga@garshol.priv.no  Thu Sep 14 09:35:43 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 14 Sep 2000 10:35:43 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <200009140727.JAA02687@loewis.home.cs.tu-berlin.de>
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net> <200009140727.JAA02687@loewis.home.cs.tu-berlin.de>
Message-ID: <m3pum7mkv4.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
| 
| [xml.sax.parse(file, MyHandler())]
|
| It's not SAX compatible, though, is it? 

It is if we say it is. :-)

| In SAX, I'd expect to create a reader object using some out-of-scope
| operation, then invoke setContentHandler() on this object. I think
| that should be supported somehow.

I agree, and I think we should retain that in SAX 2.0.  However, I
think Paul is right in that the parse function is useful as a
shorthand that captures what you want to do in 95% of the cases.
 
| What was wrong with sax2utils.make_parser() to not include it in
| Python 2?

I think we should extend it so that the default parser list can be
modified both from Python code and set via an environment variable
(PY_SAX_PARSER?).  Other than that I think SAX 1.0 showed this
approach to be very successful.

It should probably appear as

from xml import sax
parser = sax.make_parser()

--Lars M.



From Juergen Hermann" <jh@web.de  Thu Sep 14 10:47:48 2000
From: Juergen Hermann" <jh@web.de (Juergen Hermann)
Date: Thu, 14 Sep 2000 11:47:48 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <39C074C3.94809D07@prescod.net>

On Wed, 13 Sep 2000 23:48:35 -0700, Paul Prescod wrote:

>XML module without removing anything, but PyXML has not been made 2.0
>compatible yet.

BTW, am I right that one aim is to keep PyXML 1.5.2-compatible too, for =

some time (say, at least until 2.0 final is released)?


Ciao, J=FCrgen

--
J=FCrgen Hermann, Developer (jhe@webde-ag.de)
WEB.DE AG, http://webde-ag.de/




From fdrake@beopen.com  Thu Sep 14 14:50:08 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 14 Sep 2000 09:50:08 -0400 (EDT)
Subject: [XML-SIG] XML for Python 2
In-Reply-To: <200009140735.JAA02787@loewis.home.cs.tu-berlin.de>
References: <39C07AB3.92549BCD@prescod.net>
 <200009140735.JAA02787@loewis.home.cs.tu-berlin.de>
Message-ID: <14784.55184.63988.931573@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > I'd like to look into updating PyXML so it gets compatible with Python
 > 2. That may not be essential for Python 2.0 itself, but it will serve
 > as a proof-of-concept that the _xmlplus approach really works.

  Actually, we at PythonLabs consider this essential for Python
2.0b2.  If we cannot have an working combination of Python 2.0b2 +
PyXML, the xml package in the standard library should be ripped out
and put on hold until we can offer a working combination.
  And I'd rather this be done for 2.0 than for 2.1.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From jeremy@beopen.com  Thu Sep 14 16:31:53 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Thu, 14 Sep 2000 11:31:53 -0400 (EDT)
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <39C06C97.245CB6A@prescod.net>
References: <935085382.20000912182634@email.com>
 <m3u2bkoi5h.fsf@lambda.garshol.priv.no>
 <14783.31377.63536.118426@bitdiddle.concentric.net>
 <200009131853.UAA01501@loewis.home.cs.tu-berlin.de>
 <14784.14058.523463.456333@bitdiddle.concentric.net>
 <39C06C97.245CB6A@prescod.net>
Message-ID: <14784.61289.622668.781250@bitdiddle.concentric.net>

>>>>> "PP" == Paul Prescod <paul@prescod.net> writes:

  PP> Jeremy Hylton wrote:
  >> The implementation needs to work, too!  Let's optimistically say
  >> we have a Python 2.1 release nine months after a 2.0 release.
  >> That means that every new Python during that time will try to use
  >> the builtin XML libraries and have problems.

  PP> What problems are you referring to? The fourthought guys just
  PP> went through a pretty thorough review of minidom and found only
  PP> a few minor bugs. In the modules and libraries sections of
  PP> sourceforge's bug tracker I see only one listed bug. Expat has
  PP> hardly changed from the expat that people have been using
  PP> productively for years. I don't know of PyExpat bugs.

Have you read the rest of this thread?  Look at the post by Lars, the
second message in the thread.  He explains that the SAX2 doesn't
really work, after a problem report by a user.

Jeremy


From paul@prescod.net  Thu Sep 14 16:37:18 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 14 Sep 2000 08:37:18 -0700
Subject: [XML-SIG] Uniform interface with Python 2.0
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net> <200009140727.JAA02687@loewis.home.cs.tu-berlin.de>
Message-ID: <39C0F0AE.42E318DB@prescod.net>

"Martin v. Loewis" wrote:
> 
>...
> 
> It's not SAX compatible, though, is it? 

We're defining SAX: for Python.

> In SAX, I'd expect to create a
> reader object using some out-of-scope operation, then invoke
> setContentHandler() on this object. I think that should be supported
> somehow.

That's totally supported it just isn't the default way to do things. It
puts the emphasis on the parser when the programmer's emphasis is
typically on their XML file and their handler.

> What was wrong with sax2utils.make_parser() to not include it in
> Python 2?

There's nothing wrong with make_parser but the first priority is getting
people parsing with the fewest possible steps. Those who want to do the
"parser first" can create an ExpatParser. I think that there are
probably a few situations where you don't care what parser you get but
you want a "first class" parser before you begin parsing. We could add
make_parser for those situations but it isn't personally my first
priority. You could submit a patch.


-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 16:38:52 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 14 Sep 2000 08:38:52 -0700
Subject: [XML-SIG] XML for Python 2
References: <39C07AB3.92549BCD@prescod.net> <m3u2bjmmg8.fsf@lambda.garshol.priv.no>
Message-ID: <39C0F10C.BBCFA6C6@prescod.net>

Lars Marius Garshol wrote:
> 
> ...
> 
> If someone else could do the SAX documentation I think that would be
> useful as a combined test of common understanding and sanity check.
> I can of course do it if nobody else can, but it might be better if
> someone else does it.

I can do the SAX documentation.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 16:43:35 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 14 Sep 2000 08:43:35 -0700
Subject: [XML-SIG] Uniform interface with Python 2.0
References: <200009140949.FAA13749@lambe.pair.com>
Message-ID: <39C0F227.F65CA110@prescod.net>

Juergen Hermann wrote:
> 
> On Wed, 13 Sep 2000 23:48:35 -0700, Paul Prescod wrote:
> 
> >XML module without removing anything, but PyXML has not been made 2.0
> >compatible yet.
> 
> BTW, am I right that one aim is to keep PyXML 1.5.2-compatible too, for
> some time (say, at least until 2.0 final is released)?

I think we should make a 1.5.2=compatible snapshot. Nobody is adding
features to PyXML between now and Python 2. We are just doing changes to
make it compatible. So you don't lose anything by using the snapshot.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 16:44:11 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 14 Sep 2000 08:44:11 -0700
Subject: [XML-SIG] Uniform interface with Python 2.0
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net> <200009140727.JAA02687@loewis.home.cs.tu-berlin.de> <m3pum7mkv4.fsf@lambda.garshol.priv.no>
Message-ID: <39C0F24B.597F6B82@prescod.net>

Lars Marius Garshol wrote:
> 
> ...
> 
> I think we should extend it so that the default parser list can be
> modified both from Python code and set via an environment variable
> (PY_SAX_PARSER?).  Other than that I think SAX 1.0 showed this
> approach to be very successful.

If you want to implement it i won't complain but I think that this
autoconfiguration stuff is overrated. The number 1 feature of SAX is
that I can change my mind and go from Expat to XMLProc in five minutes
rather than five hours. The number 2 feature is I can program for any
parser without reading parser-specific documentation. Dynamic parser
choice is low on the list of benefits, in my personal opinion. Plus, you
could always use Python's dynamic import features to implement your own
dynamic parser choice.

> It should probably appear as
> 
> from xml import sax
> parser = sax.make_parser()

Agreed. And it probably wouldn't hurt to have an optional parser
argument to parse() and parseString()

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From johann@egenetics.com  Thu Sep 14 17:01:06 2000
From: johann@egenetics.com (Johann Visagie)
Date: Thu, 14 Sep 2000 18:01:06 +0200
Subject: [XML-SIG] Bug in xml/dom/core.py
Message-ID: <20000914180106.B47916@fling.sanbi.ac.za>

Surely the following is a case of reversed parameters to isinstance()?  I
found the problem in 0.5.4, 0.5.5 and 0.5.5.1.

(Apologies if this is not the correct place to post this sort of report.)

Regards,
-- Johann


--- xml/dom/core.py.orig	Tue Jun  6 01:46:32 2000
+++ xml/dom/core.py	Thu Sep 14 17:55:54 2000
@@ -154,7 +154,7 @@
 
     # Check doctype value, if provided.
     if doctype is not None:
-        if not isinstance( DocumentType, doctype ):
+        if not isinstance( doctype, DocumentType ):
             raise ValueError, ('doctype argument must be a DocumentType node: '
                                + repr(doctype) )


From fdrake@beopen.com  Thu Sep 14 17:01:27 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 14 Sep 2000 12:01:27 -0400 (EDT)
Subject: [XML-SIG] XML for Python 2
In-Reply-To: <39C0F10C.BBCFA6C6@prescod.net>
References: <39C07AB3.92549BCD@prescod.net>
 <m3u2bjmmg8.fsf@lambda.garshol.priv.no>
 <39C0F10C.BBCFA6C6@prescod.net>
Message-ID: <14784.63063.101819.340600@cj42289-a.reston1.va.home.com>

Paul Prescod writes:
 > I can do the SAX documentation.

  Please start with what's already in the PyXML CVS repository.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From akuchlin@mems-exchange.org  Thu Sep 14 17:09:45 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 14 Sep 2000 12:09:45 -0400
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <39C0F227.F65CA110@prescod.net>; from paul@prescod.net on Thu, Sep 14, 2000 at 08:43:35AM -0700
References: <200009140949.FAA13749@lambe.pair.com> <39C0F227.F65CA110@prescod.net>
Message-ID: <20000914120945.B31741@kronos.cnri.reston.va.us>

On Thu, Sep 14, 2000 at 08:43:35AM -0700, Paul Prescod wrote:
>I think we should make a 1.5.2=compatible snapshot. Nobody is adding
>features to PyXML between now and Python 2. We are just doing changes to
>make it compatible. So you don't lose anything by using the snapshot.

Someone is free to provide appropriate patches, but my interest in
actually doing the work for that myself is nil.  2.0 has better and
more flexible Unicode support than that available from wstrop for
1.5.2, so anyone doing serious XML work should be quickly switching to
2.0, therefore 1.5.2 compatibility is no longer of interest to me.

--amk


From paul@prescod.net  Thu Sep 14 17:25:46 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 14 Sep 2000 09:25:46 -0700
Subject: [XML-SIG] SAX2 in python20b1 usable?
References: <935085382.20000912182634@email.com>
 <m3u2bkoi5h.fsf@lambda.garshol.priv.no>
 <14783.31377.63536.118426@bitdiddle.concentric.net>
 <200009131853.UAA01501@loewis.home.cs.tu-berlin.de>
 <14784.14058.523463.456333@bitdiddle.concentric.net>
 <39C06C97.245CB6A@prescod.net> <14784.61289.622668.781250@bitdiddle.concentric.net>
Message-ID: <39C0FC0A.82BD81BE@prescod.net>

Jeremy Hylton wrote:
> 
> ...
> 
> Have you read the rest of this thread?  Look at the post by Lars, the
> second message in the thread.  He explains that the SAX2 doesn't
> really work, after a problem report by a user.

Lars wasn't really specific either. I'm using SAX2 from minidom with no
problems. If someone would be specific I would fix the bug!

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From paul@prescod.net  Thu Sep 14 17:26:44 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 14 Sep 2000 09:26:44 -0700
Subject: [XML-SIG] XML for Python 2
References: <39C07AB3.92549BCD@prescod.net> <200009140735.JAA02787@loewis.home.cs.tu-berlin.de>
Message-ID: <39C0FC44.E889B0F1@prescod.net>

That would be great. You should check with Andrew to see what he has
done on this and then continue from there.

"Martin v. Loewis" wrote:
> 
> > PyXML integration
> 
> I'd like to look into updating PyXML so it gets compatible with Python
> 2. That may not be essential for Python 2.0 itself, but it will serve
> as a proof-of-concept that the _xmlplus approach really works.
> 
> Regards,
> Martin

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From larsga@garshol.priv.no  Thu Sep 14 17:29:18 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 14 Sep 2000 18:29:18 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <39C0FC0A.82BD81BE@prescod.net>
References: <935085382.20000912182634@email.com> 		<m3u2bkoi5h.fsf@lambda.garshol.priv.no> 		<14783.31377.63536.118426@bitdiddle.concentric.net> 		<200009131853.UAA01501@loewis.home.cs.tu-berlin.de> 		<14784.14058.523463.456333@bitdiddle.concentric.net> 		<39C06C97.245CB6A@prescod.net> <14784.61289.622668.781250@bitdiddle.concentric.net> <39C0FC0A.82BD81BE@prescod.net>
Message-ID: <m3zolbkkdd.fsf@lambda.garshol.priv.no>

* Jeremy Hylton
| 
| Have you read the rest of this thread?  Look at the post by Lars,
| the second message in the thread.  He explains that the SAX2 doesn't
| really work, after a problem report by a user.

* Paul Prescod
| 
| Lars wasn't really specific either. I'm using SAX2 from minidom with
| no problems. If someone would be specific I would fix the bug!

The 'bug' is that the interfaces are not what we agreed that the
interfaces should be (after the last round of discussion). So in that
sense it is not in a usable state.

--Lars M.



From fdrake@beopen.com  Thu Sep 14 17:31:38 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 14 Sep 2000 12:31:38 -0400 (EDT)
Subject: [XML-SIG] Bug in xml/dom/core.py
In-Reply-To: <20000914180106.B47916@fling.sanbi.ac.za>
References: <20000914180106.B47916@fling.sanbi.ac.za>
Message-ID: <14784.64874.377127.193301@cj42289-a.reston1.va.home.com>

Johann Visagie writes:
 > Surely the following is a case of reversed parameters to isinstance()?  I
 > found the problem in 0.5.4, 0.5.5 and 0.5.5.1.

  The old PyDOM is no longer part of the PyXML code base; core.py was
part of that.

 > (Apologies if this is not the correct place to post this sort of report.)

  Right place, just an old version of the code.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From camnews@saaraktuell.de  Thu Sep 14 18:39:50 2000
From: camnews@saaraktuell.de (SaarAktuell Infoservice)
Date: 14 Sep 00 17:39:50 +-0200
Subject: [XML-SIG] SaarAktuell - der regionale Webkatalog ist online
Message-ID: <E13ZcR0-0003IX-00@mrvdom02.schlund.de>

-------------------------------------------------------------------------

           SAARAKTUELL Infomail   Ausgabe: 14.09.2000  
                Internet: http://www.saaraktuell.de
                                                                                                                             
-------------------------------------------------------------------------

Guten Tag xml-sig@python.org,

SaarAktuell - der regionale Webkatalog aus dem Südwesten ist online.

Nehmen Sie aktiv an unserem Angebot teil und sichern Sie sich die besten
Plätze durch den kostenlosen Eintrag Ihrer Internetseiten.

Steigern Sie den Bekannheitsgrad Ihres Online Angebotes. Uns ist es egal,
ob Sie eine kleine Homepage oder eine große Website haben - alle sind
willkommen an unserem Webkatalog teilzunehmen. 

Falls Sie Fragen oder Anregungen zu der Suchmaschine haben sollten,
schreiben Sie uns eine Mail.

Viel Spass beim durchstöbern von SaarAktuell wünscht

  Ihr SaarAktuell Team

------------------------------------------------------------------------
        "SAARAKTUELL" ist ein Projekt der Protectcom.de
  SaarAktuell - der regionale Webkatalog - (c) Copyright SaarAktuell
   www: http://www.saaraktuell.de  ---  mailto:info@saaraktuell.de
-------------------------------------------------------------------------

Anmerkung: Dies ist kein SPAM. Es ist ein Angebot an Sie, an unserem
Webkatalog teilzunehmen. Wir bieten große Vielfalt an regionalen Angeboten
- oft direkt von regionalen Surfern vorgeschlagen. Unsere Seite deckt ein
breites inhaltliches Spektrum ab. Dieses erstreckt sich auf über 13780
Rubriken. Sie werden unaufgefordert keine weiteren Emails von uns erhalten.



From martin@loewis.home.cs.tu-berlin.de  Thu Sep 14 19:33:31 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 14 Sep 2000 20:33:31 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <14784.61289.622668.781250@bitdiddle.concentric.net> (message
 from Jeremy Hylton on Thu, 14 Sep 2000 11:31:53 -0400 (EDT))
References: <935085382.20000912182634@email.com>
 <m3u2bkoi5h.fsf@lambda.garshol.priv.no>
 <14783.31377.63536.118426@bitdiddle.concentric.net>
 <200009131853.UAA01501@loewis.home.cs.tu-berlin.de>
 <14784.14058.523463.456333@bitdiddle.concentric.net>
 <39C06C97.245CB6A@prescod.net> <14784.61289.622668.781250@bitdiddle.concentric.net>
Message-ID: <200009141833.UAA00779@loewis.home.cs.tu-berlin.de>


From martin@loewis.home.cs.tu-berlin.de  Thu Sep 14 19:38:05 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 14 Sep 2000 20:38:05 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <39C0F0AE.42E318DB@prescod.net> (message from Paul Prescod on
 Thu, 14 Sep 2000 08:37:18 -0700)
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net> <200009140727.JAA02687@loewis.home.cs.tu-berlin.de> <39C0F0AE.42E318DB@prescod.net>
Message-ID: <200009141838.UAA00783@loewis.home.cs.tu-berlin.de>

> > It's not SAX compatible, though, is it? 
> 
> We're defining SAX: for Python.

Yes, but users will expect that basic methodology is similar across
languages, won't they? If not, we could say "the native xmlproc API is
SAX for Python", yet it still would not be SAX. Essentially, you can
*not* arbitrarily define SAX.

> > In SAX, I'd expect to create a
> > reader object using some out-of-scope operation, then invoke
> > setContentHandler() on this object. I think that should be supported
> > somehow.
> 
> That's totally supported it just isn't the default way to do things. It
> puts the emphasis on the parser when the programmer's emphasis is
> typically on their XML file and their handler.

But does it also support setting an error handler?

> We could add make_parser for those situations but it isn't
> personally my first priority. You could submit a patch.

I will.

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Thu Sep 14 19:34:57 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 14 Sep 2000 20:34:57 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <14784.61289.622668.781250@bitdiddle.concentric.net> (message
 from Jeremy Hylton on Thu, 14 Sep 2000 11:31:53 -0400 (EDT))
References: <935085382.20000912182634@email.com>
 <m3u2bkoi5h.fsf@lambda.garshol.priv.no>
 <14783.31377.63536.118426@bitdiddle.concentric.net>
 <200009131853.UAA01501@loewis.home.cs.tu-berlin.de>
 <14784.14058.523463.456333@bitdiddle.concentric.net>
 <39C06C97.245CB6A@prescod.net> <14784.61289.622668.781250@bitdiddle.concentric.net>
Message-ID: <200009141834.UAA00782@loewis.home.cs.tu-berlin.de>

> Have you read the rest of this thread?  Look at the post by Lars, the
> second message in the thread.  He explains that the SAX2 doesn't
> really work, after a problem report by a user.

Yes, but I'm still in the dark as to what he meant by "does not really
work". Paul said it really works. If you want, I can say that too :-)

So I really like to see code that should work but doesn't (true bug
reports, so to speak).

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Thu Sep 14 19:41:19 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 14 Sep 2000 20:41:19 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <m3zolbkkdd.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 14 Sep 2000 18:29:18 +0200)
References: <935085382.20000912182634@email.com> 		<m3u2bkoi5h.fsf@lambda.garshol.priv.no> 		<14783.31377.63536.118426@bitdiddle.concentric.net> 		<200009131853.UAA01501@loewis.home.cs.tu-berlin.de> 		<14784.14058.523463.456333@bitdiddle.concentric.net> 		<39C06C97.245CB6A@prescod.net> <14784.61289.622668.781250@bitdiddle.concentric.net> <39C0FC0A.82BD81BE@prescod.net> <m3zolbkkdd.fsf@lambda.garshol.priv.no>
Message-ID: <200009141841.UAA00802@loewis.home.cs.tu-berlin.de>

> The 'bug' is that the interfaces are not what we agreed that the
> interfaces should be (after the last round of discussion). So in that
> sense it is not in a usable state.

For those of us not who did not participate: What is it that you did
agree on, and what happened instead?

Regards,
Martin



From prescod@prescod.net  Thu Sep 14 19:47:26 2000
From: prescod@prescod.net (Paul)
Date: Thu, 14 Sep 2000 13:47:26 -0500 (CDT)
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <200009141834.UAA00782@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0009141342410.25261-100000@amati.techno.com>

On Thu, 14 Sep 2000, Martin v. Loewis wrote:

> > Have you read the rest of this thread?  Look at the post by Lars, the
> > second message in the thread.  He explains that the SAX2 doesn't
> > really work, after a problem report by a user.
> 
> Yes, but I'm still in the dark as to what he meant by "does not really
> work". Paul said it really works. If you want, I can say that too :-)
> 
> So I really like to see code that should work but doesn't (true bug
> reports, so to speak).

I looked into it further this morning and I did find some bugs. Minidom
uses a slightly different part of the API than some other SAX users might,
so I wasn't seeing them. I've sent patches in now. I think it would be
worthwhile to apply them now for immediate use even if Lars is working on
more far-reaching stuff.

 Paul



From prescod@prescod.net  Thu Sep 14 20:52:45 2000
From: prescod@prescod.net (Paul)
Date: Thu, 14 Sep 2000 14:52:45 -0500 (CDT)
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <200009141841.UAA00802@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0009141448140.25261-100000@amati.techno.com>

On Thu, 14 Sep 2000, Martin v. Loewis wrote:

> > The 'bug' is that the interfaces are not what we agreed that the
> > interfaces should be (after the last round of discussion). So in that
> > sense it is not in a usable state.
> 
> For those of us not who did not participate: What is it that you did
> agree on, and what happened instead?

Actually, I was going to ask the same question. As I recall, we left the
discussion on handler method signatures at: "Lars, do what you want."
That's with respect to some method signatures. He might also be talking
about the difference between SAX in Python 2 versus SAX 2 on his website.

Just before 2.0 alpha was supposed to ship I also made some API changes to
simplify and shrink the API from the one on his website. e.g. I added the
parse() functions and removed the (in my opinion...) Java-esque
InputSource class. I'm not sure which of those changes Lars intends to
keep versus roll-back.

 Paul




From prescod@prescod.net  Thu Sep 14 21:07:47 2000
From: prescod@prescod.net (Paul)
Date: Thu, 14 Sep 2000 15:07:47 -0500 (CDT)
Subject: [XML-SIG] XML for Python 2
In-Reply-To: <14785.9330.129808.632231@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0009141453110.25261-100000@amati.techno.com>

On Thu, 14 Sep 2000, Fred L. Drake, Jr. wrote:

> 
> Paul Prescod writes:
>  > decision on whether to document pulldom
> 
>   Perhaps you could described in a short message to the SIG what the
> differences are?  We could each look at the code, but a paragraph that
> describes the differences might be the easiest for everyone to digest.
> (You've probably done this already & I've just forgotten; a pointer
> into the archive or resend should be fine in that case.)

Are you asking: "What is PullDOM and how does it relate to SAX?" If so,
here are some references:

http://www.python.org/pipermail/xml-sig/2000-June/004205.html 
http://www.xml.com/pub/r/PullDOM_and_MiniDOM
http://www.python.org/pipermail/xml-sig/2000-June/004223.html
http://www.python.org/pipermail/xml-sig/2000-June/004274.html
http://www.python.org/pipermail/xml-sig/2000-May/003942.html
http://www.python.org/pipermail/xml-sig/2000-May/003947.html
http://www.python.org/pipermail/xml-sig/2000-May/003987.html
http://www.python.org/pipermail/xml-sig/2000-May/004013.html

The point of PullDOM is that a person who is fairly familiar with XML and
Python should be able to get up and running in 10 minutes. Although it is
not as convenient as other APIs I have used (and developed) it should be
efficient enough and powerful enough for almost any application. More
convenient layers (particularly dispatchers) can be built on top and
compete for inclusion in 2.1 or whatever.

>  > overall documentation
> 
>   What sort of documentation were you thinking of here?  Is this
> something other than module reference material?

No, I'm talking about the module reference. It needs to document all of
our final decisions.

 Paul



From fdrake@beopen.com  Thu Sep 14 21:05:35 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 14 Sep 2000 16:05:35 -0400 (EDT)
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <Pine.LNX.4.21.0009141448140.25261-100000@amati.techno.com>
References: <200009141841.UAA00802@loewis.home.cs.tu-berlin.de>
 <Pine.LNX.4.21.0009141448140.25261-100000@amati.techno.com>
Message-ID: <14785.12175.588416.892002@cj42289-a.reston1.va.home.com>

Paul writes:
 > Actually, I was going to ask the same question. As I recall, we left the
 > discussion on handler method signatures at: "Lars, do what you want."
 > That's with respect to some method signatures. He might also be talking
 > about the difference between SAX in Python 2 versus SAX 2 on his website.

  Ok, Lars, sounds like a summary of the signature changes that are
needed is on your plate.  Paul's indicated his willingness to work on
the documentation once we're clear on the signatures.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From martin@loewis.home.cs.tu-berlin.de  Thu Sep 14 21:10:22 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 14 Sep 2000 22:10:22 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
Message-ID: <200009142010.WAA01589@loewis.home.cs.tu-berlin.de>

* Paul Prescod

| SAX API finalized
| SAX implementation finalized
| SAX test suite checked in

* Lars Marius Garshol

> I've thought about it and decided that I can do all of these within
> two weeks.

I'd like to caution that the final release of Python 2.0 is scheduled
for Oct 6. So I'd rather suggest that only essential work is done,
instead of trying to 'improve' things significantly. Feature-freeze
for Python 2.0 was several weeks ago, so only things that won't work
[as documented :-] may be fixed now.

I doubt any significant changes to the xml package will be accepted a
week before the release.

If you were talking about changing PyXML instead, just ignore me.

Regards,
Martin


From paul@prescod.net  Fri Sep 15 05:18:53 2000
From: paul@prescod.net (Paul Prescod)
Date: Thu, 14 Sep 2000 21:18:53 -0700
Subject: [XML-SIG] Uniform interface with Python 2.0
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net> <200009140727.JAA02687@loewis.home.cs.tu-berlin.de> <39C0F0AE.42E318DB@prescod.net> <200009141838.UAA00783@loewis.home.cs.tu-berlin.de>
Message-ID: <39C1A32D.874C77AF@prescod.net>

"Martin v. Loewis" wrote:
> 
> ...
> 
> Yes, but users will expect that basic methodology is similar across
> languages, won't they? 

I don't think anyone will complain if it is simpler and easier to use in
Python than in SAX.

> If not, we could say "the native xmlproc API is
> SAX for Python", yet it still would not be SAX. Essentially, you can
> *not* arbitrarily define SAX.

We've knowingly diverged on a variety of issues. The point is that we
use the same streaming model as SAX. Any saxutils.make_parser() is not
part of Java SAX either.

> But does it also support setting an error handler?

It's an optional keyword argument named "errorHandler".

> > We could add make_parser for those situations but it isn't
> > personally my first priority. You could submit a patch.
> 
> I will.

Okay, but the integration with PyXML is higher priority.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From Stephan Tolksdorf <andorxor@gmx.de>  Fri Sep 15 16:55:07 2000
From: Stephan Tolksdorf <andorxor@gmx.de> (Stephan Tolksdorf)
Date: Fri, 15 Sep 2000 17:55:07 +0200
Subject: Re[2]: [XML-SIG] SAX2 in python20b1 usable?
Message-ID: <35548528.20000915175507@email.com>

Hello Paul,

> I looked into it further this morning and I did find some bugs. Minidom
> uses a slightly different part of the API than some other SAX users might,
> so I wasn't seeing them. I've sent patches in now. I think it would be
> worthwhile to apply them now for immediate use even if Lars is working on
> more far-reaching stuff.

I've seen one patch in the patch-manager that addresses the problem of
initial opening of files with ExpatReader.parse(filname). The patch doesn't
really solve the Problem as ExpatReader's prepareParser still expects a
filename not an opened file which prepareParser gets from IncrementalParser.parse().

Another thing which confuses me is that ExpatReader expects an
interface which is different from handler.ContentHandler
(startElement and endElement have different signatures in pulldom.py and
handler.py). Maybe ContentHandlers inferface isn't uptodate? This is the
source for my original problems...

Best regards,
  Stephan Tolksdorf




From paul@prescod.net  Fri Sep 15 17:12:26 2000
From: paul@prescod.net (Paul Prescod)
Date: Fri, 15 Sep 2000 09:12:26 -0700
Subject: [XML-SIG] SAX2 in python20b1 usable?
References: <35548528.20000915175507@email.com>
Message-ID: <39C24A6A.4B28E625@prescod.net>

Stephan Tolksdorf wrote:
> 
> ...
> 
> I've seen one patch in the patch-manager that addresses the problem of
> initial opening of files with ExpatReader.parse(filname). The patch doesn't
> really solve the Problem as ExpatReader's prepareParser still expects a
> filename not an opened file which prepareParser gets from IncrementalParser.parse().

Once this patch is applied it will not be a problem:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101514&group_id=5470

prepareParser becomes essentially a no-op.

> Another thing which confuses me is that ExpatReader expects an
> interface which is different from handler.ContentHandler
> (startElement and endElement have different signatures in pulldom.py and
> handler.py). Maybe ContentHandlers inferface isn't uptodate? This is the
> source for my original problems...

You are right, the published interface isn't up-to-date. That's
basically a documentation issue. You could submit a patch but I think
Lars is still going to change those method signatures next week.

Since you understand things so well, maybe you could do me a favor and
try pulldom and see if it meets your needs. The interface is very
static, and very extensible so future extensions to XML should not break
it. We are deciding whether to make pulldom an official API and your
opinion would help.

-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From andorxor@gmx.de  Fri Sep 15 17:19:24 2000
From: andorxor@gmx.de (Stephan Tolksdorf)
Date: Fri, 15 Sep 2000 18:19:24 +0200
Subject: [XML-SIG] Typo in sax.__init__.py
Message-ID: <1837005913.20000915181924@email.com>

Another bug:
In parse and parseString there's a small mistake...

parser=ExpatParser()
parser.setContentHandler( handler )
parse.setErrorHandler( errorHandler )
     ^.... Shouldn't there be an extra r?
parser.parse( buf )

Stephan Tolksdorf




From larsga@garshol.priv.no  Fri Sep 15 18:22:55 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 15 Sep 2000 19:22:55 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <39C24A6A.4B28E625@prescod.net>
References: <35548528.20000915175507@email.com> <39C24A6A.4B28E625@prescod.net>
Message-ID: <m366nx1seo.fsf@lambda.garshol.priv.no>

* Paul Prescod
| 
| You are right, the published interface isn't up-to-date. That's
| basically a documentation issue. You could submit a patch but I
| think Lars is still going to change those method signatures next
| week.

I will work on this during the weekend and try to produce some
documentation of what I am planning to do so that you people can have
a look at it next week before I actually commit anything.

--Lars M.



From prescod@prescod.net  Fri Sep 15 18:34:15 2000
From: prescod@prescod.net (Paul)
Date: Fri, 15 Sep 2000 12:34:15 -0500 (CDT)
Subject: [XML-SIG] Typo in sax.__init__.py
In-Reply-To: <1837005913.20000915181924@email.com>
Message-ID: <Pine.LNX.4.21.0009151233410.2310-100000@amati.techno.com>

Thanks, that was one of the bugs I fixed yesterday.

http://sourceforge.net/patch/?func=detailpatch&patch_id=101511&group_id=5470


On Fri, 15 Sep 2000, Stephan Tolksdorf wrote:

> 
> Another bug:
> In parse and parseString there's a small mistake...
> 
> parser=ExpatParser()
> parser.setContentHandler( handler )
> parse.setErrorHandler( errorHandler )
>      ^.... Shouldn't there be an extra r?
> parser.parse( buf )
> 
> Stephan Tolksdorf
> 
> 
> 
> _______________________________________________
> XML-SIG maillist  -  XML-SIG@python.org
> http://www.python.org/mailman/listinfo/xml-sig
> 



From prescod@prescod.net  Fri Sep 15 18:38:12 2000
From: prescod@prescod.net (Paul)
Date: Fri, 15 Sep 2000 12:38:12 -0500 (CDT)
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <m366nx1seo.fsf@lambda.garshol.priv.no>
Message-ID: <Pine.LNX.4.21.0009151236110.2310-100000@amati.techno.com>

I'm just nervous that it sounds like you have big plans and we are very
short of time and have a lot of dependencies (minidom and pulldom depend
on SAX, the docs depend on SAX and so forth). Is it just a matter of
changing a few method signatures back? Guido is talking about dropping XML
from Python 2 so we've got to be a little strict. It's my fault if the
current package is too far from what you want but we don't have time to
add in a lot of stuff.

On 15 Sep 2000, Lars Marius Garshol wrote:

> 
> * Paul Prescod
> | 
> | You are right, the published interface isn't up-to-date. That's
> | basically a documentation issue. You could submit a patch but I
> | think Lars is still going to change those method signatures next
> | week.
> 
> I will work on this during the weekend and try to produce some
> documentation of what I am planning to do so that you people can have
> a look at it next week before I actually commit anything.
> 
> --Lars M.
> 
> 
> _______________________________________________
> XML-SIG maillist  -  XML-SIG@python.org
> http://www.python.org/mailman/listinfo/xml-sig
> 



From andorxor@gmx.de  Fri Sep 15 21:11:00 2000
From: andorxor@gmx.de (Stephan Tolksdorf)
Date: Fri, 15 Sep 2000 22:11:00 +0200
Subject: [XML-SIG] Typo in sax.__init__.py
In-Reply-To: <Pine.LNX.4.21.0009151233410.2310-100000@amati.techno.com>
References: <Pine.LNX.4.21.0009151233410.2310-100000@amati.techno.com>
Message-ID: <8820901965.20000915221100@email.com>

> Thanks, that was one of the bugs I fixed yesterday.

> http://sourceforge.net/patch/?func=detailpatch&patch_id=101511&group_id=5470

Sorry, that's the second time I overlooked a patch. The next time I'll
not only look at the open patches..

Stephan Tolksdorf




From akuchlin@mems-exchange.org  Sat Sep 16 02:10:30 2000
From: akuchlin@mems-exchange.org (A.M. Kuchling)
Date: Fri, 15 Sep 2000 21:10:30 -0400
Subject: [XML-SIG] Problem with using _xmlplus
Message-ID: <E13a6Uw-0003ud-00@207-172-111-249.s249.tnt1.ann.va.dialup.rcn.com>

The code in Lib/xml/__init__.py seems to be insufficient to completely
delegate matters to the _xmlplus package.  Consider this session with
'python -v':

Script started on Fri Sep 15 21:02:59 2000
[amk@207-172-111-249 quotations]$ python -v
  ...
>>> from xml.sax import saxlib, saxexts
import xml # directory /usr/lib/python2.0/xml
import xml # precompiled from /usr/lib/python2.0/xml/__init__.pyc
import _xmlplus # directory /usr/lib/python2.0/site-packages/_xmlplus
import _xmlplus # from /usr/lib/python2.0/site-packages/_xmlplus/__init__.py
import xml.sax # directory /usr/lib/python2.0/site-packages/_xmlplus/sax
import xml.sax # from /usr/lib/python2.0/site-packages/_xmlplus/sax/__init__.py
import xml.sax.saxlib # from /usr/lib/python2.0/site-packages/_xmlplus/sax/saxlib.py
import xml.sax.saxexts # from /usr/lib/python2.0/site-packages/_xmlplus/sax/saxexts.py
import imp # builtin

So far, so good.  Now try creating a parser.  This fails; I've hacked
the code slightly so it doesn't swallow the responsible ImportError:

>>> p=saxexts.XMLParserFactory.make_parser("xml.sax.drivers.drv_pyexpat")
import xml # directory /usr/lib/python2.0/xml
import xml # precompiled from /usr/lib/python2.0/xml/__init__.pyc
import sax # directory /usr/lib/python2.0/xml/sax
import sax # precompiled from /usr/lib/python2.0/xml/sax/__init__.pyc
import sax.handler # precompiled from /usr/lib/python2.0/xml/sax/handler.pyc
import sax.expatreader # precompiled from /usr/lib/python2.0/xml/sax/expatreader.pyc
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.0/site-packages/_xmlplus/sax/saxexts.py", line 78, in make_parser
    info=rec_find_module(parser_name)
  File "/usr/lib/python2.0/site-packages/_xmlplus/sax/saxexts.py", line 25, in rec_find_module
    lastmod=apply(imp.load_module,info)
  File "/usr/lib/python2.0/xml/sax/__init__.py", line 21, in ?
    from expatreader import ExpatParser
  File "/usr/lib/python2.0/xml/sax/expatreader.py", line 23, in ?
    from xml.sax import xmlreader
ImportError: cannot import name xmlreader

_xmlplus.sax.saxexts uses imp.find_module() and imp.load_module() to
load parser drives; it looks like those functions aren't looking at
sys.modules and therefore aren't being fooled by the sys.modules
hackery in Lib/xml/__init__.py, so the _xmlplus package isn't
completely overriding the xml/ package.

The guts of Python's import machinery have always been mysterious to
me; can anyone suggest how to fix this?

--amk


From guido@beopen.com  Sat Sep 16 03:06:28 2000
From: guido@beopen.com (Guido van Rossum)
Date: Fri, 15 Sep 2000 21:06:28 -0500
Subject: [XML-SIG] Re: [Python-Dev] Problem with using _xmlplus
In-Reply-To: Your message of "Fri, 15 Sep 2000 21:10:30 -0400."
 <E13a6Uw-0003ud-00@207-172-111-249.s249.tnt1.ann.va.dialup.rcn.com>
References: <E13a6Uw-0003ud-00@207-172-111-249.s249.tnt1.ann.va.dialup.rcn.com>
Message-ID: <200009160206.VAA09344@cj20424-a.reston1.va.home.com>

[Andrew discovers that the _xmlplus hack is broken]

I have recently proposed a simple and robust fix: forget all import
hacking, and use a different name for the xml package in the core and
the xml package provided by PyXML.  I first suggested the name
'xmlcore' for the core xml package, but Martin von Loewis suggested a
better name: 'xmlbase'.

Since PyXML has had dibs on the 'xml' package name for years, it's
best not to try to change that.  We can't force everyone who has
installed an old version of PyXML to upgrade (and to erase the old
package!) so the best solution is to pick a new name for the core XML
support package.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)


From martin@loewis.home.cs.tu-berlin.de  Sat Sep 16 07:24:41 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 16 Sep 2000 08:24:41 +0200
Subject: [XML-SIG] Problem with using _xmlplus
In-Reply-To: <E13a6Uw-0003ud-00@207-172-111-249.s249.tnt1.ann.va.dialup.rcn.com>
 (amk1@erols.com)
References: <E13a6Uw-0003ud-00@207-172-111-249.s249.tnt1.ann.va.dialup.rcn.com>
Message-ID: <200009160624.IAA00804@loewis.home.cs.tu-berlin.de>

> The guts of Python's import machinery have always been mysterious to
> me; can anyone suggest how to fix this?

I had a patch for some time on SF, waiting for approval,
(http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473)
to fix that; I have now installed that patch.

Regards,
Martin


From larsga@garshol.priv.no  Sat Sep 16 11:23:58 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 16 Sep 2000 12:23:58 +0200
Subject: [XML-SIG] SAX2 in python20b1 usable?
In-Reply-To: <Pine.LNX.4.21.0009151236110.2310-100000@amati.techno.com>
References: <Pine.LNX.4.21.0009151236110.2310-100000@amati.techno.com>
Message-ID: <m3n1h8y6rl.fsf@lambda.garshol.priv.no>

* prescod@prescod.net
|
| I'm just nervous that it sounds like you have big plans and we are
| very short of time and have a lot of dependencies (minidom and
| pulldom depend on SAX, the docs depend on SAX and so forth). Is it
| just a matter of changing a few method signatures back? 

Basically, yes.  I outlined what I planned to do in this message

  <URL: http://www.python.org/pipermail/xml-sig/2000-July/004650.html >

and this is still the plan. The main changes are to the Attributes
object. 

I would also like to add back make_parser and perhaps make some minor
reorganizations. I seem to recall that I added some weird inherited
methods to do with incremental parsing that just add needless
complexity when there's only one parser to deal with.

That's more or less it (apart from the test suite), as far as I can
remember. I will sit down now to look at this more closely and
hopefully have something more detailed on Monday.

| Guido is talking about dropping XML from Python 2 so we've got to be
| a little strict. It's my fault if the current package is too far
| from what you want but we don't have time to add in a lot of stuff.

Not that it's all that interesting, but I think we can share the blame
evenly, at the very least.

--Lars M.



From larsga@garshol.priv.no  Sat Sep 16 11:26:34 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 16 Sep 2000 12:26:34 +0200
Subject: [XML-SIG] Re: [Python-Dev] Problem with using _xmlplus
In-Reply-To: <200009160206.VAA09344@cj20424-a.reston1.va.home.com>
References: <E13a6Uw-0003ud-00@207-172-111-249.s249.tnt1.ann.va.dialup.rcn.com> <200009160206.VAA09344@cj20424-a.reston1.va.home.com>
Message-ID: <m3lmwsy6n9.fsf@lambda.garshol.priv.no>

* Guido van Rossum
| 
| [suggests: the XML package in the Python core 'xmlbase']
| 
| Since PyXML has had dibs on the 'xml' package name for years, it's
| best not to try to change that.  We can't force everyone who has
| installed an old version of PyXML to upgrade (and to erase the old
| package!) so the best solution is to pick a new name for the core
| XML support package.

For what it's worth: I like this approach very much. It's simple,
intuitive and not likely to cause any problems.

--Lars M.



From larsga@garshol.priv.no  Sat Sep 16 12:16:27 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 16 Sep 2000 13:16:27 +0200
Subject: [XML-SIG] SAX 2.0 modifications
Message-ID: <m3hf7gy4c4.fsf@lambda.garshol.priv.no>

I've had a quick look through the files now before I go offline for
the weekend, and these are the changes I see now that I would like to
make. See 

<URL: http://www.python.org/pipermail/xml-sig/2000-July/004650.html > 

for some background.


 __init__.py:		Add make_parser.

 _exceptions.py:	No changes.

 expatreader.py:	Support for features and props.
			Support for external entity references.
			DocumentHandler *NS methods.
			Attributes.

 handler.py:		DocumentHandler *NS methods.
			Attributes.

 saxutils.py:		Update to interface changes.
			Make XMLGenerator NS-friendly.

 xmlreader.py:		Edit in DTDHandler and EntityResolver stuff.
			Modify AttributesImpl to new interface.
			Minor changes to IncrementalParser?
		

I also have a patch to pyexpat.c that would add support for external
entities, contributed by Oliver Gathmann.
	
--Lars M.



From tpassin@home.com  Sat Sep 16 07:13:53 2000
From: tpassin@home.com (tpassin@home.com)
Date: Sat, 16 Sep 2000 02:13:53 -0400
Subject: [XML-SIG] Re: [Python-Dev] Problem with using _xmlplus
References: <E13a6Uw-0003ud-00@207-172-111-249.s249.tnt1.ann.va.dialup.rcn.com>  <200009160206.VAA09344@cj20424-a.reston1.va.home.com>
Message-ID: <002501c01fe7$bfbe4c80$7cac1218@reston1.va.home.com>

+1 for this!

Guido van Rossum wrote -

> [Andrew discovers that the _xmlplus hack is broken]
> 
> I have recently proposed a simple and robust fix: forget all import
> hacking, and use a different name for the xml package in the core and
> the xml package provided by PyXML.  I first suggested the name
> 'xmlcore' for the core xml package, but Martin von Loewis suggested a
> better name: 'xmlbase'.
> 
> Since PyXML has had dibs on the 'xml' package name for years, it's
> best not to try to change that.  We can't force everyone who has
> installed an old version of PyXML to upgrade (and to erase the old
> package!) so the best solution is to pick a new name for the core XML
> support package.
> 

Regards,

Tom Passin




From martin@loewis.home.cs.tu-berlin.de  Sun Sep 17 19:57:45 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 17 Sep 2000 20:57:45 +0200
Subject: [XML-SIG] Aligning PyXML and Python 2
Message-ID: <200009171857.UAA02884@loewis.home.cs.tu-berlin.de>

I have installed the first sweep of alignment between the Python 2 xml
package, and the PyXML xml package. To my knowledge, PyXML can now be
used as a full replacement of Python 2 xml (with one exception, see
next message on startElement). The specific changes were:

setup.py: Install drivers2
SAX:      Implement expatreader as a wrapper around drivers2/drv_pyexpat.
          Supply a number of names in xml.sax:
           ContentHandler, ErrorHandler, exceptions, ExpatParser, 
           make_parser,  parse, parseString
          Rename saxutils.XMLFilterImpl to XMLFilterBase; add XMLGenerator
DOM:      Add minidom and pulldom. The only change to pulldom was to
          inherit from ContentHandler. 

It seems that pyexpat is quite picky about exceptions in Python.
Without inheriting from ContentHandler, drv_expat would invoke
startPrefixMapping, which is not defined in PullDOM. The exception
lead to a clearance of all handlers, which lead to a segfault on the
next call to startElementHandler.
          
I have performed some tests, which indicate that at least the minidom
part behaves identical.

If there are no objections, I'd like to prepare a release of PyXML 0.6
for use on top of Python 2.0b1; this should be done regardless of any
open issues, and regardless of whether it works with Python 1.5 - I'm
sure users will report any problems they find with the package, so
0.6.1 will be better.

Regards,
Martin

From martin@loewis.home.cs.tu-berlin.de  Sun Sep 17 20:06:32 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 17 Sep 2000 21:06:32 +0200
Subject: [XML-SIG] Signature of startElement
Message-ID: <200009171906.VAA02948@loewis.home.cs.tu-berlin.de>

When integrating PyXML and Python 2, I noticed a serious problem:

The signature of startElement must be determined. In Python 2, it
takes two arguments (name, attrs); in PyXML, it takes three arguments
(name, qname, attrs). There must be a definite decision for Python 2,
then PyXML must be updated to reflect this decision. If there is no
change to Python 2 in that area within a few days, I'll update PyXML
to reflect the current state of Python 2.

Please note that this signature business must be determined regardless
of whether there are two xml packages or one: Applications must be
able to trust the SAX2 API; they cannot provide different handlers for
different parsers (this is the whole point of SAX). 

I don't have any opinion on that question; I just observe that in
Java, the signature is

startElement(java.lang.String namespaceURI, java.lang.String localName,
             java.lang.String qName, Attributes atts) 

Not being an expert in XML namespaces, I have a hard time relating
either of the existing signatures or the SAX2 Java signature to the
proposal in

http://www.python.org/pipermail/xml-sig/2000-July/004650.html

so I'd appreciate if somebody shared a few words about how that
interface should look like.

Regards,
Martin


From tpassin@home.com  Sun Sep 17 21:53:32 2000
From: tpassin@home.com (tpassin@home.com)
Date: Sun, 17 Sep 2000 16:53:32 -0400
Subject: [XML-SIG] Signature of startElement
References: <200009171906.VAA02948@loewis.home.cs.tu-berlin.de>
Message-ID: <000f01c020e9$5746cb20$7cac1218@reston1.va.home.com>

Martin v. Loewis wites -

> When integrating PyXML and Python 2, I noticed a serious problem:
>
> The signature of startElement must be determined. In Python 2, it
> takes two arguments (name, attrs); in PyXML, it takes three arguments
> (name, qname, attrs). There must be a definite decision for Python 2,
> then PyXML must be updated to reflect this decision. If there is no
> change to Python 2 in that area within a few days, I'll update PyXML
> to reflect the current state of Python 2.
>
> Please note that this signature business must be determined regardless
> of whether there are two xml packages or one: Applications must be
> able to trust the SAX2 API; they cannot provide different handlers for
> different parsers (this is the whole point of SAX).
>
> I don't have any opinion on that question; I just observe that in
> Java, the signature is
>
> startElement(java.lang.String namespaceURI, java.lang.String localName,
>              java.lang.String qName, Attributes atts)
>
> Not being an expert in XML namespaces, I have a hard time relating
> either of the existing signatures or the SAX2 Java signature to the
> proposal in
>
> http://www.python.org/pipermail/xml-sig/2000-July/004650.html
>
> so I'd appreciate if somebody shared a few words about how that
> interface should look like.

I think that Lars' post, which you referenced, was right on target, although
I was one of those who liked using prefixes better than qnames.  Separate
methods for NS- and nonNS-aware methods.  That's how the DOM is doing it,
and it lets us have backward compatibility.

What we don't want to do is get rid of qnames/prefixes in the name of
consistency with the current (or beta 2) library if the latter doesn't
understand namespaces.  We've got to be able to get namespaces into the
distribution some way.

Not to tell the man who's doing it what to do, but if we can get Lars'
proposal implemented, and keep the **non-NS-aware** methods consistent with
the same methods in the Python 2 library, we'll be in good shape.  Does this
make sense, or am I missing something?

Thanks for your work,

Tom Passin



From martin@loewis.home.cs.tu-berlin.de  Sun Sep 17 22:25:53 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 17 Sep 2000 23:25:53 +0200
Subject: [XML-SIG] Signature of startElement
In-Reply-To: <000f01c020e9$5746cb20$7cac1218@reston1.va.home.com>
 (tpassin@home.com)
References: <200009171906.VAA02948@loewis.home.cs.tu-berlin.de> <000f01c020e9$5746cb20$7cac1218@reston1.va.home.com>
Message-ID: <200009172125.XAA03749@loewis.home.cs.tu-berlin.de>

> What we don't want to do is get rid of qnames/prefixes in the name of
> consistency with the current (or beta 2) library if the latter doesn't
> understand namespaces.  We've got to be able to get namespaces into the
> distribution some way.

FWIW, the startElement in 2.0 is defined as

    def startElement(self, name, attrs):
        """Signals the start of an element.

        The name parameter contains the name of the element type as a
        (uri ,localname) tuple, the qname parameter the raw XML 1.0
        name used in the source document, and the attrs parameter
        holds an instance of the Attributes class containing the
        attributes of the element."""

The parser does indeed pass a (uri, localname) pair to startElement,
so it *is* capable of dealing with namespaces right now. The only
uncertainty is the qname parameter, which is also passed and
documented, but not listed in the base class signature.

Now matter what change is perfomed on this API, it has to happen
quickly.

> Not to tell the man who's doing it what to do, but if we can get
> Lars' proposal implemented, and keep the **non-NS-aware** methods
> consistent with the same methods in the Python 2 library, we'll be
> in good shape.  Does this make sense, or am I missing something?

I still can't see how a full specification of the interface would look
like. I understand that there are supposed to be four methods,
{start|end}Element[NS]. What are their signatures: How many
parameters, what types have the parameters?

Regards,
Martin

From eijck@iri.tudelft.nl  Mon Sep 18 14:29:17 2000
From: eijck@iri.tudelft.nl (Lambert van Eijck)
Date: Mon, 18 Sep 2000 15:29:17 +0200 (CEST)
Subject: [XML-SIG] install problem PyXML-0.5.5.1
Message-ID: <Pine.LNX.4.10.10009181520490.9539-100000@irijsf.iri.tudelft.nl>

Hello there,

Because I'd like to take a look at PyGuiXML I tried to install
PyXML-0.5.5.1 according to README included. 

The '$ python setup.py build' is (I guess) trying to use something in the
directory '/usr/lib/python-1.5/config' which is not there (RedHat6.1). Do
you know if this is the problem and what I can do?

 
I got the following output:
_________________________________________________________

 $ python setup.py build

Executing 'build' action...

Running command: make -f Makefile.pre.in boot
rm -f *.o *~
rm -f `find . -name '*.pyc'`
rm -f `find . -name '*.o'`
rm -f `find . -name '*~'`
cd expat ; make clean
make[1]: Entering directory
`/home/eijck/src/tgz/PyXML-0.5.5.1/extensions/expat'
rm -f xmltok/xmltok.o xmltok/xmlrole.o xmlwf/xmlwf.o xmlwf/xmlfile.o
xmlwf/codepage.o xmlparse/xmlparse.o xmlparse/hashtable.o
xmlwf/unixfilemap.o xmlwf/xmlwf
make[1]: Leaving directory
`/home/eijck/src/tgz/PyXML-0.5.5.1/extensions/expat'
rm -f *.a tags TAGS config.c Makefile.pre python sedscript
rm -f *.so *.sl so_locations
cd expat ; make clobber
make[1]: Entering directory
`/home/eijck/src/tgz/PyXML-0.5.5.1/extensions/expat'
rm -f xmltok/xmltok.o xmltok/xmlrole.o xmlwf/xmlwf.o xmlwf/xmlfile.o
xmlwf/codepage.o xmlparse/xmlparse.o xmlparse/hashtable.o
xmlwf/unixfilemap.o xmlwf/xmlwf
rm -f libexpat.a
make[1]: Leaving directory
`/home/eijck/src/tgz/PyXML-0.5.5.1/extensions/expat'
VERSION=`python -c "import sys; print sys.version[:3]"`; \
installdir=`python -c "import sys; print sys.prefix"`; \
exec_installdir=`python -c "import sys; print sys.exec_prefix"`; \
make -f ./Makefile.pre.in VPATH=. srcdir=. \
        VERSION=$VERSION \
        installdir=$installdir \
        exec_installdir=$exec_installdir \
        Makefile
make[1]: Entering directory `/home/eijck/src/tgz/PyXML-0.5.5.1/extensions'
make[1]: *** No rule to make target `/usr/lib/python1.5/config/Makefile',
needed by `sedscript'.  Stop.
make[1]: Leaving directory `/home/eijck/src/tgz/PyXML-0.5.5.1/extensions'
make: *** [boot] Error 2

Running command: make
make: *** No targets.  Stop.
Traceback (innermost last):
  File "setup.py", line 185, in ?
    func()
  File "setup.py", line 155, in build_unix
    shutil.copy('extensions/' + filename, 'build/xml/parsers/')
  File "/usr/lib/python1.5/shutil.py", line 52, in copy
    copyfile(src, dst)
  File "/usr/lib/python1.5/shutil.py", line 17, in copyfile
    fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: 'extensions/pyexpat.so'
 $ 
 $
 $
________________________________________________


Thanks for the help,

Lambert van Eijck
IRI TU Delft Netherlands 


From dieter@handshake.de  Mon Sep 18 22:01:05 2000
From: dieter@handshake.de (Dieter Maurer)
Date: Mon, 18 Sep 2000 23:01:05 +0200 (CEST)
Subject: [XML-SIG] Signature of startElement
In-Reply-To: <200009172125.XAA03749@loewis.home.cs.tu-berlin.de>
References: <000f01c020e9$5746cb20$7cac1218@reston1.va.home.com>
 <200009172125.XAA03749@loewis.home.cs.tu-berlin.de>
Message-ID: <14790.33333.417013.358949@lindm.dm>

Martin v. Loewis writes:
 > FWIW, the startElement in 2.0 is defined as
 > 
 >     def startElement(self, name, attrs):
 >         """Signals the start of an element.
 > 
 >         The name parameter contains the name of the element type as a
 >         (uri ,localname) tuple, the qname parameter the raw XML 1.0
 >         name used in the source document, and the attrs parameter
 >         holds an instance of the Attributes class containing the
 >         attributes of the element."""
Obviously, the docstring and the definition are not consistent.

 > The parser does indeed pass a (uri, localname) pair to startElement,
 > so it *is* capable of dealing with namespaces right now. The only
 > uncertainty is the qname parameter, which is also passed and
 > documented, but not listed in the base class signature.
How is this possible without raising an exception?


Dieter

From martin@loewis.home.cs.tu-berlin.de  Mon Sep 18 23:26:02 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 19 Sep 2000 00:26:02 +0200
Subject: [XML-SIG] Signature of startElement
In-Reply-To: <14790.33333.417013.358949@lindm.dm> (message from Dieter Maurer
 on Mon, 18 Sep 2000 23:01:05 +0200 (CEST))
References: <000f01c020e9$5746cb20$7cac1218@reston1.va.home.com>
 <200009172125.XAA03749@loewis.home.cs.tu-berlin.de> <14790.33333.417013.358949@lindm.dm>
Message-ID: <200009182226.AAA01427@loewis.home.cs.tu-berlin.de>

> Obviously, the docstring and the definition are not consistent.

Indeed, yes.


>  > The parser does indeed pass a (uri, localname) pair to startElement,
>  > so it *is* capable of dealing with namespaces right now. The only
>  > uncertainty is the qname parameter, which is also passed and
>  > documented, but not listed in the base class signature.
> How is this possible without raising an exception?

startElement must be implemented by derived types. The only working
example, in pulldom, implements it with four parameters (including
self).

Regards,
Martin


From larsga@garshol.priv.no  Tue Sep 19 08:27:19 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 19 Sep 2000 09:27:19 +0200
Subject: [XML-SIG] Signature of startElement
In-Reply-To: <200009172125.XAA03749@loewis.home.cs.tu-berlin.de>
References: <200009171906.VAA02948@loewis.home.cs.tu-berlin.de> <000f01c020e9$5746cb20$7cac1218@reston1.va.home.com> <200009172125.XAA03749@loewis.home.cs.tu-berlin.de>
Message-ID: <m38zso4zag.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
| 
| FWIW, the startElement in 2.0 is defined as
| 
|     def startElement(self, name, attrs):
|         """Signals the start of an element.
| 
|         The name parameter contains the name of the element type as a
|         (uri ,localname) tuple, the qname parameter the raw XML 1.0
|         name used in the source document, and the attrs parameter
|         holds an instance of the Attributes class containing the
|         attributes of the element."""
| 
| The parser does indeed pass a (uri, localname) pair to startElement,
| so it *is* capable of dealing with namespaces right now. The only
| uncertainty is the qname parameter, which is also passed and
| documented, but not listed in the base class signature.

Well, this is part of the problem with the SAX code in the Python CVS
tree right now: it is not internally consistent. There are at least
two different versions of the startElement signature, if not more.
 
| Now matter what change is perfomed on this API, it has to happen
| quickly.

I have changed most of what needs to change in the API on my laptop
already. I only need to test the changes and fix any problems that
show up. I can do this this week, but would like to feel that I have
the SIG (and the Python developers) behind me before I do so.
 
| I still can't see how a full specification of the interface would
| look like. I understand that there are supposed to be four methods,
| {start|end}Element[NS]. What are their signatures: How many
| parameters, what types have the parameters?

startElement(name, attrs): 
  name is a string, attrs an Attributes instance

startElementNS(name, qname, attrs):
  name is a (uri, localname) tuple, qname the qualified XML 1.0 name,
  and attrs an Attributes instance

endElement(name):
  name is a string

endElementNS(name, qname):
  name is a (uri, localname) tuple, while qname is the qualified XML
  1.0 name

The Attributes interface also has to have some minor changes to fix
some performance problems Paul discovered incurred by generic
applications like DOM tree builders.

--Lars M.


From larsga@garshol.priv.no  Tue Sep 19 08:31:16 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 19 Sep 2000 09:31:16 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <39C0F24B.597F6B82@prescod.net>
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net> <200009140727.JAA02687@loewis.home.cs.tu-berlin.de> <m3pum7mkv4.fsf@lambda.garshol.priv.no> <39C0F24B.597F6B82@prescod.net>
Message-ID: <m37l884z3v.fsf@lambda.garshol.priv.no>

* Lars Marius Garshol
|
| It should probably appear as
| 
| from xml import sax
| parser = sax.make_parser()
|
| I think we should extend it so that the default parser list can be
| modified both from Python code and set via an environment variable
| (PY_SAX_PARSER?).  Other than that I think SAX 1.0 showed this
| approach to be very successful.

This has now been implemented and is ready to be tested against Python
2.0 and checked in. It works with Python 1.5.2 and JPython 1.1, and
uses the Java property python.xml.sax.parser from sys.registry in
JPython.

--Lars M.


From larsga@garshol.priv.no  Tue Sep 19 08:33:39 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 19 Sep 2000 09:33:39 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <200009141922.VAA01224@loewis.home.cs.tu-berlin.de>
References: <200009141922.VAA01224@loewis.home.cs.tu-berlin.de>
Message-ID: <m366ns4yzw.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
| 
| I'd like to caution that the final release of Python 2.0 is
| scheduled for Oct 6. So I'd rather suggest that only essential work
| is done, instead of trying to 'improve' things significantly.
| Feature-freeze for Python 2.0 was several weeks ago, so only things
| that won't work [as documented :-] may be fixed now.

Well, what is currently in the CVS tree is inconsistent, buggy and
incomplete, and also not what has been agreed upon. So in my opinion
fixing these things is essential, although the changes are not a total
revolution. Much of the code will stay as it is.
 
| I doubt any significant changes to the xml package will be accepted
| a week before the release.

How do we go about procuring permission to make these changes?

--Lars M.


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 19 09:35:33 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 19 Sep 2000 10:35:33 +0200
Subject: [XML-SIG] Signature of startElement
In-Reply-To: <m38zso4zag.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 19 Sep 2000 09:27:19 +0200)
References: <200009171906.VAA02948@loewis.home.cs.tu-berlin.de> <000f01c020e9$5746cb20$7cac1218@reston1.va.home.com> <200009172125.XAA03749@loewis.home.cs.tu-berlin.de> <m38zso4zag.fsf@lambda.garshol.priv.no>
Message-ID: <200009190835.KAA01163@loewis.home.cs.tu-berlin.de>

> I have changed most of what needs to change in the API on my laptop
> already. I only need to test the changes and fix any problems that
> show up. I can do this this week, but would like to feel that I have
> the SIG (and the Python developers) behind me before I do so.

Well, if you manage to change this *quickly*, you have my support :-)

Anything that works is fine with me - it does not need to be elegant,
it must be consistent, and it must be available RSN. Why don't you
just post a snapshot patch now?

> startElement(name, attrs): 
>   name is a string, attrs an Attributes instance
> 
> startElementNS(name, qname, attrs):
>   name is a (uri, localname) tuple, qname the qualified XML 1.0 name,
>   and attrs an Attributes instance
> 
> endElement(name):
>   name is a string
> 
> endElementNS(name, qname):
>   name is a (uri, localname) tuple, while qname is the qualified XML
>   1.0 name

Sounds good. The next question then is: which of those should be
invoked by the parsers, under what circumstances?

I can see two alternatives:
a) depending on some configuration setting, the parser invokes only
   one set.
b) the parser always invokes *NS. The base class implements that as

   def startElementNS(self, name, qname, attrs):
     return self.startElement(qname, attrs)

Which one is it, or is it something else?

Regards,
Martin

From martin@loewis.home.cs.tu-berlin.de  Tue Sep 19 09:41:05 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 19 Sep 2000 10:41:05 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <m366ns4yzw.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 19 Sep 2000 09:33:39 +0200)
References: <200009141922.VAA01224@loewis.home.cs.tu-berlin.de> <m366ns4yzw.fsf@lambda.garshol.priv.no>
Message-ID: <200009190841.KAA01215@loewis.home.cs.tu-berlin.de>

> | I doubt any significant changes to the xml package will be accepted
> | a week before the release.
> 
> How do we go about procuring permission to make these changes?

As a starting point, make the code available. I think there is
sufficient interest in correcting any errors that are left; positive
reports from peer review probably boost acceptance.

Regards,
Martin

From martin@loewis.home.cs.tu-berlin.de  Tue Sep 19 09:38:32 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 19 Sep 2000 10:38:32 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <m37l884z3v.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 19 Sep 2000 09:31:16 +0200)
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net> <200009140727.JAA02687@loewis.home.cs.tu-berlin.de> <m3pum7mkv4.fsf@lambda.garshol.priv.no> <39C0F24B.597F6B82@prescod.net> <m37l884z3v.fsf@lambda.garshol.priv.no>
Message-ID: <200009190838.KAA01198@loewis.home.cs.tu-berlin.de>

> This has now been implemented and is ready to be tested against Python
> 2.0 and checked in. It works with Python 1.5.2 and JPython 1.1, and
> uses the Java property python.xml.sax.parser from sys.registry in
> JPython.

I'd like to test this. Where is the patch?

Regards,
Martin

From larsga@garshol.priv.no  Tue Sep 19 10:18:40 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 19 Sep 2000 11:18:40 +0200
Subject: [XML-SIG] Signature of startElement
In-Reply-To: <200009190835.KAA01163@loewis.home.cs.tu-berlin.de>
References: <200009171906.VAA02948@loewis.home.cs.tu-berlin.de> <000f01c020e9$5746cb20$7cac1218@reston1.va.home.com> <200009172125.XAA03749@loewis.home.cs.tu-berlin.de> <m38zso4zag.fsf@lambda.garshol.priv.no> <200009190835.KAA01163@loewis.home.cs.tu-berlin.de>
Message-ID: <m3n1h4zqmn.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
| 
| Well, if you manage to change this *quickly*, you have my support :-)
| 
| Anything that works is fine with me - it does not need to be elegant,
| it must be consistent, and it must be available RSN. Why don't you
| just post a snapshot patch now?

I can try to post a patch tonight, although that will not have been
tested against Python 2.0, since I don't have it on my system.

Question is: what is the recommended way to post a patch?
 
| [startElement / startElementNS]
|
| Sounds good. The next question then is: which of those should be
| invoked by the parsers, under what circumstances?

This depends on the namespaces feature, which can be set in the
constructor of some drivers, and can be changed through the setFeature
method before parsing begins. (See feature_namespaces in handlers.py.)
 
--Lars M.


From larsga@garshol.priv.no  Tue Sep 19 10:19:27 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 19 Sep 2000 11:19:27 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <200009190838.KAA01198@loewis.home.cs.tu-berlin.de>
References: <200009080623.IAA00857@loewis.home.cs.tu-berlin.de> <39C074C3.94809D07@prescod.net> <200009140727.JAA02687@loewis.home.cs.tu-berlin.de> <m3pum7mkv4.fsf@lambda.garshol.priv.no> <39C0F24B.597F6B82@prescod.net> <m37l884z3v.fsf@lambda.garshol.priv.no> <200009190838.KAA01198@loewis.home.cs.tu-berlin.de>
Message-ID: <m3lmwozqlc.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
|
| [xml.sax.make_parser]
| 
| I'd like to test this. Where is the patch?

I can post it tonight with the rest.

--Lars M.


From fdrake@beopen.com  Tue Sep 19 16:32:17 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 19 Sep 2000 11:32:17 -0400 (EDT)
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <m366ns4yzw.fsf@lambda.garshol.priv.no>
References: <200009141922.VAA01224@loewis.home.cs.tu-berlin.de>
 <m366ns4yzw.fsf@lambda.garshol.priv.no>
Message-ID: <14791.34561.507048.992610@cj42289-a.reston1.va.home.com>

Lars Marius Garshol writes:
 > How do we go about procuring permission to make these changes?

  Bug fixes can just get checked in.  Large changes should probably go
through the patch manager, allowing us to review and record our
comments.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From alf@logilab.com  Tue Sep 19 16:29:14 2000
From: alf@logilab.com (Alexandre Fayolle)
Date: Tue, 19 Sep 2000 17:29:14 +0200 (CEST)
Subject: [XML-SIG] 4DOM: getAttributeNS vs getAttribute
Message-ID: <Pine.LNX.4.21.0009191717410.2065-100000@leo.logilab.fr>

When I create a DOM document using Sax2.FromXml, all attributes are
created in an empty namespace using setAttributeNS. Since 4DOM maintains 2
dictionnaries (one for namespaceless attributes using the attribute name
as a key, and one for the namespaced attributes using (uri,atributename)),
this means that I cannot retrieve my attributes using getAttribute, even
if no namespace was specified in the XML text (am I clear?).

I somehow feel that a setAttributeNS'ed attribute should be accessible
with getAttribute if the namespace was empty, but this is not specified in
the DOM2 spec. What the spec says is that getAttribute retrieves attribute
by name, so I do not see why it should not find an attribute that has no
namespace. 

-- 
Alexandre Fayolle
http://www.logilab.com - "Mais où est donc Ornicar ?" - 
LOGILAB, Paris (France).


From larsga@garshol.priv.no  Tue Sep 19 17:11:55 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 19 Sep 2000 18:11:55 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <14791.34561.507048.992610@cj42289-a.reston1.va.home.com>
References: <200009141922.VAA01224@loewis.home.cs.tu-berlin.de> 	<m366ns4yzw.fsf@lambda.garshol.priv.no> <14791.34561.507048.992610@cj42289-a.reston1.va.home.com>
Message-ID: <m3aed4icok.fsf@lambda.garshol.priv.no>

* Fred L. Drake, Jr.
| 
| Bug fixes can just get checked in.  Large changes should probably go
| through the patch manager, allowing us to review and record our
| comments.

OK.  It's all in the patch manager now, as:

  101570         *NS methods on handler.py
  101571         adds make_parser to xml.sax
  101572         updates XMLGenerator to new interfaces
  101573         a first start on updating expatreader.py

More remains to be added, mainly to expatreader.py, and there is also
the issue of the InputSource and EntityResolver classes.

--Lars M.


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 19 19:52:26 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 19 Sep 2000 20:52:26 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <m3aed4icok.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 19 Sep 2000 18:11:55 +0200)
References: <200009141922.VAA01224@loewis.home.cs.tu-berlin.de> 	<m366ns4yzw.fsf@lambda.garshol.priv.no> <14791.34561.507048.992610@cj42289-a.reston1.va.home.com> <m3aed4icok.fsf@lambda.garshol.priv.no>
Message-ID: <200009191852.UAA00900@loewis.home.cs.tu-berlin.de>

> OK.  It's all in the patch manager now, as:
> 
>   101570         *NS methods on handler.py
>   101571         adds make_parser to xml.sax
>   101572         updates XMLGenerator to new interfaces
>   101573         a first start on updating expatreader.py

I see 101570 and 101572 is approved, so I look forward to see them in
the tree. On 101573, the *NS part looks fine; I assume the missing
part is about updating the attributes.

For 101573, I have two concerns. First, I feel that the configuration
machinery is overkill: Python 2.0 will ship with a single driver, so
there are not much parsers to chose from. If we don't provide these
many options now, we can still add it later if users actually need
them.

Secondly, it seems that loading drivers with imp.load_module puts them
with their unqualified name into sys.modules. Why can't create_parser
simply be

    def python_create_parser(parser_name):
        drv_module = __import__(parser_name,globals(),locals(),['create_parser'])
        return drv_module.create_parser()

Regards,
Martin

From prescod@prescod.net  Tue Sep 19 20:07:54 2000
From: prescod@prescod.net (Paul)
Date: Tue, 19 Sep 2000 14:07:54 -0500 (CDT)
Subject: [XML-SIG] Signature of startElement
In-Reply-To: <m38zso4zag.fsf@lambda.garshol.priv.no>
Message-ID: <Pine.LNX.4.21.0009191401540.6001-100000@amati.techno.com>

On 19 Sep 2000, Lars Marius Garshol wrote:

> 
> ...
> 
> I have changed most of what needs to change in the API on my laptop
> already. I only need to test the changes and fix any problems that
> show up. I can do this this week, but would like to feel that I have
> the SIG (and the Python developers) behind me before I do so.

Personally, I am totally behind any changes to make things work and
against changes that add features (unless very minor and very
simple). I think we should play by the rules of the Python feature
freeze. There are some extra things you would like in SAX and some extra
things I would like in DOM, et. al., but alot of it can wait for Python
2.1.

As far as I know these are the bugs with what we have:

 * references to _source are inconsistent
 * startElement method signatures are wrong in dummy base class
 * startElement method signatures (in general) do not agree with what you
decided after our method signatures thread
 * Expat namespaces are not passed through properly

I don't think that fixing any of these requires systemic changes.

> startElement(name, attrs): 
>   name is a string, attrs an Attributes instance
> 
> startElementNS(name, qname, attrs):
>   name is a (uri, localname) tuple, qname the qualified XML 1.0 name,
>   and attrs an Attributes instance
> 
> endElement(name):
>   name is a string
> 
> endElementNS(name, qname):
>   name is a (uri, localname) tuple, while qname is the qualified XML
>   1.0 name

Okay, great. Make it so!

> The Attributes interface also has to have some minor changes to fix
> some performance problems Paul discovered incurred by generic
> applications like DOM tree builders.

If this is going to change the documented API then you should do it now.
If it is just an implementation issue I would say you should leave it and
do it later.

 Paul Prescod



From prescod@prescod.net  Tue Sep 19 20:11:27 2000
From: prescod@prescod.net (Paul)
Date: Tue, 19 Sep 2000 14:11:27 -0500 (CDT)
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <m366ns4yzw.fsf@lambda.garshol.priv.no>
Message-ID: <Pine.LNX.4.21.0009191409010.6001-100000@amati.techno.com>

On 19 Sep 2000, Lars Marius Garshol wrote:

> ...
> 
> How do we go about procuring permission to make these changes?

Just submit patches to Fred. If the changes are incremental then you
should submit many incremental patches. If they are systemic then he'll
probably have to take them somewhat on faith because I don't know if he
has time to go over all of the modules again. This is another argument for
small incremental changes.

Since these changes will possibly break minidom, I'd really appreciate it
if you could do them tomorrow so that they can be tested and minidom can
be fixed and tested.

 Paul Prescod



From prescod@prescod.net  Tue Sep 19 20:14:17 2000
From: prescod@prescod.net (Paul)
Date: Tue, 19 Sep 2000 14:14:17 -0500 (CDT)
Subject: [XML-SIG] Signature of startElement
In-Reply-To: <m3n1h4zqmn.fsf@lambda.garshol.priv.no>
Message-ID: <Pine.LNX.4.21.0009191412250.6001-100000@amati.techno.com>

On 19 Sep 2000, Lars Marius Garshol wrote:

> 
> 
> I can try to post a patch tonight, although that will not have been
> tested against Python 2.0, since I don't have it on my system.
> 
> Question is: what is the recommended way to post a patch?

Sourceforge patch manager.

> This depends on the namespaces feature, which can be set in the
> constructor of some drivers, and can be changed through the setFeature
> method before parsing begins. (See feature_namespaces in handlers.py.)

You should also make it a parameter on the parse*() functions. IMO, a
typical user should not need to deal with a parser object at all. They
just ask for a parse to happen.

 Paul Prescod



From prescod@prescod.net  Tue Sep 19 20:52:49 2000
From: prescod@prescod.net (Paul)
Date: Tue, 19 Sep 2000 14:52:49 -0500 (CDT)
Subject: [XML-SIG] Python package name
Message-ID: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com>

Did I miss an email where we decided on a resolution for the package
naming issue? I don't see any benefit in putting of this decision. I will
personally have to update a lot of code if we change the name so I would
like to know as soon as possible.

 Paul



From martin@loewis.home.cs.tu-berlin.de  Tue Sep 19 21:22:11 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 19 Sep 2000 22:22:11 +0200
Subject: [XML-SIG] Python package name
In-Reply-To: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com>
 (message from Paul on Tue, 19 Sep 2000 14:52:49 -0500 (CDT))
References: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com>
Message-ID: <200009192022.WAA01181@loewis.home.cs.tu-berlin.de>

> Did I miss an email where we decided on a resolution for the package
> naming issue? I don't see any benefit in putting of this decision. I
> will personally have to update a lot of code if we change the name
> so I would like to know as soon as possible.

To my knowledge, there has been no decision yet. There was a criterion
in the spirit '''if xml-sig does not manage to update PyXML, we will
change the package name in Python 2'''. Now, I have updated the
current PyXML to operate on top of 2.0b1 (pending synchronization with
Lars' approved patches), and I plan to release PyXML 0.6 within days.
That voids the precondition of above criterion.

The BDFL may still decide to rename the package, on grounds of the
current add-on approach being a hack and the renaming being a
technical more clean solution. I think everybody's opinion on this
matter is clear, as well, so it's a good time to make a decision :-)

Regards,
Martin




From fdrake@beopen.com  Tue Sep 19 21:48:06 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 19 Sep 2000 16:48:06 -0400 (EDT)
Subject: [XML-SIG] Python package name
In-Reply-To: <200009192022.WAA01181@loewis.home.cs.tu-berlin.de>
References: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com>
 <200009192022.WAA01181@loewis.home.cs.tu-berlin.de>
Message-ID: <14791.53510.586817.460388@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > To my knowledge, there has been no decision yet. There was a criterion
 > in the spirit '''if xml-sig does not manage to update PyXML, we will
 > change the package name in Python 2'''. Now, I have updated the
 > current PyXML to operate on top of 2.0b1 (pending synchronization with
 > Lars' approved patches), and I plan to release PyXML 0.6 within days.
 > That voids the precondition of above criterion.

  I was just talking to Guido about this matter.  Our current intent
is to add a version check to Lib/xml/__init__.py, so that we don't
override the base class with a PyXML package that's too old.
  I propose adding a constant version_info to xml/__init__.py in the
PyXML package.  The value should have a similar structure to the
sys.version_info in Python.  This can be used for the check.
  Martin, how quickly do you think you can have a PyXML package ready?
Can it be done in time for 2.0b2 (26 Sept.)?  I'd like to make the
change to Lib/xml/__init__.py to make it require the new package:

try:
    import _xmlplus
except ImportError:
    pass
else:
    if _xmlplus.version_info > (0, 6):
        import sys
        sys.modules[__name__] = _xmlplus

 > The BDFL may still decide to rename the package, on grounds of the
 > current add-on approach being a hack and the renaming being a
 > technical more clean solution. I think everybody's opinion on this
 > matter is clear, as well, so it's a good time to make a decision :-)

  I think the only real solution will be to fix the import machinery
to be more Java-like, allowing multiple directories to provides parts
of a shared package space without having to resort to really evil
hackery.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From guido@beopen.com  Tue Sep 19 22:55:13 2000
From: guido@beopen.com (Guido van Rossum)
Date: Tue, 19 Sep 2000 16:55:13 -0500
Subject: [XML-SIG] Python package name
In-Reply-To: Your message of "Tue, 19 Sep 2000 22:22:11 +0200."
 <200009192022.WAA01181@loewis.home.cs.tu-berlin.de>
References: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com>
 <200009192022.WAA01181@loewis.home.cs.tu-berlin.de>
Message-ID: <200009192155.QAA01801@cj20424-a.reston1.va.home.com>

> I think everybody's opinion on this
> matter is clear, as well, so it's a good time to make a decision :-)

Could you summarize everybody's opinions?  They're not at all clear to
me. :-)

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

From akuchlin@mems-exchange.org  Tue Sep 19 21:56:42 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 19 Sep 2000 16:56:42 -0400
Subject: [XML-SIG] Python package name
In-Reply-To: <14791.53510.586817.460388@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Tue, Sep 19, 2000 at 04:48:06PM -0400
References: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com> <200009192022.WAA01181@loewis.home.cs.tu-berlin.de> <14791.53510.586817.460388@cj42289-a.reston1.va.home.com>
Message-ID: <20000919165642.A29766@kronos.cnri.reston.va.us>

On Tue, Sep 19, 2000 at 04:48:06PM -0400, Fred L. Drake, Jr. wrote:
>  I was just talking to Guido about this matter.  Our current intent
>is to add a version check to Lib/xml/__init__.py, so that we don't
>override the base class with a PyXML package that's too old.

Er... can you explain this more clearly?  This solution seems to step
down the road of complicated magical behaviour, which is bad; better
go to xmlbase for the stuff with Python and leave the 'xml' package
name as it is.

--amk


From fdrake@beopen.com  Tue Sep 19 22:34:00 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 19 Sep 2000 17:34:00 -0400 (EDT)
Subject: [XML-SIG] documentation
Message-ID: <14791.56264.4267.959626@cj42289-a.reston1.va.home.com>

  I'm starting documentation for the xml.sax package.  We already have
the material that's part of the PyXML package, and I'm currently
working on the xml.sax package module itself.  If anyone else would
like to take a portion of the documentation to work on, I'd certainly
appreciate some help!  I'd like to have at least partial documentation
in 2.0b2, and complete documentation in the final release.
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 19 22:49:54 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 19 Sep 2000 23:49:54 +0200
Subject: [XML-SIG] Python package name
In-Reply-To: <200009192155.QAA01801@cj20424-a.reston1.va.home.com> (message
 from Guido van Rossum on Tue, 19 Sep 2000 16:55:13 -0500)
References: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com>
 <200009192022.WAA01181@loewis.home.cs.tu-berlin.de> <200009192155.QAA01801@cj20424-a.reston1.va.home.com>
Message-ID: <200009192149.XAA01886@loewis.home.cs.tu-berlin.de>

> > I think everybody's opinion on this
> > matter is clear, as well, so it's a good time to make a decision :-)
> 
> Could you summarize everybody's opinions?  They're not at all clear to
> me. :-)

I knew you'd ask :-) Anybody please correct me.

Guido, Fred, and Andrew think it is better to rename the module to
avoid hackery. Lars is also in favour of renaming the package.

Paul and myself think that having the same package name is good in the
long run, as it might include a lot of things in the future, but still
will have a non-obvious name (like Emacs' ever-growing tinylib).

Greg is also in favour of a single package xml, but doesn't like PyXML
completely superceding the standard one; he had the _xmlextra patch
for that (I also had a similar patch, playing with __path__). That
would allow to merge the two trees, and require less effort to
synchronize them.

There was also the position of dropping the xml package from Python 2
altogether, but I can't attribute this position to anybody right now :-)

I apologize for not listing everybody who has an opinion on the matter
- it turns out I don't actually know *everybody's* opinion. If I've
been missing an important alternative, please speak up.

Regards,
Martin

From uche.ogbuji@fourthought.com  Tue Sep 19 19:20:43 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Tue, 19 Sep 2000 12:20:43 -0600
Subject: [XML-SIG] 4DOM: getAttributeNS vs getAttribute
In-Reply-To: Message from Alexandre Fayolle <alf@logilab.com>
 of "Tue, 19 Sep 2000 17:29:14 +0200." <Pine.LNX.4.21.0009191717410.2065-100000@leo.logilab.fr>
Message-ID: <200009191820.MAA01678@localhost.localdomain>

> When I create a DOM document using Sax2.FromXml, all attributes are
> created in an empty namespace using setAttributeNS. Since 4DOM maintain=
s 2
> dictionnaries (one for namespaceless attributes using the attribute nam=
e
> as a key, and one for the namespaced attributes using (uri,atributename=
)),
> this means that I cannot retrieve my attributes using getAttribute, eve=
n
> if no namespace was specified in the XML text (am I clear?).
> =

> I somehow feel that a setAttributeNS'ed attribute should be accessible
> with getAttribute if the namespace was empty, but this is not specified=
 in
> the DOM2 spec. What the spec says is that getAttribute retrieves attrib=
ute
> by name, so I do not see why it should not find an attribute that has n=
o
> namespace. =


Hmm.  I disagree.  I think there's a fundamental difference between an =

attribute with null uri in an NS-aware system, and an attribute in a non-=
NS =

aware system.

This is easily the subject of very impassioned debate, I must admit howev=
er, =

and neither XML NS 1.0 or DOM Level 2 are much help for the philosophical=
 POV.

However, from a purely practical point of view, it is much easier for 4DO=
M to =

make the two situations distinct, and since the DOM spec allows this, I =

consider it an easy decision.

Why are you constrained to use non-NS API at all?  They are all but depre=
cated =

in DOM L2 for use in NS-aware documents.


-- =

Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com =

4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



From prescod@prescod.net  Tue Sep 19 23:02:43 2000
From: prescod@prescod.net (Paul)
Date: Tue, 19 Sep 2000 17:02:43 -0500 (CDT)
Subject: [XML-SIG] Python package name
In-Reply-To: <200009192149.XAA01886@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0009191658330.6230-100000@amati.techno.com>

On Tue, 19 Sep 2000, Martin v. Loewis wrote:
>
> ...
> 
> Paul and myself think that having the same package name is good in the
> long run, as it might include a lot of things in the future, but still
> will have a non-obvious name (like Emacs' ever-growing tinylib).

At one point Guido clarified that xml and xmlcore could migrate to xmlplus
and xml over time, just as long as we give people time to change and an
upgrade path.

I understood this as:

pyxml gets an xmlplus alias now
pyxml gives up xml in six months
xmlcore gets an xml alias then
xmlcore name is deprecated sometime later

It's kind of ugly but I could live with it.

If the xmlplus hack works (really works, without subtle side effects) then
I would prefer that.

 Paul Prescod



From uche.ogbuji@fourthought.com  Wed Sep 20 00:00:14 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Tue, 19 Sep 2000 17:00:14 -0600
Subject: [XML-SIG] Python package name
In-Reply-To: Message from Paul <prescod@prescod.net>
 of "Tue, 19 Sep 2000 17:02:43 CDT." <Pine.LNX.4.21.0009191658330.6230-100000@amati.techno.com>
Message-ID: <200009192300.RAA01451@localhost.localdomain>

> On Tue, 19 Sep 2000, Martin v. Loewis wrote:

> At one point Guido clarified that xml and xmlcore could migrate to xmlplus
> and xml over time, just as long as we give people time to change and an
> upgrade path.
> 
> I understood this as:
> 
> pyxml gets an xmlplus alias now
> pyxml gives up xml in six months
> xmlcore gets an xml alias then
> xmlcore name is deprecated sometime later
> 
> It's kind of ugly but I could live with it.
> 
> If the xmlplus hack works (really works, without subtle side effects) then
> I would prefer that.

I'm really sorry to be so far AWOL on such an important topic, but we've been 
running about like mad to get the next 4Suite out the door so we _can_ pay 
attention to Python 1.6 and 2.0.

But a quick pip for today:  I think the above approach to package 
naming/renaming is the best of all available hacks.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



From fdrake@beopen.com  Wed Sep 20 02:23:47 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 19 Sep 2000 21:23:47 -0400 (EDT)
Subject: [XML-SIG] Python package name
In-Reply-To: <200009192149.XAA01886@loewis.home.cs.tu-berlin.de>
References: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com>
 <200009192022.WAA01181@loewis.home.cs.tu-berlin.de>
 <200009192155.QAA01801@cj20424-a.reston1.va.home.com>
 <200009192149.XAA01886@loewis.home.cs.tu-berlin.de>
 <Pine.LNX.4.21.0009191658330.6230-100000@amati.techno.com>
Message-ID: <14792.4515.481440.122791@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > Guido, Fred, and Andrew think it is better to rename the module to
 > avoid hackery. Lars is also in favour of renaming the package.

  Ahem.  No.  I'm in favor of calling it "xml" in the core and fixing
Python's import machinery to allow multiple directories to provide
components of the package.  I think the hackery with overriding the
xml package with the _xmlplus package is "good enough" until we have a
better import mechanism.

 > Greg is also in favour of a single package xml, but doesn't like PyXML
 > completely superceding the standard one; he had the _xmlextra patch
 > for that (I also had a similar patch, playing with __path__). That
 > would allow to merge the two trees, and require less effort to
 > synchronize them.

  And the reason we originally came up with the idea of _xmlplus
overriding xml was that you get one or the other to avoiding internal
versioning issues.

 > There was also the position of dropping the xml package from Python 2
 > altogether, but I can't attribute this position to anybody right now :-)

  I think this was largely a matter of frustration with the
back-and-forth from the SIG and the lack of any real concensus.  I
understand this, and consider this the only serious option to
providing the xml package in the core and allowing PyXML to override
it.  This would have the advantage that there would no longer be an
issue of synchronizing the releases.

Paul Prescod writes:
 > If the xmlplus hack works (really works, without subtle side effects) then
 > I would prefer that.

  What do you mean by "works"?  That there be a version of PyXML that
properly overrides a core xml package without breaking any code?  I
think that's quite achievable, but we need to wrap up the basic
packages up fairly quickly (Python 2.0b2 is scheduled for next
Tuesday, and we plan to make the deadline!).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 19 22:52:56 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 19 Sep 2000 23:52:56 +0200
Subject: [XML-SIG] Python package name
In-Reply-To: <20000919165642.A29766@kronos.cnri.reston.va.us> (message from
 Andrew Kuchling on Tue, 19 Sep 2000 16:56:42 -0400)
References: <Pine.LNX.4.21.0009191451360.6230-100000@amati.techno.com> <200009192022.WAA01181@loewis.home.cs.tu-berlin.de> <14791.53510.586817.460388@cj42289-a.reston1.va.home.com> <20000919165642.A29766@kronos.cnri.reston.va.us>
Message-ID: <200009192152.XAA01946@loewis.home.cs.tu-berlin.de>

> Er... can you explain this more clearly?

I believe the proposal is that, for every Python release, there is a
minimum required PyXML release that is allowed to supercede the
standard module. Yes, it requires magic, but no, the mechanism is not
hard to understand or implement.

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 20 05:59:49 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 20 Sep 2000 06:59:49 +0200
Subject: [XML-SIG] Uniform interface with Python 2.0
In-Reply-To: <200009140949.LAA12196@mail.cs.tu-berlin.de> (jh@web.de)
References: <200009140949.LAA12196@mail.cs.tu-berlin.de>
Message-ID: <200009200459.GAA01031@loewis.home.cs.tu-berlin.de>

> BTW, am I right that one aim is to keep PyXML 1.5.2-compatible too, for 
> some time (say, at least until 2.0 final is released)?

PyXML 0.6 won't be 1.5.2 compatible; the old wstring type has already
been removed from CVS. You can, of course, continue to use 0.5. 0.6
should be compatible with Python 1.6, though.

Regards,
Martin

From uche.ogbuji@fourthought.com  Wed Sep 20 06:28:32 2000
From: uche.ogbuji@fourthought.com (Uche Ogbuji)
Date: Tue, 19 Sep 2000 23:28:32 -0600
Subject: [XML-SIG] 4Suite 0.9.0 Release Candidate
Message-ID: <39C84B00.F20B2E5B@fourthought.com>

We're still struggling with Distutils, but we thought it would be useful
to release the source.

4DOM, 4XSLT and 4XPath are now rolled into one distutils package: 4Suite
version 0.9.0.  In addition, 4RDF and 4ODS are publicly released for the
first time and avaialable in the package.

There are many bug-fixes and improvements and several significant
optimizations (we've found 4XSLT 2 to 10 times faster than the last
release).  This includes a beta of a lightweight DOM implementation in
C.

The source build should work just fine (it's the RPMs and Windows builds
that have been giving us trouble).  Download

ftp://ftp.fourthought.com/pub/4Suite/4Suite-0.9.0rc1.tar.gz

and

ftp://ftp.fourthought.com/pub/4Suite/BisonGen-0.5.0rc1.tar.gz

Python 1.5.2 (we haven't had a chance to test with 1.6) and Distutils
0.9.2 are required.

You'll have to build BisonGen first: untar it and change to the
directory, then

python setup.py install

And then do the same for theh 4Suite package.

Next, to speed things up, you'll want to strip the debugging traces:

change to the $PYTHONHOME/site-packages/xml directory and run


strip_traceout -r dom/
strip_traceout -r xpath/
strip_traceout -r xslt/
strip_traceout -r rdf/
strip_traceout -r ods/


Then start from the README int he top-level 4Suite docs, and you're
ready to go.  Hopefully we'll sort out the binary packaging and have
final releases tomorrow or so.  In the meantime let us know if anything
is completely broken so we might get it fixed in the final package. 
Note that our entire test-suite now comes in the package (installed with
the docs of each component).


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python

From martin@loewis.home.cs.tu-berlin.de  Wed Sep 20 07:30:08 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 20 Sep 2000 08:30:08 +0200
Subject: [XML-SIG] pulldom and namespaces
Message-ID: <200009200630.IAA10042@loewis.home.cs.tu-berlin.de>

I have updated xml.sax.ContentHandler in PyXML to reflect the API
proposed by Lars, largely by copying Lars' patches for Python 2.  I
have then updated pulldom to use the *NS api. As a result, it now
builds namespacely correct Nodes [I hope]. Please report any problems.

Once Lars has applied his patches to Python 2, these changes to
pulldom need to be merged into Python 2 as well.

Regards,
Martin


From mal@lemburg.com  Wed Sep 20 09:55:05 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 20 Sep 2000 10:55:05 +0200
Subject: [XML-SIG] Python package name
References: <200009192300.RAA01451@localhost.localdomain>
Message-ID: <39C87B69.DD0D2DC9@lemburg.com>

uche.ogbuji@fourthought.com wrote:
> 
> > On Tue, 19 Sep 2000, Martin v. Loewis wrote:
> 
> > At one point Guido clarified that xml and xmlcore could migrate to xmlplus
> > and xml over time, just as long as we give people time to change and an
> > upgrade path.
> >
> > I understood this as:
> >
> > pyxml gets an xmlplus alias now
> > pyxml gives up xml in six months
> > xmlcore gets an xml alias then
> > xmlcore name is deprecated sometime later
> >
> > It's kind of ugly but I could live with it.
> >
> > If the xmlplus hack works (really works, without subtle side effects) then
> > I would prefer that.
> 
> I'm really sorry to be so far AWOL on such an important topic, but we've been
> running about like mad to get the next 4Suite out the door so we _can_ pay
> attention to Python 1.6 and 2.0.
> 
> But a quick pip for today:  I think the above approach to package
> naming/renaming is the best of all available hacks.

Wouldn't the whole situation be much easier to handle if
lib/python2/site-packages was searched *before* lib/python2 ?

That way, newly installed packages could effectively completely
override stdlib packages.

We will have a similar problem with Unicode and the stdlib
during the Python 2.0 cycle: people will want to use Unicode
together with the stdlib, yet many modules in the stdlib
don't support Unicode. To remedy this, users will have to
patch the stdlib modules and put them somewhere so that they
can override the original 2.0 ones.

BTW, with distutils coming on strong I don't really see a
need for any hacks: instead distutils should be given some
smart logic to do the right thing, ie. it should support
installing subpackages of a package. If that's not desired,
then I'd opt for overriding the whole package (without any
hacks to import the overridden one).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/

From guido@beopen.com  Wed Sep 20 16:07:50 2000
From: guido@beopen.com (Guido van Rossum)
Date: Wed, 20 Sep 2000 10:07:50 -0500
Subject: [XML-SIG] Python package name
In-Reply-To: Your message of "Wed, 20 Sep 2000 10:55:05 +0200."
 <39C87B69.DD0D2DC9@lemburg.com>
References: <200009192300.RAA01451@localhost.localdomain>
 <39C87B69.DD0D2DC9@lemburg.com>
Message-ID: <200009201507.KAA04851@cj20424-a.reston1.va.home.com>

> Wouldn't the whole situation be much easier to handle if
> lib/python2/site-packages was searched *before* lib/python2 ?
> 
> That way, newly installed packages could effectively completely
> override stdlib packages.

Not necessarily -- 2.1 will install in lib/python2, so an older
xml package in site-packages would override the newer one from 2.1!

It seems we may have to start thinking about a package versioning
mechanism!

> We will have a similar problem with Unicode and the stdlib
> during the Python 2.0 cycle: people will want to use Unicode
> together with the stdlib, yet many modules in the stdlib
> don't support Unicode. To remedy this, users will have to
> patch the stdlib modules and put them somewhere so that they
> can override the original 2.0 ones.

They can use $PYTHONPATH.

> BTW, with distutils coming on strong I don't really see a
> need for any hacks: instead distutils should be given some
> smart logic to do the right thing, ie. it should support
> installing subpackages of a package. If that's not desired,
> then I'd opt for overriding the whole package (without any
> hacks to import the overridden one).

That's another possibility.  But then distutils will have to become
aware of package versions again.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

From mal@lemburg.com  Wed Sep 20 15:50:29 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 20 Sep 2000 16:50:29 +0200
Subject: [XML-SIG] Python package name
References: <200009192300.RAA01451@localhost.localdomain>
 <39C87B69.DD0D2DC9@lemburg.com> <200009201507.KAA04851@cj20424-a.reston1.va.home.com>
Message-ID: <39C8CEB5.65A70BBE@lemburg.com>

Guido van Rossum wrote:
> 
> > Wouldn't the whole situation be much easier to handle if
> > lib/python2/site-packages was searched *before* lib/python2 ?
> >
> > That way, newly installed packages could effectively completely
> > override stdlib packages.
> 
> Not necessarily -- 2.1 will install in lib/python2, so an older
> xml package in site-packages would override the newer one from 2.1!
>
> It seems we may have to start thinking about a package versioning
> mechanism!

Perhaps a good start would be using lib/python-2.0.0 as installation
target rather than just lib/python2. I'm sure this was discussed
before, but given the problems we had with this during the 1.5
cycle (with 1.5.2 providing not only patches, but also new
features), I think a more fine-grained approach should be
considered for future versions.

About package versioning: how would the version be specified
in imports ?

from mx.DateTime(1.4.0) import now
from mx(1.0.0).DateTime import now
from mx(1.0.0).DateTime(1.4.0) import now

The directory layout would then look something like this:

mx/
	1.0.0/
		DateTime/
			1.4.0/

Package __path__ hooks could be used to implement the
lookup... or of course some new importer.

But what happens if there is no (old) version mx-1.0.0 installed ?
Should Python then default to mx-1.3.0 which is installed or
raise an ImportError ?

This sounds like trouble... ;-)
		
> > We will have a similar problem with Unicode and the stdlib
> > during the Python 2.0 cycle: people will want to use Unicode
> > together with the stdlib, yet many modules in the stdlib
> > don't support Unicode. To remedy this, users will have to
> > patch the stdlib modules and put them somewhere so that they
> > can override the original 2.0 ones.
> 
> They can use $PYTHONPATH.

True, but why not help them a little by letting site
installations override the stdlib ? After all, distutils
standard target is site-packages.

> > BTW, with distutils coming on strong I don't really see a
> > need for any hacks: instead distutils should be given some
> > smart logic to do the right thing, ie. it should support
> > installing subpackages of a package. If that's not desired,
> > then I'd opt for overriding the whole package (without any
> > hacks to import the overridden one).
> 
> That's another possibility.  But then distutils will have to become
> aware of package versions again.
 
This shouldn't be hard to add to the distutils processing:
before starting an installation of a package, the package
pre-install hook could check which versions are installed
and then decide whether to raise an exception or continue.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/

From martin@loewis.home.cs.tu-berlin.de  Wed Sep 20 19:05:48 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 20 Sep 2000 20:05:48 +0200
Subject: [XML-SIG] Releasing PyXML 0.6.0
Message-ID: <200009201805.UAA00851@loewis.home.cs.tu-berlin.de>

Version 0.6.0 of the Python/XML distribution is now available.  It
should be considered a beta release, and can be downloaded from
the following URLs:

	http://download.sourceforge.net/pyxml/PyXML-0.6.0.tar.gz
	http://download.sourceforge.net/pyxml/PyXML-0.6.0.win32.exe
	http://download.sourceforge.net/pyxml/PyXML-0.6.0.noarch.rpm

Changes in this version, compared to 0.5.x:

	* The 4DOM package has been integrated into PyXML.

	* The package supports now SAX2 interfaces in addition to the
SAX1 interfaces. Currently, pyexpat and xmlproc can serve as SAX2
drivers.

	* The proprietary Unicode type has been removed. Instead,
PyXML now relies on the standard Python Unicode type. In turn, PyXML
0.6.0 will not work with Python 1.5. It has been tested with 2.0b1.

	* PyXML now operates on top of the XML package coming in
Python 2.

The Python/XML distribution contains the basic tools required for
processing XML data using the Python programming language, assembled
into one easy-to-install package.  The distribution includes parsers
and standard interfaces such as SAX and DOM, along with various other
useful modules.  

The package currently contains:

	* XML parsers: Pyexpat (Jack Jansen), xmlproc (Lars Marius
Garshol), xmllib.py (Sjoerd Mullender) using the sgmlop.c accelerator
module (Fredrik Lundh).

	* SAX interface (Lars Marius Garshol)
	* DOM interface (Stefane Fermigier, A.M. Kuchling)
	* 4DOM interface from Fourthought (Uche Ogbuji, Mike Olson)
	* xmlarch.py, for architectural forms processing (Geir Ove Grønmo)
	* Various utility modules and functions (various people)
	* Documentation and example programs (various people)

The code is being developed bazaar-style by contributors from the
Python XML Special Interest Group, so please send comments, questions,
or bug reports to <xml-sig@python.org>.

For more information about Python and XML, see:
	http://www.python.org/topics/xml/

Please report any issues you find with the package [including
corrections and additions to the announcement - this is my first PyXML
release].

-- 
Martin v. Löwis               http://www.informatik.hu-berlin.de/~loewis


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 20 19:28:22 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 20 Sep 2000 20:28:22 +0200
Subject: [XML-SIG] Removing xml.unicode
Message-ID: <200009201828.UAA01142@loewis.home.cs.tu-berlin.de>

I noticed that the xml.unicode package does not serve any purpose,
anymore. Is that correct? Are there any objections to removing it?

Regards,
Martin


From fdrake@beopen.com  Wed Sep 20 19:39:57 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Wed, 20 Sep 2000 14:39:57 -0400 (EDT)
Subject: [XML-SIG] Removing xml.unicode
In-Reply-To: <200009201828.UAA01142@loewis.home.cs.tu-berlin.de>
References: <200009201828.UAA01142@loewis.home.cs.tu-berlin.de>
Message-ID: <14793.1149.591182.412735@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > I noticed that the xml.unicode package does not serve any purpose,
 > anymore. Is that correct? Are there any objections to removing it?

  Nope!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 20 19:38:00 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 20 Sep 2000 20:38:00 +0200
Subject: [XML-SIG] CRLF in .py sources
Message-ID: <200009201838.UAA01252@loewis.home.cs.tu-berlin.de>

I noticed a number of files in the PyXML CVS repository contain CRLF
as line-ending, which confuses compileall; see the list of files
below.  Are there any objections to change these files to have
Unix-style line endings? 

CVS would still retrieve them with CRLF on Windows, even if they have
LF as line ending in the repository. Removing the CR characters would
mean that every line in the file changes.

Regards,
Martin

demo/xmlproc/dtd2schema.py
demo/xmlproc/dtdcmd.py
demo/xmlproc/outputters.py
demo/xmlproc/wxValidator.py
xml/parsers/xmlproc/catalog.py
xml/parsers/xmlproc/charconv.py
xml/parsers/xmlproc/dtdparser.py
xml/parsers/xmlproc/errors.py
xml/parsers/xmlproc/namespace.py
xml/parsers/xmlproc/utils.py
xml/parsers/xmlproc/xcatalog.py
xml/parsers/xmlproc/xmlapp.py
xml/parsers/xmlproc/xmldtd.py
xml/parsers/xmlproc/xmlproc.py
xml/parsers/xmlproc/xmlutils.py
xml/parsers/xmlproc/xmlval.py
xml/sax/drivers/drv_htmllib.py
xml/sax/drivers/drv_pyexpat.py
xml/sax/drivers/drv_sgmllib.py
xml/sax/drivers/drv_sgmlop.py
xml/sax/drivers/drv_xmldc.py
xml/sax/drivers/drv_xmllib.py
xml/sax/drivers/drv_xmlproc.py
xml/sax/drivers/drv_xmlproc_val.py
xml/sax/drivers/drv_xmltoolkit.py
xml/sax/drivers/pylibs.py
xml/sax/sax2exts.py
xml/sax/saxexts.py
xml/sax/saxlib.py
xml/sax/saxutils.py
xml/sax/drivers2/drv_pyexpat.py
xml/sax/drivers2/drv_xmlproc.py


From guido@beopen.com  Thu Sep 21 16:38:04 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 21 Sep 2000 10:38:04 -0500
Subject: [XML-SIG] Python package name
In-Reply-To: Your message of "Wed, 20 Sep 2000 16:50:29 +0200."
 <39C8CEB5.65A70BBE@lemburg.com>
References: <200009192300.RAA01451@localhost.localdomain> <39C87B69.DD0D2DC9@lemburg.com> <200009201507.KAA04851@cj20424-a.reston1.va.home.com>
 <39C8CEB5.65A70BBE@lemburg.com>
Message-ID: <200009211538.KAA08180@cj20424-a.reston1.va.home.com>

> Perhaps a good start would be using lib/python-2.0.0 as installation
> target rather than just lib/python2. I'm sure this was discussed
> before, but given the problems we had with this during the 1.5
> cycle (with 1.5.2 providing not only patches, but also new
> features), I think a more fine-grained approach should be
> considered for future versions.

We're using lib/python2.0, and we plan not to make major releases with
a 3rd level version number increment!  SO I think that's not necessary.

> About package versioning: how would the version be specified
> in imports ?
> 
> from mx.DateTime(1.4.0) import now
> from mx(1.0.0).DateTime import now
> from mx(1.0.0).DateTime(1.4.0) import now
> 
> The directory layout would then look something like this:
> 
> mx/
> 	1.0.0/
> 		DateTime/
> 			1.4.0/
> 
> Package __path__ hooks could be used to implement the
> lookup... or of course some new importer.
> 
> But what happens if there is no (old) version mx-1.0.0 installed ?
> Should Python then default to mx-1.3.0 which is installed or
> raise an ImportError ?
> 
> This sounds like trouble... ;-)

You've got it.  Please move this to python-dev.  It's good PEP
material!

> > > We will have a similar problem with Unicode and the stdlib
> > > during the Python 2.0 cycle: people will want to use Unicode
> > > together with the stdlib, yet many modules in the stdlib
> > > don't support Unicode. To remedy this, users will have to
> > > patch the stdlib modules and put them somewhere so that they
> > > can override the original 2.0 ones.
> > 
> > They can use $PYTHONPATH.
> 
> True, but why not help them a little by letting site
> installations override the stdlib ? After all, distutils
> standard target is site-packages.

Overrides of the stdlib are dangerous in general and should not be
encouraged.

> > > BTW, with distutils coming on strong I don't really see a
> > > need for any hacks: instead distutils should be given some
> > > smart logic to do the right thing, ie. it should support
> > > installing subpackages of a package. If that's not desired,
> > > then I'd opt for overriding the whole package (without any
> > > hacks to import the overridden one).
> > 
> > That's another possibility.  But then distutils will have to become
> > aware of package versions again.
>  
> This shouldn't be hard to add to the distutils processing:
> before starting an installation of a package, the package
> pre-install hook could check which versions are installed
> and then decide whether to raise an exception or continue.

Here's another half-baked idea about versions: perhaps packages could
have a __version__.py file?

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

From uche.ogbuji@fourthought.com  Thu Sep 21 02:51:16 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 20 Sep 2000 19:51:16 -0600
Subject: [XML-SIG] ANN: 4Suite 0.9.0
Message-ID: <200009210151.TAA08736@localhost.localdomain>

Fourthought, Inc. (http://Fourthought.com) announces the release of

                             4Suite 0.9.0
                      ---------------------------
    Open-Source Tools for standards-based XML, DOM, XPath, XSLT, RDF
               and object-database development in Python

4Suite is a collection of Python tools for XML processing and object
database management.  An integrated packaging of several formerly
separately-distributed components: 4DOM, 4XPath and 4XSLT,
and featuring the new 4RDF and 4ODS.


More info and Obtaining 4Suite
------------------------------

Please see

        http://Fourthought.com/4Suite

Or you can download 4Suite from

        ftp://Fourthought.com/pub/4Suite

There are Windows Packages available at

        ftp://Fourthought.com/pub/4Suite/binaries/windows/

And Linux RPMs available at

        ftp://Fourthought.com/pub/4Suite/binaries/redhat/

4Suite is distributed under a license similar to that of Python.
See http://4suite.org/COPYRIGHT


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python







From fdrake@beopen.com  Thu Sep 21 17:55:12 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 21 Sep 2000 12:55:12 -0400 (EDT)
Subject: [XML-SIG] Python package name
In-Reply-To: <200009211538.KAA08180@cj20424-a.reston1.va.home.com>
References: <200009192300.RAA01451@localhost.localdomain>
 <39C87B69.DD0D2DC9@lemburg.com>
 <200009201507.KAA04851@cj20424-a.reston1.va.home.com>
 <39C8CEB5.65A70BBE@lemburg.com>
 <200009211538.KAA08180@cj20424-a.reston1.va.home.com>
Message-ID: <14794.15728.359950.889802@cj42289-a.reston1.va.home.com>

Guido van Rossum writes:
 > Here's another half-baked idea about versions: perhaps packages could
 > have a __version__.py file?

  Why not __version__, that just contains the version number?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From guido@beopen.com  Thu Sep 21 19:59:22 2000
From: guido@beopen.com (Guido van Rossum)
Date: Thu, 21 Sep 2000 13:59:22 -0500
Subject: [XML-SIG] Python package name
In-Reply-To: Your message of "Thu, 21 Sep 2000 12:55:12 -0400."
 <14794.15728.359950.889802@cj42289-a.reston1.va.home.com>
References: <200009192300.RAA01451@localhost.localdomain> <39C87B69.DD0D2DC9@lemburg.com> <200009201507.KAA04851@cj20424-a.reston1.va.home.com> <39C8CEB5.65A70BBE@lemburg.com> <200009211538.KAA08180@cj20424-a.reston1.va.home.com>
 <14794.15728.359950.889802@cj42289-a.reston1.va.home.com>
Message-ID: <200009211859.NAA29653@cj20424-a.reston1.va.home.com>

>  > Here's another half-baked idea about versions: perhaps packages could
>  > have a __version__.py file?
> 
>   Why not __version__, that just contains the version number?

__version__.py has less of a chance of getting lost when moving or
copying files.  It can be consulted by Python code by simply saying

  import package
  if package.__version__.version <= (1, 2, 3): ...

We may restrict the contents of __version__.py for the purpose of
parsing or evaluating by a version dependency checker.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

From martin@loewis.home.cs.tu-berlin.de  Thu Sep 21 19:21:02 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 21 Sep 2000 20:21:02 +0200
Subject: [XML-SIG] Python package name
In-Reply-To: <200009211859.NAA29653@cj20424-a.reston1.va.home.com> (message
 from Guido van Rossum on Thu, 21 Sep 2000 13:59:22 -0500)
References: <200009192300.RAA01451@localhost.localdomain> <39C87B69.DD0D2DC9@lemburg.com> <200009201507.KAA04851@cj20424-a.reston1.va.home.com> <39C8CEB5.65A70BBE@lemburg.com> <200009211538.KAA08180@cj20424-a.reston1.va.home.com>
 <14794.15728.359950.889802@cj42289-a.reston1.va.home.com> <200009211859.NAA29653@cj20424-a.reston1.va.home.com>
Message-ID: <200009211821.UAA18156@loewis.home.cs.tu-berlin.de>

> __version__.py has less of a chance of getting lost when moving or
> copying files.  It can be consulted by Python code by simply saying
> 
>   import package
>   if package.__version__.version <= (1, 2, 3): ...
> 
> We may restrict the contents of __version__.py for the purpose of
> parsing or evaluating by a version dependency checker.

This is probably off-topic here, and a worth a separate PEP, but...

I always disliked __init__.py; files with that many underscores look
wrong. So the prospect of adding another file with underscores is
saddening.

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Fri Sep 22 07:13:12 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 22 Sep 2000 08:13:12 +0200
Subject: [XML-SIG] DTDHandler and EntityResolver
Message-ID: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de>

Folks,

xml.sax of Python 2 currently does not have the DTDHandler and
EntityResolver interfaces. On 26 Jun, Paul argued that they should not
appear in Python 1.6 (then), as they are too complex/esoteric. I tend
to agree, especially as pyexpat does not provide the appropriate
callbacks (does it?)

On 16 Sep, Lars mention that he wants to edit these interfaces into
xml.sax.xmlreader. Given that we are running short of time: Is that
really necessary? Adding the interfaces themselves might be ok, but
having expatreader support them seems not feasible: that would be an
extension both over Python 2 code freeze, and PyXML 0.6.0.

Comments?

Martin


From fdrake@beopen.com  Fri Sep 22 07:20:58 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 22 Sep 2000 02:20:58 -0400 (EDT)
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de>
References: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de>
Message-ID: <14794.64074.403754.860753@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > On 16 Sep, Lars mention that he wants to edit these interfaces into
 > xml.sax.xmlreader. Given that we are running short of time: Is that
 > really necessary? Adding the interfaces themselves might be ok, but

  I'd love to have them with full support, but we're pushing it as it
stands.  The release is Tuesday, and we should have a code freeze on
Sunday so that we can spend Monday doing build test and making sure
the installer is in good shape.
  (Jeremy: you're the release manager, announce the code freeze date
on python-dev & critical SIGs!)
  So let's hold off.  It can go into a future PyXML package and then
move into Python 2.1 when we're happy with the implementation and
documentation.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From lalo@hackandroll.org  Fri Sep 22 07:27:49 2000
From: lalo@hackandroll.org (Lalo Martins)
Date: Fri, 22 Sep 2000 03:27:49 -0300
Subject: [XML-SIG] xml.dom.core.Document objects don't pickle (BUG WITH PATCH)
Message-ID: <20000922032749.A5082@hackandroll.org>

--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

If you try to pickle a dom Document object you'll get a pickle
error because it stores the xml module as an attribute.

My reading of the Node class suggests you didn't intend to
pickle the Node attributes at all, just the _nodeData and the
Document reference, right?

To do that, it's not enough to just provide a __getinitargs__
method - you also need a __getstate__ which returns an empty
dictionary. I added one to my copy and it works fine.

[]s,
                                               |alo
                                               +----
--
          Hack and Roll  ( http://www.hackandroll.org )
            News for, uh, whatever it is that we are.


http://zope.gf.com.br/lalo           mailto:lalo@hackandroll.org
         pgp key: http://zope.gf.com.br/lalo/pessoal/pgp

Brazil of Darkness (RPG)    ---     http://zope.gf.com.br/BroDar

--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="xml.dom.core.diff"

--- core.py.orig	Fri Sep 22 02:39:45 2000
+++ core.py	Fri Sep 22 03:22:13 2000
@@ -318,6 +318,9 @@
     def __getinitargs__(self):
         return self._node, self._document
 
+    def __getstate__ (self):
+	return {} # no pickling
+	
     # The following two methods implement handling of properties; references
     # to attributes such as .parentNode are redirected into calls to 
     # get_parentNode or set_parentNode.

--u3/rZRmxL6MmkK24--

From larsga@garshol.priv.no  Fri Sep 22 15:18:33 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 22 Sep 2000 16:18:33 +0200
Subject: [XML-SIG] CRLF in .py sources
In-Reply-To: <200009201838.UAA01252@loewis.home.cs.tu-berlin.de>
References: <200009201838.UAA01252@loewis.home.cs.tu-berlin.de>
Message-ID: <m3hf78qzly.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
|
| I noticed a number of files in the PyXML CVS repository contain CRLF
| as line-ending, which confuses compileall; see the list of files
| below.  Are there any objections to change these files to have
| Unix-style line endings? 

None at all from me.

--Lars M.


From larsga@garshol.priv.no  Fri Sep 22 15:22:25 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 22 Sep 2000 16:22:25 +0200
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de>
References: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de>
Message-ID: <m3g0msqzfi.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
| 
| On 16 Sep, Lars mention that he wants to edit these interfaces into
| xml.sax.xmlreader. Given that we are running short of time: Is that
| really necessary? Adding the interfaces themselves might be ok, but
| having expatreader support them seems not feasible: that would be an
| extension both over Python 2 code freeze, and PyXML 0.6.0.
| 
| Comments?

They are already in xmlreader, except that they are not initialized in
the constructor and that was what I wanted to change.  Only adding the
interfaces is acceptable to me, but it would be better if we could
make pyexpat support them both.

It has the necessary callbacks to do so, and support for DTDHandler is
required for full conformance with the XML 1.0 recommendation (that is
why the handler is there, actually).

DTDHandler is dead simple, EntityResolver more complex.

--Lars M.


From larsga@garshol.priv.no  Fri Sep 22 15:25:40 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 22 Sep 2000 16:25:40 +0200
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <14794.64074.403754.860753@cj42289-a.reston1.va.home.com>
References: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de> <14794.64074.403754.860753@cj42289-a.reston1.va.home.com>
Message-ID: <m3em2cqza3.fsf@lambda.garshol.priv.no>

* Fred L. Drake, Jr.
|
| I'd love to have them with full support, but we're pushing it as it
| stands.  The release is Tuesday, and we should have a code freeze on
| Sunday so that we can spend Monday doing build test and making sure
| the installer is in good shape.

I'm happy with a code freeze on Sunday.  I plan to be online all
Sunday and do this then, which should mean that it will all be done
before noon Sunday US time anyway.

I will do this as patches and then people can say what they think
about those.

--Laers 


From fdrake@beopen.com  Fri Sep 22 15:26:43 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 22 Sep 2000 10:26:43 -0400 (EDT)
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <m3g0msqzfi.fsf@lambda.garshol.priv.no>
References: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de>
 <m3g0msqzfi.fsf@lambda.garshol.priv.no>
Message-ID: <14795.27683.513703.707835@cj42289-a.reston1.va.home.com>

Lars Marius Garshol writes:
 > It has the necessary callbacks to do so, and support for DTDHandler is
 > required for full conformance with the XML 1.0 recommendation (that is
 > why the handler is there, actually).

  This is important.
  Do you have patches ready?  We're running low on time.  ;(

 > DTDHandler is dead simple, EntityResolver more complex.

  Are both required for conformance, or just DTDHandler?  My guess
would be that EntityResolver is optional here since there's no
requirement from the recommendation that external entities are
processed, but that's just my (limited) understanding.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From larsga@garshol.priv.no  Fri Sep 22 15:47:10 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 22 Sep 2000 16:47:10 +0200
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <14795.27683.513703.707835@cj42289-a.reston1.va.home.com>
References: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de> 	<m3g0msqzfi.fsf@lambda.garshol.priv.no> <14795.27683.513703.707835@cj42289-a.reston1.va.home.com>
Message-ID: <m38zskqya9.fsf@lambda.garshol.priv.no>

[context note: we are talking about adding functionality to expat;
whether the SAX 2.0 definition should have these two interfaces is not
discussed in this subthread]

* Lars Marius Garshol
|
| It has the necessary callbacks to do so, and support for DTDHandler
| is required for full conformance with the XML 1.0 recommendation
| (that is why the handler is there, actually).

* Fred L. Drake, Jr.
| 
| This is important.
| Do you have patches ready?  We're running low on time.  ;(

I do not have the patches now, but I will have them Sunday morning and
post them in the PatchManager then.
 
* Lars Marius Garshol
|
| DTDHandler is dead simple, EntityResolver more complex.
 
* Fred L. Drake, Jr.
|
| Are both required for conformance, or just DTDHandler? 

Only DTDHandler.

| My guess would be that EntityResolver is optional here since there's
| no requirement from the recommendation that external entities are
| processed [...]

This is correct.

--Lars M. (in a rush)


From fdrake@beopen.com  Fri Sep 22 15:47:26 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 22 Sep 2000 10:47:26 -0400 (EDT)
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
Message-ID: <14795.28926.52974.455423@cj42289-a.reston1.va.home.com>

  I have a couple of questions about pyexpat.

  First question:
  At various points, Guido has commented on the strange name "pyexpat"
-- he generally doesn't like names with a "py" stuck on the front
simply because something is written in Python.
  Does anyone have an objection to renaming pyexpat _expat, and using
a Python wrapper called xml.parsers.expat?  The wrapper would only
need to import the existing interface, not wrap it with Python
classes, which would only slow things down.

  Second question:
  I'd also like to understand why the error constants are in a
sub-module, pyexpat.errors, instead of being in pyexpat itself.
pyexpat.errors is a strange little module in that you can't import it
until after you've done an "import pyexpat" -- it probably won't bite
anyone, but this doesn't really follow the least-surprise principle.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From fdrake@beopen.com  Fri Sep 22 16:00:00 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 22 Sep 2000 11:00:00 -0400 (EDT)
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <m3em2cqza3.fsf@lambda.garshol.priv.no>
References: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de>
 <14794.64074.403754.860753@cj42289-a.reston1.va.home.com>
 <m3em2cqza3.fsf@lambda.garshol.priv.no>
Message-ID: <14795.29680.189233.181558@cj42289-a.reston1.va.home.com>

Lars Marius Garshol writes:
 > I'm happy with a code freeze on Sunday.  I plan to be online all
 > Sunday and do this then, which should mean that it will all be done
 > before noon Sunday US time anyway.
 > 
 > I will do this as patches and then people can say what they think
 > about those.

  Sounds good; I'll try to look at the patches as early Sunday as I
can, but expect my wife will attempt to interfere.  ;)  Having them in
as patches is good enough I think.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From prescod@prescod.net  Fri Sep 22 20:34:45 2000
From: prescod@prescod.net (Paul)
Date: Fri, 22 Sep 2000 14:34:45 -0500 (CDT)
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0009221433120.6214-100000@amati.techno.com>

On Fri, 22 Sep 2000, Martin v. Loewis wrote:

> Folks,
> 
> xml.sax of Python 2 currently does not have the DTDHandler and
> EntityResolver interfaces. On 26 Jun, Paul argued that they should not
> appear in Python 1.6 (then), as they are too complex/esoteric. I tend
> to agree, especially as pyexpat does not provide the appropriate
> callbacks (does it?)

I agree that these are not important for 95% of all SAX users. It is the
sort of thing that we should add after we get requests from the Python
users out there.

 Paul Prescod


From prescod@prescod.net  Fri Sep 22 20:50:16 2000
From: prescod@prescod.net (Paul)
Date: Fri, 22 Sep 2000 14:50:16 -0500 (CDT)
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <14795.28926.52974.455423@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0009221443540.6214-100000@amati.techno.com>

On Fri, 22 Sep 2000, Fred L. Drake, Jr. wrote:

> 
>   I have a couple of questions about pyexpat.
> 
>   First question:
>   At various points, Guido has commented on the strange name "pyexpat"
> -- he generally doesn't like names with a "py" stuck on the front
> simply because something is written in Python.
>   Does anyone have an objection to renaming pyexpat _expat, and using
> a Python wrapper called xml.parsers.expat?  The wrapper would only
> need to import the existing interface, not wrap it with Python
> classes, which would only slow things down.

If the DLL name is hidden from the user then why not use pyexpat? It has
the virtue that in flat-namespace library environments like Windows,
nobody else is going to make a library with the same name. Whereas _expat
would be perfectly reasonable for a TCL or Perl DLL that also embeds
expat.

>   Second question:
>   I'd also like to understand why the error constants are in a
> sub-module, pyexpat.errors, instead of being in pyexpat itself.
> pyexpat.errors is a strange little module in that you can't import it
> until after you've done an "import pyexpat" -- it probably won't bite
> anyone, but this doesn't really follow the least-surprise principle.

Well, according to your proposals nobody is going to reference pyexpat (or
anything in it) directly anyhow. You can remap it however you want in your
wrapper.

I was trying to follow os.path but obviously it doesn't work exactly the
same way os.path does. The overall goal was to avoid having a confused
top-level environment. I think that dir() is one of Python's great
features and overloaded top-level environment destroy its utility.

 Paul



From martin@loewis.home.cs.tu-berlin.de  Fri Sep 22 20:50:47 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 22 Sep 2000 21:50:47 +0200
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <m38zskqya9.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 22 Sep 2000 16:47:10 +0200)
References: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de> 	<m3g0msqzfi.fsf@lambda.garshol.priv.no> <14795.27683.513703.707835@cj42289-a.reston1.va.home.com> <m38zskqya9.fsf@lambda.garshol.priv.no>
Message-ID: <200009221950.VAA01090@loewis.home.cs.tu-berlin.de>

> I do not have the patches now, but I will have them Sunday morning and
> post them in the PatchManager then.

Will you allow for necessary updates to minidom after these changes
apply?

Regards,
Martin

From martin@loewis.home.cs.tu-berlin.de  Fri Sep 22 20:46:44 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 22 Sep 2000 21:46:44 +0200
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <14795.28926.52974.455423@cj42289-a.reston1.va.home.com>
 (fdrake@beopen.com)
References: <14795.28926.52974.455423@cj42289-a.reston1.va.home.com>
Message-ID: <200009221946.VAA01078@loewis.home.cs.tu-berlin.de>

>   At various points, Guido has commented on the strange name "pyexpat"
> -- he generally doesn't like names with a "py" stuck on the front
> simply because something is written in Python.

I hesitated to ask the same question for a couple of weeks now.

>   Does anyone have an objection to renaming pyexpat _expat, and
> using a Python wrapper called xml.parsers.expat?

Actually, why do we have to have a wrapper? Wouldn't do expat as a
module name just fine? There is plenty of builtin modules that don't
start with an underscore: array, binascii, bsddb, gc, to name a few.

>   I'd also like to understand why the error constants are in a
> sub-module, pyexpat.errors, instead of being in pyexpat itself.
> pyexpat.errors is a strange little module in that you can't import it
> until after you've done an "import pyexpat" -- it probably won't bite
> anyone, but this doesn't really follow the least-surprise principle.

Good question also. If the module is renamed, code needs to adopt,
anyway - so just move the exceptions a level up.

Regards,
Martin


From prescod@prescod.net  Fri Sep 22 21:05:11 2000
From: prescod@prescod.net (Paul)
Date: Fri, 22 Sep 2000 15:05:11 -0500 (CDT)
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <200009221946.VAA01078@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0009221502570.6214-100000@amati.techno.com>

On Fri, 22 Sep 2000, Martin v. Loewis wrote:

> Actually, why do we have to have a wrapper? Wouldn't do expat as a
> module name just fine? There is plenty of builtin modules that don't
> start with an underscore: array, binascii, bsddb, gc, to name a few.

Yeah, well, expat ships with Mozilla, Apache, some versions of Perl and
some versions of TCL. If we all chose the "obvious" name you'd end up with
four expat.dll's on a fairly typical Windows machine.

> Good question also. If the module is renamed, code needs to adopt,
> anyway - so just move the exceptions a level up.

I still think that they should be all together in a dictionary but Fred
can do what he wants.

 Paul



From martin@loewis.home.cs.tu-berlin.de  Fri Sep 22 21:19:04 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 22 Sep 2000 22:19:04 +0200
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <Pine.LNX.4.21.0009221443540.6214-100000@amati.techno.com>
 (message from Paul on Fri, 22 Sep 2000 14:50:16 -0500 (CDT))
References: <Pine.LNX.4.21.0009221443540.6214-100000@amati.techno.com>
Message-ID: <200009222019.WAA01311@loewis.home.cs.tu-berlin.de>

> If the DLL name is hidden from the user then why not use pyexpat? 

It's not just a DLL name - it also is a module name. On Unix
installation, it often won't even come as a separate file, but users
will still need to do

import pyexpat

to get hold of it.

> It has the virtue that in flat-namespace library environments like
> Windows, nobody else is going to make a library with the same
> name. Whereas _expat would be perfectly reasonable for a TCL or Perl
> DLL that also embeds expat.

That is efficiently avoided by calling it expat.pyd, or expatmodule.so
on Unix.

Regards.
Martin

From martin@loewis.home.cs.tu-berlin.de  Fri Sep 22 21:31:13 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 22 Sep 2000 22:31:13 +0200
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <Pine.LNX.4.21.0009221502570.6214-100000@amati.techno.com>
 (message from Paul on Fri, 22 Sep 2000 15:05:11 -0500 (CDT))
References: <Pine.LNX.4.21.0009221502570.6214-100000@amati.techno.com>
Message-ID: <200009222031.WAA01364@loewis.home.cs.tu-berlin.de>

> Yeah, well, expat ships with Mozilla, Apache, some versions of Perl and
> some versions of TCL. If we all chose the "obvious" name you'd end up with
> four expat.dll's on a fairly typical Windows machine.

Well, ours would be expat.pyd, of course. And it would have the expat
library statically linked, so no additional DLL would be required.

It appears that those building binary distributions could even
integrate pyexpat and the expat library into python20.dll, as long as
they include a notice that expat is available in source, and point to
the MPL. Since they have to do this anyway (according to the MPL, as
they distribute a Larger Work), I see absolutely no reason for expat
to live in a DLL on Windows.

Regards,
Martin

From prescod@prescod.net  Fri Sep 22 22:04:21 2000
From: prescod@prescod.net (Paul)
Date: Fri, 22 Sep 2000 16:04:21 -0500 (CDT)
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <200009222019.WAA01311@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0009221601100.6214-100000@amati.techno.com>

On Fri, 22 Sep 2000, Martin v. Loewis wrote:

> It's not just a DLL name - it also is a module name. 

No, Fred has proposed that the module name would be xml.parsers.expat .

> That is efficiently avoided by calling it expat.pyd, or expatmodule.so
> on Unix.

I'm not as confident as you that expat.pyd and expat.dll running in the
same address space will be interpreted as being different DLLs.

 Paul Prescod


From fdrake@beopen.com  Fri Sep 22 22:42:59 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 22 Sep 2000 17:42:59 -0400 (EDT)
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <Pine.LNX.4.21.0009221601100.6214-100000@amati.techno.com>
References: <200009222019.WAA01311@loewis.home.cs.tu-berlin.de>
 <Pine.LNX.4.21.0009221601100.6214-100000@amati.techno.com>
Message-ID: <14795.53859.744183.261270@cj42289-a.reston1.va.home.com>

Paul writes:
 > No, Fred has proposed that the module name would be xml.parsers.expat .

  Let's make this (a little) easier; let's call the extension module
pyexpat, and have xml.parsers.expat be the published interface.

 > I'm not as confident as you that expat.pyd and expat.dll running in the
 > same address space will be interpreted as being different DLLs.

  I have little confidence in this as well, but am not expert on
Windows DLL behavior.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From prescod@prescod.net  Fri Sep 22 22:59:08 2000
From: prescod@prescod.net (Paul)
Date: Fri, 22 Sep 2000 16:59:08 -0500 (CDT)
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <14795.53859.744183.261270@cj42289-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.21.0009221658450.6214-100000@amati.techno.com>

On Fri, 22 Sep 2000, Fred L. Drake, Jr. wrote:

> 
> Paul writes:
>  > No, Fred has proposed that the module name would be xml.parsers.expat .
> 
>   Let's make this (a little) easier; let's call the extension module
> pyexpat, and have xml.parsers.expat be the published interface.

I thought that was what you were proposing. Sure, that's fine with me.

 Paul Prescod



From fdrake@beopen.com  Sat Sep 23 06:33:54 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Sat, 23 Sep 2000 01:33:54 -0400 (EDT)
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <Pine.LNX.4.21.0009221658450.6214-100000@amati.techno.com>
References: <14795.53859.744183.261270@cj42289-a.reston1.va.home.com>
 <Pine.LNX.4.21.0009221658450.6214-100000@amati.techno.com>
Message-ID: <14796.16578.568115.240265@cj42289-a.reston1.va.home.com>

Paul writes:
 > I thought that was what you were proposing. Sure, that's fine with me.

  What changed was that I'm no longer proposing to rename pyexpat to
_expat.
  I've added the xml.parsers.expat module and made the appropriate
updates elsewhere.  Done for the night....


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From fdrake@beopen.com  Sat Sep 23 06:43:38 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Sat, 23 Sep 2000 01:43:38 -0400 (EDT)
Subject: [XML-SIG] pyexpat v. xml.parsers.expat ?
In-Reply-To: <Pine.LNX.4.21.0009221443540.6214-100000@amati.techno.com>
References: <14795.28926.52974.455423@cj42289-a.reston1.va.home.com>
 <Pine.LNX.4.21.0009221443540.6214-100000@amati.techno.com>
Message-ID: <14796.17162.109868.834757@cj42289-a.reston1.va.home.com>

Paul writes:
 > Well, according to your proposals nobody is going to reference pyexpat (or
 > anything in it) directly anyhow. You can remap it however you want in your
 > wrapper.

  The structure is still interesting.

 > I was trying to follow os.path but obviously it doesn't work exactly the
 > same way os.path does. The overall goal was to avoid having a confused

  The reason the os.path thing actually works is that os is imported
before user code ever gets control -- when site imports os, os can do
what it needs to do.  If it wasn't import before user code is run, it
wouldn't work.  To import a submodule in the general case, the parent
must be a package -- the directory and __init__.py{,c,o} file *must*
exist.
  Tedious and somewhat annoying, but that's the current mechanism.

 > top-level environment. I think that dir() is one of Python's great
 > features and overloaded top-level environment destroy its utility.

  I don't disagree with your goal of keeping the interface clean --
the fact that it was a module was throwing me off.  When I revised the
documentation to use xml.parsers.expat, I decided not to document it
as a module, but just say it's an object.  (Hmm, now I can think of
another change that's required in the docs regarding this.)
  Sometimes it would be really nice to have an instance that doesn't
have a class for things like this.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member


From larsga@garshol.priv.no  Sat Sep 23 14:08:47 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 23 Sep 2000 15:08:47 +0200
Subject: [XML-SIG] DTDHandler and EntityResolver
In-Reply-To: <200009221950.VAA01090@loewis.home.cs.tu-berlin.de>
References: <200009220613.IAA07451@loewis.home.cs.tu-berlin.de> 	<m3g0msqzfi.fsf@lambda.garshol.priv.no> <14795.27683.513703.707835@cj42289-a.reston1.va.home.com> <m38zskqya9.fsf@lambda.garshol.priv.no> <200009221950.VAA01090@loewis.home.cs.tu-berlin.de>
Message-ID: <m3g0mr2r34.fsf@lambda.garshol.priv.no>

* Lars Marius Garshol
|
| I do not have the patches now, but I will have them Sunday morning
| and post them in the PatchManager then.

* Martin v. Loewis
| 
| Will you allow for necessary updates to minidom after these changes
| apply?

I doubt that any updates to minidom will be needed, but if so I will
try to add those to the patches as well.

--Lars M.


From larsga@garshol.priv.no  Sun Sep 24 15:49:43 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 24 Sep 2000 16:49:43 +0200
Subject: [XML-SIG] Status
Message-ID: <m38zsh26bc.fsf@lambda.garshol.priv.no>

I committed some bug fixes and some SAX test code this morning.  After
that I made the promised patches in the PatchManager:

 101573:

   This has now been updated to no longer break the minidom regression
   test, which should mean that minidom will survive the application
   of this patch.

 101630:

   Added back the InputSource class, which is referred to many places
   in doco strings and also needed by 101631.  Added test cases to the
   SAX test code to exercise it.

 101631:

   Added back EntityResolver and DTDHandler (which were already
   referred to in the code in many places) and added support for these
   to expatreader.py  Test cases added to the SAX test code.

 101632:

   Corrected the Attributes interface and extended 101573 with proper
   support for namespaces using this interface.  Added test cases for
   this as well.

As soon as this is approved it will be checked in.

--Lars M.



From martin@loewis.home.cs.tu-berlin.de  Sun Sep 24 20:16:07 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 24 Sep 2000 21:16:07 +0200
Subject: [XML-SIG] Status
In-Reply-To: <m38zsh26bc.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 24 Sep 2000 16:49:43 +0200)
References: <m38zsh26bc.fsf@lambda.garshol.priv.no>
Message-ID: <200009241916.VAA01029@loewis.home.cs.tu-berlin.de>

>  101573:
> 
>    This has now been updated to no longer break the minidom regression
>    test, which should mean that minidom will survive the application
>    of this patch.

[I was going to comment on attributes not being passed to the handler,
but that is apparently solved in 101632]

Also, on the pulldom part: Did you have a look at the pulldom in
current PyXML? I believe it does support namespaces better, which is
now possible since the namespace API of SAX2 has been determined.

>  101630:
> 
>    Added back the InputSource class, which is referred to many places
>    in doco strings and also needed by 101631.  Added test cases to the
>    SAX test code to exercise it.

I think there has been some debate on the input source class, but so
be it. It just seems that you have broken the ability to pass file
objects to the parser's parse() methods, right?

>  101631:
> 
>    Added back EntityResolver and DTDHandler (which were already
>    referred to in the code in many places) and added support for these
>    to expatreader.py  Test cases added to the SAX test code.

While I can see the others applied, this is not. Why?

Regards,
Martin


From larsga@garshol.priv.no  Sun Sep 24 20:34:11 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 24 Sep 2000 21:34:11 +0200
Subject: [XML-SIG] Status
In-Reply-To: <200009241916.VAA01029@loewis.home.cs.tu-berlin.de>
References: <m38zsh26bc.fsf@lambda.garshol.priv.no> <200009241916.VAA01029@loewis.home.cs.tu-berlin.de>
Message-ID: <m33dip1t58.fsf@lambda.garshol.priv.no>

* Lars Marius Garshol
|
| 101573:
| 
|   This has now been updated to no longer break the minidom regression
|   test, which should mean that minidom will survive the application
|   of this patch.

* Martin v. Loewis
| 
| [I was going to comment on attributes not being passed to the handler,
| but that is apparently solved in 101632]

Correct.
 
| Also, on the pulldom part: Did you have a look at the pulldom in
| current PyXML? I believe it does support namespaces better, which is
| now possible since the namespace API of SAX2 has been determined.

I have not yet had time to look at pulldom.  The version in Python 2.0
does not seem to support namespaces at all, but we should definitely
add that as soon as possible.

I will spend the rest of this evening trying to make SAX as solid as
possible, so I can't do it, but anyone else is more than welcome to
have a go at it.
 
* Lars Marius Garshol
|
| 101630:
| 
|   Added back the InputSource class, which is referred to many places
|   in doco strings and also needed by 101631.  Added test cases to the
|   SAX test code to exercise it.
 
* Martin v. Loewis
|
| I think there has been some debate on the input source class, but so
| be it. 

There has.  This is why I made it as a patch.  Since nobody complained
before time was out and it was accepted I have comitted it.

| It just seems that you have broken the ability to pass file objects
| to the parser's parse() methods, right?

That is right.  However, I guess we could extend the current support
to recognize file objects (that is, objects with a 'read' attribute)
and make it support those as well.

Otherwise, you can use InputSource to perform the same functions.

I'll make a patch for this.
 
* Lars Marius Garshol
|
| 101631:
| 
|   Added back EntityResolver and DTDHandler (which were already
|   referred to in the code in many places) and added support for these
|   to expatreader.py  Test cases added to the SAX test code.
 
* Martin v. Loewis
|
| While I can see the others applied, this is not. Why?

Because I am still working on it.  I had not written a regression test
case for it and doing so exposed a flaw in pyexpat.c: although it has
an ExternalEntityRefHandler there is no ExternalEntityParserCreate to
allow one to actually make use of the information provided by the
callback.

I'm working on adding that method now and will try to do so before I
commit this thing.  Advice on whether the method should be added
together with this patch or whether I should make it a separate patch
would be welcome.

--lars M.



From martin@loewis.home.cs.tu-berlin.de  Sun Sep 24 21:37:36 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 24 Sep 2000 22:37:36 +0200
Subject: [XML-SIG] Status
In-Reply-To: <m33dip1t58.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 24 Sep 2000 21:34:11 +0200)
References: <m38zsh26bc.fsf@lambda.garshol.priv.no> <200009241916.VAA01029@loewis.home.cs.tu-berlin.de> <m33dip1t58.fsf@lambda.garshol.priv.no>
Message-ID: <200009242037.WAA21081@loewis.home.cs.tu-berlin.de>

> That is right.  However, I guess we could extend the current support
> to recognize file objects (that is, objects with a 'read' attribute)
> and make it support those as well.
> 
> Otherwise, you can use InputSource to perform the same functions.
> 
> I'll make a patch for this.

Don't worry about that; patch 101634 has that function (as well as a
number of other bug fixes).

I've also installed the following bug fixes:

- Makefile.in: install xml/parsers, not xml/parser
- test_sax.py: Don't assume that test.xml[.out] is in the current directory.

> I'm working on adding that method now and will try to do so before I
> commit this thing.  Advice on whether the method should be added
> together with this patch or whether I should make it a separate patch
> would be welcome.

If you are reasonably certain that it at least compiles and does not
otherwise break anything unless actually used --- then I'd say just
check it in.

I still had preferred if these features (EntityResolver, DTDHandler)
wouldn't not be rushed into Python 2.0, 6 hours before the deadline of
the last beta release...

Regards,
Martin



From larsga@garshol.priv.no  Sun Sep 24 21:57:32 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 24 Sep 2000 22:57:32 +0200
Subject: [XML-SIG] Status
In-Reply-To: <200009242037.WAA21081@loewis.home.cs.tu-berlin.de>
References: <m38zsh26bc.fsf@lambda.garshol.priv.no> <200009241916.VAA01029@loewis.home.cs.tu-berlin.de> <m33dip1t58.fsf@lambda.garshol.priv.no> <200009242037.WAA21081@loewis.home.cs.tu-berlin.de>
Message-ID: <m3ya0hzewz.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
| 
| [pyexpat.ExternalParserEntityCreate]
|
| If you are reasonably certain that it at least compiles and does not
| otherwise break anything unless actually used --- then I'd say just
| check it in.

Done.
 
| I still had preferred if these features (EntityResolver, DTDHandler)
| wouldn't not be rushed into Python 2.0, 6 hours before the deadline
| of the last beta release...

So would I.  Basically, the reason was that I didn't discover how
tight the deadlines was before it was almost too late.  Hopefully it
will be better next time around.

--Lars M.



From MichaelDyck@home.com  Sun Sep 24 22:15:48 2000
From: MichaelDyck@home.com (Michael Dyck)
Date: Sun, 24 Sep 2000 14:15:48 -0700
Subject: [XML-SIG] Status
References: <m38zsh26bc.fsf@lambda.garshol.priv.no> <200009241916.VAA01029@loewis.home.cs.tu-berlin.de> <m33dip1t58.fsf@lambda.garshol.priv.no>
Message-ID: <39CE6F04.72EC262E@home.com>

Lars Marius Garshol wrote:
> 
> ... a flaw in pyexpat.c: although it has an ExternalEntityRefHandler
> there is no ExternalEntityParserCreate to allow one to actually make
> use of the information provided by the callback.
> 
> I'm working on adding that method now and will try to do so before I
> commit this thing.

I too discovered this flaw, but hadn't gotten around to complaining to
XML-SIG about it. (With this flurry of last-minute-before-the-release
activity, it seemed impolite to bring it up.)

So thanks for scratching my itch.

-Michael Dyck


From martin@loewis.home.cs.tu-berlin.de  Sun Sep 24 22:22:40 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 24 Sep 2000 23:22:40 +0200
Subject: [XML-SIG] Location of feature names
Message-ID: <200009242122.XAA27798@loewis.home.cs.tu-berlin.de>

To get at the symbolic name of a SAX2 reader feature or property (such
as feature_namespaces, which is symbolic for
http://xml.org/sax/features/namespaces), you currently have to import
them from xml.sax.handler. 

Is that the official place for these things, or should they be
available through xml.sax? I don't mind either way; however, if this
is not changed before 2.0b2 freeze date, I guess xml.sax.handler
effectively *becomes* the official place.

Of course, it will always be possible to use the full name of the
feature, regardless of any variable name that may be present.

Regards,
Martin


From fdrake@beopen.com  Sun Sep 24 22:30:46 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Sun, 24 Sep 2000 17:30:46 -0400 (EDT)
Subject: [XML-SIG] Status
In-Reply-To: <m3ya0hzewz.fsf@lambda.garshol.priv.no>
References: <m38zsh26bc.fsf@lambda.garshol.priv.no>
 <200009241916.VAA01029@loewis.home.cs.tu-berlin.de>
 <m33dip1t58.fsf@lambda.garshol.priv.no>
 <200009242037.WAA21081@loewis.home.cs.tu-berlin.de>
 <m3ya0hzewz.fsf@lambda.garshol.priv.no>
Message-ID: <14798.29318.36945.317359@cj42289-a.reston1.va.home.com>

Lars Marius Garshol writes:
 > So would I.  Basically, the reason was that I didn't discover how
 > tight the deadlines was before it was almost too late.  Hopefully it
 > will be better next time around.

  I still think its better to add this code to the beta now.  If we
find bugs that can't be resolved reasonably before the final release,
we can still back them out.  The DTDHandler changes I think are pretty
important; I'd hate to have to say that the SIG contributors did all
this work and it still wasn't XML 1.0 conformant.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From martin@loewis.home.cs.tu-berlin.de  Sun Sep 24 23:04:07 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 25 Sep 2000 00:04:07 +0200
Subject: [XML-SIG] Status
In-Reply-To: <14798.29318.36945.317359@cj42289-a.reston1.va.home.com>
 (fdrake@beopen.com)
References: <m38zsh26bc.fsf@lambda.garshol.priv.no>
 <200009241916.VAA01029@loewis.home.cs.tu-berlin.de>
 <m33dip1t58.fsf@lambda.garshol.priv.no>
 <200009242037.WAA21081@loewis.home.cs.tu-berlin.de>
 <m3ya0hzewz.fsf@lambda.garshol.priv.no> <14798.29318.36945.317359@cj42289-a.reston1.va.home.com>
Message-ID: <200009242204.AAA04432@loewis.home.cs.tu-berlin.de>

>   I still think its better to add this code to the beta now.  If we
> find bugs that can't be resolved reasonably before the final release,
> we can still back them out.  The DTDHandler changes I think are pretty
> important; I'd hate to have to say that the SIG contributors did all
> this work and it still wasn't XML 1.0 conformant.

That's a good point. "All's well that ends well", as Tim Peters said,
so I'm now looking forward to 2.0b2 (and will produce an even further
synchronized PyXML 0.6.1 simultaneously).

Good night,
Martin


From fdrake@beopen.com  Sun Sep 24 23:10:53 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Sun, 24 Sep 2000 18:10:53 -0400 (EDT)
Subject: [XML-SIG] Status
In-Reply-To: <200009242204.AAA04432@loewis.home.cs.tu-berlin.de>
References: <m38zsh26bc.fsf@lambda.garshol.priv.no>
 <200009241916.VAA01029@loewis.home.cs.tu-berlin.de>
 <m33dip1t58.fsf@lambda.garshol.priv.no>
 <200009242037.WAA21081@loewis.home.cs.tu-berlin.de>
 <m3ya0hzewz.fsf@lambda.garshol.priv.no>
 <14798.29318.36945.317359@cj42289-a.reston1.va.home.com>
 <200009242204.AAA04432@loewis.home.cs.tu-berlin.de>
Message-ID: <14798.31725.156706.378766@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > so I'm now looking forward to 2.0b2 (and will produce an even further
 > synchronized PyXML 0.6.1 simultaneously).

  Great!  I think having a version we can use with 2.0b2 is really
important for wide audience testing.  Should the core xml require 0.6
or 0.6.1?  I'll need to know sometime tomorrow morning.
  Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From larsga@garshol.priv.no  Mon Sep 25 08:11:17 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 25 Sep 2000 09:11:17 +0200
Subject: [XML-SIG] Location of feature names
In-Reply-To: <200009242122.XAA27798@loewis.home.cs.tu-berlin.de>
References: <200009242122.XAA27798@loewis.home.cs.tu-berlin.de>
Message-ID: <m3wvg1ymi2.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
|
| To get at the symbolic name of a SAX2 reader feature or property (such
| as feature_namespaces, which is symbolic for
| http://xml.org/sax/features/namespaces), you currently have to import
| them from xml.sax.handler. 
| 
| Is that the official place for these things, or should they be
| available through xml.sax? 

The reason they are where they are now is that Paul placed them there,
and I suspect that in the rush to get things done before the release
he didn't think it through very clearly.  Certainly I never found the
time to do so this time around.

| I don't mind either way; however, if this is not changed before
| 2.0b2 freeze date, I guess xml.sax.handler effectively *becomes* the
| official place.

xml.sax is a bit more natural, perhaps, but now that the freeze date
_is_ past I guess you're right.
 
--Lars M.



From martin@loewis.home.cs.tu-berlin.de  Mon Sep 25 10:15:59 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Mon, 25 Sep 2000 11:15:59 +0200
Subject: [XML-SIG] Status
In-Reply-To: <14798.31725.156706.378766@cj42289-a.reston1.va.home.com>
 (fdrake@beopen.com)
References: <m38zsh26bc.fsf@lambda.garshol.priv.no>
 <200009241916.VAA01029@loewis.home.cs.tu-berlin.de>
 <m33dip1t58.fsf@lambda.garshol.priv.no>
 <200009242037.WAA21081@loewis.home.cs.tu-berlin.de>
 <m3ya0hzewz.fsf@lambda.garshol.priv.no>
 <14798.29318.36945.317359@cj42289-a.reston1.va.home.com>
 <200009242204.AAA04432@loewis.home.cs.tu-berlin.de> <14798.31725.156706.378766@cj42289-a.reston1.va.home.com>
Message-ID: <200009250915.LAA01358@loewis.home.cs.tu-berlin.de>

>   Great!  I think having a version we can use with 2.0b2 is really
> important for wide audience testing.  Should the core xml require 0.6
> or 0.6.1?

If applications must restrict themselves to documented or otherwise
"official" interfaces, then 0.6.0 will already be compatible with
2.0b2. I'll attempt to achieve line-by-line source code equivalence
(so later synchronizations will be easier), but I won't release that
*before* 2.0b2 - so I guess requiring 0.6 is the right thing to do.

Regards,
Martin



From alf@logilab.com  Mon Sep 25 12:12:20 2000
From: alf@logilab.com (Alexandre Fayolle)
Date: Mon, 25 Sep 2000 13:12:20 +0200 (CEST)
Subject: [XML-SIG] converting iso8859-1 to UTF-8
Message-ID: <Pine.LNX.4.21.0009251226420.15594-100000@leo.logilab.fr>

Hello,

I'm using python 1.5.2 and pyxml0.5.5.1, I'm encountering a encoding
problem with 4DOM. I can use
document.createTextNode(string) with a iso-8859-1 string. However when I
use xml.dom.ext.Print, everything fails, because the text node is not
UTF-8 encoded. How can I convert iso-8859-1 strings to UTF-8 ?

-- 
Alexandre Fayolle
http://www.logilab.com - "Mais où est donc Ornicar ?" - 
LOGILAB, Paris (France).



From fdrake@beopen.com  Mon Sep 25 16:25:29 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 25 Sep 2000 11:25:29 -0400 (EDT)
Subject: [XML-SIG] PyXML 0.6.0 not sufficient
Message-ID: <14799.28265.812754.229043@cj42289-a.reston1.va.home.com>

  I just installed the current Python, then installed PyXML.  The
regression test on the installed version no longer passes since PyXML
does not include xml.parsers.expat.
  test_pyexpat fails because there isn't an _xmlplus.parsers.expat
module, and test_sax fails because _xmlplus.sax.xmlreader isn't
there.
  Martin, long long will it take to release 0.6.1?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From larsga@garshol.priv.no  Mon Sep 25 16:51:37 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: Mon, 25 Sep 2000 17:51:37 +0200
Subject: [XML-SIG] dtddoc: New version of dtddoc released
Message-ID: <200009251551.RAA18164@lambda.garshol.priv.no>

Changes since version 0.11:

 - lots of bug fixes (all those silly errors should be gone now)
 - some internal code cleanups
 - a regression test has been added to avoid embarrasments like the
   0.11 release
 - now supports Python 2.0
 - RefEntry backend now produces well-formed XML instead of SGML
 - support for documenting groups of attributes together and
   referencing these groups from elements that use them


The homepage is still

  <URL: http://www.garshol.priv.no/download/software/dtddoc/ >

--Lars M.



From fdrake@beopen.com  Mon Sep 25 16:55:19 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Mon, 25 Sep 2000 11:55:19 -0400 (EDT)
Subject: [XML-SIG] Fixing PyXML
Message-ID: <14799.30055.611294.919651@cj42289-a.reston1.va.home.com>

  The checkins I just made (adding _xmlplus.parsers.expat and
_xmlplus.sax.xmlreader) help; test.test_pyexpat passes.  test.test_sax
still fails with "cannot import name InputSource".  Adding handler.p
doesn't fix this (though it needs to be added as well).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From alf@logilab.com  Mon Sep 25 17:53:21 2000
From: alf@logilab.com (Alexandre Fayolle)
Date: Mon, 25 Sep 2000 18:53:21 +0200 (CEST)
Subject: [XML-SIG] wstring in PyXml 0.5.5.1
Message-ID: <Pine.LNX.4.21.0009251845450.16085-100000@leo.logilab.fr>

Hello,

I understand everyone is pretty busy here with the code freeze and all,
however I'd appreciate if someone could point me to some doc on wstring,
or at least tell me how I can convert iso8859-1 to UTF-8.

I have not been able to find what to pass to the _to_utf8 function.

Thanks for your support.

-- 
Alexandre Fayolle
http://www.logilab.com - "Mais où est donc Ornicar ?" - 
LOGILAB, Paris (France).




From dieter@handshake.de  Mon Sep 25 18:04:57 2000
From: dieter@handshake.de (Dieter Maurer)
Date: Mon, 25 Sep 2000 19:04:57 +0200 (CEST)
Subject: [XML-SIG] wstring in PyXml 0.5.5.1
In-Reply-To: <Pine.LNX.4.21.0009251845450.16085-100000@leo.logilab.fr>
References: <Pine.LNX.4.21.0009251845450.16085-100000@leo.logilab.fr>
Message-ID: <14799.33935.938659.357236@lindm.dm>

Alexandre Fayolle writes:
 > I understand everyone is pretty busy here with the code freeze and all,
 > however I'd appreciate if someone could point me to some doc on wstring,
 > or at least tell me how I can convert iso8859-1 to UTF-8.
 > 
 > I have not been able to find what to pass to the _to_utf8 function.
You need the "wstring.decode" function (it converts to a wstring
instance, you can convert to "utf-8" afterwards).

From its doc-string:

	Decodes a wide string when given an encoding and a string.
	The encoding must be an alias, a mapping table, a function or
	built-in.
	Optional flags have encoding-dependent semantics.

You use 'ISO_8859-1' to indicate a iso-8859-1 encoding
(ATTENTION: case is significant!).


Dieter


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 00:04:35 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 01:04:35 +0200
Subject: [XML-SIG] PyXML 0.6.0 not sufficient
In-Reply-To: <14799.28265.812754.229043@cj42289-a.reston1.va.home.com>
 (fdrake@beopen.com)
References: <14799.28265.812754.229043@cj42289-a.reston1.va.home.com>
Message-ID: <200009252304.BAA00852@loewis.home.cs.tu-berlin.de>

>   Martin, long long will it take to release 0.6.1?

Definitely this week, hopefully Wednesday.

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 00:06:50 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 01:06:50 +0200
Subject: [XML-SIG] Fixing PyXML
In-Reply-To: <14799.30055.611294.919651@cj42289-a.reston1.va.home.com>
 (fdrake@beopen.com)
References: <14799.30055.611294.919651@cj42289-a.reston1.va.home.com>
Message-ID: <200009252306.BAA00882@loewis.home.cs.tu-berlin.de>

>   The checkins I just made (adding _xmlplus.parsers.expat and
> _xmlplus.sax.xmlreader) help; test.test_pyexpat passes.  test.test_sax
> still fails with "cannot import name InputSource".  Adding handler.p
> doesn't fix this (though it needs to be added as well).

Just adding xmlreader and handler is not enough; the new classes must
be deleted from saxlib/saxutils/sax[2]exts. I'll look into it.

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 00:16:49 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 01:16:49 +0200
Subject: [XML-SIG] converting iso8859-1 to UTF-8
In-Reply-To: <Pine.LNX.4.21.0009251226420.15594-100000@leo.logilab.fr>
 (message from Alexandre Fayolle on Mon, 25 Sep 2000 13:12:20 +0200
 (CEST))
References: <Pine.LNX.4.21.0009251226420.15594-100000@leo.logilab.fr>
Message-ID: <200009252316.BAA00948@loewis.home.cs.tu-berlin.de>

> I'm using python 1.5.2 and pyxml0.5.5.1, I'm encountering a encoding
> problem with 4DOM. I can use
> document.createTextNode(string) with a iso-8859-1 string. However when I
> use xml.dom.ext.Print, everything fails, because the text node is not
> UTF-8 encoded. How can I convert iso-8859-1 strings to UTF-8 ?

Can you give a small example of what exactly you did and what exactly
happened?

Regards,
Martin



From alf@logilab.com  Tue Sep 26 08:55:21 2000
From: alf@logilab.com (Alexandre Fayolle)
Date: Tue, 26 Sep 2000 09:55:21 +0200 (CEST)
Subject: [XML-SIG] converting iso8859-1 to UTF-8
In-Reply-To: <200009252316.BAA00948@loewis.home.cs.tu-berlin.de>
Message-ID: <Pine.LNX.4.21.0009260944310.16085-100000@leo.logilab.fr>

On Tue, 26 Sep 2000, Martin v. Loewis wrote:

> > I'm using python 1.5.2 and pyxml0.5.5.1, I'm encountering a encoding
> > problem with 4DOM. I can use
> > document.createTextNode(string) with a iso-8859-1 string. However when I
> > use xml.dom.ext.Print, everything fails, because the text node is not
> > UTF-8 encoded. How can I convert iso-8859-1 strings to UTF-8 ?
> 
> Can you give a small example of what exactly you did and what exactly
> happened?

I forgot to mention I was using 4Suite0.9.0. The problem may not occur
with older versions of 4DOM (I don't know which one is included in
pyxml). To know, just check if Print (in xml.dom.ext.__init__.py) takes an
'encoding' argument.

This is being sorted out on 4Suite's mailing list. Basically what I have
is something like:

from xml.dom.ext.reader import Sax2
from xml.dom.ext import Print
d= Sax2.FromXml('''<?xml version="1.0" encoding="iso-8859-1"?>
<document>élévation</document>''')
# The following works fine, because the parser converted my iso-8859-1
# characters to UTF-8
Print(d)
# to get a readable input, I have to use:
Print(d,encoding='iso-8859-1')

# Now if I create nodes manually, I have a problem:
c=d.createElementNS('','created-child')
d.documentElement.appendChild(c)
t=d.createTextNode("le mois d'août est chaud")
c.appendChild(t)
# The next statement prints both text node 'as is' : the first one is
# UTF-8 and the second one is iso-8859-1
Print(d)
# If I ask for a print as iso-8859-1, I get an error when the second text
# node is being converted. Full traceback available on request. 
Print(d,encoding='iso-8859-1')

What was concluded on 4Suite ML was that I needed python 2 to get 'native'
support for unicode, and that until the I would have to convert by
hand. :o(

-- 
Alexandre Fayolle
http://www.logilab.com - "Mais où est donc Ornicar ?" - 
LOGILAB, Paris (France).



From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 21:23:28 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 22:23:28 +0200
Subject: [XML-SIG] Testing PyXML 0.6.1
Message-ID: <200009262023.WAA09714@loewis.home.cs.tu-berlin.de>

I have updated PyXML so that it passes the Python 2.0b2 test cases
when installed on top of that, on my system.

Please test this as much as you can; I'll release PyXML 0.6.1 soon.

Regards,
Martin



From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 21:22:00 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 22:22:00 +0200
Subject: [XML-SIG] Changes in pyexpat.c
Message-ID: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de>

I've merged a number of files from Python 2.0b2 into PyXML. In most of
the changes, I feel pretty safe. However, when merging pyexpat.c, I'm
not all that sure that the 2.0b2 version is better in every aspect.

If I lost some features by just copying the 2.0b2 version over ours,
please let me know what those where, and I'll re-apply them on top of
the current PyXML CVS. I've recorded the Python CVS version from which
I've started (2.25), so it should be easier to merge the files the
next time.

BTW, what is the reason for having
extensions/pyexpat/_checkversion.py?  pyexpat.c had VERSION #define of
1.9, and a comment saying that this should be synchronized with
_checkversion.py, which currently has a version of 1.1. Now that CVS
revision numbers are used for pyexpat.__version__, it appears that
neither of them has any significance. What am I missing?

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 21:34:41 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 22:34:41 +0200
Subject: [XML-SIG] Bogus SAX test case
Message-ID: <200009262034.WAA09761@loewis.home.cs.tu-berlin.de>

test_sax.py has the test case test_xmlgen_ns, which reads

ns_uri = "http://www.python.org/xml-ns/saxtest/"

    gen.startDocument()
    gen.startPrefixMapping("ns1", ns_uri)
    gen.startElementNS((ns_uri, "doc"), "ns:doc", {})
    gen.endElementNS((ns_uri, "doc"), "ns:doc")
    gen.endPrefixMapping("ns1")
    gen.endDocument()

Translating that to XML, it should look like

<?xml version="1.0" encoding="iso-8859-1"?>
<ns:doc xmlns:ns1="http://www.python.org/xml-ns/saxtest/"><ns:doc/>

(or, alternatively, the element could just be empty). Is that the XML
that would produce above sequence of SAX events?

It seems to me that this XML is ill-formed, the namespace prefix ns is
not defined here. Is that analysis correct? Furthermore, the test
checks whether the generator produces

<?xml version="1.0" encoding="iso-8859-1"?>
<ns1:doc xmlns:ns1="http://www.python.org/xml-ns/saxtest/"></ns1:doc>

It appears that the expected output is bogus; I'd rather expect to get
the original document back.

I noticed this because in PyXML, XMLGenerator *would* produce ns:doc
on output, so the test case broke. I have now changed PyXML to follow
Python 2.0b2 here.

My proposal would be to correct the test case to pass "ns1:doc" as the
qname, and to correct the generator to output the qname if that was
provided by the reader.

Comments?

Regards,
Martin


From fdrake@beopen.com  Tue Sep 26 21:40:19 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 26 Sep 2000 16:40:19 -0400 (EDT)
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de>
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de>
Message-ID: <14801.2483.996584.195864@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > I've merged a number of files from Python 2.0b2 into PyXML. In most of
 > the changes, I feel pretty safe. However, when merging pyexpat.c, I'm
 > not all that sure that the 2.0b2 version is better in every aspect.

  Are you still supporting Python versions before 2.0?  You may want
to be careful to test using 1.5.2 if so; I think the Python files in
the Python CVS tree use string methods in some places.  We can change
that if needed.

 > If I lost some features by just copying the 2.0b2 version over ours,
 > please let me know what those where, and I'll re-apply them on top of
 > the current PyXML CVS. I've recorded the Python CVS version from which
 > I've started (2.25), so it should be easier to merge the files the
 > next time.

  Perhaps a source comparison would help?  I don't have time to do
that today, but I don't think you're on *that* tight a schedule to get
0.6.1 out -- if it's available by next Monday everyone should be
happy.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From fdrake@beopen.com  Tue Sep 26 21:41:26 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 26 Sep 2000 16:41:26 -0400 (EDT)
Subject: [XML-SIG] Testing PyXML 0.6.1
In-Reply-To: <200009262023.WAA09714@loewis.home.cs.tu-berlin.de>
References: <200009262023.WAA09714@loewis.home.cs.tu-berlin.de>
Message-ID: <14801.2550.138433.139502@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > Please test this as much as you can; I'll release PyXML 0.6.1 soon.

  I'll try to test today, but I'm not at all sure I'll get to that.
If not today, I'll test it tomorrow.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From akuchlin@mems-exchange.org  Tue Sep 26 21:57:24 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 26 Sep 2000 16:57:24 -0400
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Tue, Sep 26, 2000 at 10:22:00PM +0200
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de>
Message-ID: <20000926165724.A24855@kronos.cnri.reston.va.us>

On Tue, Sep 26, 2000 at 10:22:00PM +0200, Martin v. Loewis wrote:
>BTW, what is the reason for having
>extensions/pyexpat/_checkversion.py?  pyexpat.c had VERSION #define of

Probably there's no reason any longer; Tools/versioncheck never really
caught on, and it's unlikely it ever will now that the Distutils
exist.  You can just delete the file.

--amk


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 22:04:54 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 23:04:54 +0200
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <14801.2483.996584.195864@cj42289-a.reston1.va.home.com>
 (fdrake@beopen.com)
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de> <14801.2483.996584.195864@cj42289-a.reston1.va.home.com>
Message-ID: <200009262104.XAA10023@loewis.home.cs.tu-berlin.de>

>   Are you still supporting Python versions before 2.0?  You may want
> to be careful to test using 1.5.2 if so; I think the Python files in
> the Python CVS tree use string methods in some places.  We can change
> that if needed.

I'm not sure. The wstring type has been removed from CVS a while ago -
I don't know whether the package ever worked without any kind of
Unicode support. If anybody thinks 1.5.2 support based on plain
strings can be revived with reasonable effort, then I'd invest into
correcting any remaining problems. 

I know a number of places where it currently won't work with 1.5.2 -
e.g. where I put Unicode string literals into the source :-) Those can
be taken out, of course.

>   Perhaps a source comparison would help?  

I did a source comparison, and I believe it were just formatting
changes, and a restructuring of the logic. I'd appreciate a
confirmation of the kind "no, the two were equivalent", or, "how dare
you killing the foobar feature". A second eye would also help...

> I don't have time to do that today, but I don't think you're on
> *that* tight a schedule to get 0.6.1 out -- if it's available by
> next Monday everyone should be happy.  ;)

Ok. OTOH, if I get feedback on things I broke, I could well release
0.6.2 by next Monday... it's not that I'll run out of natural numbers
anytime soon :-)

Regards,
Martin



From akuchlin@mems-exchange.org  Tue Sep 26 22:14:09 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 26 Sep 2000 17:14:09 -0400
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009262104.XAA10023@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Tue, Sep 26, 2000 at 11:04:54PM +0200
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de> <14801.2483.996584.195864@cj42289-a.reston1.va.home.com> <200009262104.XAA10023@loewis.home.cs.tu-berlin.de>
Message-ID: <20000926171409.A6966@kronos.cnri.reston.va.us>

On Tue, Sep 26, 2000 at 11:04:54PM +0200, Martin v. Loewis wrote:
>I'm not sure. The wstring type has been removed from CVS a while ago -
>I don't know whether the package ever worked without any kind of
>Unicode support. If anybody thinks 1.5.2 support based on plain

It did up to the final 0.5.x version.  Then I tagged the tree with the
label "v056", and began making 2.0-specific changes such as removing
the wstring type.  (This was mentioned in a posting of mine to the
XML-SIG, and people generally assented.)  Therefore, the CVS tree
won't work with 2.0, and frankly I see no need to make it work with
1.5.2.

--amk




From fdrake@beopen.com  Tue Sep 26 22:28:23 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Tue, 26 Sep 2000 17:28:23 -0400 (EDT)
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009262104.XAA10023@loewis.home.cs.tu-berlin.de>
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de>
 <14801.2483.996584.195864@cj42289-a.reston1.va.home.com>
 <200009262104.XAA10023@loewis.home.cs.tu-berlin.de>
Message-ID: <14801.5367.490225.56202@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > I'm not sure. The wstring type has been removed from CVS a while ago -
 > I don't know whether the package ever worked without any kind of

  I was never aware that the wstring material was actually used in
PyXML, other than being present.  Well, given Andrew's comments, I'll
not worry about 1.5.2 compatibility either.
  Since we're not worrying about pre-2.0 versions, perhaps pyexpat
should be removed?  It's in the core library, and the only thing that
PyXML should need to pick it up is the xml.parsers.expat module.

 > I did a source comparison, and I believe it were just formatting
 > changes, and a restructuring of the logic. I'd appreciate a
 > confirmation of the kind "no, the two were equivalent", or, "how dare
 > you killing the foobar feature". A second eye would also help...

  If you still think it needed, I'll take a look Thurday or Friday.

 > Ok. OTOH, if I get feedback on things I broke, I could well release
 > 0.6.2 by next Monday... it's not that I'll run out of natural numbers
 > anytime soon :-)

  The issue is that Python 2.0b2 will say that 0.6.1 is sufficient.
I'd like to make that work.  A couple of iterations of testing is
worth the time it takes.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 22:34:45 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 23:34:45 +0200
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <20000926171409.A6966@kronos.cnri.reston.va.us> (message from
 Andrew Kuchling on Tue, 26 Sep 2000 17:14:09 -0400)
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de> <14801.2483.996584.195864@cj42289-a.reston1.va.home.com> <200009262104.XAA10023@loewis.home.cs.tu-berlin.de> <20000926171409.A6966@kronos.cnri.reston.va.us>
Message-ID: <200009262134.XAA13331@loewis.home.cs.tu-berlin.de>

> On Tue, Sep 26, 2000 at 11:04:54PM +0200, Martin v. Loewis wrote:
> >I'm not sure. The wstring type has been removed from CVS a while ago -
> >I don't know whether the package ever worked without any kind of
> >Unicode support.
> 
> It did up to the final 0.5.x version.  

That included the wstring type, didn't it? Would it support falling
back to plain strings if not even the wstring type was available?

> Then I tagged the tree with the label "v056", and began making
> 2.0-specific changes such as removing the wstring type.  (This was
> mentioned in a posting of mine to the XML-SIG, and people generally
> assented.)

I certainly agree that was the right thing to do, especially as it led
to the xml package in 2.0 as we now have it. I'm just trying to find
out whether some kind of degraded service could be offered (*), along
the lines of "it works as long as you don't care about encodings".

> Therefore, the CVS tree won't work with 2.0, and frankly I see no
                                     °°°° without?

> need to make it work with 1.5.2.

For reasons of marketing. People complain that the XML SIG does not
produce anything useful. If they'd get a chance to install "the most
recent" PyXML (which includes 4DOM) on top of 1.5.2, they might become
happy customers, and could move to Python 2 at their own pace.

If, OTOH, we tell them to use 0.5.x, we probably don't do them a
service, as they'd be on their own in case of problems.

Regards,
Martin

(*) If the answer to that is "no way", the world won't end for me :-)


From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 22:40:50 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Tue, 26 Sep 2000 23:40:50 +0200
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <14801.5367.490225.56202@cj42289-a.reston1.va.home.com>
 (fdrake@beopen.com)
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de>
 <14801.2483.996584.195864@cj42289-a.reston1.va.home.com>
 <200009262104.XAA10023@loewis.home.cs.tu-berlin.de> <14801.5367.490225.56202@cj42289-a.reston1.va.home.com>
Message-ID: <200009262140.XAA17933@loewis.home.cs.tu-berlin.de>

>   Since we're not worrying about pre-2.0 versions, perhaps pyexpat
> should be removed?  It's in the core library, and the only thing that
> PyXML should need to pick it up is the xml.parsers.expat module.

I'd rather leave it, in case people want to enhance it after Python
2.0 is released. Currently, it will be installed only if Python
doesn't come with a suitable pyexpat on its own.

I have also my concerns about the versionitis in the expat library
itself; I'll discuss this later after I gather some more facts.

>   If you still think it needed, I'll take a look Thurday or Friday.

I'd appreciate if you could find the time. The relevant versions are
1.10 and 1.11 of extensions/pyexpat.c.

>   The issue is that Python 2.0b2 will say that 0.6.1 is sufficient.
> I'd like to make that work.  A couple of iterations of testing is
> worth the time it takes.

Definitely. I also just noticed there is a pending bug report on SF
which I'd like to resolve.

Regards,
Martin



From martin@loewis.home.cs.tu-berlin.de  Tue Sep 26 23:07:29 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 27 Sep 2000 00:07:29 +0200
Subject: [XML-SIG] Bug and patch notifications
Message-ID: <200009262207.AAA24945@loewis.home.cs.tu-berlin.de>

I've activated the SF feature that notifications of new PyXML bug
reports and patch submissions will be sent to xml-sig@python.org;
notifications on status changes on these items won't be sent.

If that turns out to produce to much traffic, we might need to use a
different address, but at the current rate, I doubt we'll see too many
messages from SF.

Regards,
Martin



From akuchlin@mems-exchange.org  Wed Sep 27 01:50:28 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Tue, 26 Sep 2000 20:50:28 -0400
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009262134.XAA13331@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Tue, Sep 26, 2000 at 11:34:45PM +0200
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de> <14801.2483.996584.195864@cj42289-a.reston1.va.home.com> <200009262104.XAA10023@loewis.home.cs.tu-berlin.de> <20000926171409.A6966@kronos.cnri.reston.va.us> <200009262134.XAA13331@loewis.home.cs.tu-berlin.de>
Message-ID: <20000926205028.B20476@newcnri.cnri.reston.va.us>

On Tue, Sep 26, 2000 at 11:34:45PM +0200, Martin v. Loewis wrote:
>That included the wstring type, didn't it? Would it support falling
>back to plain strings if not even the wstring type was available?

I don't believe any code in the CVS tree actually used it; it was
simply there so applications could convert the UTF-8 output from Expat
into their own encoding.

>> Therefore, the CVS tree won't work with 2.0, and frankly I see no
>                                     °°°° without?

Correct; I meant "without 2.0". Though 1.6 should work, I haven't been
testing it.

--amk


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 27 06:56:32 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 27 Sep 2000 07:56:32 +0200
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <20000926205028.B20476@newcnri.cnri.reston.va.us> (message from
 Andrew Kuchling on Tue, 26 Sep 2000 20:50:28 -0400)
References: <200009262022.WAA09713@loewis.home.cs.tu-berlin.de> <14801.2483.996584.195864@cj42289-a.reston1.va.home.com> <200009262104.XAA10023@loewis.home.cs.tu-berlin.de> <20000926171409.A6966@kronos.cnri.reston.va.us> <200009262134.XAA13331@loewis.home.cs.tu-berlin.de> <20000926205028.B20476@newcnri.cnri.reston.va.us>
Message-ID: <200009270556.HAA00704@loewis.home.cs.tu-berlin.de>

> I don't believe any code in the CVS tree actually used it; it was
> simply there so applications could convert the UTF-8 output from Expat
> into their own encoding.

Ok. I guess I'll just try to see how much effort it would be to adjust
PyXML to 1.5, then, without giving up clean design or features.

Regards,
Martin


From larsga@garshol.priv.no  Wed Sep 27 09:12:45 2000
From: larsga@garshol.priv.no (Lars Marius Garshol)
Date: 27 Sep 2000 10:12:45 +0200
Subject: [XML-SIG] Re: [Python-Dev] Bogus SAX test case
In-Reply-To: <200009262034.WAA09761@loewis.home.cs.tu-berlin.de>
References: <200009262034.WAA09761@loewis.home.cs.tu-berlin.de>
Message-ID: <m3hf72uubm.fsf@lambda.garshol.priv.no>

* Martin v. Loewis
| 
| <?xml version="1.0" encoding="iso-8859-1"?>
| <ns:doc xmlns:ns1="http://www.python.org/xml-ns/saxtest/"><ns:doc/>
| 
| (or, alternatively, the element could just be empty). Is that the
| XML that would produce above sequence of SAX events?

Nope, it's not.  No XML document could produce that particular
sequence of events.
 
| It seems to me that this XML is ill-formed, the namespace prefix ns
| is not defined here. Is that analysis correct? 

Not entirely.  The XML is perfectly well-formed, but it's not
namespace-compliant.

| Furthermore, the test checks whether the generator produces
| 
| <?xml version="1.0" encoding="iso-8859-1"?>
| <ns1:doc xmlns:ns1="http://www.python.org/xml-ns/saxtest/"></ns1:doc>
| 
| It appears that the expected output is bogus; I'd rather expect to get
| the original document back.

What original document? :-)
 
| My proposal would be to correct the test case to pass "ns1:doc" as
| the qname, 

I see that as being the best fix, and have now committed it.

| and to correct the generator to output the qname if that was
| provided by the reader.

We could do that, but the namespace name and the qname are supposed to
be equivalent in any case, so I don't see any reason to change it.
One problem with making that change is that it no longer becomes
possible to roundtrip XML -> pyexpat -> SAX -> xmlgen -> XML because
pyexpat does not provide qnames.

--Lars M.



From uche.ogbuji@fourthought.com  Wed Sep 27 15:47:17 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 27 Sep 2000 08:47:17 -0600
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: Message from "Fred L. Drake, Jr." <fdrake@beopen.com>
 of "Tue, 26 Sep 2000 17:28:23 EDT." <14801.5367.490225.56202@cj42289-a.reston1.va.home.com>
Message-ID: <200009271447.IAA01820@localhost.localdomain>

> 
> Martin v. Loewis writes:
>  > I'm not sure. The wstring type has been removed from CVS a while ago -
>  > I don't know whether the package ever worked without any kind of
> 
>   I was never aware that the wstring material was actually used in
> PyXML, other than being present.

We do use it in 4DOM (output encodings), but we can just mandate PyXML 0.5.5.1 
until the Py 2.0 situation is sorted out.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From uche.ogbuji@fourthought.com  Wed Sep 27 15:50:46 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 27 Sep 2000 08:50:46 -0600
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: Message from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
 of "Tue, 26 Sep 2000 23:34:45 +0200." <200009262134.XAA13331@loewis.home.cs.tu-berlin.de>
Message-ID: <200009271450.IAA01834@localhost.localdomain>

> > On Tue, Sep 26, 2000 at 11:04:54PM +0200, Martin v. Loewis wrote:
> > >I'm not sure. The wstring type has been removed from CVS a while ago=
 -
> > >I don't know whether the package ever worked without any kind of
> > >Unicode support.
> > =

> > It did up to the final 0.5.x version.  =

> =

> That included the wstring type, didn't it? Would it support falling
> back to plain strings if not even the wstring type was available?
> =

> > Then I tagged the tree with the label "v056", and began making
> > 2.0-specific changes such as removing the wstring type.  (This was
> > mentioned in a posting of mine to the XML-SIG, and people generally
> > assented.)
> =

> I certainly agree that was the right thing to do, especially as it led
> to the xml package in 2.0 as we now have it. I'm just trying to find
> out whether some kind of degraded service could be offered (*), along
> the lines of "it works as long as you don't care about encodings".
> =

> > Therefore, the CVS tree won't work with 2.0, and frankly I see no
>                                      =B0=B0=B0=B0 without?
> =

> > need to make it work with 1.5.2.
> =

> For reasons of marketing. People complain that the XML SIG does not
> produce anything useful. If they'd get a chance to install "the most
> recent" PyXML (which includes 4DOM) on top of 1.5.2, they might become
> happy customers, and could move to Python 2 at their own pace.

I don't understand.  Are we encouraging them to install the latest PyXML?=
  If =

so, how can they move to Py 2.0 at their own pace if the most recent PyXM=
L =

requires Py 2.0?

-- =

Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com =

4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From martin@loewis.home.cs.tu-berlin.de  Wed Sep 27 19:37:57 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 27 Sep 2000 20:37:57 +0200
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009271450.IAA01834@localhost.localdomain>
 (uche.ogbuji@fourthought.com)
References: <200009271450.IAA01834@localhost.localdomain>
Message-ID: <200009271837.UAA00875@loewis.home.cs.tu-berlin.de>


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 27 19:36:04 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 27 Sep 2000 20:36:04 +0200
Subject: [XML-SIG] Re: [Python-Dev] Bogus SAX test case
In-Reply-To: <m3hf72uubm.fsf@lambda.garshol.priv.no> (message from Lars Marius
 Garshol on 27 Sep 2000 10:12:45 +0200)
References: <200009262034.WAA09761@loewis.home.cs.tu-berlin.de> <m3hf72uubm.fsf@lambda.garshol.priv.no>
Message-ID: <200009271836.UAA00872@loewis.home.cs.tu-berlin.de>

> | My proposal would be to correct the test case to pass "ns1:doc" as
> | the qname, 
> 
> I see that as being the best fix, and have now committed it.

Thanks!

> | and to correct the generator to output the qname if that was
> | provided by the reader.
> 
> We could do that, but the namespace name and the qname are supposed to
> be equivalent in any case, so I don't see any reason to change it.

What about

<foo xmlns:mine="martin:von.loewis">
  <bar xmlns:meiner="martin:von.loewis">
    <mine:foobar/>
    <meiner:foobar/>
  </bar>
</foo>

In that case, one of the qnames will change on output when your
algorithm is used - even if the parser provided the original names. By
the way, when parsing this text via

import xml.sax,xml.sax.handler,xml.sax.saxutils,StringIO
p=xml.sax.make_parser()
p.setContentHandler(xml.sax.saxutils.XMLGenerator())
p.setFeature(xml.sax.handler.feature_namespaces,1)
i=xml.sax.InputSource()
i.setByteStream(StringIO.StringIO("""<foo xmlns:mine="martin:von.loewis"><bar xmlns:meiner="martin:von.loewis"><mine:foobar/><meiner:foobar/></bar></foo>"""))
p.parse(i)
print

I get a number of interesting failures. Would you mind looking into
that?

On a related note, it seems that "<xml:hello/>" won't unparse
properly, either...

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 27 19:42:06 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 27 Sep 2000 20:42:06 +0200
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009271447.IAA01820@localhost.localdomain>
 (uche.ogbuji@fourthought.com)
References: <200009271447.IAA01820@localhost.localdomain>
Message-ID: <200009271842.UAA00930@loewis.home.cs.tu-berlin.de>

> We do use it in 4DOM (output encodings), but we can just mandate
> PyXML 0.5.5.1 until the Py 2.0 situation is sorted out.

Looking at the 4DOM copy that is currently in the PyXML CVS, I can't
find the place where that is used. Can you give me a specific pointer?

Regards,
Martin



From martin@loewis.home.cs.tu-berlin.de  Wed Sep 27 19:40:50 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 27 Sep 2000 20:40:50 +0200
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009271450.IAA01834@localhost.localdomain>
 (uche.ogbuji@fourthought.com)
References: <200009271450.IAA01834@localhost.localdomain>
Message-ID: <200009271840.UAA00911@loewis.home.cs.tu-berlin.de>

> I don't understand.  Are we encouraging them to install the latest
> PyXML?  If so, how can they move to Py 2.0 at their own pace if the
> most recent PyXML requires Py 2.0?

By making the latest PyXML work with 1.5.2. If that is not feasible,
then we should not encourage them to install that, of course - PyXML
0.6.0 carries warnings that it won't work with 1.5.2.

Regards,
Martin


From noreply@sourceforge.net  Wed Sep 27 20:32:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 12:32:01 -0700
Subject: [XML-SIG] [Patch #101683] Add 1.5.2 compatibility to PyXML
Message-ID: <200009271932.MAA01241@delerium.i.sourceforge.net>

Patch #101683 has been updated. 

Project: 
Category: None
Status: Open
Summary: Add 1.5.2 compatibility to PyXML

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101683&group_id=6473


From martin@loewis.home.cs.tu-berlin.de  Wed Sep 27 20:51:43 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 27 Sep 2000 21:51:43 +0200
Subject: [XML-SIG] [Patch #101683] Add 1.5.2 compatibility to PyXML
In-Reply-To: <200009271932.MAA01241@delerium.i.sourceforge.net>
 (noreply@sourceforge.net)
References: <200009271932.MAA01241@delerium.i.sourceforge.net>
Message-ID: <200009271951.VAA01251@loewis.home.cs.tu-berlin.de>

> http://sourceforge.net/patch/?func=detailpatch&patch_id=101683&group_id=6473

These are the minimal changes necessary to support xml.sax and
xml.dom.minidom for Python 1.5.2. They mostly consist of removing
Unicode string literals, and string methods. With the patches, the 2.0
test_sax and test_minidom pass in 1.5.2 (*)

The patch does modify the files that have been just synchronized with
the 2.0 CVS. Please let me know if you think that 1.5.2 compatibility
is not that important to risk forking from Python 2.0; or if you think
that 1.5.2 compatibility is definitely desirable.

I have not tested either xmlproc, or 4DOM, for 1.5.2 compatibility -
just the core functionality that is also in 2.0.

Regards,
Martin

(*) Of course, the test cases would not work unmodified. I had to
remove Unicode literals, and imports of testsupport.



From uche.ogbuji@fourthought.com  Wed Sep 27 20:56:27 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 27 Sep 2000 13:56:27 -0600
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: Message from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
 of "Wed, 27 Sep 2000 20:42:06 +0200." <200009271842.UAA00930@loewis.home.cs.tu-berlin.de>
Message-ID: <200009271956.NAA02526@localhost.localdomain>

> > We do use it in 4DOM (output encodings), but we can just mandate
> > PyXML 0.5.5.1 until the Py 2.0 situation is sorted out.
> 
> Looking at the 4DOM copy that is currently in the PyXML CVS, I can't
> find the place where that is used. Can you give me a specific pointer?

Probably because the checked-in 4DOM is out of date.  We've hesitated checking 
in the 4Suite 0.9.x version because of all the flux and not wanting to 
contribute to the confusion (and not being sure whether we had much bandwidth 
to help sort out any resulting confusion).

However, it's time to do the right thing, so...

Do we check the latest 4DOM and back-port the output encoding stuff to PyXML 
(it's all in ext/Printer.py)  I haven't had a chance to play with Python 2.0, 
so I'm not sure how hard the port would be.  Here is the representative 
snippet from ext/Printer.py

from xml.unicode.iso8859 import wstring
wstring.install_alias('ISO-8859-1', 'ISO_8859-1:1987')

#[snip]

#Note: UCS-2 only for now
def TranslateCdata(characters, encoding='UTF-8', prev_chars='', markupSafe=0):
    if not characters:
        return ''
    if not markupSafe:
        new_string, num_subst = re.subn(
            g_cdataCharPattern,
            lambda m, d=g_charToEntity: d[m.group()],
            characters
            )
        if prev_chars[-2:] == ']]' and characters[0] == '>':
            new_string = '&gt;' + new_string[1:]
    else:
        new_string = characters
    #Note: use decimal char entity rep because some browsers are broken
    #FIXME: This will bomb for high characters.  Should, for instance, detect
    #The UTF-8 for 0xFFFE and put out &#xFFFE;
    new_string, num_subst = re.subn(XML_ILLEGAL_CHAR_PATTERN, lambda m: 
'&#%i;'%ord(m.group()), new_string)
    encoding = string.upper(encoding)
    if encoding == 'UTF-8':
        pass
    else:
        #Note: Pass through to wstrop.  This means we don't play nice and
        #Escape characters that are not in the target encoding.
        ws = wstring.from_utf8(new_string)
        new_string = ws.encode(encoding)
        #This version would skip all untranslatable chars: see wstrop.c
        #new_string = ws.encode(encoding, 1)
    return new_string




-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From martin@loewis.home.cs.tu-berlin.de  Wed Sep 27 22:16:46 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 27 Sep 2000 23:16:46 +0200
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: <200009271956.NAA02526@localhost.localdomain>
 (uche.ogbuji@fourthought.com)
References: <200009271956.NAA02526@localhost.localdomain>
Message-ID: <200009272116.XAA01410@loewis.home.cs.tu-berlin.de>

> Probably because the checked-in 4DOM is out of date.  We've
> hesitated checking in the 4Suite 0.9.x version because of all the
> flux and not wanting to contribute to the confusion (and not being
> sure whether we had much bandwidth to help sort out any resulting
> confusion).
>
> However, it's time to do the right thing, so...

Yes, I was going to ask whether PyXML could get a new copy of 4DOM...

> Do we check the latest 4DOM and back-port the output encoding stuff to PyXML 
> (it's all in ext/Printer.py)  

Sounds like a good plan to me.

> I haven't had a chance to play with Python 2.0, so I'm not sure how
> hard the port would be.  Here is the representative snippet from
> ext/Printer.py

It should not be too difficult to have this working on all Python
versions.

> from xml.unicode.iso8859 import wstring
> wstring.install_alias('ISO-8859-1', 'ISO_8859-1:1987')

try:
  import codecs #will fail on 1.5
  def utf8_to_code(string,encoding):
    encoder = codecs.lookup(encoding)[0]       # encode,decode,reader,writer
    return encoder(unicode(string,"utf-8"))[0] # result,size
except ImportError:
  def utf8_to_code(string,encoding):
    #raise exception?
    #support some trivial cases, e.g. latin1?
    #try wstrop?
    return string # silently return utf-8...

>         #Note: Pass through to wstrop.  This means we don't play nice and
>         #Escape characters that are not in the target encoding.
>         ws = wstring.from_utf8(new_string)
>         new_string = ws.encode(encoding)
>         #This version would skip all untranslatable chars: see wstrop.c
>         #new_string = ws.encode(encoding, 1)

          new_string = utf8_to_code(new_string,encoding)

Regards,
Martin


From uche.ogbuji@fourthought.com  Thu Sep 28 00:48:21 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Wed, 27 Sep 2000 17:48:21 -0600
Subject: [XML-SIG] Changes in pyexpat.c
In-Reply-To: Message from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
 of "Wed, 27 Sep 2000 23:16:46 +0200." <200009272116.XAA01410@loewis.home.cs.tu-berlin.de>
Message-ID: <200009272348.RAA03203@localhost.localdomain>

> > Probably because the checked-in 4DOM is out of date.  We've
> > hesitated checking in the 4Suite 0.9.x version because of all the
> > flux and not wanting to contribute to the confusion (and not being
> > sure whether we had much bandwidth to help sort out any resulting
> > confusion).
> >
> > However, it's time to do the right thing, so...
> 
> Yes, I was going to ask whether PyXML could get a new copy of 4DOM...

Done.  And I implemented a variation on your suggestions for Py 1.5/2.0 
compatability.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From fdrake@beopen.com  Thu Sep 28 02:35:50 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Wed, 27 Sep 2000 21:35:50 -0400 (EDT)
Subject: [XML-SIG] [Patch #101683] Add 1.5.2 compatibility to PyXML
In-Reply-To: <200009271951.VAA01251@loewis.home.cs.tu-berlin.de>
References: <200009271932.MAA01241@delerium.i.sourceforge.net>
 <200009271951.VAA01251@loewis.home.cs.tu-berlin.de>
Message-ID: <14802.41078.340944.302644@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > The patch does modify the files that have been just synchronized with
 > the 2.0 CVS. Please let me know if you think that 1.5.2 compatibility
 > is not that important to risk forking from Python 2.0; or if you think
 > that 1.5.2 compatibility is definitely desirable.

  I certainly have no objections to 1.5.2 compatibility.  The Python
version of these files should be sync'ed to match these files.

 > I have not tested either xmlproc, or 4DOM, for 1.5.2 compatibility -
 > just the core functionality that is also in 2.0.
 > 
 > Regards,
 > Martin
 > 
 > (*) Of course, the test cases would not work unmodified. I had to
 > remove Unicode literals, and imports of testsupport.

  "testsupport"?  Do you mean test.test_support?  That should be
portable; nothing in there strikes me as 2.0 specific, and the module
isn't new.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From martin@loewis.home.cs.tu-berlin.de  Thu Sep 28 07:30:08 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 28 Sep 2000 08:30:08 +0200
Subject: [XML-SIG] [Patch #101683] Add 1.5.2 compatibility to PyXML
In-Reply-To: <14802.41078.340944.302644@cj42289-a.reston1.va.home.com>
 (fdrake@beopen.com)
References: <200009271932.MAA01241@delerium.i.sourceforge.net>
 <200009271951.VAA01251@loewis.home.cs.tu-berlin.de> <14802.41078.340944.302644@cj42289-a.reston1.va.home.com>
Message-ID: <200009280630.IAA00790@loewis.home.cs.tu-berlin.de>

>   I certainly have no objections to 1.5.2 compatibility.  The Python
> version of these files should be sync'ed to match these files.

I'll submit patches to Python for "uncritical" places (e.g. string
methods). The pyexpat.c chunk probably shouldn't be integrated in
Python - it adds PyModule_AddObject/AddString into pyexpat.c if the
Python version is less then 2.

Then again, pyexpat.c already has a number of #ifdefs for older Python
versions. What is the official policy here? In the Linux kernel,
checking for the Linux kernel version in some driver is considered bad
- the kernel sources should know what kernel version they
are. 

>   "testsupport"?  Do you mean test.test_support?  That should be
> portable; nothing in there strikes me as 2.0 specific, and the module
> isn't new.

Oops, my fault. When I moved test_sax/test_minidom out of the Python
tree, the "from test_support import bla" lines would not work anymore
- the correct modification was to write "from test.test_support ...".

Regards,
Martin


From noreply@sourceforge.net  Thu Sep 28 08:33:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 00:33:15 -0700
Subject: [XML-SIG] [Bug #115544] Compile Problems on Mac OS X
Message-ID: <200009280733.AAA02214@bush.i.sourceforge.net>

Bug #115544, was updated on 2000-Sep-28 00:33
Here is a current snapshot of the bug.

Project: Python/XML
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Compile Problems on Mac OS X

Details: I have successfully compiled and installed Python 2.0b2 on my Mac OS X system, but I am having trouble building the current Python/XML CVS version.  During the linking stage, I get a warning and an error:

cc -bundle -prebind build/temp.darwin-1.2-Power Macintosh-2.0/extensions/pyexpat.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmltok/xmltok.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmltok/xmlrole.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/xmlfile.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/xmlwf.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/codepage.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlparse/xmlparse.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlparse/hashtable.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/unixfilemap.o -o build/lib.darwin-1.2-Power Macintosh-2.0/_xmlplus/parsers/pyexpat.so
/usr/bin/ld: warning -prebind has no effect with -bundle
/usr/bin/ld: Undefined symbols:
_PyArg_ParseTuple
_PyArg_ParseTupleAndKeywords
...*removed a few dozen more symbols*...

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115544&group_id=6473


From martin@loewis.home.cs.tu-berlin.de  Thu Sep 28 09:10:18 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 28 Sep 2000 10:10:18 +0200
Subject: [XML-SIG] [Bug #115544] Compile Problems on Mac OS X
In-Reply-To: <200009280733.AAA02214@bush.i.sourceforge.net>
 (noreply@sourceforge.net)
References: <200009280733.AAA02214@bush.i.sourceforge.net>
Message-ID: <200009280810.KAA01330@loewis.home.cs.tu-berlin.de>

> Details: I have successfully compiled and installed Python 2.0b2 on
> my Mac OS X system, but I am having trouble building the current
> Python/XML CVS version.  During the linking stage, I get a warning
> and an error:

I assume that your Python build does not include the pyexpat module,
right? If it did, PyXML should not attempt to build it itself.

Since building is controlled by distutils, I've cc'ed this to the
distutils-sig. Since likely fixes will also need to appear in Python
2.0, it would be good if we resolve this within the next week.

> cc -bundle -prebind build/temp.darwin-1.2-Power Macintosh-2.0/extensions/pyexpat.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmltok/xmltok.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmltok/xmlrole.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/xmlfile.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/xmlwf.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/codepage.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlparse/xmlparse.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlparse/hashtable.o build/temp.darwin-1.2-Power Macintosh-2.0/extensions/expat/xmlwf/unixfilemap.o -o build/lib.darwin-1.2-Power Macintosh-2.0/_xmlplus/parsers/pyexpat.so

I guess I need some help in resolving this, as I have no MacOS X myself.
Can you spot anything that is incorrect in this command line?

> /usr/bin/ld: warning -prebind has no effect with -bundle

What is the intended effect of -prebind and -bundle? Where do these
options come from, anyway? Grepping the distutils sources, I see no
mentioning of them, so what magic finds those options?

> /usr/bin/ld: Undefined symbols:
> _PyArg_ParseTuple
> _PyArg_ParseTupleAndKeywords
> ...*removed a few dozen more symbols*...

It's certainly the case that these symbols are undefined - we are
building an extension module, after all. On MacOS X, the compiler is
gcc, right? Normally, you'll have to pass -shared to the compiler
to have it build shared libraries.

I notice that Python's configure.in has two alternatives for building
extension modules on next/*: If dyld is used, then the options are
"-bundle -prebind", otherwise they are "-nostdlib -r". Do you use
WITH_DYLD? Can you try linking the module with "-nostdlib -r"?

Thanks,
Martin

> For detailed info, follow this link:
> http://sourceforge.net/bugs/?func=detailbug&bug_id=115544&group_id=6473


From Juergen Hermann" <jh@web.de  Thu Sep 28 10:32:22 2000
From: Juergen Hermann" <jh@web.de (Juergen Hermann)
Date: Thu, 28 Sep 2000 11:32:22 +0200
Subject: [XML-SIG] [Patch #101683] Add 1.5.2 compatibility to PyXML
In-Reply-To: <200009271951.VAA01251@loewis.home.cs.tu-berlin.de>
Message-ID: <m13ea3C-005EA7C@smtp.web.de>

On Wed, 27 Sep 2000 21:51:43 +0200, Martin v. Loewis wrote:

>The patch does modify the files that have been just synchronized with
>the 2.0 CVS. Please let me know if you think that 1.5.2 compatibility
>is not that important to risk forking from Python 2.0; or if you think
>that 1.5.2 compatibility is definitely desirable.

For us, it is desirable, so that we (R&D) and the IT department can 
switch from 1.5.2 to 2.0 at their respective pace. Of course, the price =

should not be TOO high.


Ciao, J=FCrgen

--
J=FCrgen Hermann, Developer (jhe@webde-ag.de)
WEB.DE AG, http://webde-ag.de/




From martin@loewis.home.cs.tu-berlin.de  Thu Sep 28 17:28:58 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Thu, 28 Sep 2000 18:28:58 +0200
Subject: [XML-SIG] [Patch #101683] Add 1.5.2 compatibility to PyXML
In-Reply-To: <m13ea3C-005EA7C@smtp.web.de> (jh@web.de)
References: <m13ea3C-005EA7C@smtp.web.de>
Message-ID: <200009281628.SAA00835@loewis.home.cs.tu-berlin.de>

> For us, it is desirable, so that we (R&D) and the IT department can 
> switch from 1.5.2 to 2.0 at their respective pace. Of course, the price 
> should not be TOO high.

Thanks for the encouragement. The changes are of moderate size, and
Fre has indicated that they can be integrated back into 2.0, so I have
now committed these changes.

Regards,
Martin



From martin@loewis.home.cs.tu-berlin.de  Fri Sep 29 20:18:12 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 29 Sep 2000 21:18:12 +0200
Subject: [XML-SIG] Duplicate 4DOM demos
Message-ID: <200009291918.VAA00977@loewis.home.cs.tu-berlin.de>

The current PyXML tree has two copies of the 4DOM demos, in demo/dom
and xml/dom/demo; they are slightly out-of-sync. Which copy should be
eliminated?

Regards,
Martin


From fdrake@beopen.com  Fri Sep 29 20:30:18 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 29 Sep 2000 15:30:18 -0400 (EDT)
Subject: [XML-SIG] Duplicate 4DOM demos
In-Reply-To: <200009291918.VAA00977@loewis.home.cs.tu-berlin.de>
References: <200009291918.VAA00977@loewis.home.cs.tu-berlin.de>
Message-ID: <14804.60874.233233.80072@cj42289-a.reston1.va.home.com>

Martin v. Loewis writes:
 > The current PyXML tree has two copies of the 4DOM demos, in demo/dom
 > and xml/dom/demo; they are slightly out-of-sync. Which copy should be
 > eliminated?

  The 4Suite team will have to say for certain, but I suspect the one
in xml/dom/demo/ is the most recent (judging from the checkin
messages).
  I'd certainly rather see the demos somewhere like demo/dom/,
however, so perhaps that copy should be updated and the xml/dom/demo/
removed.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From akuchlin@mems-exchange.org  Fri Sep 29 20:44:02 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 29 Sep 2000 15:44:02 -0400
Subject: [XML-SIG] Duplicate 4DOM demos
In-Reply-To: <14804.60874.233233.80072@cj42289-a.reston1.va.home.com>; from fdrake@beopen.com on Fri, Sep 29, 2000 at 03:30:18PM -0400
References: <200009291918.VAA00977@loewis.home.cs.tu-berlin.de> <14804.60874.233233.80072@cj42289-a.reston1.va.home.com>
Message-ID: <20000929154402.A19795@kronos.cnri.reston.va.us>

On Fri, Sep 29, 2000 at 03:30:18PM -0400, Fred L. Drake, Jr. wrote:
>  I'd certainly rather see the demos somewhere like demo/dom/,
>however, so perhaps that copy should be updated and the xml/dom/demo/
>removed.

I agree with Fred.  Putting the demos in xml/dom/ means they're hard
to find, and we really don't expect to install them.

--amk



From martin@loewis.home.cs.tu-berlin.de  Fri Sep 29 20:44:35 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 29 Sep 2000 21:44:35 +0200
Subject: [XML-SIG] demo/saxhack still needed?
Message-ID: <200009291944.VAA01115@loewis.home.cs.tu-berlin.de>

I've tried to run demo/saxhack, and it would not work because
xml/parsers/sgmllib is not there; I assume it got removed at one point
in time.

Should I try to restore xml.parsers.xmllib, or should I remove the
example demonstrating its SlowXMLParser instead?

Regards,
Martin


From martin@loewis.home.cs.tu-berlin.de  Fri Sep 29 22:22:54 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 29 Sep 2000 23:22:54 +0200
Subject: [XML-SIG] PyXML 0.6.1 status, demos, tests
Message-ID: <200009292122.XAA01777@loewis.home.cs.tu-berlin.de>

I've made a number of changes to PyXML:

- restore building of sgmlop, which is now installed into
  xml.parsers.sgmlop.

- fix bugs in make_parser argument processing; make_parser now
  supports both SAX1/0.5 single-string arguments and SAX2/Python2
  string-list arguments.

- moved escape from xml.utils to xml.sax.saxutils.

I've also updated the demos to work with the current code; in
particular, I have ported demo/genxml to 4DOM. Still not supported are
all sgmlop demos (demo/sgmlop and demo/sax/saxhack), as these always
want to compare with xmllib which is not there, anymore. Any
suggestion what to do with these demos?

The missing piece for a 0.6.1 release is the test suite. Specifically,
the dom tests are not executed, as xml.dom.core is not available
anymore. Should these tests be ported to 4DOM?

It appears that xml/dom/test_suite does not work in the PyXML tree, as
the Ft package is not available. What kind of software is that, anyway?

Regards,
Martin


From akuchlin@mems-exchange.org  Fri Sep 29 23:02:12 2000
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 29 Sep 2000 18:02:12 -0400
Subject: [XML-SIG] PyXML 0.6.1 status, demos, tests
In-Reply-To: <200009292122.XAA01777@loewis.home.cs.tu-berlin.de>; from martin@loewis.home.cs.tu-berlin.de on Fri, Sep 29, 2000 at 11:22:54PM +0200
References: <200009292122.XAA01777@loewis.home.cs.tu-berlin.de>
Message-ID: <20000929180212.C20008@kronos.cnri.reston.va.us>

On Fri, Sep 29, 2000 at 11:22:54PM +0200, Martin v. Loewis wrote:
>The missing piece for a 0.6.1 release is the test suite. Specifically,
>the dom tests are not executed, as xml.dom.core is not available
>anymore. Should these tests be ported to 4DOM?

I vaguely recall that someone at FourThought once asked me if that
would be OK, but don't know if anyone actually did it.  It would be a
good idea to port them, since they made some attempt at being
exhaustive (trying the various error cases, etc.).

--amk



From uche.ogbuji@fourthought.com  Sat Sep 30 02:52:08 2000
From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com)
Date: Fri, 29 Sep 2000 19:52:08 -0600
Subject: [XML-SIG] PyXML 0.6.1 status, demos, tests
In-Reply-To: Message from Andrew Kuchling <akuchlin@mems-exchange.org>
 of "Fri, 29 Sep 2000 18:02:12 EDT." <20000929180212.C20008@kronos.cnri.reston.va.us>
Message-ID: <200009300152.TAA12572@localhost.localdomain>

> On Fri, Sep 29, 2000 at 11:22:54PM +0200, Martin v. Loewis wrote:
> >The missing piece for a 0.6.1 release is the test suite. Specifically,
> >the dom tests are not executed, as xml.dom.core is not available
> >anymore. Should these tests be ported to 4DOM?
> 
> I vaguely recall that someone at FourThought once asked me if that
> would be OK, but don't know if anyone actually did it.  It would be a
> good idea to port them, since they made some attempt at being
> exhaustive (trying the various error cases, etc.).

Yes, we did check in the test suites, but as Martin points out, they're broken 
because they use the now defunct TraceOut module (that's the "Ft" stuff.  Mike 
has agreed to tackle some of the task of removing traceouts tonight so I'll 
ask hiom if he can start with the 4DOM test suites.  If so, we'll check in the 
fix tomorrow.

I'll also move the demos as discussed.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python




From martin@loewis.home.cs.tu-berlin.de  Sat Sep 30 08:34:43 2000
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sat, 30 Sep 2000 09:34:43 +0200
Subject: [XML-SIG] PyXML 0.6.1 status, demos, tests
In-Reply-To: <200009300152.TAA12572@localhost.localdomain>
 (uche.ogbuji@fourthought.com)
References: <200009300152.TAA12572@localhost.localdomain>
Message-ID: <200009300734.JAA00694@loewis.home.cs.tu-berlin.de>

> I'll also move the demos as discussed.

Thanks!

Martin