From walter@livinglogic.de Mon Jul 1 11:11:41 2002 From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=) Date: Mon, 01 Jul 2002 12:11:41 +0200 Subject: [XML-SIG] Encoding argument for toxml and toprettyxml References: <200206301507.g5UF7isO003037@paros.informatik.hu-berlin.de> Message-ID: <3D202ADD.3060806@livinglogic.de> Martin v. Löwis wrote: > Folks, > > I've added an encoding argument for toxml and toprettyxml both in the > PyXML and the Python CVSs. Making 'utf-8' the default is unfortunately > not possible for backwards compatibility. > > Please let me know what you think about this change, in particular > whether it should be made available in Python 2.2.2 as well. I like it. Even better would be if those methods were able to escape unencodable characters with character references inside Text nodes. That's exactly what PEP 293 was made for. Bye, Walter Dörwald From loewis@informatik.hu-berlin.de Mon Jul 1 14:42:46 2002 From: loewis@informatik.hu-berlin.de (Martin v. =?iso-8859-1?q?L=F6wis?=) Date: 01 Jul 2002 15:42:46 +0200 Subject: [XML-SIG] Encoding argument for toxml and toprettyxml In-Reply-To: <3D202ADD.3060806@livinglogic.de> References: <200206301507.g5UF7isO003037@paros.informatik.hu-berlin.de> <3D202ADD.3060806@livinglogic.de> Message-ID: Walter D=F6rwald writes: > I like it. Even better would be if those methods were able to escape > unencodable characters with character references inside Text nodes. > That's exactly what PEP 293 was made for. Right. Does that mean that the "errors" argument of the StreamWriter needs to be exposed, or should we silently use "xmlcharrefreplace" in 2.3? If so, how do we find out whether this is a valid error mode? Regards, Martin From walter@livinglogic.de Mon Jul 1 18:18:38 2002 From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=) Date: Mon, 01 Jul 2002 19:18:38 +0200 Subject: [XML-SIG] Encoding argument for toxml and toprettyxml References: <200206301507.g5UF7isO003037@paros.informatik.hu-berlin.de> <3D202ADD.3060806@livinglogic.de> Message-ID: <3D208EEE.4080807@livinglogic.de> Martin v. Löwis wrote: > Walter Dörwald writes: > >>I like it. Even better would be if those methods were able to escape >>unencodable characters with character references inside Text nodes. >>That's exactly what PEP 293 was made for. > > Right. Does that mean that the "errors" argument of the StreamWriter > needs to be exposed, As long as the stream writer class is derived from codecs.StreamWriter the errors attribute is already exposed. It just has to be documented that the errors attribute can be changed between calls to StreamWriter.write() to switch between different error handling modes. I should probably add this to PEP 293. > or should we silently use "xmlcharrefreplace" in > 2.3? If we use "xmlcharrefreplace" now, Python 2.2 or codecs that haven't been updated will fail with: ValueError: foo encoding error; unknown error handling code: xmlcharrefreplace instead of: UnicodeError: foo encoding error: ordinal not in range as it is now. I guess this shouldn't be a problem. We could add a comment that will be visible in the stacktrace (e.g. for minidom: def _write_data(writer, data, errors): "Writes datachars to writer." data = data.replace("&", "&") data = data.replace("<", "<") data = data.replace("\"", """) data = data.replace(">", ">") writer.errors = errors writer.write(data) # if this fails with an "unknown error handling code" exception for Text content, you should use Python 2.3 or an encoding that can encode all characters in your document. If it fails with a UnicodeError, you have unencodeable characters in comments, processing instructions, or tag names. For comments or processing instructions we could define new error handling names, that raise a different exception, tell the user that unencodable characters are not allowed in comments etc. If we want escaping to work with Python 2.2 or old codecs, we could do something like this: try: writer.errors = errors writer.write(data) except ValueError: # unknown error handling name # i.e. Python 2.2 or an old codec if errors!="xmlcharrefreplace": raise # we're in a comment or procinst else: # use the slow workaround for c in data: try: writer.write(c) except UnicodeError: writer.write(u"&#%d;" % ord(c)) But this will be slow and it isn't 100% safe, because the first writer.write(data) might have written partial data. (It is safe with the PEP 293 method, because writing never has to be retried.) > If so, how do we find out whether this is a valid error mode? The same way we find out if it's a valid encoding: just try it. If it doesn't work, catch the ValueError exception (for Python 2.2). Unfortunately a ValueError is not very specific and might have a different source. For Python 2.3 a LookupError will be raised by new codecs, but "xmlcharrefreplace" is supported by all builtin codecs anyway. Bye, Walter Dörwald From fdrake@acm.org Mon Jul 1 21:17:07 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 1 Jul 2002 16:17:07 -0400 Subject: [XML-SIG] "minidom-enhancements" branch Message-ID: <15648.47299.756037.535442@grendel.zope.com> After Python 10, I spent some time implementing some performance enhancements for minidom. There was a bit of a discussion on the list about them, and no one objected, but there hasn't been a lot of activity lately. The changes from the branch are still good, and I'd like to merge them into the PyXML trunk. These changes, combined with the pexpat buffering changes, make for a nice improvement over the existing construction process for minidom (about 2x faster; maybe more if your documents generate a lot of consecutive character data callbacks from Expat). If no one objects, I'll merge my changes into the PyXML trunk tonight or tomorrow. If you want to take a look at them before then, they are on the "minidom-enhancements" branch in the PyXML CVS. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From vdv@dyomedea.com Mon Jul 1 22:15:58 2002 From: vdv@dyomedea.com (Eric van der Vlist) Date: 01 Jul 2002 23:15:58 +0200 Subject: [XML-SIG] ann: xvif 0.1.1==Regular Fragmentations test suite+xmlcomp Message-ID: <1025558159.12499.97.camel@ibook> A short update to mention that I have uploaded the relase 0.1.1 [1] of xvif [2] which major update is a test suite for Regular Fragmentations [3] relying on a new XmlComp [4] module implementing a simple but flexible comparison between documents (the purpose is to get a "yes or no" answer rather than a diff and you can define if cosmetic details such as whitespaces, empty text nodes, namespace prefixes or namespace declarations need to be tested). Eric [1] http://downloads.xmlschemata.org/python/xvif-0.1.1.tgz [2] http://downloads.xmlschemata.org/python/xvif/ [3] http://downloads.xmlschemata.org/python/xvif/tests/regfrag/ [4] http://downloads.xmlschemata.org/python/xvif/xmlcomp.py -- See you in San Diego. http://conferences.oreillynet.com/os2002/ ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema ------------------------------------------------------------------------ From martin@v.loewis.de Mon Jul 1 23:28:14 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 02 Jul 2002 00:28:14 +0200 Subject: [XML-SIG] Encoding argument for toxml and toprettyxml In-Reply-To: <3D208EEE.4080807@livinglogic.de> References: <200206301507.g5UF7isO003037@paros.informatik.hu-berlin.de> <3D202ADD.3060806@livinglogic.de> <3D208EEE.4080807@livinglogic.de> Message-ID: Walter D=F6rwald writes: > > Right. Does that mean that the "errors" argument of the StreamWriter > > needs to be exposed, >=20 > As long as the stream writer class is derived from codecs.StreamWriter > the errors attribute is already exposed. No, it's not: toxml reads def toprettyxml(self, indent=3D"\t", newl=3D"\n", encoding =3D None): writer =3D _get_StringIO() if encoding is not None: import codecs # Can't use codecs.getwriter to preserve 2.0 compatibility writer =3D codecs.lookup(encoding)[3](writer) if self.nodeType =3D=3D Node.DOCUMENT_NODE: # Can pass encoding only to document, to put it into XML header self.writexml(writer, "", indent, newl, encoding) else: self.writexml(writer, "", indent, newl) return writer.getvalue() So the user never sees the stream writer, and can thus not adjust the errors attribute. > It just has to be documented that the errors attribute can be > changed between calls to StreamWriter.write() to switch between > different error handling modes. Is that really something you can guarantee for all stream writers? What if the stream writer needs to be stateful, and the state interpretation is affected by the error handling? > If we use "xmlcharrefreplace" now, Python 2.2 or codecs that haven't > been updated will fail with: >=20 > ValueError: foo encoding error; unknown error handling code: > xmlcharrefreplace Is this also the case for all third-party codecs? > If we want escaping to work with Python 2.2 or old codecs, we could do > something like this: I was rather looking for code like try: codecs.xmlcharrefreplace have_xmlcharrefreplace =3D 1 except AttributeError: have_xmlcharrefreplace =3D 0 > The same way we find out if it's a valid encoding: just try it. > If it doesn't work, catch the ValueError exception (for Python 2.2). That's not good enough. If the minidom implementation uses it, it better be sure that it, if not supported, has the same meaning like the "strict" error mode. Regards, Martin From noreply@sourceforge.net Tue Jul 2 12:18:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 04:18:07 -0700 Subject: [XML-SIG] [ pyxml-Bugs-576331 ] problem parsing xml with DOCTYPE decl. Message-ID: Bugs item #576331, was opened at 2002-07-02 06:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=576331&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher J. Prinos (cprinos) Assigned to: Nobody/Anonymous (nobody) Summary: problem parsing xml with DOCTYPE decl. Initial Comment: This is actually two problems, one with xmlproc, and one with expat. This is orginally from a comp.lang.python thread, Martin Loewis suggested I place a bug report here. Starting with an xml file that specifies a dtd, if the file is parsed with validation it ends up with a an empty root node. If it's parsed _without_ validation, then the document contents are correct, except that the doc will have a bogus DOCTYPE declaration that specifies the root element name without using SYSTEM or PUBLIC to specify the DTD. -- t1.xml --- simple test -- t1.dtd -- -- test code -- >>> import xml.dom.ext.reader.Sax2 as Sax2 >>> ValReader = Sax2.Reader(validate=1) >>> NonValReader = Sax2.Reader(validate=0) >>> vd = ValReader.fromStream(open('t1.xml')) >>> nvd = NonValReader.fromStream(open('t1.xml')) >>> from xml.dom.ext import PrettyPrint as PPrint >>> >>> PPrint(vd) # this shows vd to have an empty root >>> >>> PPrint(nvd) # this shows nvd to have a non-valid doctype declaration simple test ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=576331&group_id=6473 From adrien.rebollo@gmx.fr Tue Jul 2 22:44:38 2002 From: adrien.rebollo@gmx.fr (adrien.rebollo@gmx.fr) Date: Tue, 2 Jul 2002 23:44:38 +0200 Subject: [XML-SIG] Problem with adr_parse.py Message-ID: <20020702234438.A2987@hasard.gmx.fr> --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, The parser for Opera .adr files has a bug, at least with Opera 6 : if an optional field is not there, for example "VISITED", the parser goes one line too far, and all gets messed up. See attached patch. Adrien Rebollo -- --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="adr.patch" --- adr_parse.py Wed May 1 11:57:31 2002 +++ /home/rebollo/PyXML-0.7.1/demo/xbel/adr_parse.py Tue Jul 2 23:28:44 2002 @@ -21,12 +21,16 @@ # --- Methods def readfield(infile, fieldname, required = 1): - line = string.rstrip(infile.readline()) + line = infile.readline() + linelength = len(line) pos = string.find(line,fieldname+"=") if pos == -1 and required: raise OperaParseException("Field '%s' missing" % fieldname) - return line[pos+len(fieldname)+1:] + if pos == -1 and required == 0: + infile.seek(-linelength, 1) + + return string.rstrip(line[pos+len(fieldname)+1:]) def swallow_rest(infile): "Reads input until first blank line." --a8Wt8u1KmwUX3Y2C-- From walter@livinglogic.de Tue Jul 2 23:01:20 2002 From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=) Date: Wed, 03 Jul 2002 00:01:20 +0200 Subject: [XML-SIG] Encoding argument for toxml and toprettyxml References: <200206301507.g5UF7isO003037@paros.informatik.hu-berlin.de> <3D202ADD.3060806@livinglogic.de> <3D208EEE.4080807@livinglogic.de> Message-ID: <3D2222B0.8080206@livinglogic.de> Martin v. Loewis wrote: > Walter Dörwald writes: > >> > Right. Does that mean that the "errors" argument of the StreamWriter >> > needs to be exposed, >> >>As long as the stream writer class is derived from codecs.StreamWriter >>the errors attribute is already exposed. > > No, it's not: toxml reads > > def toprettyxml(self, indent="\t", newl="\n", encoding = None): > writer = _get_StringIO() > if encoding is not None: > import codecs > # Can't use codecs.getwriter to preserve 2.0 compatibility > writer = codecs.lookup(encoding)[3](writer) > if self.nodeType == Node.DOCUMENT_NODE: > # Can pass encoding only to document, to put it into XML header > self.writexml(writer, "", indent, newl, encoding) > else: > self.writexml(writer, "", indent, newl) > return writer.getvalue() > > So the user never sees the stream writer, and can thus not adjust the > errors attribute. If with "user" you mean the caller of toprettyxml(), the user does not have to adjust the errors attribute, it is done by the writexml method of various node classes: def _write_data(writer, data, errors): "Writes datachars to writer." data = data.replace("&", "&") data = data.replace("<", "<") data = data.replace("\"", """) data = data.replace(">", ">") writer.errors = errors writer.write(data) class Text: def writexml(self, writer, indent="", addindent="", newl=""): _write_data(writer, "%s%s%s"%(indent, self.data, newl), "xmlcharrefreplace") class Comment: def writexml(self, writer, indent="", addindent="", newl=""): writer.errors = "strict" writer.write("%s%s" % (indent,self.data,newl)) Of course the above code only works when an encoding is specified, so that writer is a StreamWriter. For the StringIO the assignment to writer.errors should be wrapped in a try: ... except AttributeError: pass >>It just has to be documented that the errors attribute can be >>changed between calls to StreamWriter.write() to switch between >>different error handling modes. > > Is that really something you can guarantee for all stream writers? I didn't find anything in the documentation http://www.python.org/doc/current/lib/stream-writer-objects.html about the errors attribute of the StreamWriter class, so we can't guarantee anything now. That's why PEP 293 should state that errors should be assignable in the stream classes. I'll add it in the next few days. I took a look at JapaneseCodecs 1.4.5: The StreamWriter/Reader classes are derived from codecs.StreamWriter/codecs.StreamReader (for both the C and Python based versions), so it'll work there. I don't know anything about the other third party codecs. Where can they be found? > What if the stream writer needs to be stateful, and the state > interpretation is affected by the error handling? Using a custom error handling name should be completely equivalent to applying the replacement of unencodable characters beforehand and then using the strict method. Currently I can't imagine a stream writer where the state menagement depends on the error handling name. Can you give an example? The PEP 293 machinery is explicitely designed to make state management and error handling independent. >>If we use "xmlcharrefreplace" now, Python 2.2 or codecs that haven't >>been updated will fail with: >> >>ValueError: foo encoding error; unknown error handling code: >>xmlcharrefreplace > > Is this also the case for all third-party codecs? JapaneseCodecs 1.4.5 does the following: Python 2.2 (#1, Jan 30 2002, 17:32:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u"gurk".encode("sjis", "gurk") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/src/JapaneseCodecs-1.4.5/japanese/python/shift_jis.py", line 12, in encode raise UnicodeError, "unknown error handling" i.e. it raises a UnicodeError instead of a ValueError (which would work too, because issubclass(UnicodeError, ValueError)), although it's not correct, because this is an error in the provided arguments, not in the encoding algorithm (Note that I was the one who convinced Tamito to use UnicodeError instead of ValueError, maybe I can convince him to change it back.) >>If we want escaping to work with Python 2.2 or old codecs, we could do >>something like this: > > I was rather looking for code like > > try: > codecs.xmlcharrefreplace > have_xmlcharrefreplace = 1 > except AttributeError: > have_xmlcharrefreplace = 0 or: try: codecs.register_error have_xmlcharrefreplace = 1 except AttributeError: have_xmlcharrefreplace = 0 But this only checks if the error handling API is present in Python. It does not check whether a certain codec uses the API. >>The same way we find out if it's a valid encoding: just try it. >>If it doesn't work, catch the ValueError exception (for Python 2.2). > > That's not good enough. If the minidom implementation uses it, it > better be sure that it, if not supported, has the same meaning like > the "strict" error mode. How about the following code? This will raise the same exception if assigning the errors attribute or using it doesn't work: try: try: writer.errors = errors except AttributeError: pass writer.write(data) except ValueError: try: writer.errors = "strict" except AttributeError: pass writer.write(data) BTW, thanks for your comments. The PEP did go unnoticed in python-dev and python-list so far. Bye, Walter Dörwald From martin@v.loewis.de Wed Jul 3 07:24:41 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 03 Jul 2002 08:24:41 +0200 Subject: [XML-SIG] Problem with adr_parse.py In-Reply-To: <20020702234438.A2987@hasard.gmx.fr> References: <20020702234438.A2987@hasard.gmx.fr> Message-ID: adrien.rebollo@gmx.fr writes: > The parser for Opera .adr files has a bug, at least with Opera 6 : > if an optional field is not there, for example "VISITED", the parser > goes one line too far, and all gets messed up. Can you please put patches onto sf.net/projects/pyxml? Thanks, Martin From martin@v.loewis.de Wed Jul 3 07:30:03 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 03 Jul 2002 08:30:03 +0200 Subject: [XML-SIG] Encoding argument for toxml and toprettyxml In-Reply-To: <3D2222B0.8080206@livinglogic.de> References: <200206301507.g5UF7isO003037@paros.informatik.hu-berlin.de> <3D202ADD.3060806@livinglogic.de> <3D208EEE.4080807@livinglogic.de> <3D2222B0.8080206@livinglogic.de> Message-ID: Walter D=F6rwald writes: > Currently I can't imagine a stream writer where the state menagement > depends on the error handling name. Can you give an example?=20 No, I can't. I know that encoders have to be stateful, but I can't give a real-world example where the state needs to take into account error handling. > But this only checks if the error handling API is present in > Python. It does not check whether a certain codec uses the API. Using that as a check for "Python 2.3" is good enough for me. > How about the following code? This will raise the same exception > if assigning the errors attribute or using it doesn't work: >=20 > try: > try: > writer.errors =3D errors > except AttributeError: > pass > writer.write(data) > except ValueError: > try: > writer.errors =3D "strict" > except AttributeError: > pass > writer.write(data) I don't think that can work. What if the first write was "partial", i.e. already wrote some of the data? Regards, Martin From uche.ogbuji@fourthought.com Wed Jul 3 17:17:59 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 03 Jul 2002 10:17:59 -0600 Subject: [XML-SIG] Re: [4suite] XML Tutorial at Europython In-Reply-To: <20020624173343.GA14254@orion.logilab.fr> References: <20020624173343.GA14254@orion.logilab.fr> Message-ID: <1025713080.13361.514.camel@borgia.local> On Mon, 2002-06-24 at 11:33, Alexandre wrote: > Hello everyone, > > I've put the slides for the tutorial I'll be giving at Europython > online. You can get them as HTML from > http://www.logilab.org/XMLTutorial/ or as pdf or postscript from > http://www.logilab.org/ftp/pub/talks/ > > I'd appreciate if some of you could give them a look and provide some > feedback before I leave for Charlerois. The following should be linked to any FAQs http://www.logilab.org/XMLTutorial/diap23.html A nice, succinct delineation of the status quo wrt PyXML/4Suite compatibility. I've added a bunch of pointers from my "Akara" doccumentation to appropriate sections of this great presentation. http://uche.ogbuji.net/tech/akara/pyxml/ -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From gherman@darwin.in-berlin.de Thu Jul 4 12:04:38 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Thu, 04 Jul 2002 13:04:38 +0200 (CEST) Subject: [XML-SIG] Printing "quite" pretty DOMs? Message-ID: <1025780678.3d242bc679a7d@webmail.in-berlin.de> Hi, I'm printing DOM trees in some slightly embellished fashion. In my case I'm using toprettyxml() and toxml() to get the desired output, toxml() gives me something like this, say: foobar (not very pretty) while toprettyxml() gives me: foo bar Now this is actually too pretty in my case! What I'd really need is something between the cases above, namely: foo bar i.e. with no extra whitespace added for text inside an ele- ment. Has anybody already some snippet to do this or isn't it that trivial, maybe? Thanks, Dinu From joakley@solutioninc.com Thu Jul 4 13:44:04 2002 From: joakley@solutioninc.com (James Oakley) Date: Thu, 4 Jul 2002 09:44:04 -0300 Subject: [XML-SIG] Printing "quite" pretty DOMs? In-Reply-To: <1025780678.3d242bc679a7d@webmail.in-berlin.de> References: <1025780678.3d242bc679a7d@webmail.in-berlin.de> Message-ID: <200207040944.11085.joakley@solutioninc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On July 4, 2002 08:04 am, Dinu Gherman wrote: > Now this is actually too pretty in my case! What I'd really > need is something between the cases above, namely: > > > foo > bar > > > i.e. with no extra whitespace added for text inside an ele- > ment. Has anybody already some snippet to do this or isn't > it that trivial, maybe? xml.dom.ext.PrettyPrint(doc, file_object, encoding) This gives you exactly what you're looking for. It's what I prefer as well. - -- James Oakley Engineering - SolutionInc Ltd. joakley@solutioninc.com http://www.solutioninc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9JEMZ+FOexA3koIgRAq3tAKCppy4hL7fEQmBLUdsJMJ3tKw7xRwCfSKBp dpnAfhfa5Mcjf5H3kNPxZ7Y= =IDe7 -----END PGP SIGNATURE----- From noreply@sourceforge.net Thu Jul 4 16:31:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jul 2002 08:31:48 -0700 Subject: [XML-SIG] [ pyxml-Patches-577458 ] Problem with adr_parse.py Message-ID: Patches item #577458, was opened at 2002-07-04 15:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=306473&aid=577458&group_id=6473 Category: XBEL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adrien Rebollo (rebollo) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with adr_parse.py Initial Comment: The parser for Opera .adr files has a bug, at least with Opera 6 : if an optional field is not present, for example "VISITED", the parser goes one line too far, and all the following gets messed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=306473&aid=577458&group_id=6473 From walter@livinglogic.de Thu Jul 4 22:17:52 2002 From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=) Date: Thu, 04 Jul 2002 23:17:52 +0200 Subject: [XML-SIG] Encoding argument for toxml and toprettyxml References: <200206301507.g5UF7isO003037@paros.informatik.hu-berlin.de> <3D202ADD.3060806@livinglogic.de> <3D208EEE.4080807@livinglogic.de> <3D2222B0.8080206@livinglogic.de> Message-ID: <3D24BB80.9080700@livinglogic.de> Martin v. Loewis wrote: > Walter Dörwald writes: > > >>Currently I can't imagine a stream writer where the state menagement >>depends on the error handling name. Can you give an example? > > > No, I can't. I know that encoders have to be stateful, but I can't > give a real-world example where the state needs to take into account > error handling. OK, so I hope we can ignore this potential problem. >>But this only checks if the error handling API is present in >>Python. It does not check whether a certain codec uses the API. > > > Using that as a check for "Python 2.3" is good enough for me. OK, but but using the new error handling name might fail for a third party codecs, that hasn't been updated yet. But I hope that Tamito Kajayama will update his JapanaesCodec, when (and if) PEP 293 gets accepted. >>How about the following code? This will raise the same exception >>if assigning the errors attribute or using it doesn't work: >> >>try: >> try: >> writer.errors = errors >> except AttributeError: >> pass >> writer.write(data) >>except ValueError: >> try: >> writer.errors = "strict" >> except AttributeError: >> pass >> writer.write(data) > > > I don't think that can work. What if the first write was "partial", > i.e. already wrote some of the data? That's exactly one of the reasons for the PEP. One workaround would be to do a test write to a throwaway StringIO stream at the start of toprettyxml with characters that are guaranteed to fail and check which exception is raised. The result of this test could be stored in a dictionary with the encoding as the key, so that the test has to be done only once per encoding. Bye, Walter Dörwald From t.c.jones@att.net Sat Jul 6 17:21:58 2002 From: t.c.jones@att.net (t.c.jones@att.net) Date: Sat, 06 Jul 2002 16:21:58 +0000 Subject: [XML-SIG] domain name lookup Message-ID: <20020706162158.DNZO5870.mtiwmhc23.worldnet.att.net@webmail.worldnet.att.net> I am trying to use xml page to send email, the local smtp system is not adequate, so I would like to acquire the name of the mail server by myself. This is something that nslookup does (sort of). Has anyone on the list any experience getting more data from the domain name system than is available from socket.py? Like in particular the mx records? thx ..tom From martin@v.loewis.de Sat Jul 6 21:42:17 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 06 Jul 2002 22:42:17 +0200 Subject: [XML-SIG] domain name lookup In-Reply-To: <20020706162158.DNZO5870.mtiwmhc23.worldnet.att.net@webmail.worldnet.att.net> References: <20020706162158.DNZO5870.mtiwmhc23.worldnet.att.net@webmail.worldnet.att.net> Message-ID: t.c.jones@att.net writes: > Like in particular the mx records? This question is not related to XML, is it? In any case, there are a few DNS libraries out there for Python, for example http://pydns.sourceforge.net/ http://c0re.jp/c0de/dnsmodule/ http://dustman.net/andy/python/adns-python Ask Google for more. Regards, Martin From matt_g_@hotmail.com Sun Jul 7 04:58:12 2002 From: matt_g_@hotmail.com (Matt G.) Date: Sun, 07 Jul 2002 03:58:12 +0000 Subject: [XML-SIG] Proposal: command-line interface to parser Message-ID: A quick search (i.e. 'find PyXML-0.7.1 -perm +111') doesn't turn up any general-purpose applications of the sort I'm looking for - sorry if it's there and I missed it (but why not 'chmod +x' it?). Anyhow, I think it'd be immensely useful to include a command-line tool that performs at least the following functions: * XML validation - returns a nonzero error code and pretty/useful error message if validation fails * XML document "flattening" (i.e. writes out copy of parsed document, inlining external entities, potentially applying DTD attribute defaults, and potentially also validating). This would be even more useful, if it supported XInclude. * Listing URIs of all external entities referenced (defined would be okay, too, but only as an option) My case for validation is that it's a useful thing to have, if you're feeding XML into something that doesn't use a validating parser or one with obscure error messages. Also, having a command-line interface to the parser (both validating and non-validating) would be useful for those who want to do testing and benchmarking of XML parsers. XML flattening makes sense, if you consider that SGML and XML Catalog support is the exception, among XML-based applications. I'm not quite sure how one would deal with external unparsed entities (perhaps resolve their URI to a local system path?), but it should otherwise be pretty straightforward. Listing external entities is important for using Makefiles (or Ant?) to process XML-based sourcefiles only when necessary. Perhaps you're familiar with GCC's '-M' option, which is specifically geared towards auto-dependency generation? Finally, it would have value as another example for people to look at. Anyway, I was just curious as to whether anyone else saw any value in a command-line interface to an XML parser, with these functions. I'd be willing to write it, though it doesn't seem like much work. I haven't yet poked around at PyXML, much. Would it make more sense to build such a thing on minidom? Would that have the resolver hooks, for listing external entities that get referenced? Thanks for considering this idea & providing any feedback. Matt Gruenke _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From tpassin@comcast.net Sun Jul 7 06:22:23 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Sun, 07 Jul 2002 01:22:23 -0400 Subject: [XML-SIG] Proposal: command-line interface to parser References: Message-ID: <000601c22576$465cf120$fe193044@tbp1> [Matt G.] > A quick search (i.e. 'find PyXML-0.7.1 -perm +111') doesn't turn up any > general-purpose applications of the sort I'm looking for - sorry if it's > there and I missed it (but why not 'chmod +x' it?). > > Anyhow, I think it'd be immensely useful to include a command-line tool that > performs at least the following functions: Did you not find xpcmd.py and xvcmd.py ( in 7.0, I admit, but surely they are still there)? On my Python 2.1.3 Win2000 system they got installed in Python21\xmldoc\demo\xmlproc. They give you at least the first of the three items. Cheers, Tom P From matt_g_@hotmail.com Sun Jul 7 16:19:15 2002 From: matt_g_@hotmail.com (Matt G.) Date: Sun, 07 Jul 2002 15:19:15 +0000 Subject: [XML-SIG] Proposal: command-line interface to parser Message-ID: >From: "Thomas B. Passin" >To: xml-sig@python.org >Subject: Re: [XML-SIG] Proposal: command-line interface to parser >Date: Sun, 07 Jul 2002 01:22:23 -0400 Thanks for the prompt reply. >[Matt G.] > > > A quick search (i.e. 'find PyXML-0.7.1 -perm +111') doesn't turn up any > > general-purpose applications of the sort I'm looking for - sorry if it's > > there and I missed it (but why not 'chmod +x' it?). > > > > Anyhow, I think it'd be immensely useful to include a command-line tool > > that performs at least the following functions: > >Did you not find xpcmd.py and xvcmd.py ( in 7.0, I admit, but surely they >are still there)? On my Python 2.1.3 Win2000 system they got installed in >Python21\xmldoc\demo\xmlproc. They give you at least the first of the >three >items. I'm not exactly sure how you're counting (i.e. whether you mean bullet points or what), but there are a number of things I'd do differently, given my goals (please don't mistake these for criticisms - see the first point). Some of these are: * Locate the source in an 'apps' directory - putting it in 'demo' implies that its primary purpose is as an example, rather than being intrinsically useful. This distinction is important, since it affects the tradeoffs of simplicity vs. functionality. * Set the default permissions to executable (I think the original author intended this, since they both have '#!/usr/bin/python', at the top of the file) * Print the status, warning, and error messages to stderr. I think this is best done by having the parser throw an exception object (with all the relevant information about the error or warning), which the application catches. I'm a bit lost on the benefit of registering an error handler. * Make validation an option, rather than a separate command * Improve the usage info to say a little more about the program. Add a '--help'. Also, include a statement about the conformance goals (perhaps this is too much information for --help output, but then the user should be directed to a document containing more info) * Supply an option to use an SGML catalog file (support exists for both, right?), though I suppose you could try to parse a catalog as an SGML catalog file, when it fails validation as an XML Catalog file. * Add -o/--output, for writing the parsed document to a file. This sort of implies that the number of documents per invocation would be limited to 1. Unless '-n' is supplied, the parsed document should be written to stdout (which is one reason status/warning/error messages shouldn't be written there). Actually, I could go either way, on the subject of whether this should really be the default behavior. * Add -q, for suppressing status, so that you can get output only in the case of a warning or error In addition to those, there are still some unfulfilled requirements, in my original list. Is anyone unconvinced that another application is warranted or of the value of including such an application in PyXML? I think it would provide substantial benefit, to some users, with only nominal up-front and ongoing costs to the XML-SIG. I think it's justified, given the magnitude of the ratio of how annoying it would be to install a separate package to the minimal size and complexity of such an application. Thanks for considering my position. Matt Gruenke _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From martin@v.loewis.de Sun Jul 7 16:41:55 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 07 Jul 2002 17:41:55 +0200 Subject: [XML-SIG] Proposal: command-line interface to parser In-Reply-To: References: Message-ID: "Matt G." writes: > Is anyone unconvinced that another application is warranted or of the > value of including such an application in PyXML? Feel free to contribute anything that you consider valuable. Notice that, in addition to xpcmd.py and xvcmd.py, PyXML already installs scripts/xmlproc_parse and scripts/xmlproc_val, via distutils. Any additional programs should also be installed via distutils. Please submit patches to sf.net/projects/pyxml. Regards, Martin From noreply@sourceforge.net Mon Jul 8 07:10:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jul 2002 23:10:12 -0700 Subject: [XML-SIG] [ pyxml-Bugs-578553 ] nonconformance: NOTATION-type attributes Message-ID: Bugs item #578553, was opened at 2002-07-08 02:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=578553&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: Lars Marius Garshol (larsga) Summary: nonconformance: NOTATION-type attributes Initial Comment: xmlproc's DTD parser seems to be nonconformant, in a couple of NOTATION-related areas. I tripped over the initial case, when an error was incorrectly reported, while trying to use xmlproc to parse the XML DocBook DTD v4.1.2 (there's no reason to believe 4.2 won't have the same issue). Since DocBook is a fairly popular DTD, I think this error is fairly serious, even though NOTATION-type attributes are surely one of XML's more infrequently used features. While I was reproducing this error, I figured I'd try a couple related cases, and uncovered two more areas of nonconformance. I could have reported these as separate bugs, but it was easiest to reproduce them all in the same source file, and I think they should be easy to fix. If anyone wants to split them out, please feel free to do so. The first error occurs when xmlproc complains about a default being supplied, for NOTATION-type attributes. The specific error message (for my test case) is: ERROR: 'gif' is not an allowed value for the 'format' attribute at xmlproc_notation_bugs.dtd:27:46 As far as I can tell, there's no reason a default value can't be applied to a NOTATION-type attribute, though I don't see where the spec explicitly states this as a possibility (since it does explicitly disallow defaults for ID attributes, one could assume that no similar statement, about NOTATION attributes, means it's allowed). The fact that XML DocBook does this, has been around for quite a while, and is routinely processed by dozens of different XML parsers, lends weight to the case that NOTATION-type attributes should be able to take a default value. I think the problem is that, in _xmlplus/parsers/xmlproc/xmldtd.py: Attribute.validate(), someone decided to be a little too clever and allow default values only if the type of the attribute value is StringType (types.StringType or types.UnicodeType). The second case of nonconformance is one in which an error is reported as a warning. The case is that two NOTATION-type attributes aren't allowed to be applied to the same element (the spec notes this as a compatibility constraint, so I assume it's due to some SGML legacy). I didn't look into possible causes of this. The third case I encountered is that NOTATION attributes are allowed, on empty elements, when they shouldn't be. No warning or error is issued. I didn't look into possible causes of this, either. Again, the first problem is really the highest-priority issue, for me (and probably others). However, I expect the XML-SIG will want to see all of these fixed, if knowing that xmlproc is nonconformant weighs down on anyone's conscience. ;-) I'd have gone ahead and proposed a fix, but figured the maintainer(s) may have different ideas about the best way to address it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=578553&group_id=6473 From uche.ogbuji@fourthought.com Tue Jul 9 05:15:18 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 08 Jul 2002 22:15:18 -0600 Subject: [XML-SIG] Proposal: command-line interface to parser In-Reply-To: Message from "Matt G." of "Sun, 07 Jul 2002 03:58:12 -0000." Message-ID: <200207090415.g694FId09071@localhost.localdomain> > A quick search (i.e. 'find PyXML-0.7.1 -perm +111') doesn't turn up any > general-purpose applications of the sort I'm looking for - sorry if it's > there and I missed it (but why not 'chmod +x' it?). > > Anyhow, I think it'd be immensely useful to include a command-line tool that > performs at least the following functions: > > * XML validation - returns a nonzero error code and > pretty/useful error message if validation fails The 4xml command in 4Suite CVS does this, except for the error code return, which is a good idea. Do you have some suggestions for good error codes to use? http://4suite.org/docs/4SuiteCVS.xml > * XML document "flattening" (i.e. writes out copy of parsed > document, inlining external entities, potentially applying > DTD attribute defaults, and potentially also validating). > This would be even more useful, if it supported XInclude. 4xml does all this, including XInclude support. > * Listing URIs of all external entities referenced (defined > would be okay, too, but only as an option) Doesn't do this yet, but if you post a feature request on the 4Suite SF feature request tracker, I can try to add it soon. You're right that these features are very handy, which is why I added 4xml :-) -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From uche.ogbuji@fourthought.com Tue Jul 9 05:19:23 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 08 Jul 2002 22:19:23 -0600 Subject: [XML-SIG] Proposal: command-line interface to parser In-Reply-To: Message from "Matt G." of "Sun, 07 Jul 2002 15:19:15 -0000." Message-ID: <200207090419.g694JNv09090@localhost.localdomain> > I'm not exactly sure how you're counting (i.e. whether you mean bullet = > points or what), but there are a number of things I'd do differently, g= iven = > my goals (please don't mistake these for criticisms - see the first poi= nt). = > Some of these are: > = > * Locate the source in an 'apps' directory - putting it in > 'demo' implies that its primary purpose is as an example, > rather than being intrinsically useful. This distinction > is important, since it affects the tradeoffs of simplicity > vs. functionality. If you folow the CVS install instructions for 4Suite, 4xml is a full comm= and = on your path. You don't even have to explicitly invoke Python. > * Set the default permissions to executable (I think the > original author intended this, since they both have > '#!/usr/bin/python', at the top of the file) > = > * Print the status, warning, and error messages to stderr. I > think this is best done by having the parser throw an > exception object (with all the relevant information about > the error or warning), which the application catches. I'm > a bit lost on the benefit of registering an error handler. 4xml does this: errors to stderr, any proper XML output to stdout. > * Make validation an option, rather than a separate command Yep: -v option > * Improve the usage info to say a little more about the > program. Add a '--help'. Also, include a statement about > the conformance goals (perhaps this is too much information > for --help output, but then the user should be directed to > a document containing more info) Yep. -h or --help > * Supply an option to use an SGML catalog file (support > exists for both, right?), though I suppose you could > try to parse a catalog as an SGML catalog file, when it > fails validation as an XML Catalog file. Not yet. Again if you make a feature request, should be easy to add. > * Add -o/--output, for writing the parsed document to a file. > This sort of implies that the number of documents per > invocation would be limited to 1. Unless '-n' is supplied, > the parsed document should be written to stdout (which is > one reason status/warning/error messages shouldn't be > written there). Actually, I could go either way, on the > subject of whether this should really be the default > behavior. Yes. And even uses -o, as you say. > * Add -q, for suppressing status, so that you can get output > only in the case of a warning or error Not yet. This is so trivial that no feature request is needed. I'll add= it = now in CVS. -- = Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=3D6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/= xml/library/x-think11.html From uche.ogbuji@fourthought.com Tue Jul 9 06:27:13 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 08 Jul 2002 23:27:13 -0600 Subject: [XML-SIG] Python DOM In-Reply-To: Message from "Juergen Hermann" of "Sun, 30 Jun 2002 09:51:44 +0200." Message-ID: <200207090527.g695RDT09335@localhost.localdomain> > Hi! > = > What do you people think of adding a module that can handle the "Python= = > DOM" that for example PyRXP produces. I think I have code that does the= = > conversion between that and a SAX stream (in both directions), which = > would the basis for such a module. I'm not familiar with this Python DOM. Is it similar to http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/116539 ? -- = Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=3D6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/= xml/li brary/x-think11.html From uche.ogbuji@fourthought.com Tue Jul 9 07:51:00 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 09 Jul 2002 00:51:00 -0600 Subject: [XML-SIG] Printing "quite" pretty DOMs? In-Reply-To: Message from James Oakley of "Thu, 04 Jul 2002 09:44:04 -0300." <200207040944.11085.joakley@solutioninc.com> Message-ID: <200207090651.g696p0u09929@localhost.localdomain> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On July 4, 2002 08:04 am, Dinu Gherman wrote: > > Now this is actually too pretty in my case! What I'd really > > need is something between the cases above, namely: > > > > > > foo > > bar > > > > > > i.e. with no extra whitespace added for text inside an ele- > > ment. Has anybody already some snippet to do this or isn't > > it that trivial, maybe? > > xml.dom.ext.PrettyPrint(doc, file_object, encoding) > > This gives you exactly what you're looking for. It's what I prefer as well. FYI, if you have 4Suite from CVS installed, Ft.Xml.Domlette.PrettyPrint does the same thing, but with several important optimizations and character encoding bug fixes. Most of these take advantage of the fact that 4Suite has ditched Python 1.5.2 support. I have placed an item based on your exchange in my doc project: http://uche.ogbuji.net/tech/akara/pyxml/dom-printing/ -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From matt_g_@hotmail.com Tue Jul 9 08:54:37 2002 From: matt_g_@hotmail.com (Matt G.) Date: Tue, 09 Jul 2002 07:54:37 +0000 Subject: [XML-SIG] Proposal: command-line interface to parser Message-ID: >From: Uche Ogbuji >To: "Matt G." >CC: xml-sig@python.org >Subject: Re: [XML-SIG] Proposal: command-line interface to parser Date: >Mon, 08 Jul 2002 22:15:18 -0600 > > > A quick search (i.e. 'find PyXML-0.7.1 -perm +111') doesn't turn up any > > general-purpose applications of the sort I'm looking for - sorry if it's > > there and I missed it (but why not 'chmod +x' it?). > > > > Anyhow, I think it'd be immensely useful to include a command-line tool >that > > performs at least the following functions: > > > > * XML validation - returns a nonzero error code and > > pretty/useful error message if validation fails > >The 4xml command in 4Suite CVS does this, except for the error code return, >which is a good idea. Do you have some suggestions for good error codes to >use? I don't care about actual values, beyond zero == success and nonzero == failure. This is very important for writing scripts & makefiles. I even have my prompt string configured to show me the return code of the last command (but then I'm the kind of nut who has his username, pwd, machine name, and the number of running and stopped jobs in his xterm titlebar). Some of this should be fairly obvious, but here's my wish list, for return code behaviors: * nonzero should always be returned, if the input is not well-formed * nonzero should be returned, if validation is enabled, and the document fails to validate * no output (i.e. XML written to either stdout or a file) should be produced, if the program executes with a nonzero error code. If an output file is written, it should be deleted, before the program exits. * a switch should exist, for treating warnings as errors. By default, warnings should NOT cause the program to exit with a nonzero return code. If the switch to treat them as errors is provided, they would cause the program to (eventually) terminate, with a nonzero return code. The point about not producing output is especially important, when used from a Makefile. If this is not possible, then the exit message should probably even say "bad output written to stdout", so that the user knows to make sure that the output is cleaned up, if it's either redirected to a file or piped into any other commands. BTW, I assume all your options are 'getopt'-style (i.e. multi-letter options begin with '--', while single letter, non-parameterized options use '-' and can be combined). I have a neat python module, built on top of getopt.py, that lets you specify a short option, long option, and description. It handles '--help' (though it gives you the opportunity to provide text to go before & after the options summary). This allows you to centralize your management of option listing & documentation, and could even tie into an automated system to generate user documentation of your commandline interface. If you're interested, check out sourceforge.net/projects/xml-extractor/ (you could either find it in lib/cmdopts.py, or just download xlf_to_wfx.tar.gz). Furthermore, on the usability front, I believe that any output file argument should be supplied via a '--output' or '-o' option. In fact, the only non-option file argument(s) should be input files (but taking an output file, this way (as 'tar' does), is particularly pernicious, since it could result in a file getting clobbered, if the user isn't careful or knowledgeable). > > * Listing URIs of all external entities referenced (defined > > would be okay, too, but only as an option) > >Doesn't do this yet, but if you post a feature request on the 4Suite SF >feature request tracker, I can try to add it soon. If you want to list only the entities that are actually referenced (which I think is the most reasonable behavior), then ENTITY and ENTITIES-type attributes make this slightly more complicated (though it shouldn't be much trouble, if you have a parsed representation of the DTD, lying around). For output, the primary behavior should be to resolve the entities to their ultimate SYSTEM IDs, however it might be a nice feature to have the option of only listing the PUBLIC IDs or whichever is listed in the ENTITY definition. >You're right that these features are very handy, which is why I added 4xml >:-) Wow - this would be VERY cool! Thanks for the reply & cooperation, and I'd be glad to do whatever testing or make any other contributions I can!! I'm out of time, just now, but I'll checkout the CVS 4xml ASAP! Matt Gruenke _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From matt_g_@hotmail.com Tue Jul 9 09:05:06 2002 From: matt_g_@hotmail.com (Matt G.) Date: Tue, 09 Jul 2002 08:05:06 +0000 Subject: strange idea: attribute stripping (Re: [XML-SIG] Proposal: command-line interfac Message-ID: >From: Uche Ogbuji >To: "Matt G." >CC: xml-sig@python.org >Subject: Re: [XML-SIG] Proposal: command-line interface to parser Date: >Mon, 08 Jul 2002 22:15:18 -0600 > > > * XML document "flattening" (i.e. writes out copy of parsed > > document, inlining external entities, potentially applying > > DTD attribute defaults, and potentially also validating). > > This would be even more useful, if it supported XInclude. Maybe someone should just smack me, but it seems like it'd be neat if 4xml, or a stand-alone application, would REMOVE any attributes where the supplied value coincides with the default. This would be a nice way to "compress" XML documents, and make them more human-editable, after undergoing some kind of automated processing. Anyhow, I consider this pretty far down my list of priorities, as I have no immediate need for such functionality. (On the other hand, getting automatically-generated external entity dependencies would DEFINITELY save me the error-prone manual labor of manually maintaining these.) Matt Gruenke _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From fdrake@acm.org Tue Jul 9 17:16:03 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 9 Jul 2002 12:16:03 -0400 Subject: [XML-SIG] Re: [Doc-SIG] Error in pyexpat docs In-Reply-To: <200010291916.MAA16420@localhost.localdomain> References: <200010291916.MAA16420@localhost.localdomain> Message-ID: <15659.3139.489289.158582@grendel.zope.com> [Cleaning out some old email...] On 29 Oct 2000, uche.ogbuji@fourthought.com wrote: > It turns out that ParseFile actually returns 0 on error, returning > 1 otherwise. > > The first matter is that the code and the docs need to be > reconciled. However, I would _much_ rather prefer that things were > as in the docs. I think ParseFile should raise an exception rather > than return an error flag. Interestingly enough, this is the same > argument I had with a colleague just last week. The return value for ParseFile has just recently been made to do the right thing in all cases, and now matches Parse. An exception is raised when there's an error in parsing, and the exception instance carries the "code", "offset", and "lineno" attributes. Just in case anyone thought this was still a problem. ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From info@polyglot.com.cn Wed Jul 10 07:43:57 2002 From: info@polyglot.com.cn (Polyglot) Date: Wed, 10 Jul 2002 14:43:57 +0800 Subject: [XML-SIG] Polyglot Translation Message-ID: <418-22002731064357858@An> Polyglot Translation =20 Polyglot is a professional multilingual solutions provider=2E Our rich experience and professional team established us as a leader in th= e field of multilingual solutions=2E Polyglot can provide fast and accurate translations of financial, legal an= d technical documents on over 30 languages, such as English, German, Spanish, French,=20= Italian, Chinese, Japanese, Korean, etc=2E We also provide website localization and simultaneous interpretation=2E For further information, please visit our website: =20 http://www=2Epolyglot=2Ecom=2Ecn =20 Contact us at: =20 e-mail: info@polyglot=2Ecom=2Ecn=20 =20= Tel: +86 20 8657-3608 Fax: +86 20 8657-3965 =20 Add: 968 Office Tower, Central Hotel 33 Airport Road Guangzhou, China The message below is written in Chinese characters: =B1=A3=C1=A2=D0=C5=B7=AD=D2=EB=B9=AB=CB=BE =B1=A3=C1=A2=D0=C5=B7=AD=D2=EB=B9=AB=CB=BE=CA=C7=D2=BB=BC=D2=CC=E1=B9=A9= =B6=E0=D6=D6=D3=EF=D1=D4=BD=E2=BE=F6=B7=BD=B0=B8=B5=C4=D7=A8=D2=B5=BB=FA=B9= =B9=A1=A3=B7=E1=B8=BB=B5=C4=BE=AD=D1=E9=BC=B0 =D7=A8=D2=B5=B5=C4=B6=D3=CE=E9=C8=B7=C1=A2=C1=CB=CE=D2=C3=C7=D4=DA=B6=E0=D6= =D6=D3=EF=D1=D4=BD=E2=BE=F6=B7=BD=B0=B8=C1=EC=D3=F2=B5=C4=C1=EC=CF=C8=B5=D8= =CE=BB=A1=A3 =CE=D2=C3=C7=C4=DC=CC=E1=B9=A930=B6=E0=D6=D6=D3=EF=D1=D4=B5=C4=D7=BC=C8= =B7=A1=A2=BF=EC=BD=DD=B5=C4=B7=AD=D2=EB=B7=FE=CE=F1=A3=AC=B7=AD=D2=EB=C1=EC= =D3=F2=C9=E6=BC=B0=BD=F0=C8=DA=CE=C4=BC=FE=A1=A2 =B7=A8=C2=C9=CE=C4=BC=FE=BC=B0=BC=BC=CA=F5=CE=C4=BC=FE=A3=AC=B7=AD=D2=EB=D3= =EF=D6=D6=B0=FC=C0=A8=A3=BA=D3=A2=A1=A2=B5=C2=A1=A2=CE=F7=A1=A2=B7=A8=A1=A2= =D2=E2=A1=A2=D6=D0=A1=A2=C8=D5=A1=A2=BA=AB=B5=C8=B5=C8=A1=A3 =B4=CB=CD=E2=A3=AC=CE=D2=C3=C7=BB=B9=CC=E1=B9=A9=CD=F8=D5=BE=B1=BE=B5=D8= =BB=AF=BA=CD=BB=E1=D2=E9=B5=C4=CD=AC=C9=F9=B4=AB=D2=EB=A1=A3 =B9=D8=D3=DA=CF=EA=C7=E9=A3=AC=C7=EB=B7=C3=CE=CA=CE=D2=C3=C7=B5=C4=CD=F8= =D6=B7=A3=BA http://www=2Epolyglot=2Ecom=2Ecn =20 =C1=AA=CF=B5=B7=BD=CA=BD=A3=BA =20 =B5=E7=D3=CA: info@polyglot=2Ecom=2Ecn = =20 =20 =B5=E7=BB=B0: (86-20) 8657 3608 =B4=AB=D5=E6: (86-20) 8657 3965 =20 =20 =B5=D8=D6=B7=A3=BA=D6=D0=B9=FA=B9=E3=D6=DD =BB=FA=B3=A1=C2=B733=BA=C5 =20 =D6=D0=D1=EB=BE=C6=B5=EA=D0=B4=D7=D6=C2=A5968 =20 =D3=CA=B1=E0=A3=BA510403 =20= =20 =20 =20 =20 =20 =20 =20 =20 From fdrake@acm.org Thu Jul 11 23:11:14 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Jul 2002 18:11:14 -0400 Subject: [XML-SIG] minidom enhancements Message-ID: <15662.642.543908.161925@grendel.zope.com> I've just merged the changes to minidom into the trunk; this should buy us a little performance. The new xml.dom.expatbuilder module enables the buffer_text option in the CVS version of the pyexpat wrapper, which can buy quite a bit of performance if you parse documents which contain stretches of text that span many lines. I haven't enable the buffer_text option in the SAX drivers for Expat, since it does change the callbacks the content handler receives, but doing so would not change the conformance to the SAX/SAX2 specs. Users might want to try setting buffer_text to true on the parser returned by expat.ParserCreate() in ExpatParser.reset() in the xml.sax.expatreader module. Please report your experiances with this to the list; if we can safely set this, performance will be better for more users. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Thu Jul 11 23:32:44 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Jul 2002 18:32:44 -0400 Subject: [XML-SIG] Expat 1.95.4 Message-ID: <15662.1932.583815.975967@grendel.zope.com> I'm planning to release Expat 1.95.4 tomorrow. This promises to be a stable release that fixes a lot of minor bugs and includes more platform support. What I'd like to do is: - modify pyexpat.c to support Expat's recent ability to return namespace prefixes as well as namespace URIs (useful for DOM construction), - update the DOM construction code, at least for the new minidom builder, to use this to get namespace prefixes right, and - integrate Expat 1.95.4 into PyXML. Once this is done, I'd like to see another release of PyXML go out so that these new features get broader testing. I don't know what version number this release should carry. Any objections, comments, or suggestions? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tpassin@comcast.net Fri Jul 12 00:06:02 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Thu, 11 Jul 2002 19:06:02 -0400 Subject: [XML-SIG] Expat 1.95.4 References: <15662.1932.583815.975967@grendel.zope.com> Message-ID: <000d01c2292f$8725d340$fe193044@tbp1> [Fred L. Drake, Jr] >... > What I'd like to do is: > > - modify pyexpat.c to support Expat's recent ability to return > namespace prefixes as well as namespace URIs (useful for DOM > construction), > > - update the DOM construction code, at least for the new minidom > builder, to use this to get namespace prefixes right, and > > - integrate Expat 1.95.4 into PyXML. > > Once this is done, I'd like to see another release of PyXML go out so > that these new features get broader testing. I don't know what > version number this release should carry. > > Any objections, comments, or suggestions? > If there is any potential problem with compatibility - someone using the new expat with older Python code or vice-versa - would it be possible for for a program to do version checking to learn if it is using a compatible version? Cheers, Tom P From uche.ogbuji@fourthought.com Fri Jul 12 00:57:21 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 11 Jul 2002 17:57:21 -0600 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: Message from "Fred L. Drake, Jr." of "Thu, 11 Jul 2002 18:32:44 EDT." <15662.1932.583815.975967@grendel.zope.com> Message-ID: <200207112357.g6BNvL605427@localhost.localdomain> > > I'm planning to release Expat 1.95.4 tomorrow. This promises to be a > stable release that fixes a lot of minor bugs and includes more > platform support. > > What I'd like to do is: > > - modify pyexpat.c to support Expat's recent ability to return > namespace prefixes as well as namespace URIs (useful for DOM > construction), This will be great for cDomlette as well. > - update the DOM construction code, at least for the new minidom > builder, to use this to get namespace prefixes right, and > > - integrate Expat 1.95.4 into PyXML. > > Once this is done, I'd like to see another release of PyXML go out so > that these new features get broader testing. I don't know what > version number this release should carry. > > Any objections, comments, or suggestions? Your plans for PyXML sound fine. Perhaps in the process you'll end up solving this problem I have with expat 1.95*: I tried to upgrade cDomlette to use expat 1.95.2, but because this now uses autoconf, its hard for us to create a siloed version that we can ship with 4Suite. For this reasom we still use expat 1.2 for cDomlette. I don't suppose anyone has solved the problem of having a ready cross-platform code-base for expat? That would probably mean replacing the configuration params with platform #ifdefs. This would make it much easier for us to upgrade and get the most recent improvements. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From fdrake@acm.org Fri Jul 12 03:33:07 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Jul 2002 22:33:07 -0400 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: <200207112357.g6BNvL605427@localhost.localdomain> References: <15662.1932.583815.975967@grendel.zope.com> <200207112357.g6BNvL605427@localhost.localdomain> Message-ID: <15662.16355.19184.192839@grendel.zope.com> Uche Ogbuji writes: > This will be great for cDomlette as well. Glad to hear it! > I tried to upgrade cDomlette to use expat 1.95.2, but because this > now uses autoconf, its hard for us to create a siloed version that > we can ship with 4Suite. For this reasom we still use expat 1.2 > for cDomlette. Is there a problem with the way it's handled in PyXML? The recent releases have used Expat 1.95.2, and I'm not aware of any problems with that. Have I missed a bug report on PyXML? Or Python 2.3, which uses the same approach as PyXML. I know there aren't any relevant reports against Expat itself. > I don't suppose anyone has solved the problem of having a ready > cross-platform code-base for expat? That would probably mean > replacing the configuration params with platform #ifdefs. This > would make it much easier for us to upgrade and get the most recent > improvements. What platforms have you had problems with? We've seen no reports about problems related to this. Please be specific, and we can consider changing things if needed. The Expat bug tracker is on SourceForge: http://sourceforge.net/projects/expat/ -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Fri Jul 12 03:38:13 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Jul 2002 22:38:13 -0400 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: <000d01c2292f$8725d340$fe193044@tbp1> References: <15662.1932.583815.975967@grendel.zope.com> <000d01c2292f$8725d340$fe193044@tbp1> Message-ID: <15662.16661.423143.459124@grendel.zope.com> Thomas B. Passin writes: > If there is any potential problem with compatibility - someone using the new > expat with older Python code or vice-versa - would it be possible for for a > program to do version checking to learn if it is using a compatible version? Absolutely: >>> from xml.parsers import expat >>> expat.EXPAT_VERSION '1.95.2' >>> expat.version_info (1, 95, 2) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Fri Jul 12 04:27:06 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 11 Jul 2002 21:27:06 -0600 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: Message from "Fred L. Drake, Jr." of "Thu, 11 Jul 2002 22:33:07 EDT." <15662.16355.19184.192839@grendel.zope.com> Message-ID: <200207120327.g6C3R6S02199@localhost.localdomain> > > I tried to upgrade cDomlette to use expat 1.95.2, but because this > > now uses autoconf, its hard for us to create a siloed version that > > we can ship with 4Suite. For this reasom we still use expat 1.2 > > for cDomlette. > > Is there a problem with the way it's handled in PyXML? The recent > releases have used Expat 1.95.2, and I'm not aware of any problems > with that. Have I missed a bug report on PyXML? Or Python 2.3, which > uses the same approach as PyXML. I know there aren't any relevant > reports against Expat itself. Well, you caught me out: I never actually tried just copying all the files and setup code from PyXML. For some reason that never occurred to me. I was having trouble working things so it would beuild under both Win and Linux, but looking at the setup.py code in PyXML, I think it handles what I ran into. I give it a try in 4Suite tonight and report on expat/SF if I run into any problems. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From fdrake@acm.org Fri Jul 12 06:01:37 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 12 Jul 2002 01:01:37 -0400 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: <200207120327.g6C3R6S02199@localhost.localdomain> References: <15662.16355.19184.192839@grendel.zope.com> <200207120327.g6C3R6S02199@localhost.localdomain> Message-ID: <15662.25265.552422.196450@grendel.zope.com> Uche Ogbuji writes: > Well, you caught me out: I never actually tried just copying all > the files and setup code from PyXML. For some reason that never > occurred to me. I was having trouble working things so it would > beuild under both Win and Linux, but looking at the setup.py code > in PyXML, I think it handles what I ran into. "Another one bites the dust..." ;-) I'm glad this was this easy to solve, I still have to wrap up the release! ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Alexandre.Fayolle@logilab.fr Fri Jul 12 08:09:56 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Fri, 12 Jul 2002 09:09:56 +0200 Subject: [XML-SIG] fwd: Introducing pyNMS, SNMP, MIB and other tools for Python Message-ID: <20020712070956.GB18211@orion.logilab.fr> Hello, I've just received this from the python-anounce ML. The mention of POM (python object model) for XML manipulation looks like it could interest a few of us here on the XML-SIG, so I take the liberty to forward the message. I haven't looked at thepackage yet. ----- Forwarded message from Keith Dart ----- From: "Keith Dart" Organization: Prodigy Internet http://www.prodigy.com To: python-announce-list@python.org Date: Wed, 10 Jul 2002 17:32:32 GMT Subject: Introducing pyNMS, SNMP, MIB and other tools for Python The pyNMS package is a collection of Python (and some C) modules for use in network management applications. It is also useful for testing and other types of applications. The package as a whole is currently in development, and much of the top-level NMS functionality (namely, a GUI interface). But, man low-level modules are still very useful for custom management scripts. Some notworthy sub-packages and modules: SNMP -- An implementation of SNMP v1 and v2c (Manager only now.. but Agent class just needs to be filled in). SMI -- A library, based on wrapping libsmi, for parsing and accessing MIB files. Devices -- Defines SNMP Manager objects for specific devices. You can create a class that represent as device, and define which MIBs it supports. POM -- Python Object Model for XML. This is patterned after XML DOM, but is more pythonic. It also incorporates some XPath funcionality. HTML -- Utilities and classes for creating XHTML documents. This is based on the POM module. This project is being hosted on Sourceforge. Home page: http://pynms.sourceforge.net/ Looking for feedback and testers. Have a Great day, Keith Dart -- http://mail.python.org/mailman/listinfo/python-announce-list ----- End forwarded message ----- -- Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From martin@v.loewis.de Fri Jul 12 08:11:51 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 12 Jul 2002 09:11:51 +0200 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: <15662.1932.583815.975967@grendel.zope.com> References: <15662.1932.583815.975967@grendel.zope.com> Message-ID: "Fred L. Drake, Jr." writes: > - modify pyexpat.c to support Expat's recent ability to return > namespace prefixes as well as namespace URIs (useful for DOM > construction), Will you then require that all applications of pyexpat use Expat 1.95.4? If not: How do you plan to make the use of these features optional? > Once this is done, I'd like to see another release of PyXML go out so > that these new features get broader testing. I don't know what > version number this release should carry. That will be PyXML 0.8. I'll post a Call For Patches shortly. Regards, Martin From martin@v.loewis.de Fri Jul 12 08:14:05 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 12 Jul 2002 09:14:05 +0200 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: <200207112357.g6BNvL605427@localhost.localdomain> References: <200207112357.g6BNvL605427@localhost.localdomain> Message-ID: Uche Ogbuji writes: > I tried to upgrade cDomlette to use expat 1.95.2, but because this > now uses autoconf, its hard for us to create a siloed version that > we can ship with 4Suite. For this reasom we still use expat 1.2 for > cDomlette. Use of autoconf is shallow in Expat; I removed most of that for PyXML. > I don't suppose anyone has solved the problem of having a ready > cross-platform code-base for expat? I think I did, atleast when you have distutils at your service. Not sure how this will look like with 1.95.4, though. Regards, Martin From martin@v.loewis.de Fri Jul 12 08:18:34 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 12 Jul 2002 09:18:34 +0200 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: <15662.16355.19184.192839@grendel.zope.com> References: <15662.1932.583815.975967@grendel.zope.com> <200207112357.g6BNvL605427@localhost.localdomain> <15662.16355.19184.192839@grendel.zope.com> Message-ID: "Fred L. Drake, Jr." writes: > Is there a problem with the way it's handled in PyXML? The recent > releases have used Expat 1.95.2, and I'm not aware of any problems > with that. Have I missed a bug report on PyXML? Or Python 2.3, which > uses the same approach as PyXML. I know there aren't any relevant > reports against Expat itself. I made a report for Expat (although I can't find it at the moment) that Expat does not really use autoconf. That report was closed as "Won't Fix". Regards, Martin From Alexandre.Fayolle@logilab.fr Fri Jul 12 10:40:22 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Fri, 12 Jul 2002 11:40:22 +0200 Subject: [XML-SIG] is libxmltok1 used in pyxml Message-ID: <20020712094022.GM18211@orion.logilab.fr> Hello, The debian package for pyxml has a build dependency on libxmltok, which I find strange. Does someone know if I really need the library installed to build pyxml? Or is this just something left over from an old pyxml version? Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From fdrake@acm.org Fri Jul 12 12:54:51 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 12 Jul 2002 07:54:51 -0400 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: References: <15662.1932.583815.975967@grendel.zope.com> Message-ID: <15662.50059.5809.968007@grendel.zope.com> Martin v. Loewis writes: > Will you then require that all applications of pyexpat use Expat > 1.95.4? If not: How do you plan to make the use of these features > optional? I think using the "namespace triplets" feature should require both enabling namespaces as currently done, and also explicitly requesting that the prefix be reported using an attribute on the parser object, similar to buffer_text and returns_unicode. Maybe namespace_prefixes. It should only support true values for Expat 1.95.3 and newer (though 1.95.3 should be avoided for other reasons), but pyexpat.c can provide the attribute for other versions with a false value. > That will be PyXML 0.8. I'll post a Call For Patches shortly. Cool! I still need to make the changes to pyexpat.c, which I don't think I'll get to until next week. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Fri Jul 12 13:12:35 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 12 Jul 2002 08:12:35 -0400 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: References: <15662.1932.583815.975967@grendel.zope.com> <200207112357.g6BNvL605427@localhost.localdomain> <15662.16355.19184.192839@grendel.zope.com> Message-ID: <15662.51123.414193.841433@grendel.zope.com> Martin v. Loewis writes: > I made a report for Expat (although I can't find it at the moment) > that Expat does not really use autoconf. That report was closed as > "Won't Fix". It was hiding in the patch manager: http://sourceforge.net/tracker/index.php?func=detail&aid=458907&group_id=10127&atid=310127 I wasn't able to figure out exactly why I made the rejection based on a quick look at the comments, so I'll re-open it for consideration for Expat 1.95.5 since you & Uche have both had at least some (reasonable) objection to using autoconf. Uche, you probably want to visit the report and at least click on the "Monitor" button, if not provide additional information in a comment there. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Fri Jul 12 13:16:56 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 12 Jul 2002 08:16:56 -0400 Subject: [XML-SIG] is libxmltok1 used in pyxml In-Reply-To: <20020712094022.GM18211@orion.logilab.fr> References: <20020712094022.GM18211@orion.logilab.fr> Message-ID: <15662.51384.571914.914802@grendel.zope.com> Alexandre writes: > The debian package for pyxml has a build dependency on libxmltok, which > I find strange. Does someone know if I really need the library installed > to build pyxml? Or is this just something left over from an old pyxml > version? Expat used to include a library called libxmltok.a (or xmltok.dll on Windows), but that hasn't been used for a while. What version of Expat was used to build that version of PyXML? If it was Expat 1.0, 1.1, or 1.2, the dependency is right. If 1.95.x, it can be dropped. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Alexandre.Fayolle@logilab.fr Fri Jul 12 13:19:57 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Fri, 12 Jul 2002 14:19:57 +0200 Subject: [XML-SIG] is libxmltok1 used in pyxml In-Reply-To: <15662.51384.571914.914802@grendel.zope.com> References: <20020712094022.GM18211@orion.logilab.fr> <15662.51384.571914.914802@grendel.zope.com> Message-ID: <20020712121956.GO18211@orion.logilab.fr> On Fri, Jul 12, 2002 at 08:16:56AM -0400, Fred L. Drake, Jr. wrote: > > Alexandre writes: > > The debian package for pyxml has a build dependency on libxmltok, which > > I find strange. Does someone know if I really need the library installed > > to build pyxml? Or is this just something left over from an old pyxml > > version? > > Expat used to include a library called libxmltok.a (or xmltok.dll on > Windows), but that hasn't been used for a while. What version of > Expat was used to build that version of PyXML? If it was Expat 1.0, > 1.1, or 1.2, the dependency is right. If 1.95.x, it can be dropped. It's 1.95.2. Thanks for the quick answer. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From martin@v.loewis.de Fri Jul 12 17:56:34 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 12 Jul 2002 18:56:34 +0200 Subject: [XML-SIG] is libxmltok1 used in pyxml In-Reply-To: <20020712121956.GO18211@orion.logilab.fr> References: <20020712094022.GM18211@orion.logilab.fr> <15662.51384.571914.914802@grendel.zope.com> <20020712121956.GO18211@orion.logilab.fr> Message-ID: Alexandre writes: > > Expat used to include a library called libxmltok.a (or xmltok.dll on > > Windows), but that hasn't been used for a while. What version of > > Expat was used to build that version of PyXML? If it was Expat 1.0, > > 1.1, or 1.2, the dependency is right. If 1.95.x, it can be dropped. > > It's 1.95.2. > > Thanks for the quick answer. Furthermore, recent versions of PyXML don't depend on Expat at all anymore, since they bring their own Expat library. Regards, Martin From fdrake@acm.org Fri Jul 12 21:17:25 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 12 Jul 2002 16:17:25 -0400 Subject: [XML-SIG] Expat 1.95.4 in PyXML Message-ID: <15663.14677.748000.18379@grendel.zope.com> I'm ready to commit Expat 1.95.4 into the PyXML tree. All the tests pass without changing anything else, for Python versions 2.0.1, 2.1.2, 2.2.1, and 2.3/CVS. I can just check it in on the trunk, or I can stick it on a branch and merge after people have had a chance to test it with their own applications. Given the numerous comments I received on the minidom-enhancements branch, I'm inclined to think that no one looks at branches. Martin, do you have any reason for me to use a branch? Are you planning to maintain PyXML 0.7.x once 0.8 is out? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Fri Jul 12 22:05:16 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 12 Jul 2002 23:05:16 +0200 Subject: [XML-SIG] Expat 1.95.4 in PyXML In-Reply-To: <15663.14677.748000.18379@grendel.zope.com> References: <15663.14677.748000.18379@grendel.zope.com> Message-ID: "Fred L. Drake, Jr." writes: > Martin, do you have any reason for me to use a branch? Please don't use branches unless you have code that is known not to work properly; the PyXML mainline is for the evolution of the code base. IOW, feel free to commit Expat to the mainline. > Are you planning to maintain PyXML 0.7.x once 0.8 is out? There is a branch available for further 0.7 releases. Unless somebody presents a specific requirement for another 0.7 release, there won't be any, though. One possible reason would be that a serious bug is found, and there is a Python 1.5 user who demands to get the fix in a released version. Regards, Martin From fdrake@acm.org Sat Jul 13 03:52:05 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 12 Jul 2002 22:52:05 -0400 Subject: [XML-SIG] Expat 1.95.4 in PyXML In-Reply-To: References: <15663.14677.748000.18379@grendel.zope.com> Message-ID: <15663.38357.619081.561183@grendel.zope.com> Martin v. Loewis writes: > Please don't use branches unless you have code that is known not to > work properly; the PyXML mainline is for the evolution of the code > base. Ah, that's the way it should be! ;-) It's in, in case anybody missed the check-in a few hours ago. Any bugs introduced by either the minidom changes or the Expat changes should be assigned to me. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From matt_g_@hotmail.com Sat Jul 13 05:17:50 2002 From: matt_g_@hotmail.com (Matt G.) Date: Sat, 13 Jul 2002 04:17:50 +0000 Subject: [XML-SIG] Expat 1.95.4 Message-ID: >From: "Fred L. Drake, Jr." >To: "Thomas B. Passin" >CC: XML-SIG >Subject: Re: [XML-SIG] Expat 1.95.4 >Date: Thu, 11 Jul 2002 22:38:13 -0400 > > >Thomas B. Passin writes: > > If there is any potential problem with compatibility - someone using >the new > > expat with older Python code or vice-versa - would it be possible for >for a > > program to do version checking to learn if it is using a compatible >version? > >Absolutely: > > >>> from xml.parsers import expat > >>> expat.EXPAT_VERSION >'1.95.2' > >>> expat.version_info >(1, 95, 2) If you're introducing incompatibilities, shouldn't you increment the major rev? Non-incompatible new functionality should result in an increment of the minor revision - not the patch rev. Otherwise, there's no systematic way to determine compatibility. ...or is there some sort of completely different versioning system used for Python modules/packages? I have a hard time imagining how the problem could be solved any better than by the 'COMPATIBILITY.FEATURES.FIXES' scheme, though. BTW, it would be nice to see some shared-library style scheme, to allow programs to use the most up-to-date of the compatible installed versions of a given .py. I was recently frustrated to see that distutils doesn't really seem to support this model. Matt Gruenke _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From fdrake@acm.org Sat Jul 13 05:34:38 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Sat, 13 Jul 2002 00:34:38 -0400 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: References: Message-ID: <15663.44510.745942.637734@grendel.zope.com> Matt G. writes: > If you're introducing incompatibilities, shouldn't you increment the major > rev? Non-incompatible new functionality should result in an increment of > the minor revision - not the patch rev. Otherwise, there's no systematic > way to determine compatibility. Er, I don't think I am. My intent is to be cautious in case anything crept in by accident. > ..or is there some sort of completely different versioning system > used for Python modules/packages? I have a hard time imagining how > the problem could be solved any better than by the > 'COMPATIBILITY.FEATURES.FIXES' scheme, though. I won't argue that, but there's also a substantial group of projects that uses X.high-numbers.Z as the lead-in to X+1.0.0 (such as Expat), and I don't expect that to change. There are a lot of social forces at work when people discuss versioning systems, as the Distutils-SIG determined early on. Few people are interested in having someone recommend a versioning scheme to them, no matter how rational and useful. > BTW, it would be nice to see some shared-library style scheme, to > allow programs to use the most up-to-date of the compatible > installed versions of a given .py. I was recently frustrated to > see that distutils doesn't really seem to support this model. I'd be happy to see something along those lines added to distutils and the coding style of Python programmers, but I don't have the time to contribute to that myself. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Sat Jul 13 15:02:50 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sat, 13 Jul 2002 08:02:50 -0600 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: Message from "Fred L. Drake, Jr." of "Fri, 12 Jul 2002 08:12:35 EDT." <15662.51123.414193.841433@grendel.zope.com> Message-ID: > > Martin v. Loewis writes: > > I made a report for Expat (although I can't find it at the moment) > > that Expat does not really use autoconf. That report was closed as > > "Won't Fix". > > It was hiding in the patch manager: > > http://sourceforge.net/tracker/index.php?func=detail&aid=458907&group_id=10127&atid=310127 > > I wasn't able to figure out exactly why I made the rejection based on > a quick look at the comments, so I'll re-open it for consideration for > Expat 1.95.5 since you & Uche have both had at least some (reasonable) > objection to using autoconf. > > Uche, you probably want to visit the report and at least click on the > "Monitor" button, if not provide additional information in a comment > there. Thanks, but I'm no longer as interested :-) Last night I copied over the mechanism in PyXML for setting up expat, and after some tweaking, I got it working. I now have 1.95.4 support for cDomlette checked in on a 4Suite branch, though I haven't changed cDomlette to use the new namespace feature yet (will probably wait until after 0.12.0 goes gold). -- From fdrake@acm.org Sat Jul 13 16:48:14 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Sat, 13 Jul 2002 11:48:14 -0400 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: References: <15662.51123.414193.841433@grendel.zope.com> Message-ID: <15664.19390.880836.331900@grendel.zope.com> Uche Ogbuji writes: > Last night I copied over the mechanism in PyXML for setting up > expat, and after some tweaking, I got it working. I now have > 1.95.4 support for cDomlette checked in on a 4Suite branch, though > I haven't changed cDomlette to use the new namespace feature yet > (will probably wait until after 0.12.0 goes gold). See, life is easy in the Python community! ;-) The "new" (== "now working") namespace prefix support is my next task for pyexpat as well. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Sun Jul 14 00:04:12 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sat, 13 Jul 2002 17:04:12 -0600 Subject: [XML-SIG] Expat 1.95.4 In-Reply-To: Message from "Fred L. Drake, Jr." of "Sat, 13 Jul 2002 11:48:14 EDT." <15664.19390.880836.331900@grendel.zope.com> Message-ID: > > Uche Ogbuji writes: > > Last night I copied over the mechanism in PyXML for setting up > > expat, and after some tweaking, I got it working. I now have > > 1.95.4 support for cDomlette checked in on a 4Suite branch, though > > I haven't changed cDomlette to use the new namespace feature yet > > (will probably wait until after 0.12.0 goes gold). > > See, life is easy in the Python community! ;-) Well, there's never a doubt about that. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From noreply@sourceforge.net Sun Jul 14 01:45:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jul 2002 17:45:24 -0700 Subject: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g Message-ID: Bugs item #581175, was opened at 2002-07-14 00:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=581175&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Uche Ogbuji (uche) Assigned to: Lars Marius Garshol (larsga) Summary: Bad bangpath for scripts on install (e.g Initial Comment: After installing Python locally (with ./configure --prefix=$HOME) and installing PyXML, the scripts such as xmlproc_parse were installed, as expected, in $HOME/bin. However, the bangpath headers in these scripts for some reason are #/usr/local/bin/python Which does not exist, causing them to fail. This is on Debian sid Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=581175&group_id=6473 From uche.ogbuji@fourthought.com Sun Jul 14 06:13:36 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 13 Jul 2002 23:13:36 -0600 Subject: [XML-SIG] 4XSLT focus on docbook stylesheets (and fruit thereof) Message-ID: <1026623617.9443.215.camel@malatesta> --=-V0cjoJfkKo2UZu2/tsVQ Content-Type: text/plain Content-Transfer-Encoding: 7bit Thanks to Mike Brown's sleuthing, we realized that the things that was killing 4XSLT's performance in docbook stylesheet was key preparation. He claimed it was 99% of the time, and I thought he was joking. Well, here's what happened as I worked on the problem: The attached script is a little timing script I used for keeping track of progress. At the outset, I got the following: time for 10 runs: 2624.12773895 seconds time per run 262.412773895 seconds After updating the XSLT matching logic stuff to take advantage of the shortcuts available in the XPattern processor: time for 10 runs: 837.315540075 seconds time per run 83.7315540075 seconds Which is noce, but I knew I could do better. Turns out that was understating it. After the big move: making key computation lazy until a key is requested in each doc's context, we go all the way down to: time for 10 runs: 17.4807579517 seconds time per run 1.74807579517 seconds Guys, I think the docbook ghoul is put to bed. :-) I've also gone through the archives and fixed every bug that I thought might affect docbook XSL processing. To try it, use the 4Suite CVS HOWTO http://4suite.org/docs/4SuiteCVS.xml but just use the branch EXPAT-1-95-4-branch Which inclues a few docbook fixes (in addition to updating the expat version) Feedback this week would be especially valuable as we're planning on a final 0.12.0 alpha release on Friday. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html --=-V0cjoJfkKo2UZu2/tsVQ Content-Disposition: attachment; filename=db-keys.py Content-Transfer-Encoding: quoted-printable Content-Type: text/x-python; name=db-keys.py; charset=ISO-8859-1 #The keys from docbook/xslt, boiled down by Mike Brown. #See http://lists.fourthought.com/pipermail/4suite-dev/2002-July/000293.htm= l XSLT =3D """ ]> %s """ DOC =3D """ An Example Book =20 Your first name Your surname
foo@example.com
 =20 2000 Copyright string here =20 If your book has an abstract then it should go here. =20 Preface =20 Your book may have a preface, in which case it should be plac= ed here. =20 My first chapter =20 This is the first chapter in my book. =20 My first section =20 This is the first section in my book. =20 %s """ MIDDLE =3D """
My first section =20 This is the first section in my book.
"""*50 import time from Ft.Xml.Xslt import Processor from Ft.Xml import InputSource start =3D time.time() from Ft.Lib import Uri PATH =3D Uri.OsPathToUri('.', attemptAbsolute=3D1) N =3D 1 for i in range(N): print ".", processor =3D Processor.Processor() transform =3D InputSource.DefaultFactory.fromString(XSLT%"", PAT= H+"db.xslt") processor.appendStylesheet(transform) source =3D InputSource.DefaultFactory.fromString(DOC%MIDDLE, PATH+"doc.= xml") print ".", processor.run(source) processor =3D Processor.Processor() transform =3D InputSource.DefaultFactory.fromString(XSLT%"", "http://spam.com/identity= .xslt") processor.appendStylesheet(transform) source =3D InputSource.DefaultFactory.fromString(DOC%MIDDLE, "http://spam.c= om/doc1.xml") output =3D processor.run(source) end =3D time.time() print print "time for", N, "runs:", end-start, "seconds" print "time per run", (end-start)/N, "seconds" print "dump of keys:" print output print --=-V0cjoJfkKo2UZu2/tsVQ-- From Juergen Hermann" > However, the bangpath headers in these scripts for some reason are > > #/usr/local/bin/python > > Which does not exist, causing them to fail. I have a little distutils extension that _generates_ script stubs, instead of distutils copying them. This has the added benefit that it creates .cmd files on windows. Just if anyone's interested... Ciao, J=FCrgen From martin@v.loewis.de Sun Jul 14 09:09:42 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 14 Jul 2002 10:09:42 +0200 Subject: [XML-SIG] 4XSLT focus on docbook stylesheets (and fruit thereof) In-Reply-To: <1026623617.9443.215.camel@malatesta> References: <1026623617.9443.215.camel@malatesta> Message-ID: Uche Ogbuji writes: > time for 10 runs: 2624.12773895 seconds > time per run 262.412773895 seconds [...] > time for 10 runs: 17.4807579517 seconds > time per run 1.74807579517 seconds > > > Guys, I think the docbook ghoul is put to bed. :-) That's impressive! Martin From martin@v.loewis.de Sun Jul 14 09:47:24 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 14 Jul 2002 10:47:24 +0200 Subject: Fwd: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g In-Reply-To: References: Message-ID: "Juergen Hermann" writes: > > Which does not exist, causing them to fail. > > I have a little distutils extension that _generates_ script stubs, > instead of distutils copying them. This has the added benefit that it > creates .cmd files on windows. I'd be interested for a different project (Fnorb), but in this case, I think it is unnecessary. There must be a user error of some kind, since the distributed scripts had been using /usr/bin/python. Since the user sees /usr/local/bin/python in the installed scripts, it is a clear sign that distutils had updated them correctly to point to sys.executable. So it appears that the user had been using a python executable that has a sys.executable of /usr/local/bin/python. I don't understand why he then says that /usr/local/bin/python is not present. Regards, Martin From Juergen Hermann" Message-ID: On 14 Jul 2002 10:47:24 +0200, Martin v. Loewis wrote: >> I have a little distutils extension that _generates_ script stubs, >> instead of distutils copying them. This has the added benefit that it= >> creates .cmd files on windows. > >I'd be interested for a different project (Fnorb), ... See http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/moin/dist/setup.py? rev=3D1.20&content-type=3Dtext/vnd.viewcvs-markup It's also part of Twisted and RoundUp. >So it appears that the user had been using a python executable that >has a sys.executable of /usr/local/bin/python. I don't understand why >he then says that /usr/local/bin/python is not present. Maybe compiled for that place and later installed in /usr or something (not the only broken installation of Python out there ;). Ciao, J=FCrgen From martin@v.loewis.de Sun Jul 14 14:41:20 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 14 Jul 2002 15:41:20 +0200 Subject: Fwd: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g In-Reply-To: References: Message-ID: "Juergen Hermann" writes: > See http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/moin/dist/setup.py? > rev=1.20&content-type=text/vnd.viewcvs-markup > > It's also part of Twisted and RoundUp. That won't work together with bdist_wininst, right? Since the scripts will have the hard-coded Python executable path from build time, which might be different at installation time. Regards, Martin From tpassin@comcast.net Sun Jul 14 16:04:14 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Sun, 14 Jul 2002 11:04:14 -0400 Subject: [XML-SIG] 4XSLT focus on docbook stylesheets (and fruit thereof) References: <1026623617.9443.215.camel@malatesta> Message-ID: <000b01c22b47$b7a0db40$fe193044@tbp1> [Uche Ogbuji] > Which is noce, but I knew I could do better. Turns out that was > understating it. After the big move: making key computation lazy until > a key is requested in each doc's context, we go all the way down to: > > time for 10 runs: 17.4807579517 seconds > time per run 1.74807579517 seconds > > Outstanding! Any ideas how that compares with the big guns (Xalan, msxml, saxon)? Cheers, Tom P From uche.ogbuji@fourthought.com Sun Jul 14 16:39:11 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sun, 14 Jul 2002 09:39:11 -0600 Subject: [XML-SIG] minidom enhancements In-Reply-To: Message from "Fred L. Drake, Jr." of "Thu, 11 Jul 2002 18:11:14 EDT." <15662.642.543908.161925@grendel.zope.com> Message-ID: > > I've just merged the changes to minidom into the trunk; this should > buy us a little performance. And cause some problems ;-) It looks as if the class CharacterData no longer has an __init__. Nor do the classes that derive from it. This means that the usage Text("spam") Comment("eggs") Now blows up. Which, I think is bad. We construct nodes that way in 4Suite's minidom wrapper, and I can modify the cases, but I dislike the change. I think it removes a very useful and Pythonic paradigm. Also, who knows how much code it would break? I know we've been guilty of changing APIs in 4Suite. I guess I'm reaping my whirlwind :-) Is there a good reason for this, though? Should we expect any more API surprises ;-) -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From martin@v.loewis.de Sun Jul 14 17:02:24 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 14 Jul 2002 18:02:24 +0200 Subject: [XML-SIG] minidom enhancements In-Reply-To: References: Message-ID: Uche Ogbuji writes: > Which, I think is bad. We construct nodes that way in 4Suite's > minidom wrapper, and I can modify the cases, but I dislike the > change. I think it removes a very useful and Pythonic paradigm. > Also, who knows how much code it would break? In defense of the change: you are not supposed to know what the names of the implementation classes are; the Document is a factory. This is a useful property of the DOM, and applications are encouraged to use that. So if the paradigm you are referring to is "instances are created by calling the class", so I'd dispute the usefulness of the paradigm. That said, I see no particular reason why the original behaviour couldn't be restored. Fred? Regards, Martin From uche.ogbuji@fourthought.com Sun Jul 14 18:11:14 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 14 Jul 2002 11:11:14 -0600 Subject: [XML-SIG] minidom enhancements In-Reply-To: References: Message-ID: <1026666676.15214.103.camel@malatesta> On Sun, 2002-07-14 at 10:02, Martin v. Loewis wrote: > Uche Ogbuji writes: > > > Which, I think is bad. We construct nodes that way in 4Suite's > > minidom wrapper, and I can modify the cases, but I dislike the > > change. I think it removes a very useful and Pythonic paradigm. > > Also, who knows how much code it would break? > > In defense of the change: you are not supposed to know what the names > of the implementation classes are; the Document is a factory. This is > a useful property of the DOM, and applications are encouraged to use > that. > > So if the paradigm you are referring to is "instances are created by > calling the class", so I'd dispute the usefulness of the paradigm. Yes, the DOM abstracts this, but I thought the intent of the minidom was to be more Pythonic. Just as JDOM allows you to construct DOM classes directly, I thought minidom had the same intent. If not, then disregard: we'll just adjust our wrapper API. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From uche.ogbuji@fourthought.com Sun Jul 14 19:38:17 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sun, 14 Jul 2002 12:38:17 -0600 Subject: Fwd: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g In-Reply-To: Message from martin@v.loewis.de (Martin v. Loewis) of "14 Jul 2002 10:47:24 +0200." Message-ID: > "Juergen Hermann" writes: > > > > Which does not exist, causing them to fail. > > > > I have a little distutils extension that _generates_ script stubs, > > instead of distutils copying them. This has the added benefit that it > > creates .cmd files on windows. > > I'd be interested for a different project (Fnorb), but in this case, I > think it is unnecessary. There must be a user error of some kind, Perhaps, but it certainly isn't what you say. > since the distributed scripts had been using /usr/bin/python. Since > the user sees /usr/local/bin/python in the installed scripts, it is a > clear sign that distutils had updated them correctly to point to > sys.executable. No. It's merely a clear sign that distutils has modified them. Unfortunately, it has done so incorrectly. > So it appears that the user had been using a python executable that > has a sys.executable of /usr/local/bin/python. This is not true. > I don't understand why > he then says that /usr/local/bin/python is not present. Because it isn't :-) -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From uche.ogbuji@fourthought.com Sun Jul 14 19:44:32 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sun, 14 Jul 2002 12:44:32 -0600 Subject: [XML-SIG] 4XSLT focus on docbook stylesheets (and fruit thereof) In-Reply-To: Message from "Thomas B. Passin" of "Sun, 14 Jul 2002 11:04:14 EDT." <000b01c22b47$b7a0db40$fe193044@tbp1> Message-ID: > [Uche Ogbuji] > > Which is noce, but I knew I could do better. Turns out that was > > understating it. After the big move: making key computation lazy until > > a key is requested in each doc's context, we go all the way down to: > > > > time for 10 runs: 17.4807579517 seconds > > time per run 1.74807579517 seconds > > > > > > Outstanding! Any ideas how that compares with the big guns (Xalan, msxml, > saxon)? I can't do it all on my own. I'll be happy for contributed (and careful) benchmarks, so that we can document to users what to expect. However, I must say that I don't expect to do any more major optimization passes on the current 4XSLT. Given its fundamental architecture, we're approaching the point of diminishing returns. We have plans for a complete re-architecture in 4Suite post 1.0 (which I think is actually in sight now), after 4XPath and 4XSLT have been moved into PyXML. These are quite mature, conformant, have extremely strong Python integration, and after recent work by Mike Brown, Jeremy Kloth and me, have respectable performance, although I don't expect it to outperform msxml or libxslt for obvious reasons. I think this makes them great cantidates for the PyXML built-ins. We have ideas that would make the next generation compete with the C XSLT processors, but that's a different story. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From martin@v.loewis.de Sun Jul 14 20:40:46 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 14 Jul 2002 21:40:46 +0200 Subject: [XML-SIG] minidom enhancements In-Reply-To: <1026666676.15214.103.camel@malatesta> References: <1026666676.15214.103.camel@malatesta> Message-ID: Uche Ogbuji writes: > Yes, the DOM abstracts this, but I thought the intent of the minidom was > to be more Pythonic. Just as JDOM allows you to construct DOM classes > directly, I thought minidom had the same intent. It's not clear to me what the intent of minidom is, beyond being a DOM Core implementation. At one point, there was an attempt to be "minimal" in some sense, take short-cuts in the implementation, and put undocumented restrictions on the applications. That hasn't worked out. These days, I view the idea of the Python DOM as being more Pythonic than the DOM itself. However, those extensions are useful only if documented, so if there was a documentation (in the standard Python documentation) that grants some Pythonic API, and breaking that API is not acceptable. This appears not to be the case of the minidom implementation classes. > If not, then disregard: we'll just adjust our wrapper API. I disregard not that easily. Even undocumented aspects should not be broken lightly; that you have been using the constructors is enough force to question the change. Unless Fred brings up a good reason to have a parameter-less CharacterData __init__, I will restore the original one. Regards, Martin From martin@v.loewis.de Sun Jul 14 20:48:25 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 14 Jul 2002 21:48:25 +0200 Subject: Fwd: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g In-Reply-To: References: Message-ID: Uche Ogbuji writes: > No. It's merely a clear sign that distutils has modified them. > Unfortunately, it has done so incorrectly. It is also a sign that there is something broken in the Python installation; distutils couldn't possibly make this value up. So maybe Juergen's theory is right that the installation was configured for a different directory than it is installed into. Regards, Martin From uche.ogbuji@fourthought.com Sun Jul 14 21:13:32 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 14 Jul 2002 14:13:32 -0600 Subject: Fwd: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g In-Reply-To: References: Message-ID: <1026677614.15216.320.camel@malatesta> On Sun, 2002-07-14 at 13:48, Martin v. Loewis wrote: > Uche Ogbuji writes: > > > No. It's merely a clear sign that distutils has modified them. > > Unfortunately, it has done so incorrectly. > > It is also a sign that there is something broken in the Python > installation; distutils couldn't possibly make this value up. > > So maybe Juergen's theory is right that the installation was > configured for a different directory than it is installed into. No. The --prefix I used on ./configure is exactly where it remains. I'll trace the problem through distutils, as you suggest. The reason I didn't just do this before filing the bug report was that I didn't want to spend too much time on this problem, but I think it's raised enough discussion that I should help bring it to closure. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From andrew.ittner@usa.net Mon Jul 15 06:21:26 2002 From: andrew.ittner@usa.net (Andrew Ittner) Date: Sun, 14 Jul 2002 22:21:26 -0700 Subject: [XML-SIG] Problem with 4xslt in Python on Windows Message-ID: <000101c22bbf$7754f6c0$7b7ba8c0@attbi.com> Caution: newbie alert. I have 'halls.xsl' which has two : All three XSL files, and the Hall.xml they reference, are in the same directory: D:\Internet\_XML_. Using 4xslt from the Windows 98 command line generates the HTML output perfectly. <4xslt -o..\_SITE_\halloffame.html -DTypeHall=Fame hall.xml halls.xsl> Running the same files through the following Python script fails: from Ft.Xml.Xslt import Processor from Ft.Xml import InputSource oProcessor = Processor.Processor() oStyle = InputSource.DefaultFactory.fromStream(open('D:\Internet\_XML_\halls.xsl', 'r'), 'D:\Internet\_XML_\\') oProcessor.appendStylesheet(oStyle) fX = open('D:\X.html', 'w') sResult = oProcessor.run(InputSource.DefaultFactory.fromStream(open('D:\Internet\_XML_ \Hall.xml', 'r'), 'D:\Internet\_XML_\\'), 1, None, '', fX) fX.close() print "sResult=" + str(len(sResult)) The error I get is: File "C:\PYTHON22\Lib\site-packages\Ft\Xml\Xslt\StylesheetHandler.py", line 533, in _combine_stylesheet raise XsltException(Error.INCLUDE_NOT_FOUND, href, self._input_source.uri) XsltException: Unable to open imported or included stylesheet "listofcompanies.xsl", using base URI "D:\", or all base URIs in the include PATH The line in my script causing the error starts with "oStyle=". On the line where I make oStyle, I've tried setting the fromStream's 2nd argument, a valid URI, to the following: D:\Internet\_XML_\ file://D:/Internet/_XML_/halls.xsl file://localhost/D:/Internet/_XML_/halls.xsl http://tephyr8.home.attbi.com/listofcompanies.xsl Only the last one works (when I post the included XSL files to it). What must I do to make the Python script see the XSL included files on my local drive? Since the 4xslt command-line works fine with the exact same files in the exact same location, I assume I'm missing something, but I can't figure what. Thanks, Andrew Ittner http://zip.to/tephyr From mike@skew.org Mon Jul 15 06:37:47 2002 From: mike@skew.org (Mike Brown) Date: Sun, 14 Jul 2002 23:37:47 -0600 (MDT) Subject: [XML-SIG] Problem with 4xslt in Python on Windows In-Reply-To: <000101c22bbf$7754f6c0$7b7ba8c0@attbi.com> "from Andrew Ittner at Jul 14, 2002 10:21:26 pm" Message-ID: <200207150537.g6F5blIM057811@chilled.skew.org> Andrew Ittner wrote: > XsltException: Unable to open imported or included stylesheet > "listofcompanies.xsl", using base URI "D:\", or all base URIs in the include > PATH 'D:\\Internet\\_XML_\\' is not a URI, it is a local filesystem path. You can make it into a URI by simply running the string through Ft.Lib.Uri.OsPathToUri(). You should end up with something like 'file:///D|/Internet/_XML_'. Use that as the 2nd argument to fromStream(). - Mike ____________________________________________________________________________ mike j. brown | xml/xslt: http://skew.org/xml/ denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/ From mike@skew.org Mon Jul 15 08:07:07 2002 From: mike@skew.org (Mike Brown) Date: Mon, 15 Jul 2002 01:07:07 -0600 (MDT) Subject: [XML-SIG] 4XSLT focus on docbook stylesheets (and fruit thereof) In-Reply-To: <000b01c22b47$b7a0db40$fe193044@tbp1> "from Thomas B. Passin at Jul 14, 2002 11:04:14 am" Message-ID: <200207150707.g6F778HB058326@chilled.skew.org> Thomas B. Passin wrote: > Outstanding! Any ideas how that compares with the big guns (Xalan, msxml, > saxon)? I just ran some tests against one of those guns. The contenders: 4xslt 0.12.0a3(*), incorporating expat-1.95.2, under Python 2.2.1 vs Saxon 6.5.2, with its modified Aelfred parser, running under JDK 1.1.8. (*) what will become alpha 3, rather The platform: Intel PIII-933, 256 MB RAM, FreeBSD 4.6-STABLE. The test: Transforming a 450-line, 25K Simplified DocBook article to HTML, using DocBook XSL 1.50. ============================================================================= Battle #1: The simplest test: command-line, with all the overhead of the JVM and Python interpreter starting up to throw off the results. % /usr/bin/time -h 4xslt QuickStart.xml docbook-xsl-1.50.0/html/docbook.xsl > out.html 13.63s real 12.95s user 0.39s sys % /usr/bin/time -h java com.icl.saxon.StyleSheet QuickStart.xml docbook-xsl-1.50.0/html/docbook.xsl > out2.html 22.80s real 21.61s user 0.22s sys Outcome: 4xslt finishes about 67% faster than Saxon ============================================================================= Battle #2: A proper test: timing the stylesheet preparation and transformation separately, from code. % cat 4x.py import time from Ft.Xml.Xslt import Processor from Ft.Xml import InputSource from Ft.Lib import Uri processor = Processor.Processor() source = InputSource.DefaultFactory.fromUri(Uri.OsPathToUri('/home/mike/xml/test/QuickStart.xml')) transform = InputSource.DefaultFactory.fromUri(Uri.OsPathToUri('/home/mike/xml/test/docbook-xsl-1.50.0/html/docbook.xsl')) t0 = time.time() processor.appendStylesheet(transform) t1 = time.time() print "stylesheet preparation: %ss" % str(t1 - t0) t0 = time.time() result = processor.run(source) t1 = time.time() print "transformation: %ss" % str(t1 - t0) % python 4x.py stylesheet preparation: 6.11614501476s transformation: 6.85079503059s % cat XsltTest.java import javax.xml.transform.*; import javax.xml.transform.stream.*; import java.io.BufferedOutputStream; import java.io.ByteArrayOutputStream; public class XsltTest { public static void main(String argv[]) throws TransformerException, TransformerConfigurationException { long t0,t1; String sourceID = argv[0]; String xslID = argv[1]; t0 = System.currentTimeMillis(); TransformerFactory tfactory = TransformerFactory.newInstance(); Transformer transformer = tfactory.newTransformer(new StreamSource(xslID)); t1 = System.currentTimeMillis(); System.out.println("stylesheet preparation: " + ((t1 - t0)/1000.000) + "s"); t0 = System.currentTimeMillis(); BufferedOutputStream output = new BufferedOutputStream(new ByteArrayOutputStream()); transformer.transform(new StreamSource(sourceID), new StreamResult(output)); t1 = System.currentTimeMillis(); System.out.println("transformation: " + ((t1 - t0)/1000.000) + "s"); } } % javac XsltTest.java % java XsltTest QuickStart.xml docbook-xsl-1.50.0/html/docbook.xsl stylesheet preparation: 11.307s transformation: 10.995s Outcome: 4xslt about 85% faster than Saxon at stylesheet preparation, and 4xslt about 60% faster than Saxon at transformation. ============================================================================= If anyone wants the QuickStart.xml that I was using, or wants to demand a rematch with Saxon 7 or DocBook XSL 1.52.2 or whatever, or offer constructive criticism to make these tests better, please drop me a line, or run better tests yourself :) - Mike ____________________________________________________________________________ mike j. brown | xml/xslt: http://skew.org/xml/ denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/ From mike@skew.org Mon Jul 15 08:23:56 2002 From: mike@skew.org (Mike Brown) Date: Mon, 15 Jul 2002 01:23:56 -0600 (MDT) Subject: [XML-SIG] 4XSLT focus on docbook stylesheets (and fruit thereof) In-Reply-To: <200207150707.g6F778HB058326@chilled.skew.org> "from Mike Brown at Jul 15, 2002 01:07:07 am" Message-ID: <200207150723.g6F7Nuu4058405@chilled.skew.org> I wrote: > 4xslt 0.12.0a3(*), incorporating expat-1.95.2, under Python 2.2.1 Sorry, I meant 1.95.4 or whatever the new branch is. From uche.ogbuji@fourthought.com Mon Jul 15 08:32:20 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 15 Jul 2002 01:32:20 -0600 Subject: [XML-SIG] 4XSLT focus on docbook stylesheets (and fruit thereof) In-Reply-To: Message from Mike Brown of "Mon, 15 Jul 2002 01:07:07 MDT." <200207150707.g6F778HB058326@chilled.skew.org> Message-ID: > Thomas B. Passin wrote: > > Outstanding! Any ideas how that compares with the big guns (Xalan, msxml, > > saxon)? > > I just ran some tests against one of those guns. > > The contenders: > > 4xslt 0.12.0a3(*), incorporating expat-1.95.2, under Python 2.2.1 > vs > Saxon 6.5.2, with its modified Aelfred parser, running under JDK 1.1.8. > > (*) what will become alpha 3, rather > > The platform: > > Intel PIII-933, 256 MB RAM, FreeBSD 4.6-STABLE. > > The test: > > Transforming a 450-line, 25K Simplified DocBook article to HTML, > using DocBook XSL 1.50. [SNIP] > Battle #1: The simplest test: command-line, with all the overhead of > the JVM and Python interpreter starting up to throw off the results. [SNIP] > Outcome: 4xslt finishes about 67% faster than Saxon [SNIP] > Battle #2: A proper test: timing the stylesheet preparation and > transformation separately, from code. [SNIP] > Outcome: 4xslt about 85% faster than Saxon at stylesheet preparation, > and 4xslt about 60% faster than Saxon at transformation. Thanks, Mike. I did rather suspected that we would equal or beat the Java processors at this point. I expect we'll still get taken by the C processors, but hey! Ya never know. I really appreciate your doing this, BTW. You'd better believe I'll be quoting this message with some frequency :-) -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From noreply@sourceforge.net Mon Jul 15 10:21:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jul 2002 02:21:01 -0700 Subject: [XML-SIG] [ pyxml-Bugs-581601 ] broken install on unix Message-ID: Bugs item #581601, was opened at 2002-07-15 02:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=581601&group_id=6473 Category: 4Suite Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: broken install on unix Initial Comment: Installation order is -Python 2.2.1 - PyXML 0.7.1 - 4Suite 0.11.1 The install procedure via python setup.py install does not install the files in <4Suite-0.11.1>/build/lib.irix64-6.5-2.2. Therefore the 4xslt-script runs into trouble if it is used. As the original pyxml-files resides always there, the Ft/Lib isn't used at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=581601&group_id=6473 From noreply@sourceforge.net Mon Jul 15 10:32:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 15 Jul 2002 02:32:51 -0700 Subject: [XML-SIG] [ pyxml-Bugs-581609 ] keyerror on appendStylesheetUri() Message-ID: Bugs item #581609, was opened at 2002-07-15 02:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=581609&group_id=6473 Category: 4Suite Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: keyerror on appendStylesheetUri() Initial Comment: Software used is: - Python 2.2.1 - PyXML 0.7.1 - 4Suite 0.11.1 After manual updating the installation (see broken install on unix), I checked an example from "Python & XML" Chapter 6, pp.146. Python 2.2.1 (#7, Jul 15 2002, 10:12:28) [C] on irix-n32 Type "help", "copyright", "credits" or "license" for more information. >>> from xml.xslt.Processor import Processor >>> xmlp = Processor() >>> xmlp.appendStylesheetUri('koord.xsl') Traceback (most recent call last): File "", line 1, in ? File "/opt/python/lib/python2.2/site-packages/_xmlplus/xslt/Processor.py", line 101, in appendStylesheetUri sty = self._styReader.fromUri(styleSheetUri, baseUri) File "/opt/python/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 579, in fromUri ownerDoc, stripElements) File "/opt/python/lib/python2.2/site-packages/Ft/Lib/ReaderBase.py", line 76, in fromUri rt = self.fromStream(stream, newBaseUri, ownerDoc, stripElements) File "/opt/python/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 622, in fromStream sheet.setup() File "/opt/python/lib/python2.2/site-packages/_xmlplus/xslt/Stylesheet.py", line 140, in setup self._setupChildNodes() File "/opt/python/lib/python2.2/site-packages/_xmlplus/xslt/Stylesheet.py", line 183, in _setupChildNodes curr_node.setup() File "/opt/python/lib/python2.2/site-packages/_xmlplus/xslt/TemplateElement.py", line 46, in setup namespaces=self._nss File "/opt/python/lib/python2.2/site-packages/_xmlplus/xpath/Util.py", line 83, in ExpandQName split_name = (nss[prefix], local) KeyError >>> The value return by xml.dom.ext.SplitQName(qname) isn't a string as expected. The return value is None. Therefore the if construct should be if prefix and prefix != '': After this change the example executes as expected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=581609&group_id=6473 From Alexandre.Fayolle@logilab.fr Mon Jul 15 12:40:39 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Mon, 15 Jul 2002 13:40:39 +0200 Subject: [XML-SIG] DOMImplementation.createDocumentType Message-ID: <20020715114039.GE28468@orion.logilab.fr> The DOMImplementation.createDocumentType is not documented in the python dom mapping (http://www.python.org/doc/current/lib/dom-implementation-objects.html). In 4DOM, I can pass None as the publicId argument, and this is done by xml.dom.ext.readerSax2.XmlDomGenerator. In cDomlette (from CVS), using None raises an exception. The question is: what's the right way of doing things. Is it OK to change XmlDomGenerator to use an empty string, or would this break existing code? Or should cDomlette be enhanced to accept None as the publicId? Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From tpassin@comcast.net Mon Jul 15 13:04:15 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Mon, 15 Jul 2002 08:04:15 -0400 Subject: [XML-SIG] Problem with 4xslt in Python on Windows References: <000101c22bbf$7754f6c0$7b7ba8c0@attbi.com> Message-ID: <001801c22bf7$bdaf1640$fe193044@tbp1> [Andrew Ittner] > On the line where I make oStyle, I've tried setting the fromStream's 2nd > argument, a valid URI, to the following: > D:\Internet\_XML_\ > file://D:/Internet/_XML_/halls.xsl > file://localhost/D:/Internet/_XML_/halls.xsl > http://tephyr8.home.attbi.com/listofcompanies.xsl > > Only the last one works (when I post the included XSL files to it). > > What must I do to make the Python script see the XSL included files on my > local drive? Since the 4xslt command-line works fine with the exact same > files in the exact same location, I assume I'm missing something, but I > can't figure what. > Chances are you have to use the correct url syntax for a file: (1) file:///d:\Internet\.............. If that does not work, try this incorrect version: (2) file:/d:\Internet\.............. The double slash version is the one that is least likely to work, because it is both incorrect by the RFC and also never came into (incorrect) use. (1) is technically correct according to the RFC, (2) is not correct but is the form that the Python libraries used to support. I'm not sure but I am pretty sure that (1) is now supported. If all else fails you could try (3) file:///d:/Internet/.............. The RFC is ambiguous as to whether forward or back-slashes should be used when the file system uses backslashes, and some systems are very particular about it. I do not think you need to here, though. Cheers, Tom P From uche.ogbuji@fourthought.com Mon Jul 15 15:40:09 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 15 Jul 2002 08:40:09 -0600 Subject: [XML-SIG] DOMImplementation.createDocumentType In-Reply-To: Message from Alexandre of "Mon, 15 Jul 2002 13:40:39 +0200." <20020715114039.GE28468@orion.logilab.fr> Message-ID: > The DOMImplementation.createDocumentType is not documented in the python > dom mapping > (http://www.python.org/doc/current/lib/dom-implementation-objects.html). > In 4DOM, I can pass None as the publicId argument, and this is done by > xml.dom.ext.readerSax2.XmlDomGenerator. In cDomlette (from CVS), using None > raises an exception. > > The question is: what's the right way of doing things. Is it OK to > change XmlDomGenerator to use an empty string, or would this break > existing code? Or should cDomlette be enhanced to accept None as the > publicId? I think this calls for a discussion, and then for us to make all DOMs compliant. I think that thought it's not quite the same situation (not sure what the status of empty string is in FPI spec), for consistency and least surprise, we should specify None to mean "no pubid", not empty string. If people agree, I can amend cDomlette. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From fdrake@acm.org Mon Jul 15 15:45:47 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 15 Jul 2002 10:45:47 -0400 Subject: [XML-SIG] DOMImplementation.createDocumentType In-Reply-To: References: <20020715114039.GE28468@orion.logilab.fr> Message-ID: <15666.57371.674266.24768@grendel.zope.com> Uche Ogbuji writes: > I think that thought it's not quite the same situation (not sure > what the status of empty string is in FPI spec), for consistency > and least surprise, we should specify None to mean "no pubid", not > empty string. This is similar to using None for "no namespace URI" elsewhere, so I agree. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Mon Jul 15 15:57:54 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 15 Jul 2002 10:57:54 -0400 Subject: [XML-SIG] minidom enhancements In-Reply-To: References: <15662.642.543908.161925@grendel.zope.com> Message-ID: <15666.58098.452536.479660@grendel.zope.com> Uche Ogbuji writes: > And cause some problems ;-) That's why I asked people for feedback way back. ;-) > It looks as if the class CharacterData no longer has an __init__. > Nor do the classes that derive from it. This means that the usage > > Text("spam") > Comment("eggs") > > Now blows up. Yes. I discussed my reasoning for this when I originally proposed the changes to minidom. One of the driving complaints that caused me to dive back into minidom was that Python's DOM was too slow. Since the documented API for the DOM uses factory methods on the Document instance (and using a factory is far from "non-Pythonic"!), that had to be preserved. Removing the additional method call yields a nice performance improvement, but I don't remember how much of the improvement was due specifically to that change. I did test it at the time, and the improvement was substantial. > Which, I think is bad. We construct nodes that way in 4Suite's minidom > wrapper, and I can modify the cases, but I dislike the change. I think it > removes a very useful and Pythonic paradigm. Also, who knows how much code it > would break? I know we've been guilty of changing APIs in 4Suite. I guess > I'm reaping my whirlwind :-) > > Is there a good reason for this, though? > > Should we expect any more API surprises ;-) I don't think this is an API change (since the constructors are not part of the API), nor do I think this should have been a surprise (I specifically brought this up on the list). I can certainly undo this particular part of the minidom changes if others would like to make the class constructors part of the minidom API. I'm more interested in making it reasonable to use subclassing to create extended DOM implementations. I don't think restoring the constructor signatures makes that easier (different, but not easier), and subclass-based extended DOMs are inherently going beyond the DOM API. (Proxy-based extended DOMs are another matter.) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Alexandre.Fayolle@logilab.fr Mon Jul 15 15:58:17 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Mon, 15 Jul 2002 16:58:17 +0200 Subject: [XML-SIG] DOMImplementation.createDocumentType In-Reply-To: References: <20020715114039.GE28468@orion.logilab.fr> Message-ID: <20020715145817.GA30245@orion.logilab.fr> On Mon, Jul 15, 2002 at 08:40:09AM -0600, Uche Ogbuji wrote: > > The question is: what's the right way of doing things. Is it OK to > > change XmlDomGenerator to use an empty string, or would this break > > existing code? Or should cDomlette be enhanced to accept None as the > > publicId? > > I think this calls for a discussion, and then for us to make all DOMs > compliant. > > I think that thought it's not quite the same situation (not sure what the > status of empty string is in FPI spec), for consistency and least surprise, we > should specify None to mean "no pubid", not empty string. I agree > If people agree, I can amend cDomlette. +1 Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From uche.ogbuji@fourthought.com Mon Jul 15 17:23:15 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 15 Jul 2002 10:23:15 -0600 Subject: [XML-SIG] minidom enhancements In-Reply-To: <15666.58098.452536.479660@grendel.zope.com> References: <15662.642.543908.161925@grendel.zope.com> <15666.58098.452536.479660@grendel.zope.com> Message-ID: <1026750201.16551.1527.camel@malatesta> It looks as if Martin will be the main person wanting it back now, then. If it helps performance, I'm happy to accommodate your changes. I've already actually made the needed change in 4Suite. And as for remembering any earlier discussion, you jest, no? My memory is about as reliable as a Pinto with Firestone tires. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From fdrake@acm.org Mon Jul 15 17:25:54 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 15 Jul 2002 12:25:54 -0400 Subject: [XML-SIG] minidom enhancements In-Reply-To: <1026750201.16551.1527.camel@malatesta> References: <15662.642.543908.161925@grendel.zope.com> <15666.58098.452536.479660@grendel.zope.com> <1026750201.16551.1527.camel@malatesta> Message-ID: <15666.63378.81042.316625@grendel.zope.com> Uche Ogbuji writes: > It looks as if Martin will be the main person wanting it back now, > then. If it helps performance, I'm happy to accommodate your changes. > I've already actually made the needed change in 4Suite. Cool. > And as for remembering any earlier discussion, you jest, no? > > My memory is about as reliable as a Pinto with Firestone tires. Time for an upgrade Uche! You can have my Escort wagon if I can ever get rid of it. ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Mon Jul 15 17:51:53 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 15 Jul 2002 10:51:53 -0600 Subject: [XML-SIG] DOMImplementation.createDocumentType In-Reply-To: <20020715145817.GA30245@orion.logilab.fr> References: <20020715114039.GE28468@orion.logilab.fr> <20020715145817.GA30245@orion.logilab.fr> Message-ID: <1026751921.16552.1562.camel@malatesta> On Mon, 2002-07-15 at 08:58, Alexandre wrote: > On Mon, Jul 15, 2002 at 08:40:09AM -0600, Uche Ogbuji wrote: > > > The question is: what's the right way of doing things. Is it OK to > > > change XmlDomGenerator to use an empty string, or would this break > > > existing code? Or should cDomlette be enhanced to accept None as the > > > publicId? > > > > I think this calls for a discussion, and then for us to make all DOMs > > compliant. > > > > I think that thought it's not quite the same situation (not sure what the > > status of empty string is in FPI spec), for consistency and least surprise, we > > should specify None to mean "no pubid", not empty string. > > I agree > > > If people agree, I can amend cDomlette. > > +1 Done on the EXPAT-1-95-4-branch branch. I can back it out if anyone gives a compelling reason to go the other way (though they'll have to battle Alexandre first ;-) ). -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From uche.ogbuji@fourthought.com Mon Jul 15 18:05:29 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 15 Jul 2002 11:05:29 -0600 Subject: [XML-SIG] Problem with 4xslt in Python on Windows In-Reply-To: Message from "Thomas B. Passin" of "Mon, 15 Jul 2002 08:04:15 EDT." <001801c22bf7$bdaf1640$fe193044@tbp1> Message-ID: > [Andrew Ittner] > > > On the line where I make oStyle, I've tried setting the fromStream's 2nd > > argument, a valid URI, to the following: > > D:\Internet\_XML_\ > > file://D:/Internet/_XML_/halls.xsl > > file://localhost/D:/Internet/_XML_/halls.xsl > > http://tephyr8.home.attbi.com/listofcompanies.xsl > > > > Only the last one works (when I post the included XSL files to it). > > > > What must I do to make the Python script see the XSL included files on my > > local drive? Since the 4xslt command-line works fine with the exact same > > files in the exact same location, I assume I'm missing something, but I > > can't figure what. > > > > Chances are you have to use the correct url syntax for a file: > > (1) file:///d:\Internet\.............. > > If that does not work, try this incorrect version: > > (2) file:/d:\Internet\.............. > > The double slash version is the one that is least likely to work, because it > is both incorrect by the RFC and also never came into (incorrect) use. (1) > is technically correct according to the RFC, (2) is not correct but is the > form that the Python libraries used to support. I'm not sure but I am > pretty sure that (1) is now supported. > > If all else fails you could try > > (3) file:///d:/Internet/.............. > > The RFC is ambiguous as to whether forward or back-slashes should be used > when the file system uses backslashes, and some systems are very particular > about it. I do not think you need to here, though. As Mike Brown mentioned, we do have a little utility that does this for you now: from Ft.Lib import Uri uri = Uri.OsPathToUri(filename, attemptAbsolute=1) attemptAbsolute tries to make it an absolute URL. I recommend this. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From Juergen Hermann" Message-ID: On 14 Jul 2002 15:41:20 +0200, Martin v. Loewis wrote: >That won't work together with bdist_wininst, right? Since the scripts >will have the hard-coded Python executable path from build time, which >might be different at installation time. That might indeed be true, I never used it together with a windows installer. I guess this could be corrected by checking the current command, and then emitting not the full paths to python, but only a relative one ("python.exe"). Ciao, J=FCrgen From martin@v.loewis.de Mon Jul 15 19:56:47 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 15 Jul 2002 20:56:47 +0200 Subject: [XML-SIG] minidom enhancements In-Reply-To: <1026750201.16551.1527.camel@malatesta> References: <15662.642.543908.161925@grendel.zope.com> <15666.58098.452536.479660@grendel.zope.com> <1026750201.16551.1527.camel@malatesta> Message-ID: Uche Ogbuji writes: > It looks as if Martin will be the main person wanting it back now, > then. If it helps performance, I'm happy to accommodate your changes. I was mainly asking for a rationale, and yes, I've ignored the earlier discussion on that as well. Fred's rationale is convincing, so I don't longer want the constructor back. Regards, Martin From martin@v.loewis.de Mon Jul 15 20:54:07 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 15 Jul 2002 21:54:07 +0200 Subject: Fwd: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g In-Reply-To: References: Message-ID: "Juergen Hermann" writes: > I guess this could be corrected by checking the current command, and > then emitting not the full paths to python, but only a relative one > ("python.exe"). It's even more tricky. Windows installations do associate .py with the "default" Python installation, but don't put Python into the path. Hence, you can invoke "foo.py", but invoking "python.exe foo.py" likely fails. That's why I'll be installing .py files on Windows, instead of .bat files. Users can then add .py to CMDEXT (or whatever the name of the environment variable is) if they don't want to type the .py. Regards, Martin From uche.ogbuji@fourthought.com Mon Jul 15 21:46:20 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 15 Jul 2002 14:46:20 -0600 Subject: Fwd: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g In-Reply-To: Message from martin@v.loewis.de (Martin v. Loewis) of "15 Jul 2002 21:54:07 +0200." Message-ID: > "Juergen Hermann" writes: > > > I guess this could be corrected by checking the current command, and > > then emitting not the full paths to python, but only a relative one > > ("python.exe"). > > It's even more tricky. Windows installations do associate .py with the > "default" Python installation, but don't put Python into the > path. Hence, you can invoke "foo.py", but invoking "python.exe foo.py" > likely fails. > > That's why I'll be installing .py files on Windows, instead of .bat > files. Users can then add .py to CMDEXT (or whatever the name of the > environment variable is) if they don't want to type the .py. Jeremy, in his typical evil genius way, went even farther with 4Suite. He actually compiles each script into a little C program on Windows which embeds the Python interpreter. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From martin@v.loewis.de Mon Jul 15 22:18:27 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 15 Jul 2002 23:18:27 +0200 Subject: Fwd: [XML-SIG] [ pyxml-Bugs-581175 ] Bad bangpath for scripts on install (e.g In-Reply-To: References: Message-ID: Uche Ogbuji writes: > Jeremy, in his typical evil genius way, went even farther with > 4Suite. He actually compiles each script into a little C program on > Windows which embeds the Python interpreter. That's indeed evil :-) Martin From hannu@tm.ee Mon Jul 15 22:41:41 2002 From: hannu@tm.ee (Hannu Krosing) Date: 16 Jul 2002 02:41:41 +0500 Subject: [XML-SIG] 4XSLT focus on docbook stylesheets (and fruit thereof) In-Reply-To: References: Message-ID: <1026769304.2350.63.camel@rh72.home.ee> On Mon, 2002-07-15 at 12:32, Uche Ogbuji wrote: > > Thomas B. Passin wrote: > > > Outstanding! Any ideas how that compares with the big guns (Xalan, msxml, > > > saxon)? > > > > I just ran some tests against one of those guns. > > > > The contenders: > > > > 4xslt 0.12.0a3(*), incorporating expat-1.95.2, under Python 2.2.1 > > vs > > Saxon 6.5.2, with its modified Aelfred parser, running under JDK 1.1.8. > > > > (*) what will become alpha 3, rather > > > > The platform: > > > > Intel PIII-933, 256 MB RAM, FreeBSD 4.6-STABLE. > > > > The test: > > > > Transforming a 450-line, 25K Simplified DocBook article to HTML, > > using DocBook XSL 1.50. > > [SNIP] > > > Battle #1: The simplest test: command-line, with all the overhead of > > the JVM and Python interpreter starting up to throw off the results. > > [SNIP] > > > Outcome: 4xslt finishes about 67% faster than Saxon > > [SNIP] > > > Battle #2: A proper test: timing the stylesheet preparation and > > transformation separately, from code. > > [SNIP] > > > Outcome: 4xslt about 85% faster than Saxon at stylesheet preparation, > > and 4xslt about 60% faster than Saxon at transformation. > > Thanks, Mike. I did rather suspected that we would equal or beat the Java > processors at this point. I expect we'll still get taken by the C processors, > but hey! Ya never know. To see what a C implementation can do, I tested with xsltproc from gnome's libxml2-2.4.23-1/libxslt-1.0.19-1 platform Linux RH7.1, Celeron 375, 448MB this is pure C binary: [hannu@rh72 xslttest]$ /usr/bin/time -p /usr/bin/xsltproc QuickStart.xml docbook-xsl-1.52.2/html/docbook.xsl > out.html real 7.62 user 3.67 sys 0.18 when doing it from python it was lot slower: [hannu@rh72 xslttest]$ /usr/bin/time -p ./pyxsltproc.py QuickStart.xml docbook-xsl-1.52.2/html/docbook.xsl > out4.html real 23.03 user 12.62 sys 0.58 the pyxsltproc.py reported the following times: Parsing stylesheet QuickStart.xml took 1249 ms Applying stylesheet took 8454 ms Saving result took 19 ms So it seems that actual transform should be somewhat competitive, though I used 2.5 times slower computer than Mike. If somebody (Mike ;) would like to include libxslt to his future tests, the stuff is available from http://www.xmlsoft.org/downloads.html . It seems to live quite nicely in the same installation with pyXML. ------------------ Hannu From andrew.ittner@usa.net Tue Jul 16 05:43:16 2002 From: andrew.ittner@usa.net (Andrew Ittner) Date: Mon, 15 Jul 2002 21:43:16 -0700 Subject: [XML-SIG] Problem with 4xslt in Python on Windows In-Reply-To: Message-ID: <000401c22c83$4cec7ce0$7b7ba8c0@attbi.com> > > Chances are you have to use the correct url syntax for a file: > > > > (1) file:///d:\Internet\.............. > > That works! Thank you. (Jeez, just one extra slash was all I needed???) > > As Mike Brown mentioned, we do have a little utility that does > this for you now: > > from Ft.Lib import Uri > uri = Uri.OsPathToUri(filename, attemptAbsolute=1) I don't have OsPathToUri, as I just realized that the 0.12.0a2 version I use doesn't have the latest and greatest fixes. Guess I get to learn how to use CVS (told you I was new at this!). Now, for the follow-up: I have a single parameter in my XSL file, so I can make two outputs from the same XML/XSL combo. Again, the 4xslt command-line processor runs it perfectly, but the Python script barfs. _Start of the XSL file:_ Fame _Parameter declaration inside the Python script:_ prmX = {} prmX[('http://www.w3.org/1999/XSL/Transform', 'TypeHall')] = 'Shame' _Script line that's causing problems:_ sResult = oProcessor.run(InputSource.DefaultFactory.fromStream(fXML, oURI), 1, prmX, '', fHTML) (fXML & fHTML are open files; oURI is the valid URI.) _And finally, the last lines of the error:_ File "C:\PYTHON22\Lib\site-packages\Ft\Xml\Xslt\Stylesheet.py", line 325, in _computeGlobalVar vnode = self._topVariables[0][vname] KeyError: (None, u'TypeHall') So, what am I missing? Is it as simple as a single backslash... ;-) Thanks, Andrew Ittner http://zip.to/tephyr From mike@skew.org Tue Jul 16 08:13:59 2002 From: mike@skew.org (Mike Brown) Date: Tue, 16 Jul 2002 01:13:59 -0600 (MDT) Subject: [XML-SIG] [ pyxml-Bugs-581601 ] broken install on unix In-Reply-To: "from noreply@sourceforge.net at Jul 15, 2002 02:21:01 am" Message-ID: <200207160713.g6G7DxH9061986@chilled.skew.org> > Installation order is > -Python 2.2.1 > - PyXML 0.7.1 > - 4Suite 0.11.1 Whatever anonymous person posted these, if you're out there, you can't use 4Suite 0.11.1 with PyXML 0.7 or Python 2.2. Either revert to PyXML 0.6.6 and Python 2.1, or upgrade to 4Suite 0.12.0 alpha (preferably from CVS), as per the info on http://uche.ogbuji.net:8080/uche.ogbuji.net/tech/akara/pyxml/choosing-software/ Someone close these bugs. - Mike ____________________________________________________________________________ mike j. brown | xml/xslt: http://skew.org/xml/ denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/ From tpassin@comcast.net Tue Jul 16 13:53:23 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Tue, 16 Jul 2002 08:53:23 -0400 Subject: [XML-SIG] [ pyxml-Bugs-581601 ] broken install on unix References: <200207160713.g6G7DxH9061986@chilled.skew.org> Message-ID: <000601c22cc7$c4d25d30$fe193044@tbp1> [Mike Brown] > > Installation order is > > -Python 2.2.1 > > - PyXML 0.7.1 > > - 4Suite 0.11.1 > > Whatever anonymous person posted these, if you're out there, you can't use > 4Suite 0.11.1 with PyXML 0.7 or Python 2.2. Either revert to PyXML 0.6.6 and > Python 2.1, or upgrade to 4Suite 0.12.0 alpha (preferably from CVS), as per > the info on > http://uche.ogbuji.net:8080/uche.ogbuji.net/tech/akara/pyxml/choosing-softwa re/ > > Someone close these bugs. > I have used 0.11.1 with pyXML 0.71 under Py1.5.2 on WIndows 2000. Maybe I just did not hit the incompatible bits yet. Mostly I have just used 4xslt. Cheers, Tom P From haering_python@gmx.de Wed Jul 17 02:26:39 2002 From: haering_python@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Wed, 17 Jul 2002 03:26:39 +0200 Subject: [XML-SIG] Simple DOM API a la dom4j/jdom Message-ID: <20020717012639.GA2749@lilith.my-fqdn.de> Does such a thing exist with a BSD-style license somewhere for Python? Now that I try to use XML again after a long time, I find the DOM API just too clumsy, and have written a very basic DOM wrapper that allows me to do things like: doc = reader.fromStream(open("flow.xml")) print DOMWrapper(doc)["startnode"][0].name ^ ^ ^ ^ Wrapper Element coll.| attribute | First element, also supports iterators If something like this exists already and is debugged, I'd be interested. Gerhard -- This sig powered by Python! Außentemperatur in München: 17.1 °C Wind: 2.7 m/s From matt_g_@hotmail.com Wed Jul 17 04:03:17 2002 From: matt_g_@hotmail.com (Matt G.) Date: Wed, 17 Jul 2002 03:03:17 +0000 Subject: [XML-SIG] Simple DOM API a la dom4j/jdom Message-ID: >Does such a thing exist with a BSD-style license somewhere for Python? >Now that I try to use XML again after a long time, I find the DOM API >just too clumsy, and have written a very basic DOM wrapper that allows >me to do things like: > >doc = reader.fromStream(open("flow.xml")) >print DOMWrapper(doc)["startnode"][0].name > ^ ^ ^ ^ > Wrapper Element coll.| attribute > | > First element, also supports iterators It seems that you want either XPath (http://www.w3c.org/TR/xpath) or XML Query (http://www.w3c.org/XML/Query). I agree that, for navigating a large document, these are definitely the way to go. 4Suite includes an XPath implementation, and uses the Apache license (I don't know if that's similar enough to the BSD license, for you). I assume their XPath package is used by their XSLT processor, in which case it's must be pretty solid. I poked around at the API documentation, and didn't find such a high-level interface as you seem to want. Maybe I just missed it. If not, I think it's a shame, since I wanted to use XPath w/ DOM, too. Good luck, Matt Gruenke _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From haering_python@gmx.de Wed Jul 17 04:33:28 2002 From: haering_python@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Wed, 17 Jul 2002 05:33:28 +0200 Subject: [XML-SIG] Simple DOM API a la dom4j/jdom In-Reply-To: References: Message-ID: <20020717033328.GA5685@lilith.my-fqdn.de> * Matt G. [2002-07-17 03:03 +0000]: > Gerhard wrote: > >Does such a thing exist with a BSD-style license somewhere for Python? > >Now that I try to use XML again after a long time, I find the DOM API > >just too clumsy, and have written a very basic DOM wrapper that allows > >me to do things like: > > > >doc = reader.fromStream(open("flow.xml")) > >print DOMWrapper(doc)["startnode"][0].name > > ^ ^ ^ ^ > > Wrapper Element coll.| attribute > > | > > First element, also supports iterators > > It seems that you want either XPath (http://www.w3c.org/TR/xpath) or > XML Query (http://www.w3c.org/XML/Query). [...] 4Suite includes an > XPath implementation, It's apparently included PyXML 0.7.1, but not documented at all, AFAIC. > and uses the Apache license (I don't know if that's similar enough to > the BSD license, for you). Would be fine. > [...] I poked around at the API documentation, and didn't find such a > high-level interface as you seem to want. Maybe I just missed it. If > not, I think it's a shame, since I wanted to use XPath w/ DOM, too. I once did use the DOM API in Java, and after playing around with the various alternatives (pure DOM, simplified DOM API, XML binding), I went with dom4j, which has an interface like I described in my example above. I really think that such a module should be commonly available for Python, as it's sort of grotesque that using Java (with dom4j/jdom) for accessing DOM trees is currently easier than using Python ;-) Btw. my Python DOM wrapper seems to work ok, and it's only something like 40 lines long. No test suite, namespaces or other fancy stuff yet. Now this leads me to another question. I noticed that with DOM, I can only query specific elements, as there's no method like getAllElements(). I really have to use SAX if I want this, right? Does anybody know if the XML spec says anything about the order of elements? Does the DOM API guarantee to return them in the same order as they're encountered in the XML file? Lack of a getAllElements() function makes my XML look like: where I have to use an explicit attribute 'nextnodeid' to get an order into the various elements. Probably not a big deal, as if this project will ever get finished, there'll be a GUI editor for the flows. Gerhard -- This sig powered by Python! Außentemperatur in München: 17.0 °C Wind: 2.7 m/s From martin@v.loewis.de Wed Jul 17 06:10:03 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 17 Jul 2002 07:10:03 +0200 Subject: [XML-SIG] Simple DOM API a la dom4j/jdom In-Reply-To: <20020717033328.GA5685@lilith.my-fqdn.de> References: <20020717033328.GA5685@lilith.my-fqdn.de> Message-ID: Gerhard H=E4ring writes: > It's apparently included PyXML 0.7.1, but not documented at all, AFAIC. For the moment, I'd recommend to use the XPath implementation that comes with 4Suite. > Now this leads me to another question. I noticed that with DOM, I can > only query specific elements, as there's no method like > getAllElements(). I really have to use SAX if I want this, right? No. I'd recommend to write a simple recursive function, or use an XPath expression ("*" is the XPath expression for that, I believe). The recursive function would be something like def getAllElements(node): result =3D [node] for c node.childNodes: if c.nodeType =3D=3D Node.ELEMENT_NODE: result.extend(getAllElements(c) return result > Does anybody know if the XML spec says anything about the order of > elements? Does the DOM API guarantee to return them in the same order as > they're encountered in the XML file? Certainly. > Lack of a getAllElements() function makes my XML look like: I'm not quite sure I understand the problem; in any case, it seems wrong to design the document type based on the processing algorithms that you can implement. Regards, Martin From matt_g_@hotmail.com Wed Jul 17 07:52:26 2002 From: matt_g_@hotmail.com (Matt G.) Date: Wed, 17 Jul 2002 06:52:26 +0000 Subject: [XML-SIG] Simple DOM API a la dom4j/jdom Message-ID: >From: martin@v.loewis.de (Martin v. Loewis) >To: Gerhard Häring >CC: xml-sig@python.org >Subject: Re: [XML-SIG] Simple DOM API a la dom4j/jdom >Date: 17 Jul 2002 07:10:03 +0200 > > > Now this leads me to another question. I noticed that with DOM, I can > > only query specific elements, as there's no method like > > getAllElements(). I really have to use SAX if I want this, right? > >No. I'd recommend to write a simple recursive function, or use an >XPath expression ("*" is the XPath expression for that, I believe). > >The recursive function would be something like > >def getAllElements(node): > result = [node] > for c node.childNodes: > if c.nodeType == Node.ELEMENT_NODE: > result.extend(getAllElements(c) > return result But that's so huge, compared to something like: result = node.getNodes( "*" ) Note that it doesn't actually get ALL nodes in the entire tree - that would be "//*". It'd be neat if an XpDom node had methods to: * get all matching nodes * get the next matching node * replace all matching nodes w/ X (could this even be an XPath expression?) * delete all matching nodes I suppose you could implement the latter two by having a higher-order operator, which would execute a lambda with each matching node as the context node. It'd be a bit like standard regexp functions, except with trees instead of strings. The comment about allowing an XPath expression, for the result, is even potentially a nod towards regexp backrefs. There's no reason why XPath wouldn't also work nicely w/ SAX, BTW. For example, you could register SAX handlers in terms of XPath expressions (like XSLT templates), and even use XPath expressions to process only limited chunks of the tree. Matt _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From gherman@darwin.in-berlin.de Wed Jul 17 09:24:48 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 17 Jul 2002 10:24:48 +0200 (CEST) Subject: [XML-SIG] Follow-up on "minidom toxml() / Unicode problem" Message-ID: <1026894288.3d3529d018e2d@webmail.in-berlin.de> Hi, I just read about the May thread titled "XML: minidom toxml() does not work for non English files! :-(" after being hit by the same problem (being unable to write UTF-8 files using std.lib. minidom toprettyxml()...) Can someone please try to summarize the recommended workaround, if there is any? Or is minidom/string/whatever in 2.2.1 in some sense "broken"? ;-) Regards, Dinu From noreply@sourceforge.net Wed Jul 17 11:33:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jul 2002 03:33:40 -0700 Subject: [XML-SIG] [ pyxml-Bugs-582762 ] constant VERSION - xmlparse.c line 1329 Message-ID: Bugs item #582762, was opened at 2002-07-17 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=582762&group_id=6473 Category: expat Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lars Gregori (goolo) Assigned to: Nobody/Anonymous (nobody) Summary: constant VERSION - xmlparse.c line 1329 Initial Comment: PyXML-0.7.1 extensions/expat/lib/xmlparse.c(1329) : error C2143: Syntaxfehler : Missing ';' before 'constant' I've replaced VERSION with "1.95.2" and everything works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=582762&group_id=6473 From rsalz@datapower.com Wed Jul 17 15:16:45 2002 From: rsalz@datapower.com (Rich Salz) Date: Wed, 17 Jul 2002 10:16:45 -0400 Subject: [XML-SIG] Simple DOM API a la dom4j/jdom References: Message-ID: <3D357C4D.1040000@datapower.com> > It'd be neat if an XpDom node had methods to: > * get all matching nodes > * get the next matching node Those are fairly easy with Python generators. Every once in a while someone suggest a more python XML document interface (PyDOM is bad; how about PyXDI? :). Certainly leveraging generators and making iterators should be a key part. It would be interesting to restructure XPath to be generator based. That'd break compatibility with most python releases, of course. /r$ From uche.ogbuji@fourthought.com Wed Jul 17 15:47:49 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 17 Jul 2002 08:47:49 -0600 Subject: [XML-SIG] Differing symbols in PyXML? Message-ID: I imagine the changed symbols in Fred's minidom updates (e.g. DOMStringSizeErr versus the new DomstringSizeErr) are to make them closer to Guido/Python style? Isn't this going to cause problems given that the old versions of these symbols remain in Python 2.2? Is there any harm in supporting both forms? -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From fdrake@acm.org Wed Jul 17 16:07:41 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 17 Jul 2002 11:07:41 -0400 Subject: [XML-SIG] Differing symbols in PyXML? In-Reply-To: References: Message-ID: <15669.34877.738331.290147@grendel.zope.com> Uche Ogbuji writes: > I imagine the changed symbols in Fred's minidom updates (e.g. DOMStringSizeErr > versus the new DomstringSizeErr) are to make them closer to Guido/Python style? > > Isn't this going to cause problems given that the old versions of these > symbols remain in Python 2.2? > > Is there any harm in supporting both forms? This sounds like an unintentional change, and it should be fixed. I'll take a look at it. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Wed Jul 17 16:39:29 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 17 Jul 2002 11:39:29 -0400 Subject: [XML-SIG] Differing symbols in PyXML? In-Reply-To: References: Message-ID: <15669.36785.794210.96750@grendel.zope.com> Uche Ogbuji writes: > I imagine the changed symbols in Fred's minidom updates > (e.g. DOMStringSizeErr versus the new DomstringSizeErr) are to make > them closer to Guido/Python style? Ok, I've take a quick look into this, and am confused. What are you talking about? grep can only find DOMStringSizeErr: % find -name \*.py | xargs grep -i DomstringSizeErr ./build/lib.linux-i686-2.0/_xmlplus/dom/__init__.py:class DOMStringSizeErr(DOMException): ./build/lib.linux-i686-2.1/_xmlplus/dom/__init__.py:class DOMStringSizeErr(DOMException): ./build/lib.linux-i686-2.2/_xmlplus/dom/__init__.py:class DOMStringSizeErr(DOMException): ./build/lib.linux-i686-2.3/_xmlplus/dom/__init__.py:class DOMStringSizeErr(DOMException): ./xml/dom/__init__.py:class DOMStringSizeErr(DOMException): Uche, are you looking at a modified tree? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Wed Jul 17 17:20:42 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 17 Jul 2002 10:20:42 -0600 Subject: [XML-SIG] Differing symbols in PyXML? In-Reply-To: <15669.36785.794210.96750@grendel.zope.com> References: <15669.36785.794210.96750@grendel.zope.com> Message-ID: <1026922844.9992.1006.camel@malatesta> On Wed, 2002-07-17 at 09:39, Fred L. Drake, Jr. wrote: > > Uche Ogbuji writes: > > I imagine the changed symbols in Fred's minidom updates > > (e.g. DOMStringSizeErr versus the new DomstringSizeErr) are to make > > them closer to Guido/Python style? > > Ok, I've take a quick look into this, and am confused. What are you > talking about? grep can only find DOMStringSizeErr: > > % find -name \*.py | xargs grep -i DomstringSizeErr > ./build/lib.linux-i686-2.0/_xmlplus/dom/__init__.py:class DOMStringSizeErr(DOMException): > ./build/lib.linux-i686-2.1/_xmlplus/dom/__init__.py:class DOMStringSizeErr(DOMException): > ./build/lib.linux-i686-2.2/_xmlplus/dom/__init__.py:class DOMStringSizeErr(DOMException): > ./build/lib.linux-i686-2.3/_xmlplus/dom/__init__.py:class DOMStringSizeErr(DOMException): > ./xml/dom/__init__.py:class DOMStringSizeErr(DOMException): > > Uche, are you looking at a modified tree? No. I got it exactly backwards. This is what I find on stock Debian Python 2.2. install (it's the same as what's in the Python 2.2 I built myself): $ grep -i DomstringSizeErr /usr/lib/python2.2/xml/dom/__init__.py class DomstringSizeErr(DOMException): This is from latest PyXML: $ grep -i DomstringSizeErr xml/dom/__init__.py class DOMStringSizeErr(DOMException): Looking at Python 2.1 (again stock Debian install) $ grep -i DomstringSizeErr /usr/lib/python2.1/xml/dom/__init__.py class DomstringSizeErr(DOMException): I am very confused at this point. Just to make sure my computer is not in the twilight zone, I checked on a pristine Red Hat box. Same thing. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From fdrake@acm.org Wed Jul 17 17:33:32 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 17 Jul 2002 12:33:32 -0400 Subject: [XML-SIG] Differing symbols in PyXML? In-Reply-To: <1026922844.9992.1006.camel@malatesta> References: <15669.36785.794210.96750@grendel.zope.com> <1026922844.9992.1006.camel@malatesta> Message-ID: <15669.40028.569554.451651@grendel.zope.com> Uche Ogbuji writes: > No. I got it exactly backwards. This is what I find on stock Debian > Python 2.2. install (it's the same as what's in the Python 2.2 I built > myself): Well, at least this wasn't a side effect of my minidom changes! I just trolled through the CVS logs and changes; it looks like Jeremy Kloth checked that name-change in xml/dom/__init__.py in revision 1.13. This was a 4DOM change, not a minidom change! ;-) (On the other hand, I like the new name better.) Probably the right thing to do for PyXML is to restore the original name and make the new name an alias. We should not use or encourage use of the new name. I might like it better, but that's no reason to change the Python DOM API. The documentation only names DomstringSizeErr. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Wed Jul 17 17:45:06 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 17 Jul 2002 10:45:06 -0600 Subject: [XML-SIG] Differing symbols in PyXML? In-Reply-To: <15669.40028.569554.451651@grendel.zope.com> References: <15669.36785.794210.96750@grendel.zope.com> <1026922844.9992.1006.camel@malatesta> <15669.40028.569554.451651@grendel.zope.com> Message-ID: <1026924309.9963.1035.camel@malatesta> On Wed, 2002-07-17 at 10:33, Fred L. Drake, Jr. wrote: > > Uche Ogbuji writes: > > No. I got it exactly backwards. This is what I find on stock Debian > > Python 2.2. install (it's the same as what's in the Python 2.2 I built > > myself): > > Well, at least this wasn't a side effect of my minidom changes! > > I just trolled through the CVS logs and changes; it looks like Jeremy > Kloth checked that name-change in xml/dom/__init__.py in revision > 1.13. This was a 4DOM change, not a minidom change! ;-) > > (On the other hand, I like the new name better.) So do I, but only because it's the standard :-) > Probably the right thing to do for PyXML is to restore the original > name and make the new name an alias. Agreed. > We should not use or encourage > use of the new name. I might like it better, but that's no reason to > change the Python DOM API. The documentation only names > DomstringSizeErr. Too bad. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From fdrake@acm.org Wed Jul 17 17:44:23 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 17 Jul 2002 12:44:23 -0400 Subject: [XML-SIG] Differing symbols in PyXML? In-Reply-To: <1026924309.9963.1035.camel@malatesta> References: <15669.36785.794210.96750@grendel.zope.com> <1026922844.9992.1006.camel@malatesta> <15669.40028.569554.451651@grendel.zope.com> <1026924309.9963.1035.camel@malatesta> Message-ID: <15669.40679.282393.8789@grendel.zope.com> Uche Ogbuji writes: > > Probably the right thing to do for PyXML is to restore the original > > name and make the new name an alias. > > Agreed. We'll be watching for Jeremy's checkin. ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Mike.Olson@fourthought.com Wed Jul 17 18:13:54 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 17 Jul 2002 11:13:54 -0600 Subject: [XML-SIG] xmlproc callbacks Message-ID: <1026926039.3639.91.camel@penny> In xmlval.py, the methof handle_end_tag on ValidatingApp never makes a call to its realapp's handle_end_tag. This makes it very difficult to generate DOMs using xmlproc and we never know when an element ends :). I can make the fix if no one objects. Index: xmlval.py =================================================================== RCS file: /cvsroot/pyxml/xml/xml/parsers/xmlproc/xmlval.py,v retrieving revision 1.15 diff -r1.15 xmlval.py 219a220,222 > self.realapp.handle_end_tag(name) > > -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From larsga@garshol.priv.no Wed Jul 17 18:30:37 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 17 Jul 2002 19:30:37 +0200 Subject: [XML-SIG] xmlproc callbacks In-Reply-To: <1026926039.3639.91.camel@penny> References: <1026926039.3639.91.camel@penny> Message-ID: * Mike Olson | | In xmlval.py, the methof handle_end_tag on ValidatingApp never makes | a call to its realapp's handle_end_tag. This makes it very | difficult to generate DOMs using xmlproc and we never know when an | element ends :). Ouch ouch ouch. Baad mistake. :) | I can make the fix if no one objects. Please do, but please make the call *before* the element is popped off the stack, in order to be consistent with handle_start_tag. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From Mike.Olson@fourthought.com Wed Jul 17 18:34:17 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 17 Jul 2002 11:34:17 -0600 Subject: [XML-SIG] xmlproc callbacks In-Reply-To: References: <1026926039.3639.91.camel@penny> Message-ID: <1026927259.3265.97.camel@penny> On Wed, 2002-07-17 at 11:30, Lars Marius Garshol wrote: > > * Mike Olson > | > | In xmlval.py, the methof handle_end_tag on ValidatingApp never makes > | a call to its realapp's handle_end_tag. This makes it very > | difficult to generate DOMs using xmlproc and we never know when an > | element ends :). > > Ouch ouch ouch. Baad mistake. :) > > | I can make the fix if no one objects. > > Please do, but please make the call *before* the element is popped off > the stack, in order to be consistent with handle_start_tag. Done > > -- > Lars Marius Garshol, Ontopian > ISO SC34/WG3, OASIS GeoLang TC > > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From martin@v.loewis.de Wed Jul 17 19:04:34 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 17 Jul 2002 20:04:34 +0200 Subject: [XML-SIG] Follow-up on "minidom toxml() / Unicode problem" In-Reply-To: <1026894288.3d3529d018e2d@webmail.in-berlin.de> References: <1026894288.3d3529d018e2d@webmail.in-berlin.de> Message-ID: Dinu Gherman writes: > Can someone please try to summarize the recommended workaround, > if there is any? Or is minidom/string/whatever in 2.2.1 in > some sense "broken"? ;-) The suggested work-around is result = dom.toxml() if isinstance(result, unicode): result = result.encode("utf-8") In Python 2.3, you will be able to write result = dom.toxml(encoding="utf-8") Likewise in PyXML 0.8. Regards, Martin From martin@v.loewis.de Wed Jul 17 19:16:16 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 17 Jul 2002 20:16:16 +0200 Subject: [XML-SIG] Simple DOM API a la dom4j/jdom In-Reply-To: References: Message-ID: "Matt G." writes: > Note that it doesn't actually get ALL nodes in the entire tree - that > would be "//*". Thanks for the correction; this is what I meant. > But that's so huge, compared to something like: > > result = node.getNodes( "*" ) In 4Suite (and PyXML 0.7), that should be result = xml.xpath.Evaluate("//*", node) Regards, Martin From matt@reprocessed.org Thu Jul 18 18:40:24 2002 From: matt@reprocessed.org (Matt Patterson) Date: Thu, 18 Jul 2002 18:40:24 +0100 Subject: [XML-SIG] Problems with Python and SAX on OS X Message-ID: List people (blind cross-posted to python-mac and python-XML), Having just installed unix python on Mac OS X via Fink I tried to run one of my beginner XML scripts from my Mac and not my Debian box. The scripts work fine on the debian box but crash out with a segmentation fault on the OS X box, which is kind of irritating. The crash happens when I call the parser at the end of: from xml.sax import make_parser saxparser = make_parser() saxparser.setContentHandler(cHandler) saxparser.parse(sys.stdin) I've been able to figure out that the crash happens when saxparser.parse is called (by inserting print statements after each of the calls involving saxparser... crude, but informative enough for my abilities). I'm using python 2.2.1 (Python 2.2 (#1, Apr 17 2002, 17:13:51) according to the interpreter) on Mac OS X 10.1.5 with Fink 0.4 binary distribution. Has anyone seen anything like this? Thanks, Matt -- Matt Patterson | Typographer | http://www.emdash.co.uk/ | http://reprocessed.org/ From lschaps@tzi.de Fri Jul 19 11:41:00 2002 From: lschaps@tzi.de (Lars Schaps) Date: Fri, 19 Jul 2002 12:41:00 +0200 Subject: [XML-SIG] XML-HOWTO Message-ID: <3D37ECBC.AC587ABF@tzi.de> Hello. Is it possible to get the XML-HOWTO as *.tex, *.ps, *.pdf, or as *.dvi file? Thanks Lars Schaps From fredrik@pythonware.com Fri Jul 19 14:01:20 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 19 Jul 2002 15:01:20 +0200 Subject: [XML-SIG] XML-HOWTO References: <3D37ECBC.AC587ABF@tzi.de> Message-ID: <02b801c22f24$62a2cdc0$0900a8c0@spiff> Lars Schaps wrote: > Is it possible to get the XML-HOWTO as *.tex, *.ps, *.pdf, or as *.dvi > file? the text sources are available from sourceforge: http://sourceforge.net/projects/pyxml if you don't want to do a complete CVS checkout, you can get the individual files from: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyxml/xml/doc/ direct links: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyxml/xml/doc/xml-howto.te= x?rev=3DHEAD&content-type=3Dtext/plain http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyxml/xml/doc/xml-ref.tex?= rev=3DHEAD&content-type=3Dtext/plain From Alexandre.Fayolle@logilab.fr Fri Jul 19 15:56:59 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Fri, 19 Jul 2002 16:56:59 +0200 Subject: [XML-SIG] finding the NS URI for a prefix in a DOM Message-ID: <20020719145658.GG5873@orion.logilab.fr> Hello, I have a silly DOM question. I'm using 4DOM on this one, but this may change later. What is the best way of finding the nsuri of a namespace given a prefix to which the nsuri could be mapped? Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From fdrake@acm.org Fri Jul 19 16:29:34 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 19 Jul 2002 11:29:34 -0400 Subject: [XML-SIG] finding the NS URI for a prefix in a DOM In-Reply-To: <20020719145658.GG5873@orion.logilab.fr> References: <20020719145658.GG5873@orion.logilab.fr> Message-ID: <15672.12382.849001.340947@grendel.zope.com> Alexandre writes: > I have a silly DOM question. I'm using 4DOM on this one, but this may > change later. > > What is the best way of finding the nsuri of a namespace given a prefix > to which the nsuri could be mapped? My own preference would be to use the lookupNamespaceURI() method on a node, but that would imply we have a Level 3 DOM. I suspect that minidom will eventually provide this in some form. ;-) I don't think we have a good way to do that now, but it could be done in a DOM-independent way by walking up the tree looking at namespace declarations. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Alexandre.Fayolle@logilab.fr Fri Jul 19 16:42:43 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Fri, 19 Jul 2002 17:42:43 +0200 Subject: [XML-SIG] finding the NS URI for a prefix in a DOM In-Reply-To: <15672.12382.849001.340947@grendel.zope.com> References: <20020719145658.GG5873@orion.logilab.fr> <15672.12382.849001.340947@grendel.zope.com> Message-ID: <20020719154243.GI5873@orion.logilab.fr> On Fri, Jul 19, 2002 at 11:29:34AM -0400, Fred L. Drake, Jr. wrote: > > Alexandre writes: > > I have a silly DOM question. I'm using 4DOM on this one, but this may > > change later. > > > > What is the best way of finding the nsuri of a namespace given a prefix > > to which the nsuri could be mapped? > > My own preference would be to use the lookupNamespaceURI() method on a > node, but that would imply we have a Level 3 DOM. I suspect that > minidom will eventually provide this in some form. ;-) It's a long time since I've looked at the DOM TR drafts... > > I don't think we have a good way to do that now, but it could be done > in a DOM-independent way by walking up the tree looking at namespace > declarations. What I've decided to use is XPath: from xml.xpath import Evaluate def prefix_to_nsuri(node): map = {} ns_nodes = Evaluate('namespace::node()',node) for ns in ns_nodes: map[ns.localName]=ns.value return map This works very well, and only needs a slight change to be able to get the ns uri for one given prefix. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From rsalz@datapower.com Fri Jul 19 16:51:35 2002 From: rsalz@datapower.com (Rich Salz) Date: Fri, 19 Jul 2002 11:51:35 -0400 Subject: [XML-SIG] finding the NS URI for a prefix in a DOM References: <20020719145658.GG5873@orion.logilab.fr> <15672.12382.849001.340947@grendel.zope.com> Message-ID: <3D383587.1070502@datapower.com> Fred L. Drake, Jr. wrote: > I don't think we have a good way to do that now, but it could be done > in a DOM-independent way by walking up the tree looking at namespace > declarations. That's what I do in ZSI. Here's the code, which might be of use ... _attrs = lambda E: (E.attributes and E.attributes.values()) or [] def GetElementNSdict(self, elt): '''Get a dictionary of all the namespace attributes for an element. The dictionaries are cached, and we recurse up the tree as necessary. ''' d = self.ns_cache.get(id(elt)) if not d: if elt != self.dom: d = self.GetElementNSdict(elt.parentNode) for a in _attrs(elt): if a.namespaceURI == XMLNS.BASE: if a.localName == "xmlns": d[''] = a.nodeValue else: d[a.localName] = a.nodeValue self.ns_cache[id(elt)] = d return d.copy() From Alexandre.Fayolle@logilab.fr Fri Jul 19 16:53:45 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Fri, 19 Jul 2002 17:53:45 +0200 Subject: [XML-SIG] more on DOM and namespaces Message-ID: <20020719155345.GJ5873@orion.logilab.fr> Hello again, I have another DOM and Namespaces questions. Is it necessary to add the xmlns attribute to an element which is created with createElementNS ? This is what I get with 4DOM: >>> from xml.dom.ext.reader.Sax2 import Reader >>> d = Reader().fromString("") >>> e = d.createElementNS("bar","b:elt") >>> d.documentElement.appendChild(e) >>> d.documentElement.attributes }> >>> e.attributes >>> from xml.dom.ext import PrettyPrint >>> PrettyPrint(d) So it looks like I don't need to explicitely setAttributeNS for namespace attributes, at least with 4DOM, but reading the DOML2 spec §1.1.8 didn't help me telling if theis was just a nice property of 4DOM or a DOM requirement. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From martin@v.loewis.de Sat Jul 20 01:17:51 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 20 Jul 2002 02:17:51 +0200 Subject: [XML-SIG] Re: [XML-checkins]CVS: xml/xml/dom expatbuilder.py,1.5,1.6 In-Reply-To: References: Message-ID: "Fred L. Drake" writes: > *************** > *** 273,277 **** > None, name, doctype) > if self._standalone >= 0: > ! doc.standalone = self._standalone > doc.encoding = self._encoding > doc.version = self._version > --- 275,279 ---- > None, name, doctype) > if self._standalone >= 0: > ! doc.standalone = self._standalone and True or False > doc.encoding = self._encoding > doc.version = self._version I personally find this change quite ugly. Wouldn't it be much better if pyexpat would use True and False in the standalone flag? I believe a simple change like ("(O&O&O)", STRING_CONV_FUNC,version, STRING_CONV_FUNC,encoding, standalone ? Py_True:Py_False)) would do. Also, what is the purpose of initializing _standalone to -1? Regards, Martin From uche.ogbuji@fourthought.com Sun Jul 21 01:08:04 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sat, 20 Jul 2002 18:08:04 -0600 Subject: [XML-SIG] more on DOM and namespaces In-Reply-To: Message from Alexandre of "Fri, 19 Jul 2002 17:53:45 +0200." <20020719155345.GJ5873@orion.logilab.fr> Message-ID: > Hello again, > = > I have another DOM and Namespaces questions. = > = > Is it necessary to add the xmlns attribute to an element which is > created with createElementNS ? > = > This is what I get with 4DOM: > >>> from xml.dom.ext.reader.Sax2 import Reader > >>> d =3D Reader().fromString("") > >>> e =3D d.createElementNS("bar","b:elt") > >>> d.documentElement.appendChild(e) > > >>> d.documentElement.attributes > }> > >>> e.attributes > > >>> from xml.dom.ext import PrettyPrint > >>> PrettyPrint(d) > > > > > > = > So it looks like I don't need to explicitely setAttributeNS for > namespace attributes, at least with 4DOM, but reading the DOML2 spec > =A71.1.8 didn't help me telling if theis was just a nice property of 4D= OM > or a DOM requirement. = It's a DOM L2 requirment. A node can have a namespaceURI property withou= t = having a corresponding nsdecl cttribute. -- = Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=3D6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/= xml/library/x-think11.html From Dr. Carter" Dear Sir/Ma'am: It is significantly beneficial to your local (public, private, school, col= lege, institutional, or =2E=2E=2E) library and its patrons to have a book = titled=20 "Complete Conduct Principles for the 21st Century" by Dr=2E John Newton=2E= =20 Please kindly suggest to your local library(ies) that the book be purchase= d=2E This is an easy but GREAT & respectable contribution you can make to = yourself, your family, neighborhood and society! =20 "I find it heartening that you are crusading on behalf of this worthy book= =2E It has occupied a space on our shelves for some time now=2E To have th= is book in our library is a quiet source of pride to me, the librarian=2E"= said Mr=2E Don Brusha, a highly respectable Librarian of Avon Park Librar= y in Avon Park, Florida, USA, in a letter to me regarding the book=2E This book is a MUST for EVERYONE to be better prepared for personal conduc= t for the 21st century=2E EVERY LIBRARY SHOULD HAVE IT=2E =20 You may ask yourself > How to make people respect you > How to win friends > How to let your conduct help your health, work, job, career, re= lationships, spirit, mind, well-being, =2E=2E=2E > How to make your life smoother and happier=20 > How to do whatever you like without being unpleasant to other p= eople=20 > How to develop good conduct in your children or students=20 > How to make the world peaceful and better You (and the library patrons) can find all the answers to these questions,= and much more, in this great book=2E =20 BENEFITS to each individual reader: Many! -- such as for health, work, job= , career, self-improvement, education, relationships, spirit, mind, well-b= eing, and much more -- almost all the areas that are important to you in t= he 21st century=2E People around you will benefit, too=2E (Please see the = preface of the book for details=2E)=20 EVERYONE may find this book useful and helpful, regardless of age (from ch= ildren to oldsters), occupation, rank, status, gender, religious beliefs, = nationality, country, or region=2E=20 If you are a parent or a teacher, you can learn how to develop good conduc= t in your children or students from this book=2E Please advise your childr= en or students to read the book=2E It will result in great benefits for bo= th you and them=2E=20 The book's content is obvious from its title=2E The complete useful conduc= t principles cover not only what we should do, but also what we should not= do -- especially those faults people make often and easily=2E=20 "The book will also be effective for violence prevention for the whole soc= iety=2E" said some experts=2E This timely, unique, and very important book is designed to suit most peop= le, and is self-contained and user-friendly=2E=20 This book is significantly different and better than competitive works=2E Some of its innovative contents may help solve problems that Western cultu= re cannot=2E=20 The book's merit and importance have been recognized and praised by many e= xperts, elected public officials, and world leaders=2E How to make the world peaceful and better --- You (and the library patrons) can find the solution in the book=2E Let's work together to make the world peaceful and better!=20 The author, John Newton, holds a Ph=2ED=2E from MIT, and does researches a= t Harvard=2E His long-term research on "The personal conduct in the human = society of the 21st century" resulted in this book=2E It is published by N= icer Century World Organization, headquartered beside Harvard University a= nd MIT, two leading institutes of new knowledge and literature=2E It has the Library of Congress Cataloging-in-Publication data=2E=20 Hardcover (case bound, Smyth sewn; with dust jacket) ISBN 0967370574=20 Paperback (perfect bound) ISBN 0967370582=20 Bound durably and functionally to stand up to heavy library use=2E 60 lb = natural acid-free excellent and healthful paper=2E 5=2E5inX8=2E5in=2E 192 = pages=2E Including Principle Index and General Index=2E Self-contained=2E=20= ------------------------------------------------ If you are personally interested in more information about the availabilit= y of the book and wish to request an Internet link, this section (within -= --- signs) is for you=2E Otherwise you may skip this section=2E The book is available from many fine on-line bookstores, traditional books= tores, book wholesalers, book dealers, etc=2E For your convenience, I herewith provide you with a link directly to the b= ook page in the shopping directory of Yahoo!, the world's No=2E 1 Internet= directory (Some bookstores there offer great discounts [for a limited tim= e]): http://shopping=2Eyahoo=2Ecom/shop?d=3Db&id=3D1967680641&cf=3Dsetup ------------------------------------------------- Again, please kindly suggest to your local library(ies) that the book be p= urchased=2E Also, please kindly forward this e-mail to people you know=2E Your effort to make a GREAT and respectable contribution to yourself, to y= our family and neighborhood, to people you know, and to the whole society = will be highly appreciated=2E Sincerely yours, Tom Carter, Ph=2ED=2E President, Nicer Century World Organization Massachusetts, USA (Nicer Century World Organization is an educational, non-profit, non-parti= san organization; it endeavors to make the 21st century nicer than ever be= fore=2E To accomplish its mission, Nicer Century World Organization is pro= ud to introduce this book=2E) From StillSmallVoice@DirectvInternet.com Mon Jul 22 00:53:52 2002 From: StillSmallVoice@DirectvInternet.com (Phil Glaser) Date: Sun, 21 Jul 2002 19:53:52 -0400 Subject: [XML-SIG] Accessing internal entities with minidom or 4DOM Message-ID: Hi, I am attempting to parse a an XML document and want to manipulate the internal ENTITies. I've tried with both minidom and 4DOM and am not having much luck. My doctype declaration looks like this: ]> With minidom I tried tried the following: >>> from xml.dom import minidom >>> minidoc = minidom.parse("d:\data\publications\web\UsingDocbook\usingdb.xml") >>> entities = minidoc.doctype.internalSubset >>> entities >>> print entities None If I read the documentation correctly, entities should have ended up as a list giving the internal subset. But it ends up None. With 4DOM I tried as follows: >>> from xml.dom.ext.reader import Sax2 >>> reader = Sax2.Reader() >>> doc = reader.fromStream("d:\data\publications\web\usingdocbook\usingdb.xml") >>> doc.childNodes , ]> The only documentation I could find for 4DOM (http://pyxml.sourceforge.net/topics/howto/section-DOM.html) did not give any details about how to access the internal subset, but doc.childNodes would appear to indicate that it's not seeing any entities. (If there's more documentation anywhere please let me know.) Any guidance would be greatly appreciated. Thanks! Philip Glaser Principal and Software Architect Sustainable Software Solutions, LLC StillSmallVoice@DirectvInternet.com www.sustainsoft.com 973-951-9522 From rehankhwaja@yahoo.com Mon Jul 22 03:05:22 2002 From: rehankhwaja@yahoo.com (Rehan Khwaja) Date: Sun, 21 Jul 2002 19:05:22 -0700 (PDT) Subject: [XML-SIG] Fix plus license question Message-ID: <20020722020522.74002.qmail@web9507.mail.yahoo.com> Hi, It's unclear to me what the license is for the files under demo/xbel in the pyxml package. These are all the parsing classes for msie, opera, netscape etc. I'd like to use them as part of a GPL or LGPL project. I've got the following patch for msie_parse.py in the demo/xbel directory of the pyxml package. It fixes the problem with the parser that it only opens elements and doesn't close them. *** msie_parse.orig.py Sun Jul 21 18:38:35 2002 --- msie_parse.py Sun Jul 21 18:38:27 2002 *************** *** 32,37 **** --- 32,38 ---- if os.path.isdir(fullname): self.bms.add_folder(file,None) self.__walk(subpath + [file]) + self.bms.leave_folder() else: url = self.__geturl(fullname) if url: __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From tpassin@comcast.net Mon Jul 22 03:35:31 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Sun, 21 Jul 2002 22:35:31 -0400 Subject: [XML-SIG] Fix plus license question References: <20020722020522.74002.qmail@web9507.mail.yahoo.com> Message-ID: <003c01c23128$731a46f0$fe193044@tbp1> [Rehan Khwaja] > > I've got the following patch for msie_parse.py in the > demo/xbel directory of the pyxml package. It fixes > the problem with the parser that it only opens > elements and doesn't close them. > I believe that my fix for this has already been included in CVS. It also includes a fix for another problem (the format of IE URL shortcuts seems to have changed since the original code was written, or at least some options are being used that did not used to be). Cheers, Tom P From martin@v.loewis.de Mon Jul 22 06:10:03 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 22 Jul 2002 07:10:03 +0200 Subject: [XML-SIG] Accessing internal entities with minidom or 4DOM In-Reply-To: References: Message-ID: "Phil Glaser" writes: > The only documentation I could find for 4DOM > (http://pyxml.sourceforge.net/topics/howto/section-DOM.html) did not give > any details about how to access the internal subset, but doc.childNodes > would appear to indicate that it's not seeing any entities. (If there's more > documentation anywhere please let me know.) I recommend that you read the DOM spec, at http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html Notice that there is no programmatic way to set the entities member of a DocumentType node, so an XML parser would need a private interface to the DOM implementation to set this member to a non-trivial value. In short, that aspect of the DOM is not implemented in any of the Python DOM implementations. In addition to the problems with the DOM API itself, there is also the problem that the underlying XML parser don't report the internal subset in a meaningful way. Contributions are welcome. Regards, Martin From martin@v.loewis.de Mon Jul 22 06:15:48 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 22 Jul 2002 07:15:48 +0200 Subject: [XML-SIG] Fix plus license question In-Reply-To: <20020722020522.74002.qmail@web9507.mail.yahoo.com> References: <20020722020522.74002.qmail@web9507.mail.yahoo.com> Message-ID: Rehan Khwaja writes: > It's unclear to me what the license is for the files > under demo/xbel in the pyxml package. These are all > the parsing classes for msie, opera, netscape etc. > I'd like to use them as part of a GPL or LGPL project. I think it is ok to use them in such a project. I don't think the license is properly declared; you may want to ask the original authors (Andrew Kuchling and Fred Drake) for permission. Regards, Martin From uche.ogbuji@fourthought.com Mon Jul 22 07:39:05 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 22 Jul 2002 00:39:05 -0600 Subject: [XML-SIG] Re: [4suite] Extend of cDomlette DOM API support In-Reply-To: References: Message-ID: <1027319949.31686.206.camel@malatesta> On Wed, 2002-06-12 at 21:37, L. C. Rees wrote: > Is there documentation of which DOM methods are implemented in the current version of cDomlette (I'm using 0.4.11 with Python 2.2) and which methods may be added in the future? > > One convienient method, getElementsByTagName, isn't present. Are there plans to do this sometime in the near future? Is there a substitute? I don't remember if anyone ever responded to this. Sorry if not. On Python 2.2: def doc_order_iterator(node): yield node for child in node.childNodes: for cn in doc_order_iterator(child): yield cn return def doc_order_iterator_filter(node, filter_func): if filter_func(node): yield node for child in node.childNodes: for cn in doc_order_iterator_filter(child, filter_func): if filter_func(cn): yield cn return def get_elements_by_tag_name_ns(node, ns, local): return doc_order_iterator_filter(node, lambda n: n.nodeType == Node.ELEMENT_NODE and n.namespaceURI == ns and n.localName == local) -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From StillSmallVoice@DirectvInternet.com Mon Jul 22 15:47:11 2002 From: StillSmallVoice@DirectvInternet.com (Phil Glaser) Date: Mon, 22 Jul 2002 10:47:11 -0400 Subject: [XML-SIG] Accessing internal entities with minidom or 4DOM In-Reply-To: Message-ID: Hi, > > The only documentation I could find for 4DOM > > (http://pyxml.sourceforge.net/topics/howto/section-DOM.html) > did not give > > any details about how to access the internal subset, but doc.childNodes > > would appear to indicate that it's not seeing any entities. (If > there's more > > documentation anywhere please let me know.) > > I recommend that you read the DOM spec, at > > http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html Ah, ok. I've seen this before, and should have remembered it. This is enlightening. > Notice that there is no programmatic way to set the entities member of > a DocumentType node, so an XML parser would need a private interface > to the DOM implementation to set this member to a non-trivial value. > In short, that aspect of the DOM is not implemented in any of the > Python DOM implementations. Ok, I see the problem. But according to the spec I should at least have read-only access to the internal subset. The existence of minimdom's internalSubset property lead me to believe that I should be able to do this at least with minidom, but that maybe I'm doing something wrong in my code. Or are you saying that this particular DOM Level 2 interface is not yet implemented in either minidom or 4DOM? I am grateful for your assistance. Many thanks! Regards, Phil From fdrake@acm.org Mon Jul 22 20:48:47 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 22 Jul 2002 15:48:47 -0400 Subject: [XML-SIG] Fix plus license question In-Reply-To: References: <20020722020522.74002.qmail@web9507.mail.yahoo.com> Message-ID: <15676.24991.31780.827500@grendel.zope.com> Martin v. Loewis writes: > I think it is ok to use them in such a project. I don't think the > license is properly declared; you may want to ask the original authors > (Andrew Kuchling and Fred Drake) for permission. I don't think I wrote any of the code in that directory, though I did the XBEL support for Grail (shades of late nights past...). The documentation was substantially mine, but a "license" on that should not be relevant for the use of the software. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Mon Jul 22 21:01:08 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 22 Jul 2002 16:01:08 -0400 Subject: [XML-SIG] Accessing internal entities with minidom or 4DOM In-Reply-To: References: Message-ID: <15676.25732.916302.59654@grendel.zope.com> Martin said: > Notice that there is no programmatic way to set the entities member of > a DocumentType node, so an XML parser would need a private interface > to the DOM implementation to set this member to a non-trivial value. > > In short, that aspect of the DOM is not implemented in any of the > Python DOM implementations. Not quite true, but close enough for most people. ;-) The ParsedXML DOM I wrote for Zope implements both the notations and entities attributes of the DocumentType properly (modulo not loading external entities). I expect to add this to the minidom when loaded using the new xml.dom.expatbuilder module, but that hasn't been done yet. Back to Phil: > Ok, I see the problem. But according to the spec I should at least have > read-only access to the internal subset. The existence of minimdom's > internalSubset property lead me to believe that I should be able to do this > at least with minidom, but that maybe I'm doing something wrong in my code. > Or are you saying that this particular DOM Level 2 interface is not yet > implemented in either minidom or 4DOM? The new xml.dom.expatbuilder tries pretty hard to fill in the internalSubset attribute. It only exists in CVS right now, but will be part of PyXML 0.8. If you're inclined to play with CVS, I'd certainly appreciate any comments you have on the enhancements to minidom and the xml.dom.expatbuilder module. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Mon Jul 22 21:21:07 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 22 Jul 2002 22:21:07 +0200 Subject: [XML-SIG] Accessing internal entities with minidom or 4DOM In-Reply-To: References: Message-ID: "Phil Glaser" writes: > Ok, I see the problem. But according to the spec I should at least have > read-only access to the internal subset. The existence of minimdom's > internalSubset property lead me to believe that I should be able to do this > at least with minidom, but that maybe I'm doing something wrong in my code. > Or are you saying that this particular DOM Level 2 interface is not yet > implemented in either minidom or 4DOM? That's what I'm saying, yes. Part of the problem is that both minidom and 4DOM builders use DOM API most of the time to build the DOM tree - so they can't do things that couldn't be done through the public API. In particular, if you look at the minidom implementation, there is simply no way to create a DocumentType that has a non-empty internalSubset attribute: you can't pass it to __init__ (because it accepts no such argument), and you can't modify the resulting dictionary (because it protects itself agains modification). Again, if you need such capabilities, it would be best if you implement them, and contribute your changes. Regards, Martin From mikem@ichips.intel.com Mon Jul 22 23:36:46 2002 From: mikem@ichips.intel.com (Mike F Miller) Date: Mon, 22 Jul 2002 15:36:46 -0700 Subject: [XML-SIG] comments and -- in SAX Message-ID: <200207222236.PAA18125@ichips-ra.pdx.intel.com> I've run into something in the SAX validation code that I'm not sure is entirely correct. Basically, I've got a double dash inside of a comment, and SAX doesn't seem to like it at all. Is this legal XML and SAX is legitimately complaining or am I doing something that's illegal in my XML comments? Thanks, - Mike Miller mikem@ichips.intel.com ---XML file-------------------------------------------------------------- ---Error produced (most are from my code) ------------------------------ $TCHAIN/lib/XMLDocumentHandler.py:284: in function parseFile - processing xml file mp_system.oldmax.xml $TCHAIN/lib/XMLDocumentHandler.py:284: in function parseFile - processing xml file mp_system.xml $TCHAIN/lib/XMLDocumentHandler.py:284: in function parseFile - processing xml file feed.frog.xml FATAL ERROR in feed.frog.xml:9:9: '-->' expected *************************************************************************** * * XML Errors found exiting * *************************************************************************** ------------------------------------------------------------------------- From jdnier@impressions.com Tue Jul 23 02:00:29 2002 From: jdnier@impressions.com (David Niergarth) Date: Mon, 22 Jul 2002 20:00:29 -0500 Subject: [XML-SIG] comments and -- in SAX References: <200207222236.PAA18125@ichips-ra.pdx.intel.com> Message-ID: <007701c231e4$5718e8f0$0b00c886@EP11> ["Mike F Miller" ] > I've run into something in the SAX validation code that I'm not > sure is entirely correct. Basically, I've got a double dash inside > of a comment, and SAX doesn't seem to like it at all. Is this legal > XML and SAX is legitimately complaining or am I doing something > that's illegal in my XML comments? Sorry, but neither SGML nor XML allow '--' to appear in the body of a comment. --David From fdrake@acm.org Tue Jul 23 07:02:07 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 23 Jul 2002 02:02:07 -0400 Subject: [XML-SIG] comments and -- in SAX In-Reply-To: <200207222236.PAA18125@ichips-ra.pdx.intel.com> References: <200207222236.PAA18125@ichips-ra.pdx.intel.com> <007701c231e4$5718e8f0$0b00c886@EP11> Message-ID: <15676.61791.653803.198868@grendel.zope.com> Mike F Miller writes: > Is this legal XML and SAX is legitimately complaining or am I doing > something that's illegal in my XML comments? ... > > > David Niergarth writes: > Sorry, but neither SGML nor XML allow '--' to appear in the body of a > comment. David's right, but I will point out that SGML has a slightly more complex behavior than XML. In XML, the -- is simply not allowed in comment "content", while SGML allows multiple pairs of -- ... -- to delimit "chunks" of comment content: -- -- --> Is it any wonder why there isn't an SGML-SIG? ;/ --David From martin@v.loewis.de Tue Jul 23 07:53:36 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 23 Jul 2002 08:53:36 +0200 Subject: [XML-SIG] comments and -- in SAX In-Reply-To: <200207222236.PAA18125@ichips-ra.pdx.intel.com> References: <200207222236.PAA18125@ichips-ra.pdx.intel.com> Message-ID: Mike F Miller writes: > I've run into something in the SAX validation code that I'm not > sure is entirely correct. Basically, I've got a double dash inside > of a comment, and SAX doesn't seem to like it at all. Is this legal > XML and SAX is legitimately complaining or am I doing something > that's illegal in my XML comments? It is ill-formed to use a -- in a comment in XML, "for compatibility" (that is, there is no real technical reason, but it was illegal in SGML, and to make XML a strict SGML subset, XML must carry forward this restriction). In any case, it is not "SAX" which reports this problem, but the underlying XML parser. Regards, Martin From noreply@sourceforge.net Tue Jul 23 10:19:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jul 2002 02:19:36 -0700 Subject: [XML-SIG] [ pyxml-Bugs-585316 ] Win32 v2.1.exe does not recognize Zope Message-ID: Bugs item #585316, was opened at 2002-07-23 02:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=585316&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 v2.1.exe does not recognize Zope Initial Comment: I've tried to use the PyXML installer for Python 2.1/Win32 on my Windows XP Zope 2.5.1 installation, but it doesn't recognize the Python installation there and doesn't allow to enter the path by hand. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=585316&group_id=6473 From fdrake@acm.org Tue Jul 23 12:51:02 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 23 Jul 2002 07:51:02 -0400 Subject: [XML-SIG] comments and -- in SAX In-Reply-To: <014b01c23213$e25f77b0$0b00c886@EP11> References: <200207222236.PAA18125@ichips-ra.pdx.intel.com> <007701c231e4$5718e8f0$0b00c886@EP11> <15676.61791.653803.198868@grendel.zope.com> <014b01c23213$e25f77b0$0b00c886@EP11> Message-ID: <15677.17190.858310.66953@grendel.zope.com> David Niergarth writes: > SP/nsgmls is even happy to swallow this bit as SGML without complaining: > > -- -- --> This follows the pairs rule I discussed perfectly: -- -- --> 11 11 22 22 33 33 There is no nested markup inside the comment "content", so the embedded are just more characters there, with no special meaning. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From daniell@servicefactory.se Tue Jul 23 16:40:18 2002 From: daniell@servicefactory.se (Daniel Larsson) Date: 23 Jul 2002 17:40:18 +0200 Subject: [XML-SIG] Re: [4suite] Extend of cDomlette DOM API support In-Reply-To: <1027319949.31686.206.camel@malatesta> References: <1027319949.31686.206.camel@malatesta> Message-ID: <1027438819.371.6.camel@daniell.servicefactory.se> --=-bFAkMM5nsZajSsYEGOm5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sort of unrelated, but isn't the call to filter_func inside the loop redundant in doc_order_iterator_filter? Looks like the function is applied twice on each child. Not that it normally should cause any problems... On Mon, 2002-07-22 at 08:39, Uche Ogbuji wrote: >=20 > def doc_order_iterator_filter(node, filter_func): > if filter_func(node): > yield node > for child in node.childNodes: > for cn in doc_order_iterator_filter(child, filter_func): > if filter_func(cn): # Isn't this line redundant? > yield cn > return >=20 --=20 Daniel Larsson Service Factory AB =C5rsta=E4ngsv=E4gen 17 Phone: +46 70 559 41 61 --=-bFAkMM5nsZajSsYEGOm5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQA9PXjh8CJVUq/zOt8RAiwwAJ0YG3M+LzJuE3s39gJmPwrdY9V4HwCdGx2h wIWNZKnVDpFQoxHs78c1fFo= =QGtx -----END PGP SIGNATURE----- --=-bFAkMM5nsZajSsYEGOm5-- From uche.ogbuji@fourthought.com Tue Jul 23 16:50:41 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 23 Jul 2002 09:50:41 -0600 Subject: [XML-SIG] Re: [4suite] Extend of cDomlette DOM API support In-Reply-To: <1027438819.371.6.camel@daniell.servicefactory.se> References: <1027319949.31686.206.camel@malatesta> <1027438819.371.6.camel@daniell.servicefactory.se> Message-ID: <1027439443.31684.3809.camel@malatesta> On Tue, 2002-07-23 at 09:40, Daniel Larsson wrote: > Sort of unrelated, but isn't the call to filter_func inside the loop > redundant in doc_order_iterator_filter? Looks like the function is > applied twice on each child. Not that it normally should cause any > problems... You're right. Thanks. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/library/x-think11.html From Mike Miller" Interesting behavior. Thanks for the information. I'm glad I checked with all of you before filing a bug or "fixing" it :-) - Mike Miller mikem@ichips.intel.com >David Niergarth writes: > > SP/nsgmls is even happy to swallow this bit as SGML without complaining: > > > > -- -- --> > >This follows the pairs rule I discussed perfectly: > > -- -- --> > 11 11 22 22 33 33 > >There is no nested markup inside the comment "content", so the >embedded are just more characters there, with no special >meaning. > > -Fred > >-- >Fred L. Drake, Jr. >PythonLabs at Zope Corporation > > >_______________________________________________ >XML-SIG maillist - XML-SIG@python.org >http://mail.python.org/mailman/listinfo/xml-sig From noreply@sourceforge.net Tue Jul 23 21:45:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jul 2002 13:45:28 -0700 Subject: [XML-SIG] [ pyxml-Bugs-585610 ] doesnt generate a pi Message-ID: Bugs item #585610, was opened at 2002-07-23 13:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=585610&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Lars Marius Garshol (larsga) Summary: doesnt generate a pi Initial Comment: The pi does not call handle_pi in xmlproc (it calls another callback). However, the XML specification clearly states that it is a pi, therefore handle_pi should be called even if an event is sent to another callback. XML spec 1.0: " The PI begins with a target (PITarget) used to identify the application to which the instruction is directed. The target names "XML", "xml", and so on are reserved for standardization in this or future versions of this specification. The XML Notation mechanism may be used for formal declaration of PI targets. Parameter entity references are not recognized within processing instructions." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=585610&group_id=6473 From fdrake@acm.org Tue Jul 23 22:12:38 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 23 Jul 2002 17:12:38 -0400 Subject: [XML-SIG] Expat 1.95.4 revisited In-Reply-To: <15662.1932.583815.975967@grendel.zope.com> References: <15662.1932.583815.975967@grendel.zope.com> Message-ID: <15677.50886.37751.447130@grendel.zope.com> Fred L. Drake, Jr. writes: > I'm planning to release Expat 1.95.4 tomorrow. This promises to be a > stable release that fixes a lot of minor bugs and includes more > platform support. The release has been out a week and a half, and there have been no real complaints regarding the code. I think we can consider 1.95.4 fairly stable. ;-) > What I'd like to do is: > > - modify pyexpat.c to support Expat's recent ability to return > namespace prefixes as well as namespace URIs (useful for DOM > construction), This has been done. > - update the DOM construction code, at least for the new minidom > builder, to use this to get namespace prefixes right, and This has been done. > - integrate Expat 1.95.4 into PyXML. This too has been done. > Once this is done, I'd like to see another release of PyXML go out so > that these new features get broader testing. I don't know what > version number this release should carry. I think I'm set for PyXML 0.8. I still need to look over the bug reports to see if there's anything that I can deal with easily. Does anyone else have any to-dos for 0.8? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Tue Jul 23 22:44:17 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 23 Jul 2002 17:44:17 -0400 Subject: [XML-SIG] Expat & the "default" handler Message-ID: <15677.52785.446826.567501@grendel.zope.com> There is a bug in the way Expat calls the callbacks set as DefaultHandler and DefaultHandlerExpand -- line endings are not normalized. I don't think this is a major bug, but it does cause extra work if you use the DefaultHandler or DefaultHandlerExpand callbacks. If you only use the SAX and DOM APIs, you don't need to worry about it. Is there anyone who thinks there applications will break if this is fixed? It's been in Expat a long time, so I'm a little hesitant to care about this one. ;-) The Expat bug report is here: http://sourceforge.net/tracker/index.php?func=detail&aid=585521&group_id=10127&atid=110127 -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From mike@skew.org Tue Jul 23 23:12:03 2002 From: mike@skew.org (Mike Brown) Date: Tue, 23 Jul 2002 16:12:03 -0600 (MDT) Subject: [XML-SIG] [ pyxml-Bugs-585610 ] doesnt generate a pi In-Reply-To: "from noreply@sourceforge.net at Jul 23, 2002 01:45:28 pm" Message-ID: <200207232212.g6NMC3V4022539@chilled.skew.org> > The pi does not call handle_pi in xmlproc (it > calls another callback). However, the XML specification > clearly states that it is a pi Wrong. This is a FAQ. Keep reading. Try http://www.saxproject.org/?selected=faq From uche.ogbuji@fourthought.com Wed Jul 24 00:41:14 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 23 Jul 2002 17:41:14 -0600 Subject: [XML-SIG] Expat 1.95.4 revisited In-Reply-To: Message from "Fred L. Drake, Jr." of "Tue, 23 Jul 2002 17:12:38 EDT." <15677.50886.37751.447130@grendel.zope.com> Message-ID: > > Fred L. Drake, Jr. writes: > > I'm planning to release Expat 1.95.4 tomorrow. This promises to be a > > stable release that fixes a lot of minor bugs and includes more > > platform support. > > The release has been out a week and a half, and there have been no > real complaints regarding the code. I think we can consider 1.95.4 > fairly stable. ;-) > > > What I'd like to do is: > > > > - modify pyexpat.c to support Expat's recent ability to return > > namespace prefixes as well as namespace URIs (useful for DOM > > construction), > > This has been done. > > > - update the DOM construction code, at least for the new minidom > > builder, to use this to get namespace prefixes right, and > > This has been done. > > > - integrate Expat 1.95.4 into PyXML. > > This too has been done. > > > Once this is done, I'd like to see another release of PyXML go out so > > that these new features get broader testing. I don't know what > > version number this release should carry. > > I think I'm set for PyXML 0.8. I still need to look over the bug > reports to see if there's anything that I can deal with easily. > > Does anyone else have any to-dos for 0.8? I've been planning a sweep of SF bugs before the release, and some testing with 4Suite. Just go ahead and announce the tentative release date and that will pressure me into actually getting this done :-) -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From martin@v.loewis.de Wed Jul 24 07:02:11 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 24 Jul 2002 08:02:11 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 Message-ID: I'm planning to release PyXML 0.8 in a week from now (i.e. next Wednesday or so). If you have any changes that should go into the release, please apply them now. Likewise, if you know of any patches on SF, or bug reports, that should be considered for this release, please let us know. Regards, Martin From Alexandre.Fayolle@logilab.fr Wed Jul 24 09:32:06 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 24 Jul 2002 10:32:06 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: References: Message-ID: <20020724083206.GB1839@orion.logilab.fr> On Wed, Jul 24, 2002 at 08:02:11AM +0200, Martin v. Loewis wrote: > I'm planning to release PyXML 0.8 in a week from now (i.e. next > Wednesday or so). If you have any changes that should go into the > release, please apply them now. Likewise, if you know of any patches > on SF, or bug reports, that should be considered for this release, > please let us know. Hello, Has anyone looked given a look at bug #573011? (http://sourceforge.net/tracker/index.php?func=detail&aid=573011&group_id=6473&atid=106473) I have not been able to reproduce it, but two different person submitted it on the Debian bugtracking system, there is quite possibly an issue at hand. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From gherman@darwin.in-berlin.de Wed Jul 24 10:27:56 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 24 Jul 2002 11:27:56 +0200 Subject: [XML-SIG] Test/uninstall PyXML? (Was: Preparing for PyXML 0.8) In-Reply-To: Message-ID: Martin v. Loewis: > I'm planning to release PyXML 0.8 in a week from now (i.e. next > Wednesday or so). If you have any changes that should go into the > release, please apply them now. Likewise, if you know of any patches > on SF, or bug reports, that should be considered for this release, > please let us know. Just looked into the testsuite... Is there a way to install PyXML such that one could run the test suite but not upgrade the local std. library to PyXML? Or, alternatively, how easy is it to unin- stall PyXML again (for some reason I think it's not quite easy)? Regards, Dinu From Alexandre.Fayolle@logilab.fr Wed Jul 24 10:35:52 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 24 Jul 2002 11:35:52 +0200 Subject: [XML-SIG] Test/uninstall PyXML? (Was: Preparing for PyXML 0.8) In-Reply-To: References: Message-ID: <20020724093552.GG1839@orion.logilab.fr> On Wed, Jul 24, 2002 at 11:27:56AM +0200, Dinu Gherman wrote: > Martin v. Loewis: > > >I'm planning to release PyXML 0.8 in a week from now (i.e. next > >Wednesday or so). If you have any changes that should go into the > >release, please apply them now. Likewise, if you know of any patches > >on SF, or bug reports, that should be considered for this release, > >please let us know. > > Just looked into the testsuite... Is there a way to install PyXML > such that one could run the test suite but not upgrade the local > std. library to PyXML? Or, alternatively, how easy is it to unin- > stall PyXML again (for some reason I think it's not quite easy)? Removing the _xmlplus directory should uninstall PyXML, unless I'm heavily mistaken. In order to preserve the standard xml modules, you should install pyxml to a non default directory. I usually use $ python setup.py install --prefix $HOME which causes the installation to go in ~/lib/python2.1/site-packages/_xmlplus, with ~/lib/python2.1/site-packages/ being in my PYTHONPATH. By editing the PYTHONPATH, you can switch back to the default python modules. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From walter@livinglogic.de Wed Jul 24 11:21:54 2002 From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=) Date: Wed, 24 Jul 2002 12:21:54 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 References: Message-ID: <3D3E7FC2.9060108@livinglogic.de> Martin v. Loewis wrote: > I'm planning to release PyXML 0.8 in a week from now (i.e. next > Wednesday or so). If you have any changes that should go into the > release, please apply them now. Likewise, if you know of any patches > on SF, or bug reports, that should be considered for this release, > please let us know. I'd vote for bug SF patch #412237 http://sourceforge.net/tracker/index.php?func=detail&aid=412237&group_id=6473&atid=306473 and the patch for SF bug #497322 http://sourceforge.net/tracker/index.php?func=detail&aid=497322&group_id=6473&atid=106473 Bye, Walter Dörwald From gherman@darwin.in-berlin.de Wed Jul 24 11:43:15 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 24 Jul 2002 12:43:15 +0200 Subject: [XML-SIG] Strange install issue Message-ID: <28B3014C-9EF2-11D6-B1ED-00039345C610@darwin.in-berlin.de> I'm a bit puzzled! Moving over to a new machine I found some strange errors with simple scripts handling simple XML. After a while, I've made a totally new Python 2.2.1 installation (on OS X) with only the std.lib. XML modules, but I get the traceback below. On my previous machine that worked fine, but there I also had PyXML installed... Really, all I did was to install Python with ./configure and make install... I'd like to have that running before considering to in- stall PyXML. Anybody a clue? Thanks, Dinu [localhost:~] dinu% python Python 2.2.1 (#1, Jul 24 2002, 12:15:42) [GCC 2.95.2 19991024 (release)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import xml >>> from xml.sax import make_parser >>> p = xml.sax.make_parser() Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/xml/sax/__init__.py", line 93, in make_parser raise SAXReaderNotAvailable("No parsers found", None) xml.sax._exceptions.SAXReaderNotAvailable: No parsers found >>> From akuchlin@mems-exchange.org Wed Jul 24 13:34:48 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 24 Jul 2002 08:34:48 -0400 Subject: [XML-SIG] Fix plus license question In-Reply-To: <15676.24991.31780.827500@grendel.zope.com> References: <20020722020522.74002.qmail@web9507.mail.yahoo.com> <15676.24991.31780.827500@grendel.zope.com> Message-ID: <20020724123448.GB25940@ute.mems-exchange.org> On Mon, Jul 22, 2002 at 03:48:47PM -0400, Fred L. Drake, Jr. wrote: >I don't think I wrote any of the code in that directory, though I did >the XBEL support for Grail (shades of late nights past...). The >documentation was substantially mine, but a "license" on that should >not be relevant for the use of the software. You can assume the code is under the Python 1.6 license. --amk From uche.ogbuji@fourthought.com Wed Jul 24 15:12:14 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 24 Jul 2002 08:12:14 -0600 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: Message from Alexandre of "Wed, 24 Jul 2002 10:32:06 +0200." <20020724083206.GB1839@orion.logilab.fr> Message-ID: > On Wed, Jul 24, 2002 at 08:02:11AM +0200, Martin v. Loewis wrote: > > I'm planning to release PyXML 0.8 in a week from now (i.e. next > > Wednesday or so). If you have any changes that should go into the > > release, please apply them now. Likewise, if you know of any patches > > on SF, or bug reports, that should be considered for this release, > > please let us know. > > Hello, > > Has anyone looked given a look at bug #573011? > (http://sourceforge.net/tracker/index.php?func=detail&aid=573011&group_id=6473&atid=106473) > > I have not been able to reproduce it, but two different person submitted > it on the Debian bugtracking system, there is quite possibly an issue > at hand. This is a compatability bug. Most of us don't see this because we're using the PyXML version of pyexpat. This new intern keyword arg for ParserCreate isn't even in the Python 2.2. release, so I think it should be removed, or that some better checking is done for it. I hesitate to hacka at the problem, though, without having an idea what was in mind when the arg was added. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From uche.ogbuji@fourthought.com Wed Jul 24 15:20:18 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 24 Jul 2002 08:20:18 -0600 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: Message from =?ISO-8859-1?Q?Walter_D=F6rwald?= of "Wed, 24 Jul 2002 12:21:54 +0200." <3D3E7FC2.9060108@livinglogic.de> Message-ID: > Martin v. Loewis wrote: > = > > I'm planning to release PyXML 0.8 in a week from now (i.e. next > > Wednesday or so). If you have any changes that should go into the > > release, please apply them now. Likewise, if you know of any patches > > on SF, or bug reports, that should be considered for this release, > > please let us know. > = > I'd vote for bug SF patch #412237 > = > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D412237&gro= up_id=3D6473&atid=3D306473 I applied the equivalent of diff2.txt > and the patch for SF bug #497322 > = > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D497322&gro= up_id=3D6473&atid=3D106473 Yikes! You bet I applied this one (diff.txt). Nasty typos. -- = Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=3D6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/= xml/li brary/x-think11.html From fdrake@acm.org Wed Jul 24 15:19:35 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 10:19:35 -0400 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: References: <20020724083206.GB1839@orion.logilab.fr> Message-ID: <15678.46967.836030.784176@grendel.zope.com> Uche Ogbuji writes: > This is a compatability bug. Most of us don't see this because > we're using the PyXML version of pyexpat. > > This new intern keyword arg for ParserCreate isn't even in the > Python 2.2. release, so I think it should be removed, or that some > better checking is done for it. But don't we always build our own version of pyexpat now? > I hesitate to hacka at the problem, though, without having an idea > what was in mind when the arg was added. Efficiency. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From walter@livinglogic.de Wed Jul 24 15:24:06 2002 From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=) Date: Wed, 24 Jul 2002 16:24:06 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 References: Message-ID: <3D3EB886.1060700@livinglogic.de> Uche Ogbuji wrote: >>Martin v. Loewis wrote: >> >> >>>I'm planning to release PyXML 0.8 in a week from now (i.e. next >>>Wednesday or so). If you have any changes that should go into the >>>release, please apply them now. Likewise, if you know of any patches >>>on SF, or bug reports, that should be considered for this release, >>>please let us know. >> >>I'd vote for bug SF patch #412237 >> >>http://sourceforge.net/tracker/index.php?func=detail&aid=412237&group_id=6473&atid=306473 > > > I applied the equivalent of diff2.txt > > > >>and the patch for SF bug #497322 >> >>http://sourceforge.net/tracker/index.php?func=detail&aid=497322&group_id=6473&atid=106473 > > > Yikes! You bet I applied this one (diff.txt). Nasty typos. Perfect! Thanks! Bye, Walter Dörwald From uche.ogbuji@fourthought.com Wed Jul 24 15:31:24 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 24 Jul 2002 08:31:24 -0600 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: Message from "Fred L. Drake, Jr." of "Wed, 24 Jul 2002 10:19:35 EDT." <15678.46967.836030.784176@grendel.zope.com> Message-ID: > > Uche Ogbuji writes: > > This is a compatability bug. Most of us don't see this because > > we're using the PyXML version of pyexpat. > > > > This new intern keyword arg for ParserCreate isn't even in the > > Python 2.2. release, so I think it should be removed, or that some > > better checking is done for it. > > But don't we always build our own version of pyexpat now? Apparently not in Debian. Perhaps this is actually a bug in the Debian packaging. Perhaps Jerome was extra clever and decided to disable compiling pyexpat in since Python has its own? Alexandre? Any ideas? > > I hesitate to hacka at the problem, though, without having an idea > > what was in mind when the arg was added. > > Efficiency. Smart alec :-) I was thinking more along the lines of what you said above: the person who made the change (you, I suppose) assumed PyXML always builds its own pyexpat. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From fdrake@acm.org Wed Jul 24 15:30:28 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 10:30:28 -0400 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <15678.46967.836030.784176@grendel.zope.com> References: <20020724083206.GB1839@orion.logilab.fr> <15678.46967.836030.784176@grendel.zope.com> Message-ID: <15678.47620.625924.566299@grendel.zope.com> Fred L. Drake, Jr. writes: > Efficiency. Ok, I'll say a little more than that. ;-) *Memory* efficiency. Creating a lot of Unicode objects for element and attribute names from the UTF-8 returned by Expat causes us to use many copies of the same Unicode strings. For large documents, that can make an in-memory DOM prohibitive. While using an interning dictionary only lessens the pain somewhat, it's an easy way to get some memory back without complicating the application code or the DOM implementation. It's not clear that it's as helpful for SAX applications. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Wed Jul 24 15:37:19 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 10:37:19 -0400 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: References: <15678.46967.836030.784176@grendel.zope.com> Message-ID: <15678.48031.988400.642167@grendel.zope.com> Uche Ogbuji writes: > Apparently not in Debian. Perhaps this is actually a bug in the > Debian packaging. Perhaps Jerome was extra clever and decided to > disable compiling pyexpat in since Python has its own? Alexandre? > Any ideas? Avoid excess cleverness and always use our own Expat/pyexpat? Anyone that defeats the build support we provide is on there own, and should be mercilessly hunted down with suction-cup darts. > Smart alec :-) You know me! > I was thinking more along the lines of what you said above: the > person who made the change (you, I suppose) assumed PyXML always > builds its own pyexpat. Actually, the pyexpat changes to add the interning and the xml.sax.expatreader use of that are Martin's contribution, based (at least in part) on conversations with me. I think this is something you & I also discussed at Python 10, though I don't think we talked about the SAX changes. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Alexandre.Fayolle@logilab.fr Wed Jul 24 15:54:46 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 24 Jul 2002 16:54:46 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: References: <15678.46967.836030.784176@grendel.zope.com> Message-ID: <20020724145446.GA6156@orion.logilab.fr> On Wed, Jul 24, 2002 at 08:31:24AM -0600, Uche Ogbuji wrote: > > > > Uche Ogbuji writes: > > > This is a compatability bug. Most of us don't see this because > > > we're using the PyXML version of pyexpat. > > > > > > This new intern keyword arg for ParserCreate isn't even in the > > > Python 2.2. release, so I think it should be removed, or that some > > > better checking is done for it. > > > > But don't we always build our own version of pyexpat now? > > Apparently not in Debian. Perhaps this is actually a bug in the Debian > packaging. Perhaps Jerome was extra clever and decided to disable compiling > pyexpat in since Python has its own? Alexandre? Any ideas? Well, I'm the one in charge of PyXML in Debian, now, and after looking carefully at the packaging makefile (aka debian/rules), I can see no such thing. The build step goes: python2.1 setup.py build --without-xslt python2.2 setup.py build --without-xslt which should build expat, should it not? The install step goes: python2.1 setup.py install --without-xslt --prefix=$(PYTHON21XML)/usr python2.2 setup.py install --without-xslt --prefix=$(PYTHON22XML)/usr and from then on proceeds to change some shebangs, fix access rights and remove a couple of directories. I'm baffled. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From Alexandre.Fayolle@logilab.fr Wed Jul 24 16:04:00 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 24 Jul 2002 17:04:00 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <15678.48031.988400.642167@grendel.zope.com> References: <15678.46967.836030.784176@grendel.zope.com> <15678.48031.988400.642167@grendel.zope.com> Message-ID: <20020724150400.GB6156@orion.logilab.fr> On Wed, Jul 24, 2002 at 10:37:19AM -0400, Fred L. Drake, Jr. wrote: > > Uche Ogbuji writes: > > Apparently not in Debian. Perhaps this is actually a bug in the > > Debian packaging. Perhaps Jerome was extra clever and decided to > > disable compiling pyexpat in since Python has its own? Alexandre? > > Any ideas? > > Avoid excess cleverness and always use our own Expat/pyexpat? Anyone > that defeats the build support we provide is on there own, and should > be mercilessly hunted down with suction-cup darts. Yay! As I said in my previous mail, I really don't think I'm being overly clever in that regard, espacially since I don't know the innards of the expat building support (and certainly havce no envy of messing with them) I'll forward a couple of mails I exchanged with someone affecged by the bug to the list. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From fdrake@acm.org Wed Jul 24 16:04:09 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 11:04:09 -0400 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <20020724145446.GA6156@orion.logilab.fr> References: <15678.46967.836030.784176@grendel.zope.com> <20020724145446.GA6156@orion.logilab.fr> Message-ID: <15678.49641.862185.40718@grendel.zope.com> Alexandre writes: > I'm baffled. Here's another question: Is the Python on Debian built with the pyexpat extension (not the Expat library) built statically into the Python executable, or is it dynamically loaded? I'm not sure this matters as long as PyXML provides .../site-packages/_xmlplus/parsers/pyexpat.so, though. Can you verify that in the installation as well? Thanks! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Alexandre.Fayolle@logilab.fr Wed Jul 24 16:05:01 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 24 Jul 2002 17:05:01 +0200 Subject: [XML-SIG] expat and python 2.2 debian bug Message-ID: <20020724150501.GC6156@orion.logilab.fr> Here's a request for precision I sent to the person who reported the bug. ----- Forwarded message from Alexandre ----- From: Alexandre To: Jenya , 150565@bugs.debian.org Date: Wed, 10 Jul 2002 19:14:42 +0200 Subject: Bug#150565: Bug#150763: python2.2-xml: in /sax/expatreader.py, expat.ParserCreate takes wrong number of arguments I'm sorry I was not able to reproduce your bug. Could you send me the output of the following python script: from xml.parsers import expat print expat from xml.parsers import pyexpat print pyexpat print pyexpat.__version__ print pyexpat.version_info What I get here with a fresh installation is: 2.58 (1, 95, 2) Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). ----- End forwarded message ----- -- Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From Alexandre.Fayolle@logilab.fr Wed Jul 24 16:05:33 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 24 Jul 2002 17:05:33 +0200 Subject: [XML-SIG] expath and python2.2 debian bug Message-ID: <20020724150533.GD6156@orion.logilab.fr> Here's the answer I received. ----- Forwarded message from Jenya ----- From: Jenya To: Alexandre Date: Wed, 10 Jul 2002 21:03:12 +0300 Subject: Re: Bug#150763: python2.2-xml: in /sax/expatreader.py, expat.ParserCreate takes wrong number of arguments Here the output : ------------------ Traceback (most recent call last): File "1", line 3, in ? from xml.parsers import pyexpat ImportError: cannot import name pyexpat ------------------------- but if i do it a bit different, then : >>> import pyexpat >>> print pyexpat >>> print pyexpat.__version__ 2.57 >>> print pyexpat.version_info (1, 95, 2) >>> my version of python2.2-xmlbase seems to be 2.2.1-5 Regards, Evgeny On Wednesday 10 July 2002 20:14, you wrote: > I'm sorry I was not able to reproduce your bug. > > Could you send me the output of the following python script: > > from xml.parsers import expat > print expat > from xml.parsers import pyexpat > print pyexpat > print pyexpat.__version__ > print pyexpat.version_info > > What I get here with a fresh installation is: > > '/usr/lib/python2.2/site-packages/_xmlplus/parsers/expat.pyc'> > '/usr/lib/python2.2/site-packages/_xmlplus/parsers/pyexpat.so'> > 2.58 > (1, 95, 2) > > Alexandre Fayolle ----- End forwarded message ----- -- Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From fdrake@acm.org Wed Jul 24 16:22:43 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 11:22:43 -0400 Subject: [XML-SIG] expath and python2.2 debian bug In-Reply-To: <20020724150533.GD6156@orion.logilab.fr> References: <20020724150533.GD6156@orion.logilab.fr> Message-ID: <15678.50755.591228.94570@grendel.zope.com> Alexandre writes: > Here's the answer I received. ... > Here the output : > ------------------ > '/usr/lib/python2.2/site-packages/_xmlplus/parsers/expat.pyc'> > Traceback (most recent call last): > File "1", line 3, in ? > from xml.parsers import pyexpat > ImportError: cannot import name pyexpat > ------------------------- This installation does not have a PyXML-provided pyexpat. Hmm. I'm not sure what release started to always build pyexpat... ah, the log tells me that we added that *after* 0.7.1 was released! So, this is a real bug in 0.7.1, but has already been fixed in CVS by ensuring we always provide a pyexpat that supports the intern keyword on ParserCreate(). I'll close the bug as "fixed in CVS". -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Alexandre.Fayolle@logilab.fr Wed Jul 24 16:41:37 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 24 Jul 2002 17:41:37 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <15678.49641.862185.40718@grendel.zope.com> References: <15678.46967.836030.784176@grendel.zope.com> <20020724145446.GA6156@orion.logilab.fr> <15678.49641.862185.40718@grendel.zope.com> Message-ID: <20020724154137.GA6875@orion.logilab.fr> On Wed, Jul 24, 2002 at 11:04:09AM -0400, Fred L. Drake, Jr. wrote: > > Alexandre writes: > > I'm baffled. > > Here's another question: Is the Python on Debian built with the > pyexpat extension (not the Expat library) built statically into the > Python executable, or is it dynamically loaded? usr/lib/python2.2/lib-dynload/pyexpat.so is provided by python2.2-xmlbase, so we have it as a dynamic library. > I'm not sure this matters as long as PyXML provides > .../site-packages/_xmlplus/parsers/pyexpat.so, though. Can you verify > that in the installation as well? When I build it on my machine, I get this file for both python2.1 and python2.2. I've checked in the the debian archive, and the file is missing in the python2.2 package. So it looks like different build configuration give different results. I'll have to sort this out with Jerome Marant (who rebuilds the packages before uploading them). My opinion is that this is a pure debian packaging bug, and that we can safely close it on the PyXML bug tracker. Now if someone here has an idea of what could cause pyexpat.so not to be built on some machines, I'd be very interested. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From Alexandre.Fayolle@logilab.fr Wed Jul 24 16:44:12 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 24 Jul 2002 17:44:12 +0200 Subject: [XML-SIG] expath and python2.2 debian bug In-Reply-To: <15678.50755.591228.94570@grendel.zope.com> References: <20020724150533.GD6156@orion.logilab.fr> <15678.50755.591228.94570@grendel.zope.com> Message-ID: <20020724154412.GB6875@orion.logilab.fr> On Wed, Jul 24, 2002 at 11:22:43AM -0400, Fred L. Drake, Jr. wrote: > > Alexandre writes: > > Here's the answer I received. > ... > > Here the output : > > ------------------ > > > '/usr/lib/python2.2/site-packages/_xmlplus/parsers/expat.pyc'> > > Traceback (most recent call last): > > File "1", line 3, in ? > > from xml.parsers import pyexpat > > ImportError: cannot import name pyexpat > > ------------------------- > > This installation does not have a PyXML-provided pyexpat. Hmm. I'm > not sure what release started to always build pyexpat... ah, the log > tells me that we added that *after* 0.7.1 was released! > > So, this is a real bug in 0.7.1, but has already been fixed in CVS by > ensuring we always provide a pyexpat that supports the intern keyword > on ParserCreate(). > > I'll close the bug as "fixed in CVS". Well. I'll fix this when I upload python-xml-0.8, then. Thanks for your answers. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From fdrake@acm.org Wed Jul 24 16:51:20 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 11:51:20 -0400 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <20020724154137.GA6875@orion.logilab.fr> References: <15678.46967.836030.784176@grendel.zope.com> <20020724145446.GA6156@orion.logilab.fr> <15678.49641.862185.40718@grendel.zope.com> <20020724154137.GA6875@orion.logilab.fr> Message-ID: <15678.52472.561046.292768@grendel.zope.com> Alexandre writes: > I've checked in the the debian archive, and the file is missing in the > python2.2 package. So it looks like different build configuration give > different results. I'll have to sort this out with Jerome Marant (who > rebuilds the packages before uploading them). For PyXML 0.7.1 and earlier, setup.py tried to magically determine if it was needed, and if a pyexpat from Python was considered "good enough", it didn't get built. Clearly, keeping the check for "good enough" up to date is a maintenance problem, which we now avoid. > My opinion is that this is a pure debian packaging bug, and that we can > safely close it on the PyXML bug tracker. Done. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Wed Jul 24 18:38:46 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 24 Jul 2002 11:38:46 -0600 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: Message from "Fred L. Drake, Jr." of "Wed, 24 Jul 2002 10:37:19 EDT." <15678.48031.988400.642167@grendel.zope.com> Message-ID: > > Uche Ogbuji writes: > > Apparently not in Debian. Perhaps this is actually a bug in the > > Debian packaging. Perhaps Jerome was extra clever and decided to > > disable compiling pyexpat in since Python has its own? Alexandre? > > Any ideas? > > Avoid excess cleverness and always use our own Expat/pyexpat? Anyone > that defeats the build support we provide is on there own, and should > be mercilessly hunted down with suction-cup darts. This one looks put to bed. > > Smart alec :-) > > You know me! > > > I was thinking more along the lines of what you said above: the > > person who made the change (you, I suppose) assumed PyXML always > > builds its own pyexpat. > > Actually, the pyexpat changes to add the interning and the > xml.sax.expatreader use of that are Martin's contribution, based (at > least in part) on conversations with me. I think this is something > you & I also discussed at Python 10, though I don't think we talked > about the SAX changes. Yes. I knew we wanted to start interning: at IPC10 Mike and I mentioned we already do this in cDomlette. That's still not what I meant by understanding what you or Martin had in mind. You can still add interning and provide fall-back modes for systems that can't support it. I didn't know whether the person who wrote the code knew more than I do about not needing such fall-backs. It turns out that they did know more than I did: they knew that PyXML in future releases will always build its own expat. Anyway, this issue looks all sorted out now. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From fdrake@acm.org Wed Jul 24 19:03:04 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 14:03:04 -0400 Subject: [XML-SIG] sgmlop changes cause test breakage Message-ID: <15678.60376.177023.823061@grendel.zope.com> I don't know how other people are testing their changes to PyXML, but running "make check" really works if you install enough versions of Python. ;-) This morning's changes to extensions/sgmlop.c cause warnings and failing tests: python2.0 setup.py -q build extensions/sgmlop.c: In function `fastfeed': extensions/sgmlop.c:1246: warning: implicit declaration of function `PyUnicode_GetMax' python2.1 setup.py -q build extensions/sgmlop.c: In function `fastfeed': extensions/sgmlop.c:1246: warning: implicit declaration of function `PyUnicode_GetMax' PyUnicode_GetMax() was introduced in Python 2.2. Are we not still trying to support from Python 2.0 forward? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Wed Jul 24 19:15:11 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 24 Jul 2002 20:15:11 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <20020724154137.GA6875@orion.logilab.fr> References: <15678.46967.836030.784176@grendel.zope.com> <20020724145446.GA6156@orion.logilab.fr> <15678.49641.862185.40718@grendel.zope.com> <20020724154137.GA6875@orion.logilab.fr> Message-ID: Alexandre writes: > Now if someone here has an idea of what could cause pyexpat.so not to be > built on some machines, I'd be very interested. In PyXML 0.7, setup.py looks at the pyxml version that comes with Python, and might decide not to build pyexpat. It might be that PyXML erroneously decides not to build pyexpat. This problem will go away in 0.8, since pyexpat is always built. Regards, Martin From Mike.Olson@fourthought.com Wed Jul 24 19:13:13 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 24 Jul 2002 12:13:13 -0600 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: References: Message-ID: <1027534405.4700.125.camel@penny> On Wed, 2002-07-24 at 00:02, Martin v. Loewis wrote: > I'm planning to release PyXML 0.8 in a week from now (i.e. next > Wednesday or so). If you have any changes that should go into the > release, please apply them now. Likewise, if you know of any patches > on SF, or bug reports, that should be considered for this release, > please let us know. I have the couple of changes the Frad and I talked about that I'd like to get in. I'll work on them today. Mike > > Regards, > Martin > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From martin@v.loewis.de Wed Jul 24 19:23:10 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 24 Jul 2002 20:23:10 +0200 Subject: [XML-SIG] Test/uninstall PyXML? (Was: Preparing for PyXML 0.8) In-Reply-To: <20020724093552.GG1839@orion.logilab.fr> References: <20020724093552.GG1839@orion.logilab.fr> Message-ID: Alexandre writes: > Removing the _xmlplus directory should uninstall PyXML, unless I'm > heavily mistaken. Correct (although this leaves alone the scripts - can be safely overwritten with a new install). In addition, one could use the packaging mechanisms: Perform "setup.py bdist_rpm", then "rpm -i PyXML-0.8" to install, and "rpm -e PyXML" to uninstall; likewise on Windows. Regards, Martin From martin@v.loewis.de Wed Jul 24 19:25:09 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 24 Jul 2002 20:25:09 +0200 Subject: [XML-SIG] Strange install issue In-Reply-To: <28B3014C-9EF2-11D6-B1ED-00039345C610@darwin.in-berlin.de> References: <28B3014C-9EF2-11D6-B1ED-00039345C610@darwin.in-berlin.de> Message-ID: Dinu Gherman writes: > I'm a bit puzzled! Moving over to a new machine I found some strange > errors with simple scripts handling simple XML. After a while, I've > made a totally new Python 2.2.1 installation (on OS X) with only the > std.lib. XML modules, but I get the traceback below. On my previous > machine that worked fine, but there I also had PyXML installed... > > Really, all I did was to install Python with ./configure and make > install... I'd like to have that running before considering to in- > stall PyXML. Anybody a clue? There really is no XML parser in the standard Python distribution. Python offers the pyexpat module, but does not (yet) include Expat itself. So you need an Expat installation first. I'm not sure whether Python's setup.py will correctly find Expat on OS X; you might need to edit Modules/Setup. Regards, Martin From walter@livinglogic.de Wed Jul 24 19:46:27 2002 From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=) Date: Wed, 24 Jul 2002 20:46:27 +0200 Subject: [XML-SIG] sgmlop changes cause test breakage References: <15678.60376.177023.823061@grendel.zope.com> Message-ID: <3D3EF603.5020606@livinglogic.de> Fred L. Drake, Jr. wrote: > I don't know how other people are testing their changes to PyXML, but > running "make check" really works if you install enough versions of > Python. ;-) > > This morning's changes to extensions/sgmlop.c cause warnings and > failing tests: > > python2.0 setup.py -q build > extensions/sgmlop.c: In function `fastfeed': > extensions/sgmlop.c:1246: warning: implicit declaration of function `PyUnicode_GetMax' > python2.1 setup.py -q build > extensions/sgmlop.c: In function `fastfeed': > extensions/sgmlop.c:1246: warning: implicit declaration of function `PyUnicode_GetMax' > > PyUnicode_GetMax() was introduced in Python 2.2. Are we not still > trying to support from Python 2.0 forward? I've uploaded a new patch to bug #497322 that should fix the problem. I hope that UCS4 support was introduced to Python at the same time as PyUnicode_GetMax(), otherwise the overflow check will get more complicated. Bye, Walter Dörwald From fdrake@acm.org Wed Jul 24 19:57:35 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 14:57:35 -0400 Subject: [XML-SIG] sgmlop changes cause test breakage In-Reply-To: <3D3EF603.5020606@livinglogic.de> References: <15678.60376.177023.823061@grendel.zope.com> <3D3EF603.5020606@livinglogic.de> Message-ID: <15678.63647.990720.951131@grendel.zope.com> =?ISO-8859-1?Q?Walter_D=F6rwald?= writes: > I've uploaded a new patch to bug #497322 that should fix the problem. I've checked in a different patch; see my comments in the tracker if you're interested in why. ;-) > I hope that UCS4 support was introduced to Python at the same time > as PyUnicode_GetMax(), otherwise the overflow check will get more > complicated. That's right. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From gherman@darwin.in-berlin.de Wed Jul 24 20:24:51 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 24 Jul 2002 21:24:51 +0200 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: Message-ID: <067D37FD-9F3B-11D6-A12D-00039345C610@darwin.in-berlin.de> Martin v. Loewis: > There really is no XML parser in the standard Python > distribution. Python offers the pyexpat module, but does not (yet) > include Expat itself. So you need an Expat installation first. Well, that's the miracle for me! Why is there no expat in standard Python, then? If it comes with PyXML, there cannot be any licensing issue. And then it could equally well be included in Python, couldn't it? Dinu From fdrake@acm.org Wed Jul 24 20:28:26 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 15:28:26 -0400 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: <067D37FD-9F3B-11D6-A12D-00039345C610@darwin.in-berlin.de> References: <067D37FD-9F3B-11D6-A12D-00039345C610@darwin.in-berlin.de> Message-ID: <15678.65498.15774.418385@grendel.zope.com> Dinu Gherman writes: > Well, that's the miracle for me! Why is there no expat in standard > Python, then? If it comes with PyXML, there cannot be any licensing > issue. And then it could equally well be included in Python, > couldn't it? Relax, Dinu! ;-) Guido seriously avoids checking in code to the Python CVS that needs to be updated periodically and which he doesn't feel he should maintain. We've finally convinced him that Expat should be incorporated into Python and assured to be present; this has been done for Python 2.3, primarily due to Martin's efforts. Python on Windows has been shipping the Expat DLLs for a while now, so this wasn't a problem for Python on Windows. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Wed Jul 24 20:45:16 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 24 Jul 2002 13:45:16 -0600 Subject: [XML-SIG] sgmlop changes cause test breakage In-Reply-To: Message from "Fred L. Drake, Jr." of "Wed, 24 Jul 2002 14:03:04 EDT." <15678.60376.177023.823061@grendel.zope.com> Message-ID: > > I don't know how other people are testing their changes to PyXML, but > running "make check" really works if you install enough versions of > Python. ;-) > > This morning's changes to extensions/sgmlop.c cause warnings and > failing tests: > > python2.0 setup.py -q build > extensions/sgmlop.c: In function `fastfeed': > extensions/sgmlop.c:1246: warning: implicit declaration of function `PyUnicode_GetMax' > python2.1 setup.py -q build > extensions/sgmlop.c: In function `fastfeed': > extensions/sgmlop.c:1246: warning: implicit declaration of function `PyUnicode_GetMax' > > PyUnicode_GetMax() was introduced in Python 2.2. Are we not still > trying to support from Python 2.0 forward? Sorry. I only checked with Python 2.2 -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ The many heads of XML modeling - http://adtmag.com/article.asp?id=6393 Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li brary/x-think11.html From Juergen Hermann" Hi! I noticed today that xmlproc of pyxml 0.7.1 fails to call the endDTD event of the lexical-handler interface (startDTD is called!). Any more information needed, or is this a known & fixed error? Ciao, J=FCrgen From fdrake@acm.org Wed Jul 24 20:56:24 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 15:56:24 -0400 Subject: [XML-SIG] xmlproc 0.7.1 fails to call endDTD event In-Reply-To: References: Message-ID: <15679.1640.802357.148514@grendel.zope.com> Juergen Hermann writes: > I noticed today that xmlproc of pyxml 0.7.1 fails to call the endDTD > event of the lexical-handler interface (startDTD is called!). Any more > information needed, or is this a known & fixed error? There's an open report on this: http://sourceforge.net/tracker/index.php?func=detail&aid=508378&group_id=6473&atid=106473 -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Wed Jul 24 21:27:31 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 24 Jul 2002 22:27:31 +0200 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: <067D37FD-9F3B-11D6-A12D-00039345C610@darwin.in-berlin.de> References: <067D37FD-9F3B-11D6-A12D-00039345C610@darwin.in-berlin.de> Message-ID: Dinu Gherman writes: > Well, that's the miracle for me! Why is there no expat in standard > Python, then? If it comes with PyXML, there cannot be any licensing > issue. And then it could equally well be included in Python, > couldn't it? That alone is no reason. Python provides _tkinter.c, yet does not incorporate Tcl/Tk - even though there would be no licensing problems. Likewise, it does not include OpenSSL (even though it integrates with OpenSSL, and there would be no licensing problems), or the FORMS library. At Python 2.0, people were complaining about the size of the new XML libraries, so adding Expat was out of question. Even when I added Expat for inclusion into Python 2.3 to the Python CVS, people where objecting that Expat now gets a superior position with respect to other XML parsers. It's a miracle for me that you are not asking why xmlproc isn't included in Python, even though it is pure Python! Regards, Martin From gherman@darwin.in-berlin.de Wed Jul 24 22:10:29 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 24 Jul 2002 23:10:29 +0200 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: <15678.65498.15774.418385@grendel.zope.com> Message-ID: Fred L. Drake, Jr.: > Relax, Dinu! ;-) I'm doing my best! > Guido seriously avoids checking in code to the Python CVS that needs > to be updated periodically and which he doesn't feel he should > maintain. We've finally convinced him that Expat should be > incorporated into Python and assured to be present; this has been > done for Python 2.3, primarily due to Martin's efforts. Good! I really hope it hasn't taken him 10 years, like it happened in the totally unrelated case of Boolean datatypes... ;-) > Python on Windows has been shipping the Expat DLLs for a while now, > so this wasn't a problem for Python on Windows. That *is* part of the problem. I really don't like inconsistencies. I can stand them if there is a good reason for their existence, but it should be very clearly indicated. In this case I'm not sure they are. I'll check your book again, to see what it says on that point! ;-) Dinu From gherman@darwin.in-berlin.de Wed Jul 24 22:12:20 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 24 Jul 2002 23:12:20 +0200 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: Message-ID: <0A2C4711-9F4A-11D6-A12D-00039345C610@darwin.in-berlin.de> Martin v. Loewis: > Dinu Gherman writes: > >> Well, that's the miracle for me! Why is there no expat in standard >> Python, then? If it comes with PyXML, there cannot be any licensing >> issue. And then it could equally well be included in Python, >> couldn't it? > > That alone is no reason. Python provides _tkinter.c, yet does not > incorporate Tcl/Tk - even though there would be no licensing > problems. Likewise, it does not include OpenSSL (even though it > integrates with OpenSSL, and there would be no licensing problems), > or the FORMS library. I hope that the PBF snake farm will eventually be able to make personalised Python distributions of variable sizes on the fly. Until then, concerning Python's XML support, I'll reiterate that it still surprises me to see packaging issues dominating over application issues in what is considered to be a key area for old and new Python users. > At Python 2.0, people were complaining about the size of the new XML > libraries, so adding Expat was out of question. Even when I added > Expat for inclusion into Python 2.3 to the Python CVS, people where > objecting that Expat now gets a superior position with respect to > other XML parsers. Jim's compressed expat archive has a 150 KB footprint, PyXML 0.7.1 has one of 600 KB (apparently including expat) - so what? > It's a miracle for me that you are not asking why xmlproc isn't > included in Python, even though it is pure Python! As you should well know, one argument of all Python evangelists is the label "batteries included". Quite franky, in times of cheap Gigabyte drives and ADSL, I'd expect most people to care more about wasting their time than about a few more KB... Regards, Dinu From fdrake@acm.org Wed Jul 24 22:15:45 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 17:15:45 -0400 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: References: <15678.65498.15774.418385@grendel.zope.com> Message-ID: <15679.6401.960393.301970@grendel.zope.com> Dinu Gherman writes: > That *is* part of the problem. I really don't like inconsistencies. > I can stand them if there is a good reason for their existence, > but it should be very clearly indicated. In this case I'm not sure > they are. I'll check your book again, to see what it says on that > point! ;-) There's not much about versioning in the book; perhaps there should have been more, but we wanted to stay away from things that would date the book too quickly. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Wed Jul 24 22:18:56 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 17:18:56 -0400 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: <0A2C4711-9F4A-11D6-A12D-00039345C610@darwin.in-berlin.de> References: <0A2C4711-9F4A-11D6-A12D-00039345C610@darwin.in-berlin.de> Message-ID: <15679.6592.312483.840672@grendel.zope.com> Dinu Gherman writes: > Jim's compressed expat archive has a 150 KB footprint, PyXML 0.7.1 > has one of 600 KB (apparently including expat) - so what? What's "Jim's compressed expat archive" ? > As you should well know, one argument of all Python evangelists is > the label "batteries included". Quite franky, in times of cheap > Gigabyte drives and ADSL, I'd expect most people to care more > about wasting their time than about a few more KB... But we still get a lot of complaints about the size of the Python installer for Windows, even though there are a lot of mirror sites. So it's not at all clear that it's so clear cut. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From gherman@darwin.in-berlin.de Wed Jul 24 22:24:33 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 24 Jul 2002 23:24:33 +0200 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: <15679.6592.312483.840672@grendel.zope.com> Message-ID: Fred L. Drake, Jr.: > > What's "Jim's compressed expat archive" ? ftp://ftp.jclark.com/pub/xml/expat.zip Dinu From fdrake@acm.org Wed Jul 24 22:26:55 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Jul 2002 17:26:55 -0400 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: References: <15679.6592.312483.840672@grendel.zope.com> Message-ID: <15679.7071.755184.523648@grendel.zope.com> Dinu Gherman writes: > ftp://ftp.jclark.com/pub/xml/expat.zip I don't think I've ever heard James Clark called "Jim" before. ;-) I was wondering if Jim Fulton was distributing something I didn't know about. The current versions of Expat are larger, with the 1.95.4 source archive being 257 Kb: http://sourceforge.net/project/showfiles.php?group_id=10127 -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Wed Jul 24 22:47:56 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 24 Jul 2002 23:47:56 +0200 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: <0A2C4711-9F4A-11D6-A12D-00039345C610@darwin.in-berlin.de> References: <0A2C4711-9F4A-11D6-A12D-00039345C610@darwin.in-berlin.de> Message-ID: Dinu Gherman writes: > Until then, concerning Python's XML support, I'll reiterate that > it still surprises me to see packaging issues dominating over > application issues in what is considered to be a key area for > old and new Python users. At the time the XML libraries were integrated, nobody suggested to incorporate Expat (check the archives). It is always easy to appear smart from the historical perspective :-( I really hate arguing at some point with people to explain them why things should be done in some way, and then, if they are done in a different way, to explain people why they have been done that way. Does it really surprise you that people are human beings, instead of being omnipotent? Besides, what is the point of pointing out your surprise? Regards, Martin From Mike.Olson@fourthought.com Wed Jul 24 23:38:25 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 24 Jul 2002 16:38:25 -0600 Subject: [XML-SIG] minidom changes Message-ID: <1027550306.4699.133.camel@penny> I'm going to check in my minidom changes so that 0.8 mostly works with XPath and Xslt (I'll explain more latter). I have a question first. When does the version string in xml get updated, at the time of the release? Is there a chance that we can get it changed now. If not there will be problems with people using CVS versions of both PyXML and 4Suite as the version of xml is the only key I have on what fixups to make. Here is a list of changes that I'll be checking in. Most are pretty minor interface additions. * Added childNodes to Attr. It was there but always empty, now all Attrs will have one child Text node with the nodeValue * Added empty localName and prefix on all nodes. * Added a specified attribute to Attrs. * modified createDocument on DOMImplementation. Dom Level III states that if the namespace, qname and doctype are Null then the document is created without a document element. Also removed the creation of a default doctype if the parameter is None as Dom also states that a Null doctype is valid. This is probably the most contriversial of all of my changes. * modifed the __setattr__ on Character data to update both the nodeValue and data when modified. * Changed ownerDoc to ownerDocument in createDocumentFragment * Changed so Comment inherits from CharacterData * Modified __setattr__ on processing Instruction to allow mutation of target. * Rewrote cloneNode. The cloneNode that was there only worked with nodes that were python instances (not cDomlette). The rewrite is one that I had for pDomlette so I just ported it over. It is also designed to work for importNode as well (hence the need for cloning cDomlette). * Added importNode to document. * Changed EmptyNodeList to return a list not a tuple. I kinda understand why this returned a tuple (speed, no mutation), but it breaks code in Xslt because you cannot do [] + () which we do a fair amount. There are four changes I did not add to minidom that are still in our abstraction module. I can add them if everyone thinks they are acceptable. 1. allow a data argument to the constructor of Text. 2. Dictionary interface on ReadOnlySequentialNamedNodeMap 3. module level implementation variable. 4. Changed all of the dictionary access methods on NamedNodeMap to access the NS values. Example, currently, keys() access self.__attrs and keysNS() access self._attrsNS. Since 4Suite is NS only, all of our code calls keys() and expects to get back the NS attributes. Checking in now. Mike -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From Mike.Olson@fourthought.com Thu Jul 25 00:07:49 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 24 Jul 2002 17:07:49 -0600 Subject: [XML-SIG] minidom changes In-Reply-To: <1027550306.4699.133.camel@penny> References: <1027550306.4699.133.camel@penny> Message-ID: <1027552071.4699.137.camel@penny> On Wed, 2002-07-24 at 16:38, Mike Olson wrote: > > I'm going to check in my minidom changes so that 0.8 mostly works with > XPath and Xslt (I'll explain more latter). I have a question first. > When does the version string in xml get updated, at the time of the > release? Is there a chance that we can get it changed now. If not > there will be problems with people using CVS versions of both PyXML and > 4Suite as the version of xml is the only key I have on what fixups to > make. Never mind, this was changed today while I was coding. Mike -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From gherman@darwin.in-berlin.de Thu Jul 25 07:53:12 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Thu, 25 Jul 2002 08:53:12 +0200 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: Message-ID: <2FF343A6-9F9B-11D6-A12D-00039345C610@darwin.in-berlin.de> Martin v. Loewis: > At the time the XML libraries were integrated, nobody suggested to > incorporate Expat (check the archives). It is always easy to appear > smart from the historical perspective :-( > > I really hate arguing at some point with people to explain them why > things should be done in some way, and then, if they are done in a > different way, to explain people why they have been done that way. There must be a missing sentence here or something, otherwise I can't believe that statement! You say why you do X, but do Y and hate to say why? ;-) It would make more sense if it is not you in both cases. > Does it really surprise you that people are human beings, instead of > being omnipotent? Besides, what is the point of pointing out your > surprise? Before we get totally off-track here: I do know the difference between software and people. Unlike people, software can be in- finitely changed, while it is much more difficult for people to reconsider their own decisions. In this case that means, std. Python XML is worth less for me than I thought. I was confused because on Windows nothing indi- cated to me it had more "batteries" than on other platforms, and on Unix I erroneously thought it was included because once I tried PyXML, but for some reasons uninstalled it again (which very likely means expat was still there, afterwards). All this has implications for distributing software building on add-ons. I once asked you of how many companies/products you know which were really using PyXML and you said none, remember? I'm just reporting "user experience", which one is rarely able to point out when things are "integrated", but only when star- ting to "use" them. If this information is useless to you, it's been worth for me to find out. Regards, Dinu From martin@v.loewis.de Thu Jul 25 08:22:52 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 25 Jul 2002 09:22:52 +0200 Subject: [XML-SIG] Expat (Was: Strange install issue) In-Reply-To: <2FF343A6-9F9B-11D6-A12D-00039345C610@darwin.in-berlin.de> References: <2FF343A6-9F9B-11D6-A12D-00039345C610@darwin.in-berlin.de> Message-ID: Dinu Gherman writes: > > I really hate arguing at some point with people to explain them why > > things should be done in some way, and then, if they are done in a > > different way, to explain people why they have been done that way. > > There must be a missing sentence here or something, otherwise > I can't believe that statement! You say why you do X, but do > Y and hate to say why? ;-) It would make more sense if it is > not you in both cases. No. I hate having to explain this over and over again, to everybody who was not originally involved when Y was done instead of X. > I was confused because on Windows nothing indicated to me it had > more "batteries" than on other platforms, and on Unix I erroneously > thought it was included because once I tried PyXML, but for some > reasons uninstalled it again (which very likely means expat was > still there, afterwards). I guess you are still confused about that. Most likely, on your Unix system, the Python installation did have a pyexpat module - atleast if that Unix system was Linux, since then an expat library came with the system, and was found while Python was built. > I once asked you of how many companies/products you know which > were really using PyXML and you said none, remember? Correct. As I explained at that time, I don't know any company who is using XML in the first place, mainly because I don't know details of organizations other than my own (I think we were talking about German companies at that time). > I'm just reporting "user experience", which one is rarely able > to point out when things are "integrated", but only when star- > ting to "use" them. If this information is useless to you, it's > been worth for me to find out. I'm indeed not certain what to make out of this information. If you think anything should be done now, please say so. If you think anything should have been done in the past - I don't know how to react to that other than to express my sympathy. Regards, Martin From fdrake@acm.org Thu Jul 25 17:18:07 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 25 Jul 2002 12:18:07 -0400 Subject: [XML-SIG] minidom changes In-Reply-To: <1027550306.4699.133.camel@penny> References: <1027550306.4699.133.camel@penny> Message-ID: <15680.9407.40539.296654@grendel.zope.com> Mike Olson writes: > I'm going to check in my minidom changes so that 0.8 mostly works with > XPath and Xslt (I'll explain more latter). I have a question first. The tests fail for me for Python versions 2.0.1, 2.1.3, 2.2.1, and 2.3a0 (CVS). This is with a completely fresh build of PyXML. Here's the output of "make check": ------------------------------------------------------------------------ python2.0 setup.py -q build python2.1 setup.py -q build python2.2 setup.py -q build python2.3 setup.py -q build cd test && PYTHONPATH=../build/lib.linux-i686-2.0 python2.0 testxml.py Traceback (most recent call last): File "test_minidom.py", line 773, in ? func() File "test_minidom.py", line 534, in testUserData c = n.cloneNode(1) File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.0/_xmlplus/dom/minidom.py", line 186, in cloneNode clone = CloneNode(self,deep,self.ownerDocument or self) File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.0/_xmlplus/dom/minidom.py", line 1221, in CloneNode clone = newOwnerDocument.createElementNS(node.namespaceURI, File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.0/_xmlplus/dom/minicompat.py", line 134, in __getattr__ raise AttributeError, key AttributeError: createElementNS test_c14n test_dom test_encodings test_filter test_howto test_htmlb test_javadom test_marshal test test_marshal failed -- Writing: "[None, 1, 10301051460877537453973547267843L, {2: 'eggs', 1: 'spam'}, '', (1+5j), [...]]", expected: "[None, 1, 10301051460877537453973547267843L, {1: 'spam', 2: 'eggs'}, '', (1+5j), [...]]" test_minidom test test_minidom failed -- Writing: 'Test Failed: testUserData\012createElementNS\012', expected: '' test_pyexpat test_pyxmldom Warning: can't open ./output/test_pyxmldom test_sax test_sax2 test_sax2_xmlproc test_sax_xmlproc test_saxdrivers test_utils test_xmlbuilder test_xmlproc 17 tests OK. 2 tests failed: test_marshal test_minidom cd test && PYTHONPATH=../build/lib.linux-i686-2.1 python2.1 testxml.py Traceback (most recent call last): File "test_minidom.py", line 773, in ? func() File "test_minidom.py", line 534, in testUserData c = n.cloneNode(1) File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.1/_xmlplus/dom/minidom.py", line 186, in cloneNode clone = CloneNode(self,deep,self.ownerDocument or self) File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.1/_xmlplus/dom/minidom.py", line 1221, in CloneNode clone = newOwnerDocument.createElementNS(node.namespaceURI, File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.1/_xmlplus/dom/minicompat.py", line 134, in __getattr__ raise AttributeError, key AttributeError: createElementNS test_c14n test_dom test_encodings test_filter test_howto test_htmlb test_javadom test_marshal test test_marshal failed -- Writing: "[None, 1, 10301051460877537453973547267843L, {2: 'eggs', 1: 'spam'}, '', (1+5j), [...]]", expected: "[None, 1, 10301051460877537453973547267843L, {1: 'spam', 2: 'eggs'}, '', (1+5j), [...]]" test_minidom test test_minidom failed -- Writing: 'Test Failed: testUserData\ncreateElementNS\n', expected: '' test_pyexpat test_pyxmldom Warning: can't open ./output/test_pyxmldom test_sax test_sax2 test_sax2_xmlproc test_sax_xmlproc test_saxdrivers test_utils test_xmlbuilder test_xmlproc 17 tests OK. 2 tests failed: test_marshal test_minidom cd test && PYTHONPATH=../build/lib.linux-i686-2.2 python2.2 testxml.py Traceback (most recent call last): File "test_minidom.py", line 773, in ? func() File "test_minidom.py", line 247, in testGetElementsByTagNameNS confirm(len(elem) == 1) File "test_minidom.py", line 25, in confirm print "Failed " + testname File "regrtest.py", line 205, in write raise test_support.TestFailed, \ TestFailed: Writing: 'Failed Test', expected: '' test_c14n test_dom test_encodings test_filter test_howto test_htmlb test_javadom test_marshal test_minidom test test_minidom failed -- Writing: "Test Failed: testGetElementsByTagNameNS\nWriting: 'Failed Test', expected: ''\n", expected: '' test_pyexpat test_pyxmldom Warning: can't open ./output/test_pyxmldom test_sax test_sax2 test_sax2_xmlproc test_sax_xmlproc test_saxdrivers test_utils test_xmlbuilder test test_xmlbuilder crashed -- exceptions.AssertionError : [(('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/a'), (('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/a'), (('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/b'), ((u'http://xml.python.org/a', None), u'a'), ((u'http://xml.python.org/b', None), u'b')] test_xmlproc 17 tests OK. 2 tests failed: test_minidom test_xmlbuilder cd test && PYTHONPATH=../build/lib.linux-i686-2.3 python2.3 testxml.py Traceback (most recent call last): File "test_minidom.py", line 773, in ? func() File "test_minidom.py", line 247, in testGetElementsByTagNameNS confirm(len(elem) == 1) File "test_minidom.py", line 25, in confirm print "Failed " + testname File "regrtest.py", line 205, in write raise test_support.TestFailed, \ TestFailed: Writing: 'Failed Test', expected: '' test_c14n test_dom test_encodings test_filter test_howto test_htmlb test_javadom test_marshal test_minidom test test_minidom failed -- Writing: "Test Failed: testGetElementsByTagNameNS\nWriting: 'Failed Test', expected: ''\n", expected: '' test_pyexpat test_pyxmldom Warning: can't open ./output/test_pyxmldom test_sax test_sax2 test_sax2_xmlproc test_sax_xmlproc test_saxdrivers test_utils test_xmlbuilder test test_xmlbuilder crashed -- exceptions.AssertionError : [(('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/a'), (('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/a'), (('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/b'), ((u'http://xml.python.org/a', None), u'a'), ((u'http://xml.python.org/b', None), u'b')] test_xmlproc 17 tests OK. 2 tests failed: test_minidom test_xmlbuilder ------------------------------------------------------------------------ (I'd *really* like to see the PyXML tests all be converted to use unittest, but haven't had the time to deal with that yet. ;-( ) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From npetry@accesscomm.ca Thu Jul 25 20:42:48 2002 From: npetry@accesscomm.ca (Norman Petry) Date: 25 Jul 2002 13:42:48 -0600 Subject: [XML-SIG] XBEL Webpage - suggested update Message-ID: <1027626168.2003.9.camel@curunir> Hi, I came across the webpage for XBEL: http://pyxml.sourceforge.net/topics/xbel/ and noticed that several xbel-compatible applications are mentioned there. When you have time, you may also wish to add Galeon (the most popular browser for the GNOME desktop) to this list, as it has also been using xbel as its native bookmark format since version 1.1. See: http://galeon.sourceforge.net/news/ for more information. Thanks! -- Norm Petry From fdrake@acm.org Thu Jul 25 21:14:31 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 25 Jul 2002 16:14:31 -0400 Subject: [XML-SIG] XBEL Webpage - suggested update In-Reply-To: <1027626168.2003.9.camel@curunir> References: <1027626168.2003.9.camel@curunir> Message-ID: <15680.23591.866507.427011@grendel.zope.com> Norman Petry writes: > When you have time, you may also wish to add Galeon (the most > popular browser for the GNOME desktop) to this list, as it has also > been using xbel as its native bookmark format since version 1.1. Thanks! I've added it to the copy of the pages in our CVS repository; it should appear on the site before too long. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Mike.Olson@fourthought.com Thu Jul 25 23:58:35 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 25 Jul 2002 16:58:35 -0600 Subject: [XML-SIG] minidom changes In-Reply-To: <15680.9407.40539.296654@grendel.zope.com> References: <1027550306.4699.133.camel@penny> <15680.9407.40539.296654@grendel.zope.com> Message-ID: <1027637917.3273.0.camel@penny> On Thu, 2002-07-25 at 10:18, Fred L. Drake, Jr. wrote: > > Mike Olson writes: > > I'm going to check in my minidom changes so that 0.8 mostly works with > > XPath and Xslt (I'll explain more latter). I have a question first. > > The tests fail for me for Python versions 2.0.1, 2.1.3, 2.2.1, and > 2.3a0 (CVS). This is with a completely fresh build of PyXML. Sorry, I didn;t run these tests before I checked in, i didn't even think to do it. The problem is that the element that the test is cloning does not have an owner document. So the question is, is that an error with the clone node code (ie should that be allowed) or is it a problem with the test harness (as all nodes should have an owner document). I can fix it either way. I think it is a problem with the test harness. However, I think we say it is OK to do xml.dom.minidom.Element('e') inwhich case we could have a lot of nodes without owner documents and a lot of people will get these errors. Mike > > Here's the output of "make check": > > ------------------------------------------------------------------------ > python2.0 setup.py -q build > python2.1 setup.py -q build > python2.2 setup.py -q build > python2.3 setup.py -q build > cd test && PYTHONPATH=../build/lib.linux-i686-2.0 python2.0 testxml.py > Traceback (most recent call last): > File "test_minidom.py", line 773, in ? > func() > File "test_minidom.py", line 534, in testUserData > c = n.cloneNode(1) > File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.0/_xmlplus/dom/minidom.py", line 186, in cloneNode > clone = CloneNode(self,deep,self.ownerDocument or self) > File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.0/_xmlplus/dom/minidom.py", line 1221, in CloneNode > clone = newOwnerDocument.createElementNS(node.namespaceURI, > File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.0/_xmlplus/dom/minicompat.py", line 134, in __getattr__ > raise AttributeError, key > AttributeError: createElementNS > test_c14n > test_dom > test_encodings > test_filter > test_howto > test_htmlb > test_javadom > test_marshal > test test_marshal failed -- Writing: "[None, 1, 10301051460877537453973547267843L, {2: 'eggs', 1: 'spam'}, '', (1+5j), [...]]", expected: "[None, 1, 10301051460877537453973547267843L, {1: 'spam', 2: 'eggs'}, '', (1+5j), [...]]" > test_minidom > test test_minidom failed -- Writing: 'Test Failed: testUserData\012createElementNS\012', expected: '' > test_pyexpat > test_pyxmldom > Warning: can't open ./output/test_pyxmldom > test_sax > test_sax2 > test_sax2_xmlproc > test_sax_xmlproc > test_saxdrivers > test_utils > test_xmlbuilder > test_xmlproc > 17 tests OK. > 2 tests failed: test_marshal test_minidom > cd test && PYTHONPATH=../build/lib.linux-i686-2.1 python2.1 testxml.py > Traceback (most recent call last): > File "test_minidom.py", line 773, in ? > func() > File "test_minidom.py", line 534, in testUserData > c = n.cloneNode(1) > File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.1/_xmlplus/dom/minidom.py", line 186, in cloneNode > clone = CloneNode(self,deep,self.ownerDocument or self) > File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.1/_xmlplus/dom/minidom.py", line 1221, in CloneNode > clone = newOwnerDocument.createElementNS(node.namespaceURI, > File "/home/fdrake/projects/pyxml/xml/build/lib.linux-i686-2.1/_xmlplus/dom/minicompat.py", line 134, in __getattr__ > raise AttributeError, key > AttributeError: createElementNS > test_c14n > test_dom > test_encodings > test_filter > test_howto > test_htmlb > test_javadom > test_marshal > test test_marshal failed -- Writing: "[None, 1, 10301051460877537453973547267843L, {2: 'eggs', 1: 'spam'}, '', (1+5j), [...]]", expected: "[None, 1, 10301051460877537453973547267843L, {1: 'spam', 2: 'eggs'}, '', (1+5j), [...]]" > test_minidom > test test_minidom failed -- Writing: 'Test Failed: testUserData\ncreateElementNS\n', expected: '' > test_pyexpat > test_pyxmldom > Warning: can't open ./output/test_pyxmldom > test_sax > test_sax2 > test_sax2_xmlproc > test_sax_xmlproc > test_saxdrivers > test_utils > test_xmlbuilder > test_xmlproc > 17 tests OK. > 2 tests failed: test_marshal test_minidom > cd test && PYTHONPATH=../build/lib.linux-i686-2.2 python2.2 testxml.py > Traceback (most recent call last): > File "test_minidom.py", line 773, in ? > func() > File "test_minidom.py", line 247, in testGetElementsByTagNameNS > confirm(len(elem) == 1) > File "test_minidom.py", line 25, in confirm > print "Failed " + testname > File "regrtest.py", line 205, in write > raise test_support.TestFailed, \ > TestFailed: Writing: 'Failed Test', expected: '' > test_c14n > test_dom > test_encodings > test_filter > test_howto > test_htmlb > test_javadom > test_marshal > test_minidom > test test_minidom failed -- Writing: "Test Failed: testGetElementsByTagNameNS\nWriting: 'Failed Test', expected: ''\n", expected: '' > test_pyexpat > test_pyxmldom > Warning: can't open ./output/test_pyxmldom > test_sax > test_sax2 > test_sax2_xmlproc > test_sax_xmlproc > test_saxdrivers > test_utils > test_xmlbuilder > test test_xmlbuilder crashed -- exceptions.AssertionError : > [(('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/a'), > (('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/a'), > (('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/b'), > ((u'http://xml.python.org/a', None), u'a'), > ((u'http://xml.python.org/b', None), u'b')] > test_xmlproc > 17 tests OK. > 2 tests failed: test_minidom test_xmlbuilder > cd test && PYTHONPATH=../build/lib.linux-i686-2.3 python2.3 testxml.py > Traceback (most recent call last): > File "test_minidom.py", line 773, in ? > func() > File "test_minidom.py", line 247, in testGetElementsByTagNameNS > confirm(len(elem) == 1) > File "test_minidom.py", line 25, in confirm > print "Failed " + testname > File "regrtest.py", line 205, in write > raise test_support.TestFailed, \ > TestFailed: Writing: 'Failed Test', expected: '' > test_c14n > test_dom > test_encodings > test_filter > test_howto > test_htmlb > test_javadom > test_marshal > test_minidom > test test_minidom failed -- Writing: "Test Failed: testGetElementsByTagNameNS\nWriting: 'Failed Test', expected: ''\n", expected: '' > test_pyexpat > test_pyxmldom > Warning: can't open ./output/test_pyxmldom > test_sax > test_sax2 > test_sax2_xmlproc > test_sax_xmlproc > test_saxdrivers > test_utils > test_xmlbuilder > test test_xmlbuilder crashed -- exceptions.AssertionError : > [(('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/a'), > (('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/a'), > (('http://www.w3.org/2000/xmlns/', None), u'http://xml.python.org/b'), > ((u'http://xml.python.org/a', None), u'a'), > ((u'http://xml.python.org/b', None), u'b')] > test_xmlproc > 17 tests OK. > 2 tests failed: test_minidom test_xmlbuilder > ------------------------------------------------------------------------ > > (I'd *really* like to see the PyXML tests all be converted to use > unittest, but haven't had the time to deal with that yet. ;-( ) > > > -Fred > > -- > Fred L. Drake, Jr. > PythonLabs at Zope Corporation -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From noreply@sourceforge.net Fri Jul 26 00:20:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 16:20:33 -0700 Subject: [XML-SIG] [ pyxml-Bugs-586754 ] build of expat fails on darwin Message-ID: Bugs item #586754, was opened at 2002-07-25 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=586754&group_id=6473 Category: expat Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: build of expat fails on darwin Initial Comment: here is the shell text python setup.py build running build running build_py not copying xml/__init__.py (output up-to-date) not copying xml/FtCore.py (output up-to-date) not copying xml/ns.py (output up-to-date) not copying xml/dom/__init__.py (output up-to-date) not copying xml/dom/Attr.py (output up-to-date) not copying xml/dom/CDATASection.py (output up-to-date) not copying xml/dom/CharacterData.py (output up-to-date) not copying xml/dom/Comment.py (output up-to-date) not copying xml/dom/Document.py (output up-to-date) not copying xml/dom/DocumentFragment.py (output up-to-date) not copying xml/dom/DocumentType.py (output up-to-date) not copying xml/dom/DOMImplementation.py (output up-to-date) not copying xml/dom/domreg.py (output up-to-date) not copying xml/dom/Element.py (output up-to-date) not copying xml/dom/Entity.py (output up-to-date) not copying xml/dom/EntityReference.py (output up-to-date) not copying xml/dom/Event.py (output up-to-date) not copying xml/dom/FtNode.py (output up-to-date) not copying xml/dom/javadom.py (output up-to-date) not copying xml/dom/MessageSource.py (output up-to-date) not copying xml/dom/minidom.py (output up-to-date) not copying xml/dom/minitraversal.py (output up-to-date) not copying xml/dom/NamedNodeMap.py (output up-to-date) not copying xml/dom/NodeFilter.py (output up-to-date) not copying xml/dom/NodeIterator.py (output up-to-date) not copying xml/dom/NodeList.py (output up-to-date) not copying xml/dom/Notation.py (output up-to-date) not copying xml/dom/ProcessingInstruction.py (output up-to-date) not copying xml/dom/pulldom.py (output up-to-date) not copying xml/dom/Range.py (output up-to-date) not copying xml/dom/Text.py (output up-to-date) not copying xml/dom/TreeWalker.py (output up-to-date) not copying xml/dom/html/__init__.py (output up-to-date) not copying xml/dom/html/GenerateHtml.py (output up-to-date) not copying xml/dom/html/HTMLAnchorElement.py (output up-to- date) not copying xml/dom/html/HTMLAppletElement.py (output up-to- date) not copying xml/dom/html/HTMLAreaElement.py (output up-to- date) not copying xml/dom/html/HTMLBaseElement.py (output up-to- date) not copying xml/dom/html/HTMLBaseFontElement.py (output up- to-date) not copying xml/dom/html/HTMLBodyElement.py (output up-to- date) not copying xml/dom/html/HTMLBRElement.py (output up-to-date) not copying xml/dom/html/HTMLButtonElement.py (output up-to- date) not copying xml/dom/html/HTMLCollection.py (output up-to-date) not copying xml/dom/html/HTMLDirectoryElement.py (output up- to-date) not copying xml/dom/html/HTMLDivElement.py (output up-to-date) not copying xml/dom/html/HTMLDListElement.py (output up-to- date) not copying xml/dom/html/HTMLDocument.py (output up-to-date) not copying xml/dom/html/HTMLDOMImplementation.py (output up-to-date) not copying xml/dom/html/HTMLElement.py (output up-to-date) not copying xml/dom/html/HTMLFieldSetElement.py (output up-to- date) not copying xml/dom/html/HTMLFontElement.py (output up-to- date) not copying xml/dom/html/HTMLFormElement.py (output up-to- date) not copying xml/dom/html/HTMLFrameElement.py (output up-to- date) not copying xml/dom/html/HTMLFrameSetElement.py (output up- to-date) not copying xml/dom/html/HTMLHeadElement.py (output up-to- date) not copying xml/dom/html/HTMLHeadingElement.py (output up-to- date) not copying xml/dom/html/HTMLHRElement.py (output up-to-date) not copying xml/dom/html/HTMLHtmlElement.py (output up-to- date) not copying xml/dom/html/HTMLIFrameElement.py (output up-to- date) not copying xml/dom/html/HTMLImageElement.py (output up-to- date) not copying xml/dom/html/HTMLInputElement.py (output up-to- date) not copying xml/dom/html/HTMLIsIndexElement.py (output up-to- date) not copying xml/dom/html/HTMLLabelElement.py (output up-to- date) not copying xml/dom/html/HTMLLegendElement.py (output up-to- date) not copying xml/dom/html/HTMLLIElement.py (output up-to-date) not copying xml/dom/html/HTMLLinkElement.py (output up-to- date) not copying xml/dom/html/HTMLMapElement.py (output up-to- date) not copying xml/dom/html/HTMLMenuElement.py (output up-to- date) not copying xml/dom/html/HTMLMetaElement.py (output up-to- date) not copying xml/dom/html/HTMLModElement.py (output up-to- date) not copying xml/dom/html/HTMLObjectElement.py (output up-to- date) not copying xml/dom/html/HTMLOListElement.py (output up-to- date) not copying xml/dom/html/HTMLOptGroupElement.py (output up- to-date) not copying xml/dom/html/HTMLOptionElement.py (output up-to- date) not copying xml/dom/html/HTMLParagraphElement.py (output up- to-date) not copying xml/dom/html/HTMLParamElement.py (output up-to- date) not copying xml/dom/html/HTMLPreElement.py (output up-to-date) not copying xml/dom/html/HTMLQuoteElement.py (output up-to- date) not copying xml/dom/html/HTMLScriptElement.py (output up-to- date) not copying xml/dom/html/HTMLSelectElement.py (output up-to- date) not copying xml/dom/html/HTMLStyleElement.py (output up-to- date) not copying xml/dom/html/HTMLTableCaptionElement.py (output up-to-date) not copying xml/dom/html/HTMLTableCellElement.py (output up- to-date) not copying xml/dom/html/HTMLTableColElement.py (output up-to- date) not copying xml/dom/html/HTMLTableElement.py (output up-to- date) not copying xml/dom/html/HTMLTableRowElement.py (output up- to-date) not copying xml/dom/html/HTMLTableSectionElement.py (output up-to-date) not copying xml/dom/html/HTMLTextAreaElement.py (output up- to-date) not copying xml/dom/html/HTMLTitleElement.py (output up-to- date) not copying xml/dom/html/HTMLUListElement.py (output up-to- date) not copying xml/dom/ext/__init__.py (output up-to-date) not copying xml/dom/ext/c14n.py (output up-to-date) not copying xml/dom/ext/Dom2Sax.py (output up-to-date) not copying xml/dom/ext/Printer.py (output up-to-date) not copying xml/dom/ext/Visitor.py (output up-to-date) not copying xml/dom/ext/XHtml2HtmlPrinter.py (output up-to-date) not copying xml/dom/ext/XHtmlPrinter.py (output up-to-date) not copying xml/dom/ext/reader/__init__.py (output up-to-date) not copying xml/dom/ext/reader/HtmlLib.py (output up-to-date) not copying xml/dom/ext/reader/HtmlSax.py (output up-to-date) not copying xml/dom/ext/reader/PyExpat.py (output up-to-date) not copying xml/dom/ext/reader/Sax.py (output up-to-date) not copying xml/dom/ext/reader/Sax2.py (output up-to-date) not copying xml/dom/ext/reader/Sax2Lib.py (output up-to-date) not copying xml/dom/ext/reader/Sgmlop.py (output up-to-date) not copying xml/marshal/__init__.py (output up-to-date) not copying xml/marshal/generic.py (output up-to-date) not copying xml/marshal/wddx.py (output up-to-date) not copying xml/unicode/__init__.py (output up-to-date) not copying xml/unicode/iso8859.py (output up-to-date) not copying xml/unicode/utf8_iso.py (output up-to-date) not copying xml/parsers/__init__.py (output up-to-date) not copying xml/parsers/expat.py (output up-to-date) not copying xml/parsers/sgmllib.py (output up-to-date) not copying xml/parsers/xmlproc/__init__.py (output up-to-date) not copying xml/parsers/xmlproc/_outputters.py (output up-to- date) not copying xml/parsers/xmlproc/catalog.py (output up-to-date) not copying xml/parsers/xmlproc/charconv.py (output up-to-date) not copying xml/parsers/xmlproc/dtdparser.py (output up-to-date) not copying xml/parsers/xmlproc/errors.py (output up-to-date) not copying xml/parsers/xmlproc/namespace.py (output up-to- date) not copying xml/parsers/xmlproc/utils.py (output up-to-date) not copying xml/parsers/xmlproc/xcatalog.py (output up-to-date) not copying xml/parsers/xmlproc/xmlapp.py (output up-to-date) not copying xml/parsers/xmlproc/xmldtd.py (output up-to-date) not copying xml/parsers/xmlproc/xmlproc.py (output up-to-date) not copying xml/parsers/xmlproc/xmlutils.py (output up-to-date) not copying xml/parsers/xmlproc/xmlval.py (output up-to-date) not copying xml/sax/__init__.py (output up-to-date) not copying xml/sax/_exceptions.py (output up-to-date) not copying xml/sax/expatreader.py (output up-to-date) not copying xml/sax/handler.py (output up-to-date) not copying xml/sax/sax2exts.py (output up-to-date) not copying xml/sax/saxexts.py (output up-to-date) not copying xml/sax/saxlib.py (output up-to-date) not copying xml/sax/saxutils.py (output up-to-date) not copying xml/sax/writer.py (output up-to-date) not copying xml/sax/xmlreader.py (output up-to-date) not copying xml/sax/drivers/__init__.py (output up-to-date) not copying xml/sax/drivers/drv_htmllib.py (output up-to-date) not copying xml/sax/drivers/drv_ltdriver.py (output up-to-date) not copying xml/sax/drivers/drv_ltdriver_val.py (output up-to-date) not copying xml/sax/drivers/drv_pyexpat.py (output up-to-date) not copying xml/sax/drivers/drv_sgmllib.py (output up-to-date) not copying xml/sax/drivers/drv_sgmlop.py (output up-to-date) not copying xml/sax/drivers/drv_xmldc.py (output up-to-date) not copying xml/sax/drivers/drv_xmllib.py (output up-to-date) not copying xml/sax/drivers/drv_xmlproc.py (output up-to-date) not copying xml/sax/drivers/drv_xmlproc_val.py (output up-to-date) not copying xml/sax/drivers/drv_xmltoolkit.py (output up-to-date) not copying xml/sax/drivers/pylibs.py (output up-to-date) not copying xml/sax/drivers2/__init__.py (output up-to-date) not copying xml/sax/drivers2/drv_htmllib.py (output up-to-date) not copying xml/sax/drivers2/drv_javasax.py (output up-to-date) not copying xml/sax/drivers2/drv_pyexpat.py (output up-to-date) not copying xml/sax/drivers2/drv_sgmllib.py (output up-to-date) not copying xml/sax/drivers2/drv_sgmlop.py (output up-to-date) not copying xml/sax/drivers2/drv_sgmlop_html.py (output up-to- date) not copying xml/sax/drivers2/drv_xmlproc.py (output up-to-date) not copying xml/utils/__init__.py (output up-to-date) not copying xml/utils/characters.py (output up-to-date) not copying xml/utils/iso8601.py (output up-to-date) not copying xml/utils/qp_xml.py (output up-to-date) not copying xml/schema/__init__.py (output up-to-date) not copying xml/schema/trex.py (output up-to-date) not copying xml/xpath/__init__.py (output up-to-date) not copying xml/xpath/BuiltInExtFunctions.py (output up-to-date) not copying xml/xpath/Context.py (output up-to-date) not copying xml/xpath/Conversions.py (output up-to-date) not copying xml/xpath/CoreFunctions.py (output up-to-date) not copying xml/xpath/ExpandedNameWrapper.py (output up-to- date) not copying xml/xpath/MessageSource.py (output up-to-date) not copying xml/xpath/NamespaceNode.py (output up-to-date) not copying xml/xpath/ParsedAbsoluteLocationPath.py (output up- to-date) not copying xml/xpath/ParsedAxisSpecifier.py (output up-to-date) not copying xml/xpath/ParsedExpr.py (output up-to-date) not copying xml/xpath/ParsedNodeTest.py (output up-to-date) not copying xml/xpath/ParsedPredicateList.py (output up-to-date) not copying xml/xpath/ParsedRelativeLocationPath.py (output up- to-date) not copying xml/xpath/ParsedStep.py (output up-to-date) not copying xml/xpath/pyxpath.py (output up-to-date) not copying xml/xpath/Set.py (output up-to-date) not copying xml/xpath/Util.py (output up-to-date) not copying xml/xpath/XPathGrammar.py (output up-to-date) not copying xml/xpath/XPathParser.py (output up-to-date) not copying xml/xpath/XPathParserBase.py (output up-to-date) not copying xml/xpath/yappsrt.py (output up-to-date) not copying xml/xslt/_4xslt.py (output up-to-date) not copying xml/xslt/__init__.py (output up-to-date) not copying xml/xslt/ApplyTemplatesElement.py (output up-to- date) not copying xml/xslt/AttributeElement.py (output up-to-date) not copying xml/xslt/AttributeSetElement.py (output up-to-date) not copying xml/xslt/AttributeValueTemplate.py (output up-to-date) not copying xml/xslt/BuiltInExtElements.py (output up-to-date) not copying xml/xslt/CallTemplateElement.py (output up-to-date) not copying xml/xslt/ChooseElement.py (output up-to-date) not copying xml/xslt/CommentElement.py (output up-to-date) not copying xml/xslt/CopyElement.py (output up-to-date) not copying xml/xslt/CopyOfElement.py (output up-to-date) not copying xml/xslt/ElementElement.py (output up-to-date) not copying xml/xslt/ForEachElement.py (output up-to-date) not copying xml/xslt/HtmlWriter.py (output up-to-date) not copying xml/xslt/IfElement.py (output up-to-date) not copying xml/xslt/LiteralElement.py (output up-to-date) not copying xml/xslt/LiteralText.py (output up-to-date) not copying xml/xslt/MessageElement.py (output up-to-date) not copying xml/xslt/MessageSource.py (output up-to-date) not copying xml/xslt/minisupport.py (output up-to-date) not copying xml/xslt/NullWriter.py (output up-to-date) not copying xml/xslt/NumberElement.py (output up-to-date) not copying xml/xslt/OtherwiseElement.py (output up-to-date) not copying xml/xslt/OtherXslElement.py (output up-to-date) not copying xml/xslt/OutputHandler.py (output up-to-date) not copying xml/xslt/ParamElement.py (output up-to-date) not copying xml/xslt/ParsedLocationPathPattern.py (output up-to- date) not copying xml/xslt/ParsedPattern.py (output up-to-date) not copying xml/xslt/ParsedRelativePathPattern.py (output up-to- date) not copying xml/xslt/ParsedStepPattern.py (output up-to-date) not copying xml/xslt/PlainTextWriter.py (output up-to-date) not copying xml/xslt/ProcessingInstructionElement.py (output up- to-date) not copying xml/xslt/Processor.py (output up-to-date) not copying xml/xslt/Roman.py (output up-to-date) not copying xml/xslt/RtfWriter.py (output up-to-date) not copying xml/xslt/SortElement.py (output up-to-date) not copying xml/xslt/Stylesheet.py (output up-to-date) not copying xml/xslt/StylesheetReader.py (output up-to-date) not copying xml/xslt/TemplateElement.py (output up-to-date) not copying xml/xslt/TextElement.py (output up-to-date) not copying xml/xslt/TextSax.py (output up-to-date) not copying xml/xslt/TextWriter.py (output up-to-date) not copying xml/xslt/ValueOfElement.py (output up-to-date) not copying xml/xslt/VariableElement.py (output up-to-date) not copying xml/xslt/WhenElement.py (output up-to-date) not copying xml/xslt/WithParamElement.py (output up-to-date) not copying xml/xslt/XmlWriter.py (output up-to-date) not copying xml/xslt/XPattern.py (output up-to-date) not copying xml/xslt/XPatternParser.py (output up-to-date) not copying xml/xslt/XPatternParserBase.py (output up-to-date) not copying xml/xslt/XsltContext.py (output up-to-date) not copying xml/xslt/XsltFunctions.py (output up-to-date) running build_ext building '_xmlplus.parsers.pyexpat' extension cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp - DHAVE_EXPAT_H -DVERSION="1.95.2" -DXML_NS=1 - DXML_DTD=1 -DXML_BYTE_ORDER=21 - DXML_CONTEXT_BYTES=1024 -Iextensions/expat/lib -I/usr/local/ include/python2.2 -c extensions/pyexpat.c -o build/temp.darwin- 1.4-Power Macintosh-2.2/pyexpat.o cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp - DHAVE_EXPAT_H -DVERSION="1.95.2" -DXML_NS=1 - DXML_DTD=1 -DXML_BYTE_ORDER=21 - DXML_CONTEXT_BYTES=1024 -Iextensions/expat/lib -I/usr/local/ include/python2.2 -c extensions/expat/lib/xmlparse.c -o build/ temp.darwin-1.4-Power Macintosh-2.2/xmlparse.o cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp - DHAVE_EXPAT_H -DVERSION="1.95.2" -DXML_NS=1 - DXML_DTD=1 -DXML_BYTE_ORDER=21 - DXML_CONTEXT_BYTES=1024 -Iextensions/expat/lib -I/usr/local/ include/python2.2 -c extensions/expat/lib/xmlrole.c -o build/ temp.darwin-1.4-Power Macintosh-2.2/xmlrole.o extensions/expat/lib/xmlrole.c:7: warning: `RCSId' defined but not used cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp - DHAVE_EXPAT_H -DVERSION="1.95.2" -DXML_NS=1 - DXML_DTD=1 -DXML_BYTE_ORDER=21 - DXML_CONTEXT_BYTES=1024 -Iextensions/expat/lib -I/usr/local/ include/python2.2 -c extensions/expat/lib/xmltok.c -o build/ temp.darwin-1.4-Power Macintosh-2.2/xmltok.o cc -bundle -flat_namespace -undefined suppress build/ temp.darwin-1.4-Power Macintosh-2.2/pyexpat.o build/ temp.darwin-1.4-Power Macintosh-2.2/xmlparse.o build/ temp.darwin-1.4-Power Macintosh-2.2/xmlrole.o build/temp.darwin- 1.4-Power Macintosh-2.2/xmltok.o -o build/lib.darwin-1.4-Power Macintosh-2.2/_xmlplus/parsers/pyexpat.so -flat_namespace /usr/bin/ld: -undefined: unknown argument: -lbundle1.o error: command 'cc' failed with exit status 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106473&aid=586754&group_id=6473 From fdrake@acm.org Fri Jul 26 04:37:25 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 25 Jul 2002 23:37:25 -0400 Subject: [XML-SIG] minidom changes In-Reply-To: <1027637917.3273.0.camel@penny> References: <1027550306.4699.133.camel@penny> <15680.9407.40539.296654@grendel.zope.com> <1027637917.3273.0.camel@penny> Message-ID: <15680.50165.50196.802595@grendel.zope.com> Mike Olson writes: > Sorry, I didn;t run these tests before I checked in, i didn't even think > to do it. I really, really, *really* like to push running "make check" frequently. I find it very helpful to leave just one Python version enabled there when I'm deep in development, two when coming out of development (one of Python 2.0/2.1, and one of Python 2.2/2.3), and all four before committing. I wouldn't mind setting up the repository so that commits are rejected if they cause the tests to fail. ;-) > The problem is that the element that the test is cloning does not have > an owner document. So the question is, is that an error with the clone > node code (ie should that be allowed) or is it a problem with the test > harness (as all nodes should have an owner document). I can fix it > either way. I think it is a problem with the test harness. I agree. The DOM is definately a factory-centric API. > However, I think we say it is OK to do xml.dom.minidom.Element('e') > inwhich case we could have a lot of nodes without owner documents and a > lot of people will get these errors. I'm not sure what you mean. I certainly don't know of any documentation that indicates that's a way to do it. I'm less concerned about maintaining undocumented behavior than Martin. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Fri Jul 26 07:44:39 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 26 Jul 2002 08:44:39 +0200 Subject: [XML-SIG] minidom changes In-Reply-To: <15680.50165.50196.802595@grendel.zope.com> References: <1027550306.4699.133.camel@penny> <15680.9407.40539.296654@grendel.zope.com> <1027637917.3273.0.camel@penny> <15680.50165.50196.802595@grendel.zope.com> Message-ID: "Fred L. Drake, Jr." writes: > I really, really, *really* like to push running "make check" > frequently. I think this is unrealistic. It requires different Python versions, and hence is a lot of effort. I never noticed Makefile until you told me it was there. I always run the test suite by invoking regrtest. Regards, Martin From martin@v.loewis.de Fri Jul 26 07:56:09 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 26 Jul 2002 08:56:09 +0200 Subject: [XML-SIG] Re: [XML-checkins]xml setup.py,1.69,1.70 In-Reply-To: References: Message-ID: "Fred L. Drake, Jr." writes: > We set the VERSION definition for Expat to "1.95.2", but include 1.95.4. > Since Expat 1.95.3 and newer no longer require this, remove it. > This closes SF bug #582762. By the same rationale, you could remove all the other defines from setup.py as well. It's not that VERSION is not needed anymore - instead, PACKAGE_VERSION is now defined in expat_config.h. This ought to be a generated file, but isn't. We'll see how this works out: In principle, shipping a preconfigured expat_config.h is evil, since it says things like HAVE_BCOPY, HAVE_DLFCN_H, ... which may not be true for the target system. Regards, Martin From fdrake@acm.org Fri Jul 26 15:55:27 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 26 Jul 2002 10:55:27 -0400 Subject: [XML-SIG] Re: [XML-checkins]xml setup.py,1.69,1.70 In-Reply-To: References: Message-ID: <15681.25311.918533.79366@grendel.zope.com> Martin v. Loewis writes: > By the same rationale, you could remove all the other defines from > setup.py as well. It's not that VERSION is not needed anymore - I've now removed XML_NS, XML_DTD, and XML_CONTEXT_BYTES. The code to determine byteorder is simpler since we require Python 2.0 or newer. > instead, PACKAGE_VERSION is now defined in expat_config.h. This ought > to be a generated file, but isn't. I'm guessing PACKAGE_VERSION came from the GNU autosplat tools; it's not used in Expat, and there's nothing in Expat's configure.in that would cause it to be added as far as I can tell, though I'm no autosplat expert. > We'll see how this works out: In principle, shipping a preconfigured > expat_config.h is evil, since it says things like HAVE_BCOPY, > HAVE_DLFCN_H, ... which may not be true for the target system. I agree in principle, but don't have an alternate solution handy. You already have a bug report filed on this for Expat, which seems the appropriate place for this to be dealt with. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From ndemaill@ext.cri74.org Fri Jul 26 16:45:09 2002 From: ndemaill@ext.cri74.org (Nicolas) Date: Fri, 26 Jul 2002 17:45:09 +0200 Subject: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" Message-ID: <3D416E85.7080708@ext.cri74.org> I' ve just installed python and here the probleme: it gives me the following error: >>> from Ft.Xml.Xslt import Processor Traceback (most recent call last): File "", line 1, in ? File "Ft/Xml/Xslt/__init__.py", line 41, in ? from Ft.Xml import XPath File "Ft/Xml/XPath/__init__.py", line 25, in ? from Ft.Lib import boolean ImportError: cannot import name boolean what must I make to solve this problem? From Mike.Olson@fourthought.com Fri Jul 26 17:43:33 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 26 Jul 2002 10:43:33 -0600 Subject: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <3D416E85.7080708@ext.cri74.org> References: <3D416E85.7080708@ext.cri74.org> Message-ID: <1027701814.3373.8.camel@penny> On Fri, 2002-07-26 at 09:45, Nicolas wrote: > I' ve just installed python and here the probleme: it gives me the > following error: > >>> from Ft.Xml.Xslt import Processor > Traceback (most recent call last): > File "", line 1, in ? > File "Ft/Xml/Xslt/__init__.py", line 41, in ? > from Ft.Xml import XPath > File "Ft/Xml/XPath/__init__.py", line 25, in ? > from Ft.Lib import boolean > ImportError: cannot import name boolean > > what must I make to solve this problem? Are you running this from the directory that you installed 4Suite from? Mike > > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From uche.ogbuji@fourthought.com Fri Jul 26 18:47:23 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 26 Jul 2002 11:47:23 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027703336.3273.10.camel@penny> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> Message-ID: <1027705645.31684.20113.camel@malatesta> On Fri, 2002-07-26 at 11:08, Mike Olson wrote: > On Fri, 2002-07-26 at 09:45, Nicolas wrote: > > This is such a common problem that I've added code to print out a decent > error message when it happens. Great. I was wanting to get around to this. As it is, I fixed the infamous "Unknown driver Postgres" message so that the true exception ins exposed. > Unfortunatly, the code I've added could > cause use problems down the line unless we encourage people to do a > fresh install as opposed to upgrading 4Suite. Could you clarify this last sentence a bit? > [molson@penny 4Suite]$ python -c"from Ft.Lib import boolean" > There is a problem importing the compiled boolean module. > This can mean that there were errors with ths installation of > 4Suite. Inwhich case you should contact 4Suite@lists.fourthought.com > with the > error messages generated during installation. > > This can also mean that you are attempting to execute code from the > installation > directory. If your current working directory contains the setup.py file > for > 4Suite installation then you are in the installation directory for > 4Suite. You > must change directories before you can use the Ft module. Could you reverse the order of this message? I think it should first of all make them check that they're not running from the build dir, and *then* say if they have a remaining problem they should report to the list. I just worry that people won't read through the whole message. I can do this, if you like. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC From Mike.Olson@fourthought.com Fri Jul 26 18:08:55 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 26 Jul 2002 11:08:55 -0600 Subject: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <3D416E85.7080708@ext.cri74.org> References: <3D416E85.7080708@ext.cri74.org> Message-ID: <1027703336.3273.10.camel@penny> On Fri, 2002-07-26 at 09:45, Nicolas wrote: This is such a common problem that I've added code to print out a decent error message when it happens. Unfortunatly, the code I've added could cause use problems down the line unless we encourage people to do a fresh install as opposed to upgrading 4Suite. [molson@penny 4Suite]$ python -c"from Ft.Lib import boolean" There is a problem importing the compiled boolean module. This can mean that there were errors with ths installation of 4Suite. Inwhich case you should contact 4Suite@lists.fourthought.com with the error messages generated during installation. This can also mean that you are attempting to execute code from the installation directory. If your current working directory contains the setup.py file for 4Suite installation then you are in the installation directory for 4Suite. You must change directories before you can use the Ft module. Mike > I' ve just installed python and here the probleme: it gives me the > following error: > >>> from Ft.Xml.Xslt import Processor > Traceback (most recent call last): > File "", line 1, in ? > File "Ft/Xml/Xslt/__init__.py", line 41, in ? > from Ft.Xml import XPath > File "Ft/Xml/XPath/__init__.py", line 25, in ? > from Ft.Lib import boolean > ImportError: cannot import name boolean > > what must I make to solve this problem? > > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From Mike.Olson@fourthought.com Fri Jul 26 18:46:16 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 26 Jul 2002 11:46:16 -0600 Subject: [XML-SIG] minidom changes In-Reply-To: <15680.50165.50196.802595@grendel.zope.com> References: <1027550306.4699.133.camel@penny> <15680.9407.40539.296654@grendel.zope.com> <1027637917.3273.0.camel@penny> <15680.50165.50196.802595@grendel.zope.com> Message-ID: <1027705577.3373.20.camel@penny> On Thu, 2002-07-25 at 21:37, Fred L. Drake, Jr. wrote: > > > I agree. The DOM is definately a factory-centric API. I've fixed the test file to create the element correctly and checked in. > > > However, I think we say it is OK to do xml.dom.minidom.Element('e') > > inwhich case we could have a lot of nodes without owner documents and a > > lot of people will get these errors. > > I'm not sure what you mean. I certainly don't know of any > documentation that indicates that's a way to do it. I'm less > concerned about maintaining undocumented behavior than Martin. > Maybe its not documented. I also think I'm out of date. I know we had a lot of code that just created Elements but having moved to cDomlette I think we removed most of that. So never mind :) Mike > > -Fred > > -- > Fred L. Drake, Jr. > PythonLabs at Zope Corporation -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From Mike.Olson@fourthought.com Fri Jul 26 18:42:54 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 26 Jul 2002 11:42:54 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027705645.31684.20113.camel@malatesta> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> Message-ID: <1027705375.3273.18.camel@penny> On Fri, 2002-07-26 at 11:47, Uche Ogbuji wrote: > > > Unfortunatly, the code I've added could > > cause use problems down the line unless we encourage people to do a > > fresh install as opposed to upgrading 4Suite. > > Could you clarify this last sentence a bit? Before my change there was Ft/Lib/boolean.so After my change: Ft/Lib/boolean.py Ft/Lib/booleanc.so boolean.py basically does from booleanc import * inside a try and except. The problem is that is you upgrade, then there will be two files called boolean in that directory. boolean.py and boolean.so boolean.so will never get reinstalled, but it could get imported first. this is not really a problem until we change boolean.c (fix a bug, add a feature, etc). Inwhich case, if the old boolean.so gets imported before boolean.py, then the new functionality will not be available. Also note, we cannot really get around this. If we do anything in Ft/Lib/__init__.py then we hav installation issues as setup.py imports from Ft/Lib/DistExt in the installation directory. At install time, boolean.* does not exist yet and we would get exceptions. Is that clear? :) Mike > > > > [molson@penny 4Suite]$ python -c"from Ft.Lib import boolean" > > There is a problem importing the compiled boolean module. > > This can mean that there were errors with ths installation of > > 4Suite. Inwhich case you should contact 4Suite@lists.fourthought.com > > with the > > error messages generated during installation. > > > > This can also mean that you are attempting to execute code from the > > installation > > directory. If your current working directory contains the setup.py file > > for > > 4Suite installation then you are in the installation directory for > > 4Suite. You > > must change directories before you can use the Ft module. > > Could you reverse the order of this message? I think it should first of > all make them check that they're not running from the build dir, and > *then* say if they have a remaining problem they should report to the > list. I just worry that people won't read through the whole message. > > I can do this, if you like. > > > -- > Uche Ogbuji Fourthought, Inc. > http://uche.ogbuji.net http://4Suite.org http://fourthought.com > Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ > Basic XML and RDF techniques for knowledge management, Part 7 - > http://www-106.ibm.com/developerworks/xml/library/x-think12.html > Keeping pace with James Clark - > http://www-106.ibm.com/developerworks/xml/library/x-jclark.html > Python and XML development using 4Suite, Part 3: 4RDF - > http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From uche.ogbuji@fourthought.com Fri Jul 26 19:00:40 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 26 Jul 2002 12:00:40 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027705375.3273.18.camel@penny> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> Message-ID: <1027706444.31684.20172.camel@malatesta> On Fri, 2002-07-26 at 11:42, Mike Olson wrote: > On Fri, 2002-07-26 at 11:47, Uche Ogbuji wrote: > > > > > Unfortunatly, the code I've added could > > > cause use problems down the line unless we encourage people to do a > > > fresh install as opposed to upgrading 4Suite. > > > > Could you clarify this last sentence a bit? > > Before my change there was Ft/Lib/boolean.so > > After my change: > Ft/Lib/boolean.py > Ft/Lib/booleanc.so > > boolean.py basically does from booleanc import * inside a try and > except. > > The problem is that is you upgrade, then there will be two files called > boolean in that directory. boolean.py and boolean.so > > boolean.so will never get reinstalled, but it could get imported first. > > this is not really a problem until we change boolean.c (fix a bug, add a > feature, etc). Inwhich case, if the old boolean.so gets imported before > boolean.py, then the new functionality will not be available. > > Also note, we cannot really get around this. If we do anything in > Ft/Lib/__init__.py then we hav installation issues as setup.py imports > from Ft/Lib/DistExt in the installation directory. At install time, > boolean.* does not exist yet and we would get exceptions. Can't we fix this with an import hook inside Ft/Lib/__init__.py? I'm sure that's not clear, so I'll do a bit of experimentation and report back. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC From fdrake@acm.org Fri Jul 26 19:16:14 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 26 Jul 2002 14:16:14 -0400 Subject: [XML-SIG] Gone for a few days. Message-ID: <15681.37358.410990.728573@grendel.zope.com> I'm off for a long weekend, and won't have access to email until Monday evening (probably very late). I'll catch up then. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From shane@irosoft.com Fri Jul 26 19:30:36 2002 From: shane@irosoft.com (Daniel Shane) Date: Fri, 26 Jul 2002 14:30:36 -0400 Subject: [XML-SIG] XmlProc and the ANY element Message-ID: <200207261430.36852.shane@irosoft.com> Hi everyone, I am currently building an application using xmlproc and have found that = I=20 need to know what are the next valid elements even when the content model= is=20 ANY. In its current state XMLProc returns the empty list and although som= e=20 may have built applications that expect this behavior I think it should=20 really return the list of all the valid DTD elements. I am sending this email to gather if anyone else had this need in the pas= t and=20 how it was handled. If a good solution pops out of this thread, I am sure= =20 Lars would include a patch to change the behavior of the ElementAny. To start the flames (oups... I meant process!) here are the three solutio= ns I=20 propose: a) Change the automaton to physically have steps from ANY to all elements= ,=20 therefore eliminating the special ElementAny class (I am not sure this is= =20 possible...) at the same time. This would mean that the parsing of the DT= D=20 would have two steps, first it would parse the DTD to detect all the=20 elements, and after it would re-parse it to build the elementType objects= =20 using the list of the DTD elements built in the first pass to convert the= ANY=20 to standard ElementType objects. b) Catch the current elementType is the main program and call a function = on=20 the dtd which would return the list of all elements if the type is ANY. T= his=20 would not break the current implementation but is a bit of a hassle for t= he=20 programmer. =20 c) Keep a reference to the dtd in the ElementType ANY and return dtd.get_= elems=20 (or the equivalent). With the advent of Python 2.x this should not leak=20 memory but we would need an unlink, which is not that nice. Please feel free to comment on these! Regards, Daniel Shane -- Daniel Shane Programmeur Analyste, IROSoft inc. web: http://www.irosoft.com email: shane@irosoft.com=20 From martin@v.loewis.de Fri Jul 26 20:04:12 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 26 Jul 2002 21:04:12 +0200 Subject: [XML-SIG] XmlProc and the ANY element In-Reply-To: <200207261430.36852.shane@irosoft.com> References: <200207261430.36852.shane@irosoft.com> Message-ID: Daniel Shane writes: > Please feel free to comment on these! While I haven't used validation that much in the first place, I feel that what you suggest is reasonable. If you need this soon, the best way might be to implement it yourself; when you are done, please post a patch to SourceForge. It sounds like there is a slight chance that performance will go down every time the content model is ANY; it would be good if you could arrange a test that shows that any slowdown is only insignificant. If you want to be particularly careful, please run the xmlproc test suite, which is in separate CVS module on PyXML CVS. Regards, Martin From Mike.Olson@fourthought.com Fri Jul 26 20:49:21 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 26 Jul 2002 13:49:21 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027706444.31684.20172.camel@malatesta> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> Message-ID: <1027712962.3273.22.camel@penny> On Fri, 2002-07-26 at 12:00, Uche Ogbuji wrote: > > Can't we fix this with an import hook inside Ft/Lib/__init__.py? > > I'm sure that's not clear, so I'll do a bit of experimentation and > report back. Nope, unless we move DistExt. The problem is that in setup.py we do "from Ft.Lib import DistExt". If, in Ft/Lib/__init__.py you mess with boolean, which does not exist at install time, then we won't be able to install. Mike > > > -- > Uche Ogbuji Fourthought, Inc. > http://uche.ogbuji.net http://4Suite.org http://fourthought.com > Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ > Basic XML and RDF techniques for knowledge management, Part 7 - > http://www-106.ibm.com/developerworks/xml/library/x-think12.html > Keeping pace with James Clark - > http://www-106.ibm.com/developerworks/xml/library/x-jclark.html > Python and XML development using 4Suite, Part 3: 4RDF - > http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From uche.ogbuji@fourthought.com Sat Jul 27 06:52:55 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 26 Jul 2002 23:52:55 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027712962.3273.22.camel@penny> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> <1027712962.3273.22.camel@penny> Message-ID: <1027749179.31686.22591.camel@malatesta> On Fri, 2002-07-26 at 13:49, Mike Olson wrote: > On Fri, 2002-07-26 at 12:00, Uche Ogbuji wrote: > > > > Can't we fix this with an import hook inside Ft/Lib/__init__.py? > > > > I'm sure that's not clear, so I'll do a bit of experimentation and > > report back. > > > Nope, unless we move DistExt. > > The problem is that in setup.py we do "from Ft.Lib import DistExt". If, > in Ft/Lib/__init__.py you mess with boolean, which does not exist at > install time, then we won't be able to install. Was this meant to be a challenge? No better way to get me to fix the problem :-) And fix it I did. No boolean.py necessary. All I did was use os.environ to flag when we were in setup.py. I tested it after blowing away build and site-packages/Ft. Works. It gives the error message in the install dir, and doesn't outside of it. All is well, I think. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC From Mike.Olson@fourthought.com Sun Jul 28 00:41:03 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 27 Jul 2002 17:41:03 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027749179.31686.22591.camel@malatesta> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> <1027712962.3273.22.camel@penny> <1027749179.31686.22591.camel@malatesta> Message-ID: <1027813298.3269.0.camel@penny> On Fri, 2002-07-26 at 23:52, Uche Ogbuji wrote: > On Fri, 2002-07-26 at 13:49, Mike Olson wrote: > > On Fri, 2002-07-26 at 12:00, Uche Ogbuji wrote: > > > > > > Can't we fix this with an import hook inside Ft/Lib/__init__.py? > > > > > > I'm sure that's not clear, so I'll do a bit of experimentation and > > > report back. > > > > > > Nope, unless we move DistExt. > > > > The problem is that in setup.py we do "from Ft.Lib import DistExt". If, > > in Ft/Lib/__init__.py you mess with boolean, which does not exist at > > install time, then we won't be able to install. > > Was this meant to be a challenge? No better way to get me to fix the > problem :-) > > And fix it I did. No boolean.py necessary. All I did was use > os.environ to flag when we were in setup.py. Yah thought of this as well but it doesn;t seem as clean to me. Actually, Jeremy recommended using builtins as opposed to the environment. Actually, it is easier then that. Looking at import precidence, boolean.so will always get imported before boolean.py. So, the only time that boolean.py will get imported is in the installation directory. We should keep both boolean.py and rename booleanc.so back to boolean.so, then we won't have any problems. Mike > > I tested it after blowing away build and site-packages/Ft. Works. It > gives the error message in the install dir, and doesn't outside of it. > > All is well, I think. > > > -- > Uche Ogbuji Fourthought, Inc. > http://uche.ogbuji.net http://4Suite.org http://fourthought.com > Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ > Basic XML and RDF techniques for knowledge management, Part 7 - > http://www-106.ibm.com/developerworks/xml/library/x-think12.html > Keeping pace with James Clark - > http://www-106.ibm.com/developerworks/xml/library/x-jclark.html > Python and XML development using 4Suite, Part 3: 4RDF - > http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From Mike.Olson@fourthought.com Sun Jul 28 00:42:16 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 27 Jul 2002 17:42:16 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027749179.31686.22591.camel@malatesta> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> <1027712962.3273.22.camel@penny> <1027749179.31686.22591.camel@malatesta> Message-ID: <1027813362.3292.2.camel@penny> On Fri, 2002-07-26 at 23:52, Uche Ogbuji wrote: > On Fri, 2002-07-26 at 13:49, Mike Olson wrote: > > On Fri, 2002-07-26 at 12:00, Uche Ogbuji wrote: > > > > > > Can't we fix this with an import hook inside Ft/Lib/__init__.py? > > > > > > I'm sure that's not clear, so I'll do a bit of experimentation and > > > report back. > > > > > > Nope, unless we move DistExt. > > > > The problem is that in setup.py we do "from Ft.Lib import DistExt". If, > > in Ft/Lib/__init__.py you mess with boolean, which does not exist at > > install time, then we won't be able to install. > > Was this meant to be a challenge? No better way to get me to fix the > problem :-) > Oh yah, XSLT and RDF are slow and I don't think these are fixable :) Mike > > > -- > Uche Ogbuji Fourthought, Inc. > http://uche.ogbuji.net http://4Suite.org http://fourthought.com > Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ > Basic XML and RDF techniques for knowledge management, Part 7 - > http://www-106.ibm.com/developerworks/xml/library/x-think12.html > Keeping pace with James Clark - > http://www-106.ibm.com/developerworks/xml/library/x-jclark.html > Python and XML development using 4Suite, Part 3: 4RDF - > http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From uche.ogbuji@fourthought.com Sun Jul 28 06:52:31 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 27 Jul 2002 23:52:31 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027813298.3269.0.camel@penny> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> <1027712962.3273.22.camel@penny> <1027749179.31686.22591.camel@malatesta> <1027813298.3269.0.camel@penny> Message-ID: <1027835555.31686.26916.camel@malatesta> On Sat, 2002-07-27 at 17:41, Mike Olson wrote: > On Fri, 2002-07-26 at 23:52, Uche Ogbuji wrote: > > On Fri, 2002-07-26 at 13:49, Mike Olson wrote: > > > On Fri, 2002-07-26 at 12:00, Uche Ogbuji wrote: > > > > > > > > Can't we fix this with an import hook inside Ft/Lib/__init__.py? > > > > > > > > I'm sure that's not clear, so I'll do a bit of experimentation and > > > > report back. > > > > > > > > > Nope, unless we move DistExt. > > > > > > The problem is that in setup.py we do "from Ft.Lib import DistExt". If, > > > in Ft/Lib/__init__.py you mess with boolean, which does not exist at > > > install time, then we won't be able to install. > > > > Was this meant to be a challenge? No better way to get me to fix the > > problem :-) > > > > And fix it I did. No boolean.py necessary. All I did was use > > os.environ to flag when we were in setup.py. > > Yah thought of this as well but it doesn;t seem as clean to me. > Actually, Jeremy recommended using builtins as opposed to the > environment. Whatever is unclean about it? It is using the environment for just what it is supposed to be. Do you say that having clashing modules with the same name is cleaner? I hardly think so. Can you give a practical problem with my fix? You yourself already provided a practical problem with your own. As for using builtings, I do think this would be too hacky. The environment is just ideal for this sort of thing, as long as you're not on one of the small minority of POSIX OSes that treat the environment in strange ways. And if you're on one of those, you have bigger problems with the environment. > Actually, it is easier then that. Looking at import precidence, > boolean.so will always get imported before boolean.py. So, the only > time that boolean.py will get imported is in the installation > directory. We should keep both boolean.py and rename booleanc.so back > to boolean.so, then we won't have any problems. I already removed boolean.py. I think it's a bad idea, and unnecessary, to boot. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC From uche.ogbuji@fourthought.com Sun Jul 28 06:56:23 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 27 Jul 2002 23:56:23 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027813362.3292.2.camel@penny> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> <1027712962.3273.22.camel@penny> <1027749179.31686.22591.camel@malatesta> <1027813362.3292.2.camel@penny> Message-ID: <1027835784.31685.26932.camel@malatesta> On Sat, 2002-07-27 at 17:42, Mike Olson wrote: > On Fri, 2002-07-26 at 23:52, Uche Ogbuji wrote: > > On Fri, 2002-07-26 at 13:49, Mike Olson wrote: > > > On Fri, 2002-07-26 at 12:00, Uche Ogbuji wrote: > > > > > > > > Can't we fix this with an import hook inside Ft/Lib/__init__.py? > > > > > > > > I'm sure that's not clear, so I'll do a bit of experimentation and > > > > report back. > > > > > > > > > Nope, unless we move DistExt. > > > > > > The problem is that in setup.py we do "from Ft.Lib import DistExt". If, > > > in Ft/Lib/__init__.py you mess with boolean, which does not exist at > > > install time, then we won't be able to install. > > > > Was this meant to be a challenge? No better way to get me to fix the > > problem :-) > > > > Oh yah, XSLT and RDF are slow and I don't think these are fixable :) I disagree. They are quite "fixable", but I'm personally not interested in any more non-trivial optimizations to this generation of XSLT and RDF. I'm looking forward to 4Suite 1.0 so that we can refactor the lot. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC From uche.ogbuji@fourthought.com Sun Jul 28 07:10:59 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 28 Jul 2002 00:10:59 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027835784.31685.26932.camel@malatesta> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> <1027712962.3273.22.camel@penny> <1027749179.31686.22591.camel@malatesta> <1027813362.3292.2.camel@penny> <1027835784.31685.26932.camel@malatesta> Message-ID: <1027836664.31686.26987.camel@malatesta> On Sat, 2002-07-27 at 23:56, Uche Ogbuji wrote: > On Sat, 2002-07-27 at 17:42, Mike Olson wrote: > > On Fri, 2002-07-26 at 23:52, Uche Ogbuji wrote: > > > On Fri, 2002-07-26 at 13:49, Mike Olson wrote: > > > > On Fri, 2002-07-26 at 12:00, Uche Ogbuji wrote: > > > > > > > > > > Can't we fix this with an import hook inside Ft/Lib/__init__.py? > > > > > > > > > > I'm sure that's not clear, so I'll do a bit of experimentation and > > > > > report back. > > > > > > > > > > > > Nope, unless we move DistExt. > > > > > > > > The problem is that in setup.py we do "from Ft.Lib import DistExt". If, > > > > in Ft/Lib/__init__.py you mess with boolean, which does not exist at > > > > install time, then we won't be able to install. > > > > > > Was this meant to be a challenge? No better way to get me to fix the > > > problem :-) > > > > > > > Oh yah, XSLT and RDF are slow and I don't think these are fixable :) > > I disagree. They are quite "fixable", but I'm personally not interested > in any more non-trivial optimizations to this generation of XSLT and > RDF. I'm looking forward to 4Suite 1.0 so that we can refactor the lot. Just to point out what I know about optimizing XSLT and RDF, in case someone else is feeling extraordinarily ambitious: When I was putting a lot of work into optimizing Versa at Client behest, and seeing a great deal of result, I would occasionally notice parallel optimizations that could be made in XPath. We do very little intelligent truncation of result sets in XPath, and very little caching of partial results. Implementing such optimizations would make a dramatic difference. As for RDF: there are several matters. First of all, our parsing is very slow and inefficient because it is based on DOM. If we re-wrote the parser to use SAX (according to my analysis RDF is actually quite amenable to SAX parsing, and this is what Redfoot does, after all), we'd have a lot to reap. We could also go straight to low-level expat interface, of course. We could also implement statements and objects as C extensions, which would help speed and space Also, we make a lot of round trips to the DBMS in some cases. By using PsycoPG's ability to aggregate querites, we could glean significant speed-ups. This could be combined with writing stored procs for certain aggregated queries. Finally, I think based on Postgres C API, we could write an RDF-specialized indexer with a moderate amount of effort that would yield dramatic results. I already had to shut off our index on objects because it's really easy to blow PG's maximum text index block limitations, and in any case, PG does not use indexes if the tables have entries beyond a certain length. It was just slowing down our manip with no gain in query speed. Starting from the full-text Intermedia-like-thingie that comes in PG's contrib bundle, I think we could write something very spiffy for RDF. But as I said, I think all such effort should be spent on the next generation. My personal biggest interest for 4Suite now is completeness and stability. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC From Mike.Olson@fourthought.com Sun Jul 28 07:45:35 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 28 Jul 2002 00:45:35 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027835555.31686.26916.camel@malatesta> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> <1027712962.3273.22.camel@penny> <1027749179.31686.22591.camel@malatesta> <1027813298.3269.0.camel@penny> <1027835555.31686.26916.camel@malatesta> Message-ID: <1027838736.3269.8.camel@penny> On Sat, 2002-07-27 at 23:52, Uche Ogbuji wrote: > > Whatever is unclean about it? It is using the environment for just what > it is supposed to be. Do you say that having clashing modules with the > same name is cleaner? I hardly think so. It comes down to our difference of opinion on what env vars are used for. I think they should be used for a user of an application to give information to the application. Not as another place for an application to store global variables. The clashing modules is not an issue if people remove the previous installation. This is far from the first time that we have required this. It can even be added to our installation to see if the old one exists and remove it. > > Can you give a practical problem with my fix? You yourself already > provided a practical problem with your own. Nope, just not the correct use of env vars. I think the best solution is to use the 2 boolean approach. > > As for using builtings, I do think this would be too hacky. The > environment is just ideal for this sort of thing, as long as you're not > on one of the small minority of POSIX OSes that treat the environment in > strange ways. And if you're on one of those, you have bigger problems > with the environment. > > > Actually, it is easier then that. Looking at import precidence, > > boolean.so will always get imported before boolean.py. So, the only > > time that boolean.py will get imported is in the installation > > directory. We should keep both boolean.py and rename booleanc.so back > > to boolean.so, then we won't have any problems. > > I already removed boolean.py. I think it's a bad idea, and unnecessary, > to boot. I still like this solution better. It does exactly what we need, does not effect import time, does not improperly use env vars. The only down side to it is that it could confuse people that look at boolean.py in the src tree but that it doesn;t get run. Mike > > > -- > Uche Ogbuji Fourthought, Inc. > http://uche.ogbuji.net http://4Suite.org http://fourthought.com > Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ > Basic XML and RDF techniques for knowledge management, Part 7 - > http://www-106.ibm.com/developerworks/xml/library/x-think12.html > Keeping pace with James Clark - > http://www-106.ibm.com/developerworks/xml/library/x-jclark.html > Python and XML development using 4Suite, Part 3: 4RDF - > http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From uche.ogbuji@fourthought.com Sun Jul 28 16:25:55 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 28 Jul 2002 09:25:55 -0600 Subject: [4suite] Re: [XML-SIG] problem whith the error " ImportError: cannot import name boolean" In-Reply-To: <1027838736.3269.8.camel@penny> References: <3D416E85.7080708@ext.cri74.org> <1027703336.3273.10.camel@penny> <1027705645.31684.20113.camel@malatesta> <1027705375.3273.18.camel@penny> <1027706444.31684.20172.camel@malatesta> <1027712962.3273.22.camel@penny> <1027749179.31686.22591.camel@malatesta> <1027813298.3269.0.camel@penny> <1027835555.31686.26916.camel@malatesta> <1027838736.3269.8.camel@penny> Message-ID: <1027869961.31685.28667.camel@malatesta> On Sun, 2002-07-28 at 00:45, Mike Olson wrote: > On Sat, 2002-07-27 at 23:52, Uche Ogbuji wrote: > > > > Whatever is unclean about it? It is using the environment for just what > > it is supposed to be. Do you say that having clashing modules with the > > same name is cleaner? I hardly think so. > > It comes down to our difference of opinion on what env vars are used > for. I think they should be used for a user of an application to give > information to the application. Not as another place for an application > to store global variables. Actually, I have never heard of this difference of opinion before. The last time I pinned you down on any remotely related matter was the issue of extension modules where you said that your problem was not the use of the environment, but the use of a module-global dictionary, which I had never denied was unsuitable. We still use the environment for listign additional extension modules, and should. In several conversations I remember your just generally grumbling that you don't like environment variables, but never really giving any substance to back such grumbling. Yet you used the environment in the implementation of 4ss agent, which I think is fine, but involves the app using the environment to store global data, which seems a contradiction to your view. Anyway, do you have any basis for your restriction of what you think environments should be used for? They are precisely a global "dictionary" for applications, have always been so, and are used so in a million different ways by a million different applications. Since I doubt you'll be able to answer this on spec or conventional grounds, I'll make the task easier: can you tell me specifically how using os.environment in the way I did is problematic in 4Suite? > I still like this solution better. It does exactly what we need, As does mine > does not effect import time, I would bet my approach is faster than yours. > does not improperly use env vars. matter of dispute. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC From bates@stat.wisc.edu Tue Jul 30 22:29:54 2002 From: bates@stat.wisc.edu (Douglas Bates) Date: 30 Jul 2002 16:29:54 -0500 Subject: [XML-SIG] "Character reference too large" error with HtmlLib.Reader() Message-ID: <6rznw8q4z1.fsf@franz.stat.wisc.edu> I am using Debian GNU/Linux 3.0 (woody) with the Debian python2.2-xml (0.7.1-2) package. I am trying to build a DOM of an HTML URI using from xml.dom.ext.reader.HtmlLib import Reader dom =3D Reader().fromUri(...) The HTML returned from this URI occasionally has character references such as
Alberto Luceño and Jaime Puig-Pey
and I get errors of Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/_xmlplus/dom/ext/reader/HtmlLib.py= ", line 63, in fromUri return self.fromStream(stream, ownerDoc, charset) File "/usr/lib/python2.2/site-packages/_xmlplus/dom/ext/reader/HtmlLib.py= ", line 28, in fromStream self.parser.parse(stream) File "/usr/lib/python2.2/site-packages/_xmlplus/dom/ext/reader/Sgmlop.py"= , line 57, in parse self._parser.parse(stream.read()) ValueError: character reference too large As I understand the code in Sgmlop.py the default characterset is ISO-8859-1 and ñ should be small n, tilde =F1 ñ --> =F1 ñ --> = =F1 in ISO-8859-1. I welcome suggestions (and thank the developers for a wonderful package). --=20 Douglas Bates bates@stat.wisc.edu Statistics Department 608/262-2598 University of Wisconsin - Madison http://www.stat.wisc.edu/~bates/ From larsga@garshol.priv.no Tue Jul 30 22:35:48 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 30 Jul 2002 23:35:48 +0200 Subject: [XML-SIG] "Character reference too large" error with HtmlLib.Reader() In-Reply-To: <6rznw8q4z1.fsf@franz.stat.wisc.edu> References: <6rznw8q4z1.fsf@franz.stat.wisc.edu> Message-ID: * Douglas Bates |=20 | The HTML returned from this URI occasionally has character references | such as |
Alberto Luceño and Jaime Puig-Pey
| and I get errors of | [...] | ValueError: character reference too large This sounds like an obvious bug. I suggest you make the smallest document you can that reproduces the error, and then report this as a bug in the PyXML Sourceforge project (it seems to be in sgmlop, which I don't think is part of Python proper), attaching the file to it. =20 | As I understand the code in Sgmlop.py the default characterset is | ISO-8859-1 and ñ should be |=20 | small n, tilde =F1 ñ --> =F1 ñ --= > =F1 |=20 | in ISO-8859-1. Actually, character references are based on the document character set, and for HTML that's declared in the SGML declaration, and declared to be Unicode. Which gives the same result. (So that might actually be another bug...) --=20 Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From larsga@garshol.priv.no Tue Jul 30 22:38:37 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 30 Jul 2002 23:38:37 +0200 Subject: [XML-SIG] XmlProc and the ANY element In-Reply-To: References: <200207261430.36852.shane@irosoft.com> Message-ID: * Martin v. Loewis | | It sounds like there is a slight chance that performance will go | down every time the content model is ANY; it would be good if you | could arrange a test that shows that any slowdown is only | insignificant. Actually, there won't be a performance problem. The method that returns the currently valid elements is not used by the XML validator in xmlproc. The method is just there because the XML content model validation code is written in a way that means we have this information, and it's useful for some types of applications (like DTD-driven editors). | If you want to be particularly careful, please run the xmlproc test | suite, which is in separate CVS module on PyXML CVS. That would be good, in any case. Is that test suite up to date, BTW? (I haven't looked at it in a looong time, I'm ashamed to admit.) -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From larsga@garshol.priv.no Tue Jul 30 22:46:55 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 30 Jul 2002 23:46:55 +0200 Subject: [XML-SIG] XmlProc and the ANY element In-Reply-To: <200207261430.36852.shane@irosoft.com> References: <200207261430.36852.shane@irosoft.com> Message-ID: * Daniel Shane | | a) Change the automaton to physically have steps from ANY to all | elements, therefore eliminating the special ElementAny class (I am | not sure this is possible...) at the same time. This is possible, but would require the automatons for ANY content models to be computed only when the entire DTD has been parsed. And it wouldn't work for DTDs generated using the API (well, that might not work anyway). It would have a performance impact, however, and it would cause certain complications, so I think I would discourage this approach. | This would mean that the parsing of the DTD would have two steps, | first it would parse the DTD to detect all the elements, and after | it would re-parse it to build the elementType objects using the list | of the DTD elements built in the first pass to convert the ANY to | standard ElementType objects. Well, you can just make a list of all elements with ANY content models, and then run over that at the end. Reparsing the DTD would be quite costly (think of DocBook!), so I would prefer to avoid that. | b) Catch the current elementType is the main program and call a | function on the dtd which would return the list of all elements if | the type is ANY. This would not break the current implementation but | is a bit of a hassle for the programmer. I guess this is what people do now. I think Alexandre Fayolle had this very issue a while ago. I'd be interested to see what he says. | c) Keep a reference to the dtd in the ElementType ANY and return | dtd.get_elems (or the equivalent). With the advent of Python 2.x | this should not leak memory but we would need an unlink, which is | not that nice. I think this is the best solution, though what is worst of the disease and the cure I am not sure. :-) -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From fdrake@acm.org Tue Jul 30 23:02:14 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 30 Jul 2002 18:02:14 -0400 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <3D3E7FC2.9060108@livinglogic.de> References: <3D3E7FC2.9060108@livinglogic.de> Message-ID: <15687.3302.102707.808032@grendel.zope.com> =?ISO-8859-1?Q?Walter_D=F6rwald?= writes: > I'd vote for bug SF patch #412237 > > http://sourceforge.net/tracker/index.php?func=detail&aid=412237&group_id=6473&atid=306473 > > and the patch for SF bug #497322 > > http://sourceforge.net/tracker/index.php?func=detail&aid=497322&group_id=6473&atid=106473 These have both been taken care of. Are we ready for 0.8 ?? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Wed Jul 31 02:54:22 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 30 Jul 2002 19:54:22 -0600 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: Message from "Fred L. Drake, Jr." of "Tue, 30 Jul 2002 18:02:14 EDT." <15687.3302.102707.808032@grendel.zope.com> Message-ID: > > =?ISO-8859-1?Q?Walter_D=F6rwald?= writes: > > I'd vote for bug SF patch #412237 > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=412237&group_id=6473&atid=306473 > > > > and the patch for SF bug #497322 > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=497322&group_id=6473&atid=106473 > > These have both been taken care of. > > Are we ready for 0.8 ?? OK. I guess I know what I'm doing this evening :-) I have a very simple DOM reader based on HTMLParser. Should I check this in with the right try/except around the import? It might even address the recent problem with the sgmlop parser and numerical char entities. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra ry/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A 1EA5A2CF4621C386256BBB006F4CEC From fdrake@acm.org Wed Jul 31 03:31:04 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 30 Jul 2002 22:31:04 -0400 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: References: <15687.3302.102707.808032@grendel.zope.com> Message-ID: <15687.19432.316123.786584@grendel.zope.com> Uche Ogbuji writes: > I have a very simple DOM reader based on HTMLParser. Should I > check this in with the right try/except around the import? It > might even address the recent problem with the sgmlop parser and > numerical char entities. The HTMLParser module from the standard library? Or is there another I'm missing? I suppose it's not unreasonable, but I'd think there's a lot to be added to the basic parser code, which is really little more than a "high-level tokenizer." Why would you need to catch an ImportError? ... Hm. Getting around lack of that module in 2.1.x and earlier is fairly painful. One option would be to include a copy of it in xml.parsers (or better yet, hidden away where it can be forgotten!). Does it make more sense to figure a hack around the repeated-import issues or just fix problems in sgmlop so it can always be used? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Wed Jul 31 03:42:34 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 30 Jul 2002 20:42:34 -0600 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <15687.19432.316123.786584@grendel.zope.com> References: <15687.3302.102707.808032@grendel.zope.com> <15687.19432.316123.786584@grendel.zope.com> Message-ID: <1028083355.1072.795.camel@malatesta> On Tue, 2002-07-30 at 20:31, Fred L. Drake, Jr. wrote: > > Uche Ogbuji writes: > > I have a very simple DOM reader based on HTMLParser. Should I > > check this in with the right try/except around the import? It > > might even address the recent problem with the sgmlop parser and > > numerical char entities. > > The HTMLParser module from the standard library? Or is there another > I'm missing? The std library. 2.1 or later onnly, ya know. > I suppose it's not unreasonable, but I'd think there's a lot to be > added to the basic parser code, which is really little more than a > "high-level tokenizer." Yes. I did add the code that generates a DOM given an impl. But then again, it was for a quick and dirty hack, and hasn't been heavily tested. > Why would you need to catch an ImportError? ... Hm. Getting around > lack of that module in 2.1.x and earlier is fairly painful. One > option would be to include a copy of it in xml.parsers (or better yet, > hidden away where it can be forgotten!). > > Does it make more sense to figure a hack around the repeated-import > issues or just fix problems in sgmlop so it can always be used? I just mentioned it because I already had it lying around. Given that the release is impending, I think I should put away the idea for now. Someone really should fix the sgmlop char ent bug before this release, though. I don't suppose Walter has a moment? I would, but I'll already have my hands full of PyXML work tonight and I think he knows sgmlop better than I do. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A1EA5A2CF4621C386256BBB006F4CEC From fdrake@acm.org Wed Jul 31 04:02:47 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 30 Jul 2002 23:02:47 -0400 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: <1028083355.1072.795.camel@malatesta> References: <15687.3302.102707.808032@grendel.zope.com> <15687.19432.316123.786584@grendel.zope.com> <1028083355.1072.795.camel@malatesta> Message-ID: <15687.21335.151870.994470@grendel.zope.com> Uche Ogbuji writes: > The std library. 2.1 or later onnly, ya know. I know -- I wrote that module! ;-) > I just mentioned it because I already had it lying around. Given that > the release is impending, I think I should put away the idea for now. Agreed. Perhaps it would be useful to add an "html" package to the "sandbox" area to let people look at / work on the module to see if there's sufficient interest in polishing it up for release. > Someone really should fix the sgmlop char ent bug before this release, > though. I don't suppose Walter has a moment? I would, but I'll already > have my hands full of PyXML work tonight and I think he knows sgmlop > better than I do. Probably. I've not been using any of the HTML support code myself. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From uche.ogbuji@fourthought.com Wed Jul 31 05:34:13 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 30 Jul 2002 22:34:13 -0600 Subject: [XML-SIG] (no subject) Message-ID: Re: https://sourceforge.net/tracker/?func=detail&aid=490069&group_id=6473&atid=3064 73 I had hoped to get this in PyXML for 0.8, but I haven't heard from the author after a recent enquiry. It seems to work well, based on my simple tests. What do folks think of adding it to utils? -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Track chair, XML/Web Services One Boston: http://www.xmlconference.com/ Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra ry/x-jclark.html Python and XML development using 4Suite, Part 3: 4RDF - http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A 1EA5A2CF4621C386256BBB006F4CEC From martin@v.loewis.de Wed Jul 31 06:28:31 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 31 Jul 2002 07:28:31 +0200 Subject: [XML-SIG] Preparing for PyXML 0.8 In-Reply-To: References: Message-ID: Uche Ogbuji writes: > I have a very simple DOM reader based on HTMLParser. Should I check > this in with the right try/except around the import? Why is this urgent for PyXML 0.8? It appears not to be in the tree right now, so I guess it is too late for 0.8. THere will always be another release. Regards, Martin From martin@v.loewis.de Wed Jul 31 07:05:27 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 31 Jul 2002 08:05:27 +0200 Subject: [XML-SIG] XmlProc and the ANY element In-Reply-To: References: <200207261430.36852.shane@irosoft.com> Message-ID: Lars Marius Garshol writes: > That would be good, in any case. Is that test suite up to date, BTW? > (I haven't looked at it in a looong time, I'm ashamed to admit.) Unfortunately, I have to admit the same thing. Regards, Martin From martin@v.loewis.de Wed Jul 31 07:08:01 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 31 Jul 2002 08:08:01 +0200 Subject: [XML-SIG] (no subject) In-Reply-To: References: Message-ID: Uche Ogbuji writes: > What do folks think of adding it to utils? I was hoping that, in particular, Lars-Marius can comment on this patch. In any case, it's too late for 0.8. Regards, Martin From martin@v.loewis.de Wed Jul 31 07:55:35 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 31 Jul 2002 08:55:35 +0200 Subject: [XML-SIG] "Character reference too large" error with HtmlLib.Reader() In-Reply-To: References: <6rznw8q4z1.fsf@franz.stat.wisc.edu> Message-ID: Lars Marius Garshol writes: > This sounds like an obvious bug. I suggest you make the smallest > document you can that reproduces the error, and then report this as a > bug in the PyXML Sourceforge project (it seems to be in sgmlop, which > I don't think is part of Python proper), attaching the file to it. It turns out that the bug is not that obvious. sgmlop cannot return a Unicode string, since, in SGML mode, it would have to know what the character set for character references is. Instead, this was a bug in xml.dom.reader.SgmlOp.HtmlParser, which failed to implement handler_charref (sgmlop only tries to interpret the character references itself if handle_charref is not implemented). This will be fixed in PyXML 0.8; the fix is in SgmlOp.py 1.10. Regards, Martin From larsga@garshol.priv.no Wed Jul 31 13:15:02 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 31 Jul 2002 14:15:02 +0200 Subject: [XML-SIG] "Character reference too large" error with HtmlLib.Reader() In-Reply-To: References: <6rznw8q4z1.fsf@franz.stat.wisc.edu> Message-ID: * Lars Marius Garshol | | This sounds like an obvious bug. I suggest you make the smallest | document you can that reproduces the error, and then report this as | a bug in the PyXML Sourceforge project (it seems to be in sgmlop, | which I don't think is part of Python proper), attaching the file to | it. * Martin v. Loewis | | It turns out that the bug is not that obvious. sgmlop cannot return | a Unicode string, since, in SGML mode, it would have to know what the | character set for character references is. That I understand, but it shouldn't just say that the reference is too big. So the error message, at least, has to be improved. | Instead, this was a bug in xml.dom.reader.SgmlOp.HtmlParser, which | failed to implement handler_charref (sgmlop only tries to interpret | the character references itself if handle_charref is not | implemented). Sounds reasonable to me. | This will be fixed in PyXML 0.8; the fix is in SgmlOp.py 1.10. Good. :) -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From larsga@garshol.priv.no Wed Jul 31 13:19:10 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 31 Jul 2002 14:19:10 +0200 Subject: [XML-SIG] XmlProc and the ANY element In-Reply-To: References: <200207261430.36852.shane@irosoft.com> Message-ID: * Lars Marius Garshol | | That would be good, in any case. Is that test suite up to date, BTW? | (I haven't looked at it in a looong time, I'm ashamed to admit.) * Martin v. Loewis | | Unfortunately, I have to admit the same thing. I guess that means that it's not up to date, which I guess means that if any volunteer is looking for a useful self-contained substantial task they've now found one. :) Going through that test suite is a *lot* of work, and I can't really expect to find the time for that in the near future. (Just so people know.) If anyone does go through it, emails with questions about the failures and borderline cases would be very welcome. (In a lot of cases, what is correct is far from obvious.) -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From martin@v.loewis.de Wed Jul 31 19:20:05 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 31 Jul 2002 20:20:05 +0200 Subject: [XML-SIG] "Character reference too large" error with HtmlLib.Reader() In-Reply-To: References: <6rznw8q4z1.fsf@franz.stat.wisc.edu> Message-ID: Lars Marius Garshol writes: > That I understand, but it shouldn't just say that the reference is too > big. So the error message, at least, has to be improved. In PyXML 0.8, it says "character reference &#x%x; exceeds ASCII range". Regards, Martin From larsga@garshol.priv.no Wed Jul 31 20:07:00 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 31 Jul 2002 21:07:00 +0200 Subject: [XML-SIG] "Character reference too large" error with HtmlLib.Reader() In-Reply-To: References: <6rznw8q4z1.fsf@franz.stat.wisc.edu> Message-ID: * Lars Marius Garshol | | That I understand, but it shouldn't just say that the reference is too | big. So the error message, at least, has to be improved. * Martin v. Loewis | | In PyXML 0.8, it says "character reference &#x%x; exceeds ASCII range". Good. That should do. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC