From horst@freedict.de Wed Jan 2 11:37:03 2002 From: horst@freedict.de (horst@freedict.de) Date: Wed, 2 Jan 2002 12:37:03 +0100 (CET) Subject: [XML-SIG] accessing publicID / systemID Message-ID: <200201021137.g02Bb3R12498@eaglesnest.mceggman> Hello, I am using xml.dom and create the DOM tree by doing: DOM = Sax2.FromXmlStream(xmlfile) I made sure previously that the document is valid. How would I access the publicID and systemID? I expected that DOM.doctype.publicID for example would do the job, but failed. Can anyone enlighten me, please? Regards, horst -- Horst@freedict.de Horst Eyermann Germany You need a dictionary? - visit http://www.freedict.de for free (GPL) dictionaries (unix; windows work in progress) For windows, visit http://www.freedict.de/wbuch A article (in German) about dictionary efforts on the net http://www.heise.de/tp/deutsch/inhalt/on/5927/1.html From Sylvain.Thenault@logilab.fr Wed Jan 2 16:51:12 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Wed, 2 Jan 2002 17:51:12 +0100 (CET) Subject: [XML-SIG] accessing publicID / systemID In-Reply-To: <200201021137.g02Bb3R12498@eaglesnest.mceggman> Message-ID: On Wed, 2 Jan 2002 horst@freedict.de wrote: > Hello, > > I am using xml.dom and create the DOM tree by doing: > > DOM = Sax2.FromXmlStream(xmlfile) > > I made sure previously that the document is valid. How would I access > the publicID and systemID? > > I expected that DOM.doctype.publicID for example would do the job, but > failed. > > Can anyone enlighten me, please? > I don't know if it is a type in your mail, but the correct attributes of the doctype node are "systemId" and "publicId", not "systemID" and "publicID" Anyway, the problem is that most parsers don't take the time to correctly initialize the doctype node of the DOM tree, since only a few people would use it. Bad luck for you, you are in this case... ;) I think that the xmlproc parser handles this correctly. regards -- Sylvain Thenault LOGILAB http://www.logilab.org From arteri@airnett.com Thu Jan 3 08:44:02 2002 From: arteri@airnett.com (teri renee) Date: Thu, 3 Jan 2002 00:44:02 -0800 Subject: [XML-SIG] (no subject) Message-ID: <002401c19432$cbf9b5a0$2098bbd8@teri> This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C193EF.BD0D0B20 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0021_01C193EF.BD0D0B20 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0021_01C193EF.BD0D0B20-- From arteri@airnett.com Thu Jan 3 08:45:34 2002 From: arteri@airnett.com (teri renee) Date: Thu, 3 Jan 2002 00:45:34 -0800 Subject: [XML-SIG] (no subject) Message-ID: <005701c19433$02b5db00$2098bbd8@teri> This is a multi-part message in MIME format. ------=_NextPart_000_0054_01C193EF.F40DDAA0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0054_01C193EF.F40DDAA0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0054_01C193EF.F40DDAA0-- From Richard.Philips@ua.ac.be Thu Jan 3 10:17:38 2002 From: Richard.Philips@ua.ac.be (Richard Philips) Date: Thu, 03 Jan 2002 11:17:38 +0100 Subject: [XML-SIG] PyXML and python2.2 Message-ID: <3C342FC2.8090805@ua.ac.be> Is PyXML-0.7 safe to use with python-2.2 ? If not, is there a timeline for it ? Thank you, Richard Philips -- Dr. Richard PHILIPS University of Antwerp Systemmanager Anet Phone: +32 3 8202153 Fax: +32 3 8202159 Email: Richard.Philips@ua.ac.be From martin@v.loewis.de Thu Jan 3 21:27:21 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Thu, 3 Jan 2002 22:27:21 +0100 Subject: [XML-SIG] PyXML and python2.2 In-Reply-To: <3C342FC2.8090805@ua.ac.be> (message from Richard Philips on Thu, 03 Jan 2002 11:17:38 +0100) References: <3C342FC2.8090805@ua.ac.be> Message-ID: <200201032127.g03LRLK01417@mira.informatik.hu-berlin.de> > Is PyXML-0.7 safe to use with python-2.2 ? It is. Martin From haering_python@gmx.de Thu Jan 3 21:42:25 2002 From: haering_python@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Thu, 3 Jan 2002 22:42:25 +0100 Subject: [XML-SIG] PyXML and python2.2 In-Reply-To: <200201032127.g03LRLK01417@mira.informatik.hu-berlin.de> References: <3C342FC2.8090805@ua.ac.be> <200201032127.g03LRLK01417@mira.informatik.hu-berlin.de> Message-ID: <20020103214225.GA1319@lilith.hqd-internal> Le 03/01/02 à 22:27, Martin v. Loewis écrivit: > > Is PyXML-0.7 safe to use with python-2.2 ? > > It is. Could then anybody please upload a Windows installer for Python 2.2 for those who don't have a compiler installed? Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From martin@v.loewis.de Thu Jan 3 23:00:23 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Fri, 4 Jan 2002 00:00:23 +0100 Subject: [XML-SIG] PyXML and python2.2 In-Reply-To: <20020103214225.GA1319@lilith.hqd-internal> (message from Gerhard =?iso-8859-15?Q?H=E4ring?= on Thu, 3 Jan 2002 22:42:25 +0100) References: <3C342FC2.8090805@ua.ac.be> <200201032127.g03LRLK01417@mira.informatik.hu-berlin.de> <20020103214225.GA1319@lilith.hqd-internal> Message-ID: <200201032300.g03N0NG01808@mira.informatik.hu-berlin.de> > Could then anybody please upload a Windows installer for Python 2.2 for > those who don't have a compiler installed? I'll do it when I get to it (i.e. when I reboot Windows the next time). Regards, Martin From spierre@isb-sib.ch Fri Jan 4 12:33:00 2002 From: spierre@isb-sib.ch (=?ISO-8859-1?Q?S=E9bastien_Pierre?=) Date: Fri, 4 Jan 2002 13:33:00 +0100 Subject: [XML-SIG] Attribute none object Message-ID: <30530846-010F-11D6-A9E1-00039344BB54@isb-sib.ch> Hi all, This may be a PyXML related issued, but as it is from 4DOM I=20 post it on 4Suite also... Using PyXML 0.66, 4Suite 0.11, I do the following: a =3D node.getAttributeNS('','src')) print a a =3D node.attributes.getNamedItem('src') print a print a.nodeValue The first print does nothing (blank line), so obviously a is None The second print is: The third one generates an exception: AttributeError: 'None' object has no attribute 'nodeValue' So in this case a is an Attr at the second print and then=20 becomes None at the following one... I'm puzzled. Any ideas? -- S=E9bastien -- =ABToo old to be alternative, too alternative to be old.=BB http://www.type-z.org | Robert Smith, talking about his epitaph. From Alexandre.Fayolle@logilab.fr Fri Jan 4 16:09:28 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre Fayolle) Date: Fri, 4 Jan 2002 17:09:28 +0100 (CET) Subject: [XML-SIG] Re: [4suite] Attribute none object In-Reply-To: <30530846-010F-11D6-A9E1-00039344BB54@isb-sib.ch> Message-ID: Try a = node.getAttribute('src') print a The attribute probably was set using setAttribute and not setAttributeNS. On Fri, 4 Jan 2002, Sébastien Pierre wrote: > Hi all, > > This may be a PyXML related issued, but as it is from 4DOM I > post it on 4Suite also... > > Using PyXML 0.66, 4Suite 0.11, I do the following: > > a = node.getAttributeNS('','src')) > print a > a = node.attributes.getNamedItem('src') > print a > print a.nodeValue > > The first print does nothing (blank line), so obviously a is None > > The second print is: > Value="../Schemas/Planning-Preliminary.png"> > > The third one generates an exception: > AttributeError: 'None' object has no attribute 'nodeValue' > > So in this case a is an Attr at the second print and then > becomes None at the following one... I'm puzzled. > > Any ideas? > > -- Sébastien > > -- > «Too old to be alternative, too alternative to be old.» > http://www.type-z.org | Robert Smith, talking about his epitaph. > > _______________________________________________ > 4suite mailing list > 4suite@lists.fourthought.com > http://lists.fourthought.com/mailman/listinfo/4suite > 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 Fri Jan 4 16:09:34 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 04 Jan 2002 09:09:34 -0700 Subject: [XML-SIG] Re: [4suite] Attribute none object References: <30530846-010F-11D6-A9E1-00039344BB54@isb-sib.ch> Message-ID: <3C35D3BE.5241678E@fourthought.com> S=E9bastien Pierre wrote: >=20 > Hi all, >=20 > This may be a PyXML related issued, but as it is from 4DOM I > post it on 4Suite also... >=20 > Using PyXML 0.66, 4Suite 0.11, I do the following: >=20 > a =3D node.getAttributeNS('','src')) > print a > a =3D node.attributes.getNamedItem('src') > print a > print a.nodeValue >=20 > The first print does nothing (blank line), so obviously a is None >=20 > The second print is: > Value=3D"../Schemas/Planning-Preliminary.png"> >=20 > The third one generates an exception: > AttributeError: 'None' object has no attribute 'nodeValue' >=20 > So in this case a is an Attr at the second print and then > becomes None at the following one... I'm puzzled. It's an FAQ, but don't feel bad because no one has bothered to keep an updated FAQ with answers :-) You need to use getNamedItem('', 'src') Remember that in PyXML 0.7 and 4Suite in CVS, you would have to use None rather than '', or better yet, EMPTY_PREFIX --=20 Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com=20 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From horst@freedict.de Fri Jan 4 14:51:40 2002 From: horst@freedict.de (horst@freedict.de) Date: Fri, 4 Jan 2002 15:51:40 +0100 (CET) Subject: [XML-SIG] accessing publicID / systemID In-Reply-To: Message-ID: <200201041451.g04EphS04317@eaglesnest.mceggman> Thanks for the answer, but did not find any hints on using xmlproc to read in a DOM tree - can anyone help? Thanks, Horst On 2 Jan, Sylvain Thenault wrote: > On Wed, 2 Jan 2002 horst@freedict.de wrote: >> I am using xml.dom and create the DOM tree by doing: >> >> DOM = Sax2.FromXmlStream(xmlfile) >> >> I made sure previously that the document is valid. How would I access >> the publicID and systemID? >> > Anyway, the problem is that most parsers don't take the time to > correctly initialize the doctype node of the DOM tree, since only a few > people would use it. Bad luck for you, you are in this case... ;) > > I think that the xmlproc parser handles this correctly. -- Horst@freedict.de Horst Eyermann Germany You need a dictionary? - visit http://www.freedict.de for free (GPL) dictionaries (unix; windows work in progress) For windows, visit http://www.freedict.de/wbuch A article (in German) about dictionary efforts on the net http://www.heise.de/tp/deutsch/inhalt/on/5927/1.html From martin@v.loewis.de Fri Jan 4 21:16:22 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Fri, 4 Jan 2002 22:16:22 +0100 Subject: [XML-SIG] accessing publicID / systemID In-Reply-To: <200201041451.g04EphS04317@eaglesnest.mceggman> (horst@freedict.de) References: <200201041451.g04EphS04317@eaglesnest.mceggman> Message-ID: <200201042116.g04LGMe02163@mira.informatik.hu-berlin.de> > but did not find any hints on using xmlproc to read in a DOM tree - can > anyone help? For 4DOM, either pass the validate=1 option to your reader, or pass a pre-created SAX reader. For minidom, create a SAX reader, then pass that to minidom.parse. Regards, Martin From noreply@sourceforge.net Fri Jan 4 22:16:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 04 Jan 2002 14:16:33 -0800 Subject: [XML-SIG] [ pyxml-Bugs-499608 ] XMLWriter attribute ns declaration Message-ID: Bugs item #499608, was opened at 2002-01-04 14:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=499608&group_id=6473 Category: SAX Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XMLWriter attribute ns declaration Initial Comment: In startElementNS of XMLGenerator (in saxutils, revision 1.29), there's name = prefix + ':' + name[1] self._out.write(' xmlns:%s=%s' % (prefix, quoteattr(name[0]))) This effectively sets the URI in the namespace declaration to the first character of the chosen prefix. To fix, one could either change it to nsURI = name[0] name = prefix + ";" + name[1] self._out.write(' xmlns:%s=%s' % (prefix, quoteattr(nsURI))) or one could re-name the 'name' variable appropriately. Cheers, ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=499608&group_id=6473 From mark@mceahern.com Sat Jan 5 00:07:16 2002 From: mark@mceahern.com (Mark McEahern) Date: Fri, 4 Jan 2002 16:07:16 -0800 Subject: [XML-SIG] pyxml 0.7 and cygwin Message-ID: I'm trying to install PyXml 0.7 on Cygwin (Python 2.2) and it's failing. Is this a known problem? I found Garth Kidd's patch for 0.65: http://sourceforge.net/tracker/index.php?func=detail&aid=445405&group_id=647 3&atid=306473 and am currently trying to figure out why 0.7 is failing. If someone else has figured this out--or if it's "just supposed to work", please let me know. Thanks, // mark From martin@v.loewis.de Sat Jan 5 05:28:39 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sat, 5 Jan 2002 06:28:39 +0100 Subject: [XML-SIG] pyxml 0.7 and cygwin In-Reply-To: References: Message-ID: <200201050528.g055SdS01673@mira.informatik.hu-berlin.de> > I'm trying to install PyXml 0.7 on Cygwin (Python 2.2) and it's failing. Is > this a known problem? Not to me. It would have helped if you had reported how it failed. > I found Garth Kidd's patch for 0.65: > > > http://sourceforge.net/tracker/index.php?func=detail&aid=445405&group_id=647 > 3&atid=306473 As you can see in the Message fraction of that report: the patch has been applied. Regards, Martin From altis@semi-retired.com Sat Jan 5 06:20:37 2002 From: altis@semi-retired.com (Kevin Altis) Date: Fri, 4 Jan 2002 22:20:37 -0800 Subject: [XML-SIG] stripping 8-bit ASCII from an XML stream using encode? Message-ID: The code at the end of demonstrates a problem I'm having parsing XML files downloaded from SourceForge. The specific issue is that there are characters in the XML stream above ASCII 127; decimal 233 and 246 in the example file. The cleanText function is supposed to strip the problem characters. Some of the files contain non-printing ASCII characters below decimal 32, so I'm trying to strip those manually after the XML is converted. Once the file is parsed I'm using the fields in a GUI interface to the SourceForge tracker database. Here is the URL for the XML version of the Python Feature Requests: http://sourceforge.net/export/sf_tracker_export.php?atid=355470&group_id=547 0 I thought that encode could be used to strip these characters, but I sometimes get the following traceback. t = t.encode('ascii', 'ignore') UnicodeError: ASCII decoding error: ordinal not in range(128) I haven't done much XML processing, so this could be a FAQ, but I haven't been able to find the answer so far. What is the proper way to strip the 8-bit values? Is there another issue at work here? Thanks, ka --- Kevin Altis altis@semi-retired.com --- example code by Mark Pilgrim: def cleanText(t, collapseWhitespace=0): t = t.encode('ascii', 'ignore') t = t.replace(chr(19), '') if collapseWhitespace: t = t.replace('\t', '').replace('\n', '') return t def getText(node, collapseWhitespace=0): return cleanText("".join([c.data for c in node.childNodes if c.nodeType == c.TEXT_NODE]), collapseWhitespace) def doParse(xml): from xml.dom import minidom xml = cleanText(xml) xmldoc = minidom.parseString(xml) artifacts = xmldoc.getElementsByTagName('artifact') trackerDict = {} for a in artifacts: trackerDict[a.attributes["id"].value] = \ {"summary":getText(a.getElementsByTagName("summary")[0], collapseWhitespace=1), "detail":getText(a.getElementsByTagName('detail')[0])} return trackerDict if __name__ == '__main__': # KEA # added code to download URL and save the file # comment out once you have the have the XML # the XML file is approximately 174K import urllib url = 'http://sourceforge.net/export/sf_tracker_export.php?atid=355470&group_id=54 70' fp = urllib.urlopen(url) xml = fp.read() fp.close() filename = r'Python_FeatureRequests.xml' op = open(filename, 'wb') op.write(xml) op.close() fsock = open(filename) xml = fsock.read() fsock.close() trackerDict = doParse(xml) import pprint pprint.pprint(trackerDict) From martin@v.loewis.de Sat Jan 5 07:11:08 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sat, 5 Jan 2002 08:11:08 +0100 Subject: [XML-SIG] stripping 8-bit ASCII from an XML stream using encode? In-Reply-To: References: Message-ID: <200201050711.g057B8T09054@mira.informatik.hu-berlin.de> > The code at the end of demonstrates a problem I'm having parsing XML files > downloaded from SourceForge. Please understand that the file you have downloaded is *not* an XML file, even though it may look like one at a shallow glance. The bytes above 128 are the precise cause of this ill-formedness: the file does not declare an encoding, so it ought to be UTF-8; yet it is not (most likely, it is meant to be iso-8859-1). For any processing you are performing, I'd be sorry to hear that you are ignoring the exact spelling of my name :-) > t = t.encode('ascii', 'ignore') > UnicodeError: ASCII decoding error: ordinal not in range(128) > > I haven't done much XML processing, so this could be a FAQ, but I haven't > been able to find the answer so far. What is the proper way to strip the > 8-bit values? It's not really an XML issue. The .encode call is equivalent to encoder = codecs.lookup('ascii')[0] t = encoder(t, 'ignore')[0] Now, encoder is ascii_encode, which is a function expecting a Unicode string, returning the ASCII byte string. The first argument to encoder is a (byte) string, so that is auto-converted to Unicode first, using the system encoding, in strict mode. Since the system encoding is 'ascii' also, your code becomes equivalent to encoder, decoder, _, _ = codecs.lookup('ascii') t = encoder(decoder(t, 'strict')[0], 'ignore')[0] #or unicode(t, 'ascii') It is the conversion to Unicode that fails. If you write t = unicode(t, 'ascii', 'ignore').encode('ascii') you will strip the non-ASCII characters. > Is there another issue at work here? Definitely. It would be much better if it was proper XML that you try to parse. If you add an XML header, i.e. minidom.parse will process it just fine. The carriage-return characters do no harm, either, since an XML processor is supposed to deal with various line endings; I could not find occurrences of other control characters in that docment. Regards, Martin From marklists@mceahern.com Sat Jan 5 08:02:15 2002 From: marklists@mceahern.com (Mark McEahern) Date: Sat, 5 Jan 2002 00:02:15 -0800 Subject: [XML-SIG] pyxml 0.7 and cygwin In-Reply-To: <200201050528.g055SdS01673@mira.informatik.hu-berlin.de> Message-ID: me: > I'm trying to install PyXml 0.7 on Cygwin (Python 2.2) and it's failing. Is > this a known problem? Martin v. Loewis: > Not to me. It would have helped if you had reported how it failed. Here's what happened: $ python setup.py install [skip a lot of "not copying (output up-to-date)"] not copying xml/xslt/__init__.py (output up-to-date) running build_ext building '_xmlplus.parsers.pyexpat' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DHAVE_EXPAT_H -DV ERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 -DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYT ES=1 024 -Iextensions/expat/lib -I/usr/include/python2.2 -c extensions/pyexpat.c -o b uild/temp.cygwin-1.3.6-i686-2.2/pyexpat.o extensions/pyexpat.c:1800: initializer element is not constant extensions/pyexpat.c:1800: (near initialization for `handler_info[2].setter') extensions/pyexpat.c:1803: initializer element is not constant extensions/pyexpat.c:1803: (near initialization for `handler_info[3].setter') extensions/pyexpat.c:1806: initializer element is not constant extensions/pyexpat.c:1806: (near initialization for `handler_info[4].setter') extensions/pyexpat.c:1809: initializer element is not constant extensions/pyexpat.c:1809: (near initialization for `handler_info[5].setter') extensions/pyexpat.c:1818: initializer element is not constant extensions/pyexpat.c:1818: (near initialization for `handler_info[8].setter') extensions/pyexpat.c:1827: initializer element is not constant extensions/pyexpat.c:1827: (near initialization for `handler_info[11].setter') extensions/pyexpat.c:1830: initializer element is not constant extensions/pyexpat.c:1830: (near initialization for `handler_info[12].setter') extensions/pyexpat.c:1833: initializer element is not constant extensions/pyexpat.c:1833: (near initialization for `handler_info[13].setter') extensions/pyexpat.c:1836: initializer element is not constant extensions/pyexpat.c:1836: (near initialization for `handler_info[14].setter') extensions/pyexpat.c:1856: initializer element is not constant extensions/pyexpat.c:1856: (near initialization for `handler_info[17].setter') extensions/pyexpat.c:1859: initializer element is not constant extensions/pyexpat.c:1859: (near initialization for `handler_info[18].setter') extensions/pyexpat.c:1862: initializer element is not constant extensions/pyexpat.c:1862: (near initialization for `handler_info[19].setter') extensions/pyexpat.c:1865: initializer element is not constant extensions/pyexpat.c:1865: (near initialization for `handler_info[20].setter') error: command 'gcc' failed with exit status 1 // mark From martin@v.loewis.de Sat Jan 5 08:32:50 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sat, 5 Jan 2002 09:32:50 +0100 Subject: [XML-SIG] pyxml 0.7 and cygwin In-Reply-To: References: Message-ID: <200201050832.g058WoB09260@mira.informatik.hu-berlin.de> > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DHAVE_EXPAT_H > -DV > ERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 -DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYT > ES=1 > uild/temp.cygwin-1.3.6-i686-2.2/pyexpat.o > extensions/pyexpat.c:1800: initializer element is not constant > extensions/pyexpat.c:1800: (near initialization for > `handler_info[2].setter') Hmm. This refers to {"ProcessingInstructionHandler", (xmlhandlersetter)XML_SetProcessingInstructionHandler, /*line 1800*/ (xmlhandler)my_ProcessingInstructionHandler}, Right? I fail to see what it complains about; XML_SetProcessingInstructionHandler *is* constant. What gcc version is that? Can you try replacing that with {"ProcessingInstructionHandler", (xmlhandlersetter)&XML_SetProcessingInstructionHandler, (xmlhandler)my_ProcessingInstructionHandler}, Unless I'm missing something obvious, this looks like a bug in gcc to me. Since my gcc on Linux accepts this just fine, I'd say it is a cygwin bug. However, I'm also surprised that it does not pass -Iextensions/expat/lib to the compiler. Where does it get expat.h from, then? Can you print ext_modules in setup.py right before setup is invoked? Can you also try to trace how the value of include_dirs gets lost? Regards, Martin From marklists@mceahern.com Sat Jan 5 15:31:51 2002 From: marklists@mceahern.com (Mark McEahern) Date: Sat, 5 Jan 2002 07:31:51 -0800 Subject: [XML-SIG] pyxml 0.7 and cygwin In-Reply-To: <200201050832.g058WoB09260@mira.informatik.hu-berlin.de> Message-ID: > From: Martin v. Loewis [mailto:martin@v.loewis.de] > Hmm. This refers to > > {"ProcessingInstructionHandler", > (xmlhandlersetter)XML_SetProcessingInstructionHandler, /*line 1800*/ > (xmlhandler)my_ProcessingInstructionHandler}, > > Right? I fail to see what it complains about; > XML_SetProcessingInstructionHandler *is* constant. What gcc version is > that? > > Can you try replacing that with > > {"ProcessingInstructionHandler", > (xmlhandlersetter)&XML_SetProcessingInstructionHandler, > (xmlhandler)my_ProcessingInstructionHandler}, I tried this as you suggested and it does not change the result: extensions/pyexpat.c:1800: initializer element is not constant extensions/pyexpat.c:1800: (near initialization for `handler_info[2].setter') > Unless I'm missing something obvious, this looks like a bug in gcc to > me. Since my gcc on Linux accepts this just fine, I'd say it is a > cygwin bug. This is a little over my head; however, could it have something to do with this? http://www.cygwin.com/ml/cygwin/1999-11/msg00397.html (I found that searching for __declspec with Google.) >From expat.h, line 11: #ifndef XMLPARSEAPI # if defined(__declspec) && !defined(__BEOS__) # define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl # else # define XMLPARSEAPI(type) type # endif #endif /* not defined XMLPARSEAPI */ I replaced that with this: #ifndef XMLPARSEAPI # define XMLPARSEAPI(type) type #endif /* not defined XMLPARSEAPI */ and it compiled just fine. Please understand, *I have no sense of the implication of this*. Consider me as slightly better than a random monkey when it comes to C++. There is in all likelihood a better fix. Hmm, now what should I do? For what it's worth, here are the results from regrtest.py: $ regrtest.py test_c14n test test_c14n failed -- Writing: '\n', expected: '\r' test_dom test test_dom failed -- Writing: '\n', expected: '\r' test_domu test test_domu failed -- Writing: '\n', expected: '\r' test_encodings test_howto test test_howto failed -- Writing: '\n', expected: '\r' test_htmlb test test_htmlb failed -- Writing: '\n', expected: '\r' test_javadom test test_javadom failed -- Writing: '\n', expected: '\r' test_marshal test test_marshal failed -- Writing: '\n', expected: '\r' test_minidom test test_minidom failed -- Writing: '\n', expected: '\r' test_pyexpat test test_pyexpat failed -- Writing: '\n', expected: '\r' test_pyxmldom Warning: can't open ./output/test_pyxmldom test_sax test test_sax failed -- Writing: '\n', expected: '\r' test_sax2 test test_sax2 failed -- Writing: '\n', expected: '\r' test_sax2_xmlproc test test_sax2_xmlproc failed -- Writing: '\n', expected: '\r' test_sax_xmlproc test test_sax_xmlproc failed -- Writing: '\n', expected: '\r' test_saxdrivers test test_saxdrivers failed -- Writing: '\n', expected: '\r' test_utils test test_utils failed -- Writing: '\n', expected: '\r' 2 tests OK. 15 tests failed: test_c14n test_dom test_domu test_howto test_htmlb test_javadom test_marshal test_minidom test_pyexpat test_sax test_sax2 test_sax2_xmlproc tes t_sax_xmlproc test_saxdrivers test_utils > However, I'm also surprised that it does not pass > -Iextensions/expat/lib to the compiler. Where does it get expat.h > from, then? Can you print ext_modules in setup.py right before setup > is invoked? Can you also try to trace how the value of include_dirs > gets lost? include_dirs isn't getting lost. Let me recopy the gcc call, but format the line so that it's more readable: building '_xmlplus.parsers.pyexpat' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DHAVE_EXPAT_H -DVERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 -DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYTES=1024 -Iextensions/expat/lib -I/usr/include/python2.2 -c extensions/pyexpat.c -o build/temp.cygwin-1.3.6-i686-2.2/pyexpat.o Thanks, // mark From noreply@sourceforge.net Sat Jan 5 20:35:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 05 Jan 2002 12:35:32 -0800 Subject: [XML-SIG] [ pyxml-Bugs-499946 ] Please provide diffs for PyXML updates Message-ID: Bugs item #499946, was opened at 2002-01-05 12:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=499946&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Himanshu Gohel (hgohel) Assigned to: Nobody/Anonymous (nobody) Summary: Please provide diffs for PyXML updates Initial Comment: Hi, With the size of the distrbution growing, it would be really nice to have diffs to go from one version to the next for those of us who still download via 56K modems. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=499946&group_id=6473 From akuchlin@mems-exchange.org Sun Jan 6 02:42:25 2002 From: akuchlin@mems-exchange.org (akuchlin@mems-exchange.org) Date: Sat, 5 Jan 2002 21:42:25 -0500 Subject: [XML-SIG] RELAX NG: who wants to write a parser? Message-ID: <20020105214224.A31004@mozart.mems-exchange.org> James Clark has just written a description of the RELAX NG validation algorithm using in Jing, and I've made a rough Python implementation that can be found in http://www.amk.ca/files/xml/ . I think the validation engine is complete, though it's only been spottily tested by building pattern trees by hand. The next step is to write a parser for RELAX NG's XML input format, and then we can begin throwing the test suite at it. I don't like writing parsers, so I'm viewing that task with the same attitude as a small boy contemplating liver and onions for dinner. Does anyone want to code up a parser? --amk From ibcupid@koreails.com Sun Jan 6 13:19:21 2002 From: ibcupid@koreails.com (ibcupid) Date: Sun, 6 Jan 2002 22:19:21 +0900 Subject: [XML-SIG] [±¤°í]¹ÌÆõµ ÇÏ°í ¿µÈ­µµ º¸°í ! Message-ID: Untitled Document
     
 ¾È³çÇϼ¼¿ä? º» ¸ÞÀÏÀº ±ÍÇÏÀÇ ¾Æ¹«·± Á¤º¸¸¦ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù
 
     
   
 
 
 
 

¹ÌÆÃÁ¤º¸ ÀԷ½à º»ÀÎÀÇ »çÁøÀ» ¿Ã¸®½Å ºÐµé Áß¿¡¼­ ÀÌ´ÞÀÇ Å·Ä« ÄýÄ«¿¡ ¿Ã¶ó°¡½Å ³×ºÐ²²!!!

¹ÌÆø¶´ç¿¡ ¸ÚÁø ½Åû±ÛÀ» ¾²½Å ºÐµé Áß¿¡¼­ ¾ÆÀ̺ñÅ¥Çǵ尡 »Ð~°¥ ¸¸ÇÑ ¸ÚÁø±ÛÀ» ¿Ã·ÁÁֽô ¼¼ºÐ²²!!!

»ç¶û¸¸µé±â °Ô½ÃÆÇ¿¡ ¸ÚÁö°Å³ª À̻ڰųª Àç¹Õ°Å³ª °¨µ¿ÀûÀÎ »ç¶û±ÛÀ» ¿Ã·ÁÁֽô ºÐµé Áß ¼¼ºÐ²²!!

  
  
 

" ¿µÈ­°üÀº 2002³â 1¿ùÁß ¿ÀÇ ¿¹Á¤ÀÔ´Ï´Ù. ¸¸È­ ÄÁÅÙÃ÷µµ Æ÷ÇԵǾî À־~~
2002³â 1¿ùÁß¿¡ ¹ÞÀº Âò°ú °Ô½ÃµÈ ±Û¿¡ ÇÑÇϱ¸¿© ¿µÈ­°ü ÀÌ¿ë±ÇÀº 2¿ù¿¡ µå¸³´Ï´Ù."

¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ ´­·¯¼­ ¹ß¼ÛÇØÁÖ½Ã¸é ´Ù½Ã´Â º¸³»Áö ¾Ê°Ú½À´Ï´Ù. °¨»çÇÕ´Ï´Ù.

  
 
 
From akuchlin@mems-exchange.org Sun Jan 6 21:17:52 2002 From: akuchlin@mems-exchange.org (akuchlin@mems-exchange.org) Date: Sun, 6 Jan 2002 16:17:52 -0500 Subject: [XML-SIG] RELAX NG: who wants to write a parser? In-Reply-To: <20020105214224.A31004@mozart.mems-exchange.org>; from akuchlin@mems-exchange.org on Sat, Jan 05, 2002 at 09:42:25PM -0500 References: <20020105214224.A31004@mozart.mems-exchange.org> Message-ID: <20020106161752.A6136@mozart.mems-exchange.org> On Sat, Jan 05, 2002 at 09:42:25PM -0500, akuchlin@mems-exchange.org wrote: >Does anyone want to code up a parser? This Sunday I was trapped somewhere with nothing else to do, and spent a few hours writing a parser for the simplified syntax described in section 5 of the RELAX NG specification. So now there's another part of the task that no longer needs to be done. However it's still not possible to run the test suite because the numerous simplifications described in section 4 of the spec have to be implemented in order to convert the full syntax into the simple syntax. So does anyone want to do *that*? (That seems to be more complicated than the task of parsing the simple syntax.) The parser code isn't available yet, as I'm still trapped at this meeting and can't make a new release, but I'll send a note as soon as it's available. --amk From akuchlin@mems-exchange.org Mon Jan 7 03:22:27 2002 From: akuchlin@mems-exchange.org (akuchlin@mems-exchange.org) Date: Sun, 6 Jan 2002 22:22:27 -0500 Subject: [XML-SIG] RELAX NG: who wants to write a parser? In-Reply-To: <20020106161752.A6136@mozart.mems-exchange.org>; from akuchlin@mems-exchange.org on Sun, Jan 06, 2002 at 04:17:52PM -0500 References: <20020105214224.A31004@mozart.mems-exchange.org> <20020106161752.A6136@mozart.mems-exchange.org> Message-ID: <20020106222227.A6337@mozart.mems-exchange.org> Version 0.0.2 of the RELAX NG validator is now in http://www.amk.ca/files/xml/ . This version adds a parser for the simple syntax and various fixes. --amk From xml-sig-request@python.org Mon Jan 7 03:59:27 2002 From: xml-sig-request@python.org (xml-sig-request@python.org) Date: Sun, 06 Jan 2002 22:59:27 -0500 Subject: [XML-SIG] See what EVERYONE has been talking about!!! 163813770 Message-ID: Below is the result of your feedback form. It was submitted by (xml-sig-request@python.org) on Sunday, January 6, 2002 at 21:59:26 --------------------------------------------------------------------------- : Do you want to watch real girls showing off their body and doing crazy things on there webcam? I know you do and you can watch and chat with them for free!!! There are over 1 million men and women right now that have their cameras running waiting for you to come watch. It's all free and if you want you can even host your own show. You don't need anything to get started just visit my site at http://beam.to/ghettohoes3, you can sign up for free, and begin watching and chatting today! We GUARANTEE that you will not be billed a penny! If you are not satisfied you can always unsubscribe without cost! So what are you waiting for?!?! Go to http://beam.to/ghettohoes3 now!! 131769777 --------------------------------------------------------------------------- From noreply@sourceforge.net Mon Jan 7 16:51:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 08:51:18 -0800 Subject: [XML-SIG] [ pyxml-Patches-500455 ] Add iterator support to pulldom Message-ID: Patches item #500455, was opened at 2002-01-07 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=500455&group_id=6473 Category: DOM Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add iterator support to pulldom Initial Comment: The attached patch adds a __iter__() and next() to the pulldom.DOMStream class, for use with 2.2. (A quick grep through the tree for __getitem__ didn't turn up any other cases where iterator support seems needed.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=500455&group_id=6473 From noreply@sourceforge.net Mon Jan 7 16:51:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 07 Jan 2002 08:51:38 -0800 Subject: [XML-SIG] [ pyxml-Patches-500457 ] Add iterator support to pulldom Message-ID: Patches item #500457, was opened at 2002-01-07 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=500457&group_id=6473 Category: DOM Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add iterator support to pulldom Initial Comment: The attached patch adds a __iter__() and next() to the pulldom.DOMStream class, for use with 2.2. (A quick grep through the tree for __getitem__ didn't turn up any other cases where iterator support seems needed.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=500457&group_id=6473 From mike@nthwave.net Mon Jan 7 17:22:26 2002 From: mike@nthwave.net (Michael Mell) Date: Mon, 07 Jan 2002 09:22:26 -0800 Subject: [XML-SIG] xml vs. sql Message-ID: <3C39D951.94926B9B@nthwave.net> I'm considering building a data-centric website using xml instead of the usual SQL database. I expect the site will receive about 1000 hits per day. There will never be more than a couple thousand records in the data. I'm planning on using Apache, mod_python and Python's minidom. The benefits of doing without the database are: 1. the data will be highly portable 2. the data will not be subject to corruption 3. no need for DB admin Potential downsides: 1. Slow processing under load Any thing else I need to consider? Anyone care to share past experiences doing the same? thanks -- mike@nthwave.net llemekim YahooIM 415.455.8812 voice 419.735.1167 fax From brian@sweetapp.com Mon Jan 7 22:40:43 2002 From: brian@sweetapp.com (Brian Quinlan) Date: Mon, 7 Jan 2002 14:40:43 -0800 Subject: [XML-SIG] Pyana 0.2.5 released Message-ID: <000301c197cc$575cd9f0$445d4540@Dell2> Pyana is a bridge between the Xalan XSLT engine and Python. See: http://pyana.sourceforge.net/ Changes: - updated to use Xalan 1.3/Xerces 1.6 - includes the Xalan extension library (http://xml.apache.org/xalan-c/extensionslib.html) - better documentation strings - binaries for Python 2.2 Windows binaries are available immediately, Linux and Solaris binaries may become available at a later date. Cheers, Brian From martin@v.loewis.de Mon Jan 7 23:03:25 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Tue, 8 Jan 2002 00:03:25 +0100 Subject: [XML-SIG] xml vs. sql In-Reply-To: <3C39D951.94926B9B@nthwave.net> (message from Michael Mell on Mon, 07 Jan 2002 09:22:26 -0800) References: <3C39D951.94926B9B@nthwave.net> Message-ID: <200201072303.g07N3PT01557@mira.informatik.hu-berlin.de> > I'm considering building a data-centric website using xml instead of the > usual SQL database. I expect the site will receive about 1000 hits per > day. There will never be more than a couple thousand records in the > data. I'm planning on using Apache, mod_python and Python's minidom. If you are looking into a Python implementation, I recommend to use pickle/cPickle over XML. If desired, you can still offer XML import/export. > The benefits of doing without the database are: > 1. the data will be highly portable If, by that, you mean "across operating systems and software versions", then this will be about pickles as well. > 2. the data will not be subject to corruption Depends on how you operate on them. It is certainly possible to truncate or otherwise garble XML files. > 3. no need for DB admin The same would be true for pickles. > Potential downsides: > 1. Slow processing under load pickles likely load much faster than XML is being parsed. > Any thing else I need to consider? Complexity of the source code. An XML application will be many more lines than using pickles. > Anyone care to share past experiences doing the same? mailman uses pickles for its databases, and I believe many other tools do as well. 4Suite offers pickle support for all their DOM implementations. Regards, Martin From info@e-janco.com Tue Jan 8 00:13:14 2002 From: info@e-janco.com (info@e-janco.com) Date: Mon, 07 Jan 2002 16:13:14 PST Subject: [XML-SIG] January 2002 Salary Survey - Now Available Message-ID:

We have just completed our January 2002 Salary Survey.  You can download your FREE copy of the Survey Summary from:

http://www.e-janco.com/SamplePages/SurveySummary.pdf

 In addition you can purchase the Survey at our Special Offer price of $79.95 by going to the following Page

 http://www.ejobdescription.com/search_result_detail.asp?CATALOGID=601


You have opted in for mail on our products. If you wish to be removed from
our list just select the link that follows or reply to this message with the word
Remove
 

From mike@nthwave.net Tue Jan 8 01:32:00 2002 From: mike@nthwave.net (Michael Mell) Date: Mon, 07 Jan 2002 17:32:00 -0800 Subject: [XML-SIG] xml vs. sql References: <3C39D951.94926B9B@nthwave.net> <200201072303.g07N3PT01557@mira.informatik.hu-berlin.de> Message-ID: <3C3A4C10.7B964CBC@nthwave.net> "Martin v. Loewis" wrote: > > > I'm considering building a data-centric website using xml instead of the > > usual SQL database. I expect the site will receive about 1000 hits per > > day. There will never be more than a couple thousand records in the > > data. I'm planning on using Apache, mod_python and Python's minidom. > > If you are looking into a Python implementation, I recommend to use > pickle/cPickle over XML. If desired, you can still offer XML > import/export. Thanks Martin. The pickle solution looks effective. I'd prefer to find a more generic solution. The generic solution would allow any common language (Java, Perl, Python, PHP come to mind) to manage the data. We're back to XML, right? My goals are to ~ never have the data locked in an unusable (proprietary) format ~ reduce installation and maintenance hurdles to a minimum thanks. -- mike@nthwave.net llemekim YahooIM 415.455.8812 voice 419.735.1167 fax From akuchlin@mems-exchange.org Tue Jan 8 04:13:04 2002 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Mon, 07 Jan 2002 23:13:04 -0500 Subject: [XML-SIG] Filtering nodes from a DOM tree Message-ID: The RELAX NG simplifications include a number of steps where certain elements and attributes need to be dropped or modified. As a first cut I'm just building a DOM tree and modifying, and there doesn't seem to be any very neat way to do that. There are NodeIterator and TreeWalker classes in xml.dom, but looking at the code they don't seem to cope with the tree being modified while it's being traversed. Is there an elegant way to do this kind of filtering, in DOM or some other API? I thought of writing XPath declarations for matching elements, and then deleting or changing all the nodes that result, but that seems likely to be slow because there are about 20 different simplifications to be applied, and that would mean walking the whole document 20 times. -- A.M. Kuchling http://www.amk.ca America doesn't have a monopoly on bad taste. -- The Doctor, in "Revelation of the Daleks" From tpassin@home.com Tue Jan 8 05:40:15 2002 From: tpassin@home.com (Thomas B. Passin) Date: Tue, 8 Jan 2002 00:40:15 -0500 Subject: [XML-SIG] xml vs. sql References: <3C39D951.94926B9B@nthwave.net> Message-ID: <002a01c19806$f3b4c260$7cac1218@cj64132b> [Michael Mell] > I'm considering building a data-centric website using xml instead of the > usual SQL database. I expect the site will receive about 1000 hits per > day. There will never be more than a couple thousand records in the > data. I'm planning on using Apache, mod_python and Python's minidom. > > The benefits of doing without the database are: > 1. the data will be highly portable > 2. the data will not be subject to corruption > 3. no need for DB admin > > Potential downsides: > 1. Slow processing under load > Any thing else I need to consider? > > Anyone care to share past experiences doing the same? > I would say that a lot depends on the data model and the nature of the queries you will be doing. For complex queries needing multiple joins, I'd probably want to use a relational database. For simple extraction from tables, XML could work well. It also depends on the size of the table-equivalents. If they are small, processing with xml could be fast. You could even cache the tables and stylesheets (if that's what you were to use) as DOM structures. If they are "too" large - find out by testing - a database might be better. Also, you haven't mentioned if the data will change a lot or just be static. If there were going to be a lot of changes to the data, I'd be interested in a database with transaction capability. SQL data can be pretty portable, especially if the database can do a dump in that uses SQL insert statements to save the data. And I wouldn't say the data were less subject to corruption if stored as XML. I just did a job where I initially stored html form data as lines of text in files (I was keeping the database server separate from the web form machinery, so I had to store it first before loading it into the database), used xml/xslt and batch files to create python scripts that inserted the data into an SQL database (the data forms were created using xml templates, so I could compute nearly everything else I needed using xslt) and created other Python scripts with xslt that ran reports using stored queries in Zope. I was happy I could use a relational database because it made it easy to create the queries for the reports. As for pickles, I have always understood (perhaps wrongly) that the pickle format is subject to change for each new version of Python. If so, to use pickles you have to ensure that you can recreate the pickled data, so you still need some way to store it - why not xml? So it depends. I'd say, try it in straight xml first (modulo my first two remarks above) and see if it's fast enough and that the xpath or xslt isn't too complex to maintain easily. If that's not good enough, consider going to Zope and any convenient database it can talk to (like mySQL or whatever). That would be pretty portable. Or just talk to mySQL or another database directly from Python, especially if you don't need a web interface. Cheers, Tom P From martin@v.loewis.de Tue Jan 8 07:17:50 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Tue, 8 Jan 2002 08:17:50 +0100 Subject: [XML-SIG] xml vs. sql In-Reply-To: <3C3A4C10.7B964CBC@nthwave.net> (message from Michael Mell on Mon, 07 Jan 2002 17:32:00 -0800) References: <3C39D951.94926B9B@nthwave.net> <200201072303.g07N3PT01557@mira.informatik.hu-berlin.de> <3C3A4C10.7B964CBC@nthwave.net> Message-ID: <200201080717.g087Hol01405@mira.informatik.hu-berlin.de> > I'd prefer to find a more generic solution. The generic solution would > allow any common language (Java, Perl, Python, PHP come to mind) to > manage the data. We're back to XML, right? Yes, probably. A database which is equally supported in all these languages is another option (and which fulfills your requirement of no administrative overhead). BSDDB (www.sleepycat.com) comes to mind; this is a database format that requires no database management, is accessible from all these languages, and is *very* efficient. Regards, Martin From martin@v.loewis.de Tue Jan 8 07:43:19 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Tue, 8 Jan 2002 08:43:19 +0100 Subject: [XML-SIG] xml vs. sql In-Reply-To: <002a01c19806$f3b4c260$7cac1218@cj64132b> (tpassin@home.com) References: <3C39D951.94926B9B@nthwave.net> <002a01c19806$f3b4c260$7cac1218@cj64132b> Message-ID: <200201080743.g087hJx01442@mira.informatik.hu-berlin.de> > As for pickles, I have always understood (perhaps wrongly) that the pickle > format is subject to change for each new version of Python. I think this is mostly wrong. While more recent versions may add additional types, along with marshalling support, the format of existing types is guaranteed to never change (as stupid as it may be, such as the long int binary format). Regards, Martin From mal@lemburg.com Tue Jan 8 10:00:59 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 08 Jan 2002 11:00:59 +0100 Subject: [XML-SIG] xml vs. sql References: <3C39D951.94926B9B@nthwave.net> <200201072303.g07N3PT01557@mira.informatik.hu-berlin.de> Message-ID: <3C3AC35B.477ADC9D@lemburg.com> "Martin v. Loewis" wrote: > > > I'm considering building a data-centric website using xml instead of the > > usual SQL database. I expect the site will receive about 1000 hits per > > day. There will never be more than a couple thousand records in the > > data. I'm planning on using Apache, mod_python and Python's minidom. > > If you are looking into a Python implementation, I recommend to use > pickle/cPickle over XML. If desired, you can still offer XML > import/export. Just a note: you should always make the nature of your queries guide you in the choice of underyling data storage. Pickles and Python objects won't help you with fulltext search, SQL rows don't support nested object structures too well and maintaining Gigabytes of XML files can be troublesome without some solid XML repository as engine. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From goldrock@verizonmail.com Tue Jan 8 10:32:14 2002 From: goldrock@verizonmail.com (goldrock@verizonmail.com) Date: Tue, 8 Jan 2002 19:32:14 +0900 Subject: [XML-SIG] =?euc-kr?B?WyC3r7rqvK3HwbimIMPfw7XH1bTPtNkuIF0=?= Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_2F554_01C1987B.2CA05930 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 tNQuLiC+yLPnx8+8vL/kPyANCg0KW2NsaWNrIHRvIHNlZSBdDQo8aHR0cDovL3d3dy5sb3Zlc3Vy Zi5jby5rci9kZWZhdWx0LmFzcD9zPTExMzgwODEmZW1haWw9eG1sLXNpZ0BweXRob24ub3INCmc+ ICAJDQoNCiK757b7IMfPuOm8rSDEo7G4t84guLizqrTCsNQguau9vCDAx7nMsKEgwNbB0j8iIA0K IrnZtvO4uCC6uLTCILvntvu1tSDA1r7uv+QuIg0KIr/WILHXt7Egu+e2+8C7IMfPwdI/ILDFus60 58fSsKEgtc63wb/2v+Q/IiANCiKzrSCx1yC757b3wLsgu+e2+8fPtMKwxcH2LCC757b7ud6x4rim IL/4x8+0wrDHIL7Gs9e/5C4uLiINCg0Kd3d3LkxvdmVzdXJmLmNvLmtyDQo8aHR0cDovL3d3dy5s b3Zlc3VyZi5jby5rci9kZWZhdWx0LmFzcD9zPTExMzgwODEmZW1haWw9eG1sLXNpZ0BweXRob24u b3INCmc+ICogx9Gx28bHwLogw9EgMjksMDAwIMbkwMzB9rfOILTcwM+x4rTJIMClILvnwMzGrrfO tMIgx9GxucC6ILmwt9AgvLyw6CDD1rTrsdS48MDHILvnwMzGrrfOILy6wM4gW7OysPq/qV0sDQpb s7Kw+rOyXSwgW7+pv82/qV0sIMO7vNKz4luzsrD6v6ldwMcgNCCws8DHIMS/ucK0z8a8uKYguPC1 ziC89r/rx9Egu+fAzMaut84gvcyx2yC288DMx8HAxyC757v9yLCxx8DHILq4yKO/zSC9usXkxL/A xw0KuebB9rimIMPWv+y8scC4t84gwbbB97XIIMClILvnwMzGriDA1LTPtNkuIA0Kw7u80rPiwLsg wKfH0SC758DMxq60wiB3d3cubXlnYWwuY28ua3IgPGh0dHA6Ly93d3cubXlnYWwuY28ua3IvZGVm YXVsdC5hc3A+ICDA1LTPtNkuIA0KDQrD38O1wM4gLSANCg0KDQrAzCC43sDPwLsgvtXAuLfOILne sO0gvc3B9iC+ysC4vcO02bjpILjewM+89r3FsMXA/Q0KPGh0dHA6Ly93d3cubG92ZXN1cmYuY28u a3IvdG9wYXIvcmVqZWN0LmFzcD9zPTExMzgwODEmZW1haWw9eG1sLXNpZ0BweXRoDQpvbi5vcmc+ ICDAuyDFqbivIMfPvLy/5C4gDQoNCg== ------=_NextPart_000_2F554_01C1987B.2CA05930 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable =B4=D4.. = =BE=C8=B3=E7=C7=CF=BC=BC=BF=E4?
3D"[click

"=BB=E7=B6=FB = =C7=CF=B8=E9=BC=AD =C4=A3=B1=B8=B7=CE =B8=B8=B3=AA=B4=C2=B0=D4 = =B9=AB=BD=BC =C0=C7=B9=CC=B0=A1 =C0=D6=C1=D2?"

"=B9=D9=B6=F3=B8=B8 =BA=B8=B4=C2 =BB=E7=B6=FB=B5=B5 = =C0=D6=BE=EE=BF=E4."
"=BF=D6 =B1=D7=B7=B1 =BB=E7=B6=FB=C0=BB =C7=CF=C1=D2? = =B0=C5=BA=CE=B4=E7=C7=D2=B0=A1 =B5=CE=B7=C1=BF=F6=BF=E4?"
"=B3=AD =B1=D7 =BB=E7=B6=F7=C0=BB =BB=E7=B6=FB=C7=CF=B4=C2=B0=C5=C1=F6, = =BB=E7=B6=FB=B9=DE=B1=E2=B8=A6 =BF=F8=C7=CF=B4=C2=B0=C7 = =BE=C6=B3=D7=BF=E4..."

www.Lovesurf.co.kr* =C7=D1=B1=DB=C6=C7=C0=BA =C3=D1 29,000 =C6=E4=C0=CC=C1=F6=B7=CE = =B4=DC=C0=CF=B1=E2=B4=C9 =C0=A5 =BB=E7=C0=CC=C6=AE=B7=CE=B4=C2 = =C7=D1=B1=B9=C0=BA =B9=B0=B7=D0 =BC=BC=B0=E8 = =C3=D6=B4=EB=B1=D4=B8=F0=C0=C7 =BB=E7=C0=CC=C6=AE=B7=CE =BC=BA=C0=CE [=B3=B2=B0=FA=BF=A9], [=B3=B2=B0=FA=B3=B2], = [=BF=A9=BF=CD=BF=A9], =C3=BB=BC=D2=B3=E2[=B3=B2=B0=FA=BF=A9]=C0=C7 4 = =B0=B3=C0=C7 =C4=BF=B9=C2=B4=CF=C6=BC=B8=A6 =B8=F0=B5=CE = =BC=F6=BF=EB=C7=D1 =BB=E7=C0=CC=C6=AE=B7=CE =BD=CC=B1=DB = =B6=F3=C0=CC=C7=C1=C0=C7 =BB=E7=BB=FD=C8=B0=B1=C7=C0=C7 = =BA=B8=C8=A3=BF=CD =BD=BA=C5=E4=C4=BF=C0=C7 =B9=E6=C1=F6=B8=A6 = =C3=D6=BF=EC=BC=B1=C0=B8=B7=CE =C1=B6=C1=F7=B5=C8 =C0=A5 = =BB=E7=C0=CC=C6=AE =C0=D4=B4=CF=B4=D9.
=C3=BB=BC=D2=B3=E2=C0=BB =C0=A7=C7=D1 =BB=E7=C0=CC=C6=AE=B4=C2 www.mygal.co.kr =C0=D4=B4=CF=B4=D9.

=C3=DF=C3=B5=C0=CE -


=C0=CC =B8=DE=C0=CF=C0=BB = =BE=D5=C0=B8=B7=CE =B9=DE=B0=ED =BD=CD=C1=F6 = =BE=CA=C0=B8=BD=C3=B4=D9=B8=E9 =B8=DE=C0=CF=BC=F6=BD=C5=B0=C5=C0=FD =C0=BB =C5=A9=B8=AF =C7=CF=BC=BC=BF=E4.
------=_NextPart_000_2F554_01C1987B.2CA05930-- From marklists@mceahern.com Tue Jan 8 22:39:45 2002 From: marklists@mceahern.com (Mark McEahern) Date: Tue, 8 Jan 2002 14:39:45 -0800 Subject: [XML-SIG] pyxml 0.7 and cygwin In-Reply-To: Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C19852.5127D630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Attached is a patch that allows you to run setup.py for PyXml 0.7 on Cygwin (Python 2.2). I don't know whether I should submit this to sourceforge? I don't know enough about C++ or gcc to comment whether the need for this patch indicates a bug in gcc. If you find it useful, cheers. Thanks, // mark ------=_NextPart_000_0000_01C19852.5127D630 Content-Type: application/octet-stream; name="gcc_cygwin_dllimport.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gcc_cygwin_dllimport.patch" Index: extensions/pyexpat.c =================================================================== RCS file: /cvsroot/pyxml/xml/extensions/pyexpat.c,v retrieving revision 1.45 diff -c -r1.45 pyexpat.c *** extensions/pyexpat.c 2001/12/28 16:08:14 1.45 --- extensions/pyexpat.c 2002/01/08 00:37:15 *************** *** 14,19 **** --- 14,20 ---- #include "compile.h" #include "frameobject.h" #ifdef HAVE_EXPAT_H + #define PYEXPAT #include "expat.h" #ifdef XML_MAJOR_VERSION #define EXPAT_VERSION (0x10000 * XML_MAJOR_VERSION \ Index: extensions/expat/lib/expat.h =================================================================== RCS file: /cvsroot/pyxml/xml/extensions/expat/lib/expat.h,v retrieving revision 1.1 diff -c -r1.1 expat.h *** extensions/expat/lib/expat.h 2001/08/11 07:19:41 1.1 --- extensions/expat/lib/expat.h 2002/01/08 00:37:17 *************** *** 9,15 **** #include #ifndef XMLPARSEAPI ! # if defined(__declspec) && !defined(__BEOS__) # define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl # else # define XMLPARSEAPI(type) type --- 9,15 ---- #include #ifndef XMLPARSEAPI ! # if defined(__declspec) && !defined(__BEOS__) && !defined(PYEXPAT) # define XMLPARSEAPI(type) __declspec(dllimport) type __cdecl # else # define XMLPARSEAPI(type) type ------=_NextPart_000_0000_01C19852.5127D630-- From bre392@alibaba.com Wed Jan 9 12:45:23 2002 From: bre392@alibaba.com (Êг¡ÉÌÇéÐÅÏ¢Íø) Date: Wed, 9 Jan 2002 12:45:23 Subject: [XML-SIG] ÆóÒµÉÏÍø£¬Ã¿ÄêÖ»Ðè188Ôª Message-ID: ÄúºÃ ÄúµÄÆóÒµÓÐ×Ô¼ºµÄÍøÕ¾£¿ÓÐ×Ô¼ºÓòÃûϵÄÓʼþÂð£¿Öйú¼ÓÈëWTO£¬ ¿ì½¨Á¢×Ô¼ºµÄÍøÕ¾£¬ÓÐÁË×Ô¼ºµÄÍøÕ¾¾Í¶à·ÝÉÌ»ú£¬¾ÍÔöÇ¿Á˾ºÕùÁ¦¡£ ÎÒÃÇÊÇרҵµÄÍøÕ¾½¨ÉèÌṩµ¥Î»£¬ÓжÀÁ¢µÄDNS(ÓòÃû½âÎö·þÎñÆ÷) ²¢ÔÚInternicÕýʽµÇ¼Ç×¢²á£¬ÄܽâÎö¹ú¼ÊºÍ¹úÄÚËùÓкó׺µÄÓòÃû¡£ÎÒ ÓжÀÁ¢µÄµç×ÓÓʼþ·þÎñÆ÷¡¢Êý¾Ý¿â·þÎñÆ÷¡¢ÐéÄâÖ÷»ú´æ·Å·þÎñÆ÷ºÍ±¸ ·Ý·þÎñÆ÷£¬²¢ÓÐÒ»Åú³¤ÆÚ´ÓÊÂÍøÕ¾¹ÜÀí¡¢Î¬»¤µÄרҵÈËÔ±£¬Ìṩ24С ʱÔÚÏß·þÎñ¡£ÎÒÃÇ´Ó1995Äê¾Í¿ªÊ¼×¢²á²¢Ìṩ¹ú¼Ê¶¥¼¶ÓòÃûµÄ·þÎñ£¬ ÎÒÃÇÄ¿Ç°ÒѾ­ÓÐ ¹ú¼Ò·À»ð½¨²Ä¼à¶½¼ìÑéÖÐÐÄ ÖйúÄÚȼ»úÍø ÖйúƤ ë½»Ò×Íø µÈ´óÐÍÍøÕ¾´æ·ÅÔÚÎÒÃǵķþÎñÆ÷ÉÏ¡£ »¶Ó­ÓëÎÒÃǺÏ×÷½¨Á¢Äú×Ô¼ºµÄÍøÕ¾¡£Èç¹ûÄãÒѾ­ÓÐÁË×Ô¼ºµÄÍøÕ¾ Ò²¿ÉÒÔËæʱתÒƵ½ÎÒÃǵķþÎñÆ÷ÉÏÀ´¡£·²ÊÇÔÚÎÒ´¦½¨Á¢ÍøÕ¾µÄ¿Í»§ ÎÒÃǶ¼½«¸ÃÍøÕ¾Ãâ·ÑµÇ¼µ½ ÐÂÀË¡¢ÖлªÍø¡¢ÍøÒס¢ËѺü¡¢www.21onl ine.netµÄËÑË÷ÒýÇæÀï¡£²¢½«Ãâ·ÑΪÄúµÄÍøÕ¾ÔÚwww.21online.netËÑË÷ ÒýÇæÀｫËÑË÷½á¹ûÅÅÃûÔÚÇ°20λ£¬Ê±¼äΪһÄ꣬ÔÚ¾­Ã³ÐÅÏ¢ÍøµÄÊ×Ò³ É쵀 ÉÌÒµÍøÕ¾ÍƼö Àï×öÃâ·ÑÁ´½Ó¡£Õ⽫Ìá¸ßÄúµÄÍøÕ¾µÄ·ÃÎÊÁ¿¡£ ÎÒÃǵÄÍøÕ¾»¹ÌṩÃâ·ÑµÄÍâÉÌÇó¹ºÐÅÏ¢¡¢Õбꡢ·¨¹æ¡¢ÏîÄ¿ºÏ×÷¡¢ ¼¼ÊõתÈᢹúÄÚ¹©ÇóµÈÐÅÏ¢£¬ÄãÒ²¿ÉÒÔÃâ·Ñ·¢²¼×Ô¼ºµÄÐÅÏ¢¡£ »¶Ó­·ÃÎÊÎÒÃǵÄÍøÕ¾»òÀ´ÐÅË÷È¡Ïà¹Ø×ÊÁÏ µç»°¡¢010-63272965 010-63272955 ´«Õæ¡¢010-63272964 ÁªÏµÈË¡¢Ö£»ª ËïÕñ»ª Óʼþ¡¢web@bre392.com.cn http://www.bre392.com.cn ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ ÏÂÔØÍøÖ·£ºhttp://love2net.51.net/£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- From contact@g-point.co.kr Wed Jan 9 12:06:01 2002 From: contact@g-point.co.kr (ÁöÆ÷ÀÎÆ® µðÀÚÀÎ (ÁÖ)) Date: Wed, 9 Jan 2002 21:06:01 +0900 Subject: [XML-SIG] [±¤°í] ȨÆäÀÌÁö¸¦ È® ¹Ù²ãµå¸³´Ï´Ù. (Á¦¾È) Message-ID:  

¿øÄ¡ ¾ÊÀº ±¤°í¶ó¸é Á¤¸» Á˼ÛÇÕ´Ï´Ù.¼ö½Å°ÅºÎ¸¦ ´­·¯ÁÖ½Ã¸é ´Ù½Ã´Â ±¤°í¸ÞÀÏÀ» º¸³»Áö ¾Ê°Ú½À´Ï´Ù. ÀÌ ¸ÞÀÏÁÖ¼Ò´Â °Ô½ÃÆÇÀ̳ª °Ë»öÀ» ÅëÇؼ­ ¾òÀº ÁÖ¼ÒÀÔ´Ï´Ù. ±ÍÇÏ¿¡°Ô ºÒÀÌÀÍÀÌ °¡Áö ¾ÊÀ» °ÍÀÔ´Ï´Ù.

ÀÚ»ç´Â ±×·¡ÇȵðÀÚÀÎÀ» Àü¹®À¸·Î ÇÏ´Â ½Å»ý¾÷üÀÔ´Ï´Ù. ÇöÀç´Â °ÔÀÓ±×·¡ÇÈ°ú ¸ÖƼ¹Ìµð¾î ºÐ¾ßÀÇ µðÀÚÀÎÀ» ÁÖ ¾÷¹«·Î ÁøÇàÇÏ°í ÀÖ½À´Ï´Ù.

ÃÖ±ÙÀÇ È¨ÆäÀÌÁö´Â Ãß¼¼´Â ¸¸µå´Â °ÍÀÌ ¸ñÀûÀÌ ¾Æ´Ñ ÃÖ´ëÇÑÀÇ ±¤°í¸¦ ¸ñÀûÀ¸·Î Á¦ÀÛÀ» ÇÏ¿©¾ß ÇÕ´Ï´Ù. ÀúÈñ´Â ȨÆäÀÌÁö Á¦ÀÛ°ú µ¿½Ã¿¡ ±¤°í¿¡ ´ëÇÑ ºÎºÐ¿¡ Á¦°øÇØ µå¸±·Á°í ÇÏ°í ÀÖ½À´Ï´Ù.

±×¸®°í ÀúÈñ´Â µðÀÚÀÎȸ»çÀ̱⶧¹®¿¡ µðÀÚÀο¡ ¸Â´Â °¡°Ý¸¸ ¹Þ°Ú½À´Ï´Ù. È®½ÇÈ÷ ´Ù¸¥ µðÀÚÀÎÀ»
º¸¿©µå¸®°Ú½À´Ï´Ù.
ÀúÈñÀÇ ¸¶Àεå´Â ÃÖ´ëÇÑ ±â¾÷Áֵ鿡°Ô ºñ¿ëºÎ´ãÀ» ÁÙÀ̱â À§ÇØ ³ë·ÂÇÏ°í ÀÖ½À´Ï´Ù.

Áö±Ý À̺¥Æ®·Î ½ºÅ©¸°¼¼À̹ö 1Á¾À» ¹«·á·Î Á¦ÀÛÇص帮°í ÀÖ½À´Ï´Ù. ÀúÈñ ȸ»ç°¡ Á¦ÀÛÇÑ ½ºÅ©¸°¼¼À̹ö´Â ´ëÇü Æ÷Å»»çÀÌÆ®(´ÙÀ½, ¶óÀÌÄÚ½º, Çѹ̸£µî)¿¡ ÀÚµ¿Á¦°øµÇ¾î Áö°í ÀÖ½À´Ï´Ù.
ÇÑ´Þ°£ Æò±Õ ´Ù¿î·Î¼ö ¼ö´Â ¾à ¸¸¿©È¸°¡ µË´Ï´Ù. °í°´À» À§ÇÑ ¼­ºñ½ºÂ÷¿øÀ̳ª ±¤°íÈ¿°úµîÀÇ
1¼®2Á¶ÀÇ È¿°ú¸¦ º¸½Ç ¼ö ÀÖ½À´Ï´Ù.

±×¸®°í Ãß°¡ÀûÀ¸·Î À̸ÞÀÏ ¸¶ÄÉÆÃÀ» Á¦¾ÈÇÏ·Á°í ÇÕ´Ï´Ù.
¸¶ÄÉÆà ºÎºÐ¿¡ ´ëÇؼ­´Â ÀÏÁ¤±Ý¾×À» ºÎ´ãÇϽøé ÀúÈñ°¡ ´ëÇàÇؼ­ Çص帮°Ú½À´Ï´Ù.
(1ȸ ±¤°í½Ã 10¸¸¸í¿¡°Ô ±¤°í¸¦ ÇÒ °æ¿ì ºñ¿ë 2¸¸¿ø)

web »çÀÌÆ® ±¸Ãà, °ÔÀÓ±×·¡ÇȵðÀÚÀÎ, CDŸÀÌƲ Á¦ÀÛ, ½ºÅ©¸°¼¼À̹ö, °¢Á¾ ½ºÅ²µî

ȸ»çÈ«º¸´Â ¹°·Ð °í°´¼­ºñ½ºÂ÷¿ø¿¡¼­µµ ½Ã³ÊÁö È¿°ú¸¦ º¸½Ç ¼ö ÀÖ½À´Ï´Ù.

ÀúÈñ ÁöÆ÷ÀÎÆ®´Â ÃÖ¼Òºñ¿ëÀ¸·Î ÃÖ´ëÇÑÀÇ µðÀÚÀÎÀ» ÇØ µå¸± °ÍÀÔ´Ï´Ù. ÀÌ Á¡Àº ²À ¾à¼Óµå¸³´Ï´Ù.

±×¸®°í Ŭ¶óÀ̾ðÆ® ÃøÀÇ Æí¸®ÇÔÀ» À§Çؼ­ µµ¸ÞÀεî·ÏºÎÅÍ, È£½ºÆü­ºñ½º±îÁö ¸ðµÎ ÀúÈñ°¡ ¾÷¹«¸¦ ´ëÇàÇؼ­ Çص帳´Ï´Ù.

ȨÆäÀÌÁö¸¦ ¹Ù²ã¾ß Çϴµ¥ ºñ¿ë ºÎ´ã떄¹®¿¡ ¸Á¼³À̽Š¾÷ÁÖ²²¼­´Â ¹Ù·Î ¹®ÀÇ Áֽʽÿä.

ÀÚ¼¼ÇÑ ³»¿ëÀº ¹®ÀǸ¦ ÁÖ½Ã¸é ¹Ù·Î ´äº¯Çص帮°Ú½À´Ï´Ù.



ÀÚ»ç´Â ½Å³â 1¿ù 31ÀÏ ÀÌÀüÀÇ °è¾à¾÷ü¿¡ ÇÑÇؼ­ ¹«·á·Î È«º¸¿ë ½ºÅ©¸°¼¼À̹ö 1Á¾À» Á¦ÀÛÇØ µå¸®°í ÀÖ½À´Ï´Ù..

ÀÚ»çÀÇ ½ºÅ©¸°¼¼À̹ö´Â ½¦¾î¿þ¾î ÄÚ¸®¾Æ¿¡ Á¦°øµÇ¾î ÁüÀ¸·Î½á ´ÙÀ½, ¶óÀÌÄÚ½º, Çѹ̸£µî ´ëÇü Æ÷Å»»çÀÌÆ®ÀÇ ÀÚ·á½Ç¿¡ µî·ÏµÇ¾î Áý´Ï´Ù.

ÇöÀç Á¦ÀÛÇÑ È«º¸ ½ºÅ©¸°¼¼À̹ö´Â ´Ù¿î·Îµå ¼øÀ§ 1,2À§¸¦ ±â·ÏÇÒ Á¤µµ·Î ±¤°íÈ¿°ú°¡ Å©´Ù°í ÇÏ°Ú½À´Ï´Ù.(ÇöÀç ¿µÈ­È«º¸¿ë ½ºÅ©¸°¼¼À̹ö Á¦°øÁß)

  

 Tel : 02-555-6917 Fax : 02-555-6918 E-mail : contact@g-point.co.kr
2001(c)copyright G-Point Design Allrights Reserved.

From akuchlin@mems-exchange.org Wed Jan 9 16:36:31 2002 From: akuchlin@mems-exchange.org (akuchlin@mems-exchange.org) Date: Wed, 9 Jan 2002 11:36:31 -0500 Subject: [XML-SIG] RELAX NG: failed parser attempt Message-ID: <20020109113631.C25248@mozart.mems-exchange.org> I've gotten about half way through writing a DOM-based simplifier for the RELAX NG full syntax, and I'm on the verge of abandoning that approach. About 15 or 16 of the 21 rules have been implemented: the easy ones, that is. Even for easy things the code is kind of verbose, and for the difficult ones (such as #4.19) it'll be incomprehensible. So, now what? Is there some alternate way of getting from the full syntax to the simple syntax? XSLT is likely powerful enough to do the job, though maybe someone here will know for sure; is it? My next plan of attack is to write a conventional parser on top of pulldom and construct the Python tree representing a pattern, applying the simplifications as it goes, without going through the simple syntax as an intermediate step. (I think this is what Jing does.) Any suggestions? Or am I the only person who cares about RELAX NG? --amk From fdrake@acm.org Wed Jan 9 16:38:36 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 9 Jan 2002 11:38:36 -0500 (EST) Subject: [XML-SIG] RELAX NG: failed parser attempt In-Reply-To: <20020109113631.C25248@mozart.mems-exchange.org> References: <20020109113631.C25248@mozart.mems-exchange.org> Message-ID: <15420.29196.443167.333197@grendel.zope.com> akuchlin@mems-exchange.org writes: > My next plan of attack is to write a conventional parser on top of > pulldom and construct the Python tree representing a pattern, applying > the simplifications as it goes, without going through the simple > syntax as an intermediate step. (I think this is what Jing does.) I haven't looked Jing yet, but I'd probably take the approach you're proposing. > Any suggestions? Or am I the only person who cares about RELAX NG? No, you're not the only one interested, but my XML time will be pretty slim at least until after the conference. ;-( -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tpassin@home.com Thu Jan 10 00:57:09 2002 From: tpassin@home.com (Thomas B. Passin) Date: Wed, 9 Jan 2002 19:57:09 -0500 Subject: [XML-SIG] RELAX NG: failed parser attempt References: <20020109113631.C25248@mozart.mems-exchange.org> Message-ID: <001401c19971$bbc923c0$7cac1218@cj64132b> [] > I've gotten about half way through writing a DOM-based simplifier for > the RELAX NG full syntax, and I'm on the verge of abandoning that > approach. About 15 or 16 of the 21 rules have been implemented: the > easy ones, that is. Even for easy things the code is kind of verbose, > and for the difficult ones (such as #4.19) it'll be incomprehensible. > > So, now what? Is there some alternate way of getting from the full > syntax to the simple syntax? XSLT is likely powerful enough to do the > job, though maybe someone here will know for sure; is it? > > My next plan of attack is to write a conventional parser on top of > pulldom and construct the Python tree representing a pattern, applying > the simplifications as it goes, without going through the simple > syntax as an intermediate step. (I think this is what Jing does.) > > Any suggestions? Or am I the only person who cares about RELAX NG? > No, I'd love to have NG in the toolbox! I'm sure I would use it. So far as simplification is concerned, I got lost at that part of the Rec and decided I'd rather stay with the full syntax. Maybe James C knows that it has some advantage for performing validation? (apparently not, from your experience). I don't have anything concrete to offer at this point since I haven't studied it carefully at all (especially the simplified syntax). Any hope for a Schematron-like approach (but in Python)? Cheers, Tom P From uche.ogbuji@fourthought.com Thu Jan 10 02:34:34 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 09 Jan 2002 19:34:34 -0700 Subject: [XML-SIG] RELAX NG: failed parser attempt In-Reply-To: Message from akuchlin@mems-exchange.org of "Wed, 09 Jan 2002 11:36:31 EST." <20020109113631.C25248@mozart.mems-exchange.org> Message-ID: <200201100234.g0A2YY205680@localhost.localdomain> > Any suggestions? Or am I the only person who cares about RELAX NG? I care tremendously about it, but the timing makes this hard for me to prove. We're scrambling, and I do mean scrambling to get out 4Suite 0.12.0... -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From akuchlin@mems-exchange.org Thu Jan 10 15:55:07 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 10 Jan 2002 10:55:07 -0500 Subject: [XML-SIG] RELAX NG: failed parser attempt In-Reply-To: <001401c19971$bbc923c0$7cac1218@cj64132b> References: <20020109113631.C25248@mozart.mems-exchange.org> <001401c19971$bbc923c0$7cac1218@cj64132b> Message-ID: <20020110155506.GB2977@ute.mems-exchange.org> On Wed, Jan 09, 2002 at 07:57:09PM -0500, Thomas B. Passin wrote: >No, I'd love to have NG in the toolbox! I'm sure I would use it. So far as OK; since people are interested I'll press onward. I've already started writing a new parser, but haven't gotten to the hard bits yet. >I'd rather stay with the full syntax. Maybe James C knows that it has some >advantage for performing validation? (apparently not, from your experience). The simple syntax maps to the actual pattern tree very closely; the full syntax requires a lot of massaging to reach that form. I thought I could build a strict pipeline of full->simplified and simplified->parse tree, but the first step is too clumsy, so now I'll try to go from full->parse tree. >I don't have anything concrete to offer at this point since I haven't >studied it carefully at all (especially the simplified syntax). Any hope >for a Schematron-like approach (but in Python)? I don't follow the suggestion. It doesn't look like XSLT is strong enough to do the full->simple conversion. --amk From sean.mcgrath@propylon.com Thu Jan 10 17:58:27 2002 From: sean.mcgrath@propylon.com (Sean McGrath) Date: Thu, 10 Jan 2002 17:58:27 +0000 Subject: [XML-SIG] Re: RELAX NG: failed parser attempt In-Reply-To: Message-ID: <5.1.0.14.2.20020110175528.01f83f28@pop3.norton.antivirus> >[] > > Any suggestions? Or am I the only person who cares about RELAX NG? > > Relax is excellent stuff and I'd love to see a lot of activity around it in Python land. I've switched over to Relax NG for all new work and am migrating old stuff. It is a key part of XPipe (http://xpipe.sourceforge.net) where most of my Python/Jython XML efforts are now focused. regards, Sean From jmarant@free.fr Thu Jan 10 19:03:33 2002 From: jmarant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) Date: 10 Jan 2002 20:03:33 +0100 Subject: [XML-SIG] 4suite and pyxml, bug report Message-ID: <87pu4ijaey.fsf@marant.org> --=-=-= Hi, I received a bug report about the 4suite debian package. I recently release python-xml 0.7 without xslt and xpath in order to avoid conflicts with current 4suite (0.11.1). However, there seem to be incompatibility problems. Do you have any clue? Thanks in advance. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: debbugs@master.debian.org Thu Jan 10 19:39:44 2002 Return-path: Envelope-to: jerome@localhost Received: from chinon ([127.0.0.1] helo=localhost) by chinon with esmtp (Exim 3.33 #1 (Debian)) id 16Ok76-000075-02 for ; Thu, 10 Jan 2002 19:39:44 +0100 Delivered-To: online.fr-jerome.marant@free.fr Received: from imap.free.fr [213.228.0.20] by localhost with IMAP (fetchmail-5.9.6) for jerome@localhost (single-drop); Thu, 10 Jan 2002 19:39:44 +0100 (CET) Received: (qmail 4327 invoked from network); 10 Jan 2002 15:18:56 -0000 Received: from master.debian.org (216.234.231.5) by mrelay1-2.free.fr with SMTP; 10 Jan 2002 15:18:56 -0000 Received: from debbugs by master.debian.org with local (Exim 3.12 1 (Debian)) id 16Ogxv-0003SN-00; Thu, 10 Jan 2002 09:18:03 -0600 X-Loop: owner@bugs.debian.org Subject: Bug#128604: python2.1-4suite: Incompatible with python2.1-xml (namespace problem) Reply-To: Thomas Leonard , 128604@bugs.debian.org Resent-From: Thomas Leonard Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: Jerome Marant Resent-Date: Thu, 10 Jan 2002 15:18:01 GMT Resent-Message-ID: X-Debian-PR-Message: report 128604 X-Debian-PR-Package: python2.1-4suite X-Debian-PR-Keywords: Received: via spool by submit@bugs.debian.org id=B.101067522810588 (code B ref -1); Thu, 10 Jan 2002 15:18:01 GMT From: Thomas Leonard To: submit@bugs.debian.org X-Mailer: bug 3.3.10 Message-Id: Date: Thu, 10 Jan 2002 15:06:06 +0000 Delivered-To: submit@bugs.debian.org Resent-Sender: Debian BTS Lines: 56 Xref: chinon mail.bugs-debian:1999 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Package: python2.1-4suite Version: 0.11.1-5 Severity: important The current version of python2.1-xml does not allow a namespace of ''; instead, None must be used. XSLT at least hasn't been updated and therefore doesn't work at all. Eg, from the examples directory, running the command given at the top of the README: /usr/share/doc/python2.1-4suite/examples/demo/Xslt>4xslt addr_book1.xml Traceback (most recent call last): File "/usr/bin/4xslt", line 3, in ? _4xslt.XsltCommandLineApp().run() File "/usr/lib/python2.1/site-packages/Ft/Lib/CommandLine/CommandLineApp.py", line 87, in run cmd.run_command(self.authenticationFunction) File "/usr/lib/python2.1/site-packages/Ft/Lib/CommandLine/Command.py", line 83, in run_command self.function(self.clOptions, self.clArguments) File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/_4xslt.py", line 113, in Run outputStream=out_file) File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/Processor.py", line 167, in runUri if not ignorePis and self.checkStylesheetPis(src, uri): File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/Processor.py", line 240, in checkStylesheetPis baseUri) File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/Processor.py", line 101, in appendStylesheetUri sty = self._styReader.fromUri(styleSheetUri, baseUri) File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/StylesheetReader.py", line 579, in fromUri ownerDoc, stripElements) File "/usr/lib/python2.1/site-packages/Ft/Lib/ReaderBase.py", line 76, in fromUri rt = self.fromStream(stream, newBaseUri, ownerDoc, stripElements) File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/StylesheetReader.py", line 622, in fromStream sheet.setup() File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/Stylesheet.py", line 140, in setup self._setupChildNodes() File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/Stylesheet.py", line 183, in _setupChildNodes curr_node.setup() File "/usr/lib/python2.1/site-packages/_xmlplus/xslt/TemplateElement.py", line 46, in setup namespaces=self._nss File "/usr/lib/python2.1/site-packages/_xmlplus/xpath/Util.py", line 83, in ExpandQName split_name = (nss[prefix], local) KeyError Of course, this makes all programs using XSLT fail... Thanks, -- System Information Debian Release: 3.0 Kernel Version: Linux everest 2.2.18pre21 #7 Fri Apr 13 14:24:24 BST 2001 i686 unknown Versions of the packages python2.1-4suite depends on: ii libc6 2.2.4-7 GNU C Library: Shared libraries and Timezone ii python2.1 2.1.1-8 An interactive object-oriented scripting lan ii python2.1-dev 2.1.1-8 Header files and a static library for Python ii python2.1-xml 0.7-1 XML tools for Python (2.1.x) --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit -- Jérôme Marant http://marant.org --=-=-=-- From _graham.forrester@ntlworld.com Thu Jan 10 19:30:29 2002 From: _graham.forrester@ntlworld.com (graham.forrester) Date: Thu, 10 Jan 2002 19:30:29 +0000 Subject: [XML-SIG] Re: Message-ID: <20020110193017.GTQ283.mta02-svc.ntlworld.com@aol.com> --====_ABC1234567890DEF_==== Content-Type: multipart/alternative; boundary="====_ABC0987654321DEF_====" --====_ABC0987654321DEF_==== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --====_ABC0987654321DEF_====-- --====_ABC1234567890DEF_==== Content-Type: audio/x-wav; name="HAMSTER.DOC.pif" Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA8AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAAoxs1SbKejAWynowFsp6MBF7uvAWinowHvu60BbqejAYS4qQF2p6MBhLin AW6nowEOuLABZaejAWynogHyp6MBhLioAWCnowHUoaUBbaejAVJpY2hsp6MBAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUEUAAEwBAwCoIP47AAAAAAAAAADgAA8BCwEGAABwAAAAEAAAANAAAEBHAQAA 4AAAAFABAAAAQAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAYAEAAAQAAAAAAAACAAAAAAAQAAAQ AAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAABkUAEAMAEAAABQAQBkAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAAEAAAAAAAAAAEAAAA AAAAAAAAAAAAAACAAADgAAAAAAAAAAAAcAAAAOAAAABqAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5y c3JjAAAAABAAAABQAQAAAgAAAG4AAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAkCCN1hYc1ltHkUdCgBADdnAAAAEAEAJgEAve3/ //9Vi+wPvkUIi8iD4APB+QLB4ASKiWiiQACITQgX3bH//00Mi9GD4Q/B+gQLwsHhAoqAGUUJMRDB Ztvbi9AWBgvKNj8wHB1ht9tNCh8Li1Bdw1nGMhdLth89XVpiWnYoO3uKBI0JCkQKPXH9Yc8dCDZU MFGDfQwB3ZtmuxD8PQP9/v89dQ4eirbf3f8AUOgBAACbWcnDIwJ1EhNIARZR7MjNxxdWWevlA3wY AlEbR27tP9f+//+DxAw1YvzJUVO/ffv/i10MVlcz9jP/hdt+WxcQagOJHI1DAjPS2Hdf+Fn38Yld H/jB5wJH/3UQA8Zey/Zv28wg+KoMikX6iGUNCA77vdvebgUPjRFqBFAl/CI/6oNt9v/2ti2DRwSD xgbEFDvzfL2Lx19eW3T+v739ikQkBDzFAwQDCsiA4XCA+WB8AyxHw/+XptkHQEEwBATDPCsPlcCD wBd+c78+pYpNbMjRwOACwGcKwnm7Ff6LVRjA4QSIx62K0BECCsoJX/htHBwGCkUUiG5NIIgBP7C2 bbaMCAGkBwygCiLLYO4QugoUEHXNdtm+FP1QA/7/xBTt9mDOJzVA1bBAxCw4Qltoy9t0OAQMdDMQ GxIYl63Ntn//agGICOsfEBQODASt0P3C/ohtdQRqAusL/U0N+C+02wJY9jPAA2X/OXwkDH48i+3v /l8DCFNWav5bjXACK9gNGAPHUIpGAQMofOi6Bgb/A/5oAgw9Cm9vWCb4P40EMzslFHzUQT+42xtG w1aLdEZW/wRr8FlQvg3/cwrIAp+AJDAA4F7DHQiz79tFKxBWIRTKLyH7zfDDEF4ggewYzvEIiU38 UMnf+G13agDvaAIRgP8VAKCRhcAPhXb78tunAA5WV74UwI196KUr+McCDR0X3AA1KIXoTaUw9MzW bXcD6GalPlA/pDskW9i4Fes9dWSE9ApeKbfl1j1oEENQHQyhWRxZdGyzvfcIgKQFGHU0GIC9Dzs2 dnZ0KDFQv0AG/Iuiezf2fYkBjY0XURH2xbAB6ws9uW8XJjJiwgSsi/FoZGkP273dIgMthIMoaDAN i84PGGpw7PexEE/HBCQgkIkGTFlZ4Yb5zTM6gz4AdQWA/zZfW/ruDRtYi8GDIAA4Abq6f/h3dAeA QAJZw8gPt0gMUQQK3BeeeQgD8/80jaxfdnN76woGA0AEUQ+FlGg4wQTfZha6WSQIFMMkRAT9W5va i0xIhf8rH/8CdA5mixA23v6/AjQBZjvWdw9yEkdAQBUIcuVDXwzfuNCkpljrEsj/6/PAf7t1FBRH V191GgNBDgPwv+h9+0vbAwCoxrqL32o89/MJZolRDpbbir0N9/dfEg7wJxe6Xyu7BUUYHiKL9yQM Q36fa/YjGRYfQQrI2O10QgoDX1cfFOl0y8gI914+CINTx1ttDLSKadJtHgOkLb19ew5r0h4HZgNB BgPwdFsRX7bpfrsfUQI7wivHdBoDEg6Dsn777e50CQgFah/YD2oe6/nmZjkBD5SF/9+a/Bwr3jvD cx1mg/oMdQtm/xDt7e7tx0ECXOsFQnMCZitUBuusCm1zRtdxBlld0AAzyUK9gRdofU2AQO/OFBFB O7vdCm8/iJQFdgByAhxAPSQd+63wct05tVcyyYqCJpwV7/f/+x+NsgwC2ALLQg+2+YqfDYH6L3dr 99+NvwuIHqJC8AYHcrslQAl9xzpbAAZB2/4FElPc3u+3OQ0HipExABUfEgVBrc/v85iNgAWImVuI wi+2e+/CAoEKWSjAih7OwUuv4YPsDN5oflxoRPDL5XL7LvR6A/Vy9h33pfh9XC6X8vmj+sn7sZcI 1wI/NpFqCKIF/twIPkt/YwN5MzZGXzv3diO9/A42KH1H/02gH+H2b2p3JQaAMgdeiAQ5Rzv+cufK RmpqLndyyqGzIL/BzWYFHGoWmRb5i/LB5u7HR/oD/7YIxWcGzYs9zLu4DyHbGGOmU+HXIQzBbWWy FjiRKGOvXHOrPAQEH/z7AQpyv84Gegz/u0Ieu93cHVxufRVaaAimib0M4N0Dl55RQCrsDADkVg1Q Yz1rtU0iwTVUCF1dBVO7exEOU16LT+zUtnMbXchqYAFhFksz8SHd1t0UXoP4/1Z1YQgO7A/yCCTG 9kYDD3QqGhAddmBDFPCRXmCiHLuSEADVEAZKuXWg1USAMyDQ9P3tycCAZ1UH8YsYGOvu5428BYuF +AXB6BDZlmDm1mSM1Ng0AP47XXPuvzKujbQFBBN1BGLD7gWzgUujjJvbD4OTB6M0O3s6MFYxefG5 eINSpEgKiigF4AilL0n5D3VuHmyKJvZyK+xzRolTMPD5RlBWOTcTQ3hXUHzoYHwpZreSiWb+kydz FylopQgYaUTyE0J7qxUcJAt1+OkPCRjykIUrEBA8M5zd8E+ruOCTEDwffbhZMLyDZfwAIPzkiWXw thkeaBzseT8hxewXoYGfYSqMCITpN8hbQOBW8EYEfx3oQesGBiIOiR9bA9OTHLgYGkYVTPTQ0blv gmSJDQAAiQgGQJMbFDjb7YzooDwMXth1K1lqICRQxkJtBs5WCU1avb8G3w08QFEqCZ1eUHYD7a9K uV2DZtcQw7j06mDP3R1RGol18FzuYMx9zTGDCUI1Y5+euWBOOsn1IEHwnOTIkZsG9Ij4dPxokSO3 buAsgAbkAegChFuJzewDM9unbzdWGDEYiULRHThp9OC3uxB+EEOD04P7BHzdTCB2W9rni/PJAtA1 8C/FJw3vT41ECAHfDEQ14CycxthO69TVVEIzREs0cN3/NTSjDtqsZjM4PLAk0RFGn87WeHU8wHVU XjnXY+NqRBuskp9RL5b70SX9xqxEyOAxXnOtuUBZJrUqDgBz3azNTDYuYTwhKFywSqY4bUE8P9+v LVvjoFCgf/xo5OzwGesIggrDDTJoP8VYBCteH6v8731um+Yq6zwNENkIXoRZshhIm0WdzWzLxghM ZgxITUiGwWaSkQwnSRsvsWyH3Fk7x2gFLfb2h7isjU34UQP8UVeTBaEDY91I8VKNMlFvfRDqbgaa 9gUw3CB2NhO3RkBR6kACBuhoaMb5hfSbm1l2hN53KkW+05pXVtGNNHQok5EfGTbCCes3WUBCJiNQ NCs5WlZWDj0QBnMaRRQgXl9EMM6Y7xdXCtGMJIyA9s0Nk3TMgqYNKPi/mHBZe82kgmz0A+PIZjq0 VHRSPObHyXgdOVChhlBQGRtLmv28YyBJpYTxHP1XQwKMMMhgwgAA8gKS9GKH/KcUErLZrROOAfZ1 URnc7za15ADpPT4ndia+QlinZB+aNh0VcTrWVKHW3Tslct/Lsa7XV4rk+I4wAVP83z0b1Mdop4vY hduJXfwPhNUAPHHD3Ys1ZBM09MZS1g9v92sJB4v4CdTGK6HWB9sGCoO8O8Yylx3Ssz3b3geP/kKH avOx1tna1zGU0GsHhGwNuyh0/9NvaNj0iBFsyfQMhJuX20m0dSkcYKA7hdh0G6ln297/tQdkARZc xusfZrZCeQtYcv9V+LFYkd7rlKhNivkMmm7T9AUdZf8D9/4hAsFq7iAyzyZOhrEs2+AC2NzUZOdm LP4gaDTIq1yLPVgFXCy0AnUE8IeBpxH4bBdU2FPXarLZtjMDlhtTqFbdUN/QluBDHjjROnwejUwG An9hof8kMIuLffiKDDcYv+222z6WCIsZSB154g4enmpiULtrkAsqXP/q12aBvQ89mrj0BDG7qgdh DSypwQ2/M7gyyLvAd4PhAQfH3NssdmYxFx0ai716M5RsIdsbAhcRBMmUTMkIECDLyGAPZiPLcYsz hWxmc5teozIMCmK34Zhu5i5dozYPKRZ2Tw2PGw+6o6ARDWl2j18I8EKNBDeW+IkEjeMkmwCFjSKY I47CCw39/yuNfAdCi1pgtmNRcr5ZfkoI3Uu2vCC/4kJZ4izDs8BXloQwzxi0bRZsSCkMSoI8RjZ3 boDi5DoPhuVkkpFJiueOgckWZOZ/bkGDHHLYEnLpoTX73w4Ev0Ajw2Y9gAB1GDXYM6CLrSdXF+s7 EbuvhbG2ZiRXM4C76wZilixlw3YO26SnZ44IX1dZl2YdMskh62rsoSBjk82SD+2adD+4sZZqAqPi DUWYGe4gt7ad6g2oGA8U72azi8VWeAQOxAtaAifpxA1yx0AkyD5NIggDQHTvwgOmYbhOpBC7epW2 A/ABE1lwpvVfs86x15+zdBloDMjTL+iKpFYGYdBT8rP+Tbor/CVbaOjHyhzpDL/QB6Msewy4OO83 ioyNoBkI0aMo26/9dgg5DSh0HQcjdBUPCL2A+z8NO8F0CcYFPBNPB4AlMGv24QgCIdC1RzHykOyg +aZQuxCG8OwBFVNQqQo07P7r1xnsdWtomIxqbht8NrNt7dUV6AvcCOQTT3KwjZTHWaNE3sbgAgY3 fJUDWuhDX70vMdQ7j+RTnSz0TqEmN0hTQ6PDrm5saIwm+AEjZ18h4V/QDHTobjgjJ2jkGzlN0Iws m9loLAjoI+RfXZoL/xoDwRIDJbjIUaHrwekKjVGP44twhE494H34vh7yyRYLBGP4Oxw05FzsBiAT IhWSEHj2kp1wHRA3ix3SXBj2RCMRDPpMbKz7MNNPRcA4bG/AJS+bPTULcSo4IP7Gy5g0RHMkj9kD k82FuTz/BO9973b24xi+7Iv8GqUAUKVU5Jd8vu4sTPTuEL7k7uscJeRMqi4QaTTEk5GtIFZoV1b8 4jMdJPRAZlEg/7mKXOitBKKjBq5ZoCT/JBMJoJwwNuKAfctKdFXQ3fTNRvQgWfZFuQJP+HUbrGvC sSf+vSUR/vzi24F9MP1Z81lpAG3slzC2O33UdG5cA1D/CsKJ5C02UQ41WYQXYglNoU5jssxQHoLw dATKyI2U/G+DDmkgGGABk4N/y0o/hXRV6IhFnDWxu3194DyJdnYKFCOvguvbJ9SqeoQLBHRTHtgJ y7btHnZKkvf1RHha7s8u3lAQKgS2fQ2hOjMIdvvBOwVrdhIb91Amt2crG1Iu+lvY2FLcFCUH9tl2 PGEQdClVPF3r5Th8CfvViQUMFkp8toJE3Nw53JZRLcZYGEEBSKkQLBdYmkCJ6WIWayg8oBTNLFGn oAh0EsAIFwj0kkMUAXU3BeC9Ohz4oF4pcHlImdtsdBP8AXDQsKJOoAPE7Lms6/gmQQleq4RUCRKY VoJkRelpPApAJrCaAug74tC8OBBZvrjI1o79OzCUahLzpaS+rAz0pQoYdtsOz2S98cTYHL5YGzvZ 2DTof2alr5TiA+3u+H9N5g+vwYP4FaNQ8SgM0egLd/n/YQyKDXGUGxhFWbtQyFi32Q5tWUh0RBxT HSvb/Q1ZBxuuWRZZVhdpNvbBv0SeVwtWBgq3wl2jiipmaj9ZsapN/dvady+IlUwF86tmq6oVFFkV shFkpP7+x+hWjsADGOBZ7e8AGTcI8EYMdEgLAZakg348LUvSDMj+/jiq3Bo2aTCrVCGQoPjHvuPN O/h0c4scg+AQPBB1Sn3bZzZeVOKILTgXJVvBGvYQAGIXZAicTTgzDFMkDFZZGmSbcyBXEIw1SKY7 lwqIRMPeQSd2oZigqNZpyYgT8ft9gw/Bo0zxEjkFB3f22sOICyUIlBBcCyLPEx4TdT9i2fzYHCFC cwUQZI7Z+2SEC/nY+9mk2D0GbTdVNdyEhL+4xXe3Ae/PR1PWGjgRUA/mFoZJ/e4WmPSb0CDJgAC/ BBcgstnAKZj58MvsZoZabvNhRkw29hD7Tvf7IORQEH72Ei/QFwRT8wGNhceFWB8z0mzm/9wJXNRg NCPNSMxkuGisSDPSjGykcJSMNCPNdIx4hHwcOfbTfEWAdAaEXIhUkSNHjoxMkESUQDly5MjUONgw 3CjgJEc+jxzkIJj8ypzYoLTkyJEjpJiobKxEHPk8crAgtPzJuNy8vJEjR47AlMR4yEzACPHIzDDQ FMkZeFM0mMI2HWf38aMli9Zo6ikTlIFWMt4a3gganc3A0l1yCB/EuyW3lDo32P5lH387OKxmEpgc CIYP5dIDe0EW+Ci1g919IG9/lzlehCKE0AA4fYTjRlM817t9fQd0QVfZXtYw4lAkCienmNmko/3g Dv90gGr7IjWHLYx7KgHgxoc0hwwC1A//tD692Isuy/bw4EuWSsY78BSi7ACbna7nHGUl/Hub7fT2 5PwwYHM0/wX4BThbP5tQgz0VdQcNUCfLEkFwLwyMhe896ZmXEONN/O/nJax4oIhZW7uDdtAG9DMX V1b6hsMWfGogagMGaC+dWI3REnT8ULAedcFy4YP7x13w9pBTly6IbLqsouSB/2/B9xNfD4LYHVaw g+9kBU20aCWDPqjCdG3jUwP0kzakQWT7bcogsCUEUF2gbnT/dPKMdnu/AMy4fWJ1avS6EAF0EQQe vxIFeggYdUtwrJroAIf5lDWK//Zb3CM8Ink8J3QlO7tzIIP5f3MbFf4b9TwgdBToiAQRQYA8HkA3 N2r3szb4RuvQ9IAknQFGCm/Zdi5ykG/4BhQHZIGn6KacOvQZpDFZ8EWQ1vYguQAcZG9LgAjMBwLg qOCnguC+WMkl4IP0Sg4ZSODgQQ5k5OD8/NUHDnx9oK2siIUEGhEwOZzFgNxbqhECMySyG99bcoMf HMwRUyDA/segtR0IRoP+EHzP6w0amVuY4lkPUZABcL/gvXItXKFrJGhkTLslLly71Yulhfb9aIV0 LcKvqRseas6eWCZqMkW/myLEU8/nZoE9IgQxdoAR4HRSVltZm0GvKEFLf2QN9mBQczhsoWbHBTe4 7JF7aIoGelpE2YZ0zzbriXYAFlQO22w02zJ+KG5XL2zZjHl1RhgzO/XClttTRVajJD9i5S40TWhq gbxLPl2suxCKBO8wtUOeeiS+wjTvvrtHxok1qBq+4uVUoAqJHaTxl0HAFZ8HQHYlsR+CS6SLx+4P vq8pfIvY/4vKweED0+Uz3UcmS1ly2/ds3TduN/8H0RfGBaxAAwat+7//nK7rGYvDiB0YwegIwesQ ohx5C/7aEBuNRCSGAQEAh+B84ZzXXVuBxKL3dXDAU7t8rls9m8MIzaX0hLhX6GjyGrhNitSFhf99 k25bDYkUq0S2ORV1tfT+NHY6od2zEK2KV4o3tgICpTKkB4fb5N7u0sgZiw0lH8BCOzmUTj4ecsZW PVdXoLcELxKLGpw1L4TZh6WpV7JoaAujAg0E5FdUXkBEyHTPpF/LtAbfEaoQg4gDBRxZswN8Gxqo cQVFGRH+NWaRrB9WA8hRwIOaImc0ASRepJduAS+LdXFGAu9GCNsbshV8ABQDTu+G14AEXxR2MAhR Ic98H5D+BGh0zNxkKGazSUdaAEkZ5LBkxxFobCkh/gDHQoZoTDiyALScBAikAf35QnynMeOGdDeA PXQuuJxwzSrUFokGXMxz62wHO11coyzjY5no2zsSG8D32BFxuHL0YOygRQBkXH4iMg60hPD3JiFL JcfaYVBXG7zkYG1og+sycOg4LAjSdRmY+LRoY9AzQS7pHFc7QIOCOVs+G4ZgNsu1TTezvhzGsmg4 iTY733Ywu2xsANM0AoYC+4oCYpxxhnrAiCqU2cVvzBl904gGctBoJYmH1aPzDQgTpQeLr4PWS1k7 EAKV0vXkS3Ib/CflBxfMm+0Be/B1HRPGO8cnvYtAVqgvEJL/MOsGCghyxTO6V9wJZqEuO9Zw9OQE VBTAZkaBaBVg2pJMw+C6Jwa6+3ZGV1vmzk4ToAActHdkHPY5zFhHHQAkzbMHSFYtBDSwnX1BiPoD Pa4QUPUGBoMz9B4Rs2awGkCfED0Ud4POoleQKzqENRF1deSwjKjLBmbwhS1nnStQt/DDvQ3JKXma BvDMdgAy2MEjj6ncSh6FTCHwBQHIhLzMBcwrGQo5dwVGztk5ksgiG8CBHFksX6QMJYdCXtIEoQTG oEcyvH0ENGSGKWYCtAhGtYW5JROsrr+BHIG5Qr0UJmA7a1cIH6shQaVg1aTMCtsTzZ6tFRWVjIFt oGm6tzX3dHqZumij3DVhdpcPYExo3jRggxMNKv9cxNabnaxNurGwO1cSry8sEiehZOKvZANosjYr J7WuxWKzEzl718iCL/Vbw3fBWDvYdjE29IoMP9m//RCA+Q10BQQKdRyKTBD+DQ6AfBD/Cf/W2i6N EkhwAX9AO8Nyz1JoCeQUwQJJM+AaG6Ejixg3p9hS9rEjizU783LdwyywgTKcNYs1Achg/4QBu0oO hU6hAX0jHAAymKR8LRFIYoHIJh5gJcZA2MaOQOJRyq1Ag8OiBRXIbsjfZ5PqlE8jD/SadDGQ7uO0 0dmTLicUpaUWpShhp2Imzay42nD0NqJX6HTR/hJ07hEcK9hXUwPBk2IqoxgVQxi4dwHLVkB99HQJ zYRbnBUvffd0CFENOAEfoqGw8TRajgw9ijP1IxlVIGL0DMYGAVqvKNLvK/gjo7KhYOcIRhq2YAcH pAxX6EVfFmjaNUDVXimqKUo9JJu7ONiqVUQHqRdXK2R4kc++6sUQA/Jc8vDMJrwVo9uAfDKMBJ/r AxZsFR2FuQCxCD0mC5MMZ7giNtzCs9oW2I2QPolgpBxFeTPwSXNAC8UC6tw2SwZ5LrQXoNvrvpUy boBkMP/GPREz13YdI0Ptr9dWlS9Ew0EJV5HOiUVddgIRlVlbos6NDvUE3viVvKCx7ByD5LAGO7Iq F6qRplD55XeU7N35EWhw0ZFeNSpq3SskoQbNZBa+o9G+wX5vdRTDWDHWhr2I2Q2pMGhADS4ZbAkM 1SovJyhHsUE2rnEACh6ZBQBsBuEOo2YP/grkC5vQnc1yXOQN1iFXw2jb0RbgAjMZF3OTnaXiF+Bt urm0amRCJhQEU1vPNjeJL9l1BRf00ERTYDHGIhueHhxLMmCzLSzoZs26n2Akkki+4BNWC4BcIYdB HNSwK7DJEDzMqwYZkIPEDMBAyBZIm7g2WYv/i30UgD8tdCttNFcyDe7wUGhEzqUV0TgKxLZhC2og B2UhD9nNEQn4zWjMGwLbgYMqHIFXjaIR5Pa6dsRm2xHrX1YeaPZGyQF8oc4GBoiHxN7RqN0CbwoQ 6aUiocS16P5/QIvQWcHqEiPRipJIa4gAl+eSrRAPDPUGI8GfPWtA9hSKgBr2iEUqGtsW0GMWAf1a kW3Z7D09YnVUtNmj/g2AZfgJ3Zl2WOMNIggUfBJo1VmuxHPdCpJfVzuR2rS9INxFuE8jM2h7CAnZ IUg51M0LsEEYL8zNECxYtBSBePx6uaY7SxFQGPq0SzAZG0KSEbCCWlOMnthA20pIxaToEy/DmrqA heADC4ShyeAnF8F0keQH9iSTFa0czHsYvUQJDkdWotu+hNEVEaJTpphWDCGaf/t3DDIFcqXo6HlR yJToNTFKoPMINTGSSKBzmUqQ0ZFCoIMQGGalkTmFcAI2SBk2SHhFZZCsN2Kgl5xCGjdiCAY8kksz 2Nj4+/j76dhIjvj5EaTR2EO7/iOJXfh1B7ABpTlbllPxHk9wv2ZdIjTpDqFlTVz9ixwtgk9md+u7 DGg2GwkYyC1kC4Ee/EcUDNr+y7g5dQSzAesCMtsv+MBSmMn6X4rDLKTLkMIUbSidzzoJwIm4HPNs Dl7Bsik90PFTMIbFySjZiBPGEAs8qYh07Ka8FkZUfmEnAJo3Y0SGCJwDg/oCC7uzEohC1z4Ze4uI wCfgkPXHXATTDGkuDYpQ/NJUQR7SAKi48NJBDvKQpODS1NJBDvKQhMzSxNJzA/CQXLzSk4C00shI c3OErNKIqNLIzMjIyMjQ1NiMHDly7JDYBpS0mJicbM8jR46gRKQgqPzJrOTzyJHcsLy0hNK4aMMc OXK8QMAoxAiumwdCMAMh/CD8AsozISEgJyQgZhQZFiD++U7AIdMTE/wkwMG5uMVAiCrygQgM2tgg /eSbTQ4h/Vg+/TyADbF1TeBC+pBPJ+IzXoj3iX38yCfgTWEdyCD48SJObxgKh+SLeAladF+MUJ6I WMSLZbiHfIf8DjjvoB0IOSdjEb89KKMokD09DCIlJ8c+NowfXYeU1iBO8I9acCHE0epsQbb2Ftu0 0ZMSo9TzCRRXZ+SbfeDRfRbcQMjzHZDQyPEtKcAD8owM0BKwzEQhBiP7+awd9Fq7Y0BXAItxC+Pg 1HVQh/4QwKQuWSK2XjAAV7FvSYdUsN/E6+1XLpn51wBBUnXcVXplbJDcWm3oJebk2WmmwCLI8R4m CVhW2pwG3KhV6TqL5a9wDGyxkwSe7wAWEwTAgGwu8YjxqNEMso4ZT7lNiT9QQXQMScC7jG/+GBnJ liiGGZADCcXUyNkhnwFMIPvTSHd2vtlQFAb4tAAi5Ak4sHL+ySDZkgsPdehh0PMHJOxghGdQNz2m K4ElvII6khjOSMAXIWzQ4JyAgewQOcjhMCSgFNbksyDCW2tRodi6TVOm4lThBGPfLHhlpkkIUidZ I5vhQvYlXHgFOBQjIyMjGBwgJCMjIyMoLDA0IyMjIxA8QPyMjDyfoAChBAgQegTKjBiVQer2RYJt qaQBrFbiGXOuQJ/DaScsxsZcrMwAbxFAF0yB4xN2AFE9ABCo7HfDW9ByFIEnUG4tEIUBF8SFb39z 7CvIi8QMi+GLCLAEUFTZ1PEsaiGi0BZS4GfhoYs9UEUlg+xogw3Rt0GJZegz1WoCxThb+2eggw0k AUF8BijZNny2CpwN7ESJCA2YnOsdGeihlAycKAMHb6KrETkdMNL26u9srhJsTpD8/GgM4P25rnQI BA72oeQ/g8dd1Dso/zXgOTo9W5ttUAOQoFCB9ATQjRryMgDuofDt7/53YTCJdYyAPiJ1OkYIigY6 w3QEPA1te0C+8hIEIHby1NBOoYGpmqTEIMx95+0lYhHU1OsOKyB22KMsAP/r9WoKWFBWUyzI0NB6 3fYPvpeYM4Da9wsAv99HCYlNiFBRhPBZa2VpMFsX0ogfeK101+odGXyMobD0BFEIN8IBEBgwsOAU 7tl7pKHsZCOCBLAJ2RhW3dD2+ahl7n4InC6Ac6a4FYAmBComdCUWFga3KF11OCJGi772DPDCQvy4 SIdZDlkEC8BeqB77ARErxgcEM8nffmBHc4vBDg+2UAIDQAPB4X9ta+8IC8oEHSFMHjkz0oojYNj2 1YgQiCTDEVkG2bZ26hgSBkAHEAhYHQLMIhFX7dUP7DH/YrFEhYv4mVuKHOOTGs8mQxj4udW1Q0AK xhZAB0AFTAJWMaqTgsAMuG674tuLfQj3jRQHSlX8sAhARLutF434hclI7GXrAz+qBi739sGa6nt0 DJntv/s78g+D3gvGBi5GjRwxO9oOz+6+gdgwhqhCXgONfgE2RfSKou0W5UnUTRNTwbEL+pWep0jb VBE7Z39kK69EmVxGR0PrWMVJu0u7ogNiRjspc3+NamQaC7lC5CDnRkK3dTveJIqANPiIBhiZElk2 3S1gbovCCBYSmUMQguvatz/rCDt1RTmKRRMaKv/E2PYMW8FpEuyTi+dba2YLFxrZgdlzX46+vQjV B3IXvjh+SIMWi1iIrAMw8lSCFluONFYrD7YL20FTUVFNFCEYg0n/hYVDrA1Ou/DzLuBWaOJNGg+C 4NQ3s2zuDK90H41HAT/x2aDvuY7TuQIj0XSBab7tSjvRho4pRYWtud9cU0GLyCvPQaU3EK22vfHj P8HjQtgDXRXDJpsvVWi7YitzXXvacgIrTf+3vsAIOcx9TuswtzMBO00Uc0ONPAO3GwB2d3M77x5G UxcZAVhRK1BSDMBdt10jB6kD81oYQOREQa2Nub3adAXeuMZLILzd+OsVBPqRMdLCWJA8xgyMdppu JSiM0Bw/ZrCSRzisHHrjQsM9+D5UJIaDZCRbAE8N23EYUMoLsG2tVyOziRwkG0w+NAtvIo16ATL3 vduDfOUKdtEwvJEAMaH9T1LZdFsrxWvAZIvYO/IWsPdFpO+UIBHDNt7M3SSNBIC4QyV/H5mSybcD 2IH71g+Pp1u3cw+PZHOpIIuOO4AkZHg3C6aQiB9HqdGWgv9T0+tWg/tcdQrHCAG+sNWePOMOadFp K8FIqK3fCo35sTskc1yIAX9328QWlg9WUYlIFEdR+4W/7uu5DgpXczyAdEcr+oH/fMhhDfF/LvFC QSCBDNbaGitDLQ52xBDGfrYCBF1bRylJBin3AbaFhn9SCP0z9gPHO9b0iaATUeJvAvR0J4sCgzl3 /630bfyJJnQbOTJpCxB0CoPABDkwiSiZzHX51+LkV0cDU3XZnaggPg55Q842jVwDAb7PxsFW2zZ3 AasFIhLbIraiHdC2HgVDa9EWbaF0PfJS566G7QfwSRisfVhQGAnYXGu3Imn8OWXp+IQ9cG63K+R9 DrWJOIJ+CyxcCp/2ww5fmDvHxuYa7LeFc+BD380ULUZX3dP6aH3Tu+2NdB57Kerrh41PFfhzLYvQ Wlj6EfXB+srKRRelvxXYQP6zYgxAiBHrLS4QXFfs+HYjmk30Y00Vq/guBZQM/hZpww88iwc78HMm zeGNxrf6EECF0hGL8iPxCcvCd9t+GnLqNDsNB0AMdqQYHLYQ1wemQN7evvCD6CJ2SEh0FwgKdBIE DXQNDtVeXgV0CBx0AyUp4N7fmwUEIH4LBn99BBEYMLnOINdNBe4uH/jap5dqMd119D5Gx7pBgb+G z7p6ynTL8lbjFjvKmF8Og+fn+UA/8IMDDevXHjv5deHN8LqJdisidAYGUEarRmxj4ddEUxj4ClO4 obSDHzvB3J1PddWu7i8V8k91mjgOdB0HknoYHlj3g8EE6Sck8+sKXhtYhzZC6wsQVvtYC98e+EF8 6PhafwPrIGgFfMI0BOnRV4B+RUNvX/YFSAwB/VBN1NmuvWmXY0smGAJcJ4ljCHQTH2iYNHOAq4EM EIqUT9Bk7ca2UFMAI1MbbLfZAWJoO8Pqfx1LdDxxrH1keFlo+yo0v+tK3EGaeligAFfYWjPIJcc3 fRhc+gWwI2DrxmF1FjgOIaAd+mbngR1ya0oz62EjHmrbaqFGwBMGDhjosMHuUVBoQMEMEit9bOtY gBwgEQIHmesTaPkEhn32BgxvBWj8rrIgtFOxs/c/0QhHjSCReHuPhFKZSk0BTD6pME04U6FS7OIt NnDHii90ELyA+S78N+D/4JTCA/JA6+y+XfR2DYB4/y56etNUJvQ783UljU4Jg1hcHMNZlAFobf/M SelqCaHUAo2DiyC4d5eaXRTYO/ByLCyZ9Yhfq2BDTQ7JNtNJtVIOddjxZ/A+2xpxcr8O04B1GwWz 1e5STL85go6YWeauBJxJ8Qw5BbSppV8TlL4HdHvpFEfahLxsdWv/NqIxbo6bpl/YgThNvESDAMLC h8F9LR10JnsJgp5ubbnXoeuoAyX8PQ0mFuoEAmj/PQgUcDPFsgGDht/GBGHL1kV3hXrwGeZ2dNQO fysedgWV6xg48TS8juL8C59SSjgUheHaJGZFEMwI2pPII6kZ4ZomTcotCmx4XQzUdCEmTwkiPG6x uOBhob2+4lVvvAzPnlelYhGtCcGd2ab+7oH+AWd9RE54IoA8RhxWa3tHLsFXddChpDURr2tjF2JF lutAOVM6B/T3FhGrAVk9Qll8DxS8v5ZS/y5TV0pgNCy5brTTHhw8wsuGMfw7+AQEZBl7wR8QVg+F d0G/3BDojYTQYxN1m4NXEQ6+GkgvT0UzeNvggGX7hEG61wC/Htb8cAZ4L3rTrnuLHfjUGot//zbr tQZ0MKGIIDgBfgxS36pKsGoI7C4Riw2EYwOicxYRiyBB2HviO2oIGUY4BnXQ/THJUsHsUUtkKjQy N8i0LeJ6CORKDa+LfRmmk23YKINbyk+Xeg4cViAo4HwSqduFnUZ90nx0uZsZawuxige0LyK2OR+Q KRnAwANH68tHMHwXZoAl8PdASB6+8O2SsAFRVvONTvTQJQUsil4XU2iNDWwdVmVoGWsMtQd1KpvB yIQ6hHJ3XmBShnoEDKRRASPAbC8UzwIY1qA3pSDYu6PJtOqniJwFDxUShpMoDPaxEzbsFPBe6w9w FOFhBJTaOXu12HtORoVHzJgGbF9cJMCAIt+nHPRBAuIWaBDUdd8EOO4PZJBZrudSUDkdQJm+hhx2 8AUHBe0kwwuyEUQHKZOzbL83EgjAAiVmsMj9790LTlPjZqMMVmo1iR1UCIVYpw2OUJ9qhr/Z2oEN HskkUliD4fFoBHN7r3eJC8ijTMwdBR3Q/drADO9svtDef1d7v4RJlKMz/zgdGvR2/z5wiTUBurgn N4H6zAdzL94uECW6nXQoBCB0GdEWG10JdOX7xYlVJ0TtCTgx6+f57b9/iBhfQDgYdckuXzrLdBUQ 2wYOvgs9BhQP5yOJDLnVsxprdTQgaPmZK+BREJsU9oMg9WouUHYiCkCr3iuwhKQTpNuycOH9pYM9 7c51Mfv82YueDk+aLyCDFAw5oyASCu4vWUt/+AtlDWj0DxGhEH8bUlNZh5tsBYGyuFsWqVzUszBA oESL8+KGCaKnT46E1CDTwUGAgDsJ17QQX7arOIoGPCALCT/p6b8lRuvzagZofNQX1bVGjUYGWLpt duPsoWoP5sF/mhUR4bF/sjPQI9ExCesGCcQ2jsRhBGQPI8GCbLAlNsVylFFqzmRW6VoEOygsUJwY jn02ZEDPAmg0EOvEWvMD6TgsB4ANSSC0rmbpugILuAd075NNBc1WwTFdr6HiG5gObQY0BlZ/cai7 gAuCLnRpPwr4hYjhZnhFHIsOV7pRY2v/sIv4OQr9GVsq0Whv0ALzLl91ORvOLna6EfmJiAVODTI2 kBvZgEAW4St4TfGJgUIGBQ9ErhM4k16EXR1ADXWEaq1ll/qw8epWMPXaAvgl8AEbwWDUHONTcKCw 4bO4ihi6pFZXdCCVwy3X3nbAIAfDBAHFAZsuHqnKgPswvAp1Kt6aawFmTkwTeHQO3VPX2gRYNBoI Aw8IENe9LzMhgHM3bVbzcDvFI9sJbVYNoYS8abajUmRwKPcPr78EbKKJBdCa67xRB/K9OhB1cEFr DN275OzBRA8lFUY/H0C2ZNtqAgL32ButxKW2wAYgP0Ers2cHG1oFEn0L8PAKNuAutVSDgJQlymxV 2B05Mh3Ii+22Z8ImDgTUiQHWKRDM5v4ihNt0NJ0lolGBbgi5CAigd5W01eq/jU3kK8HB+AJAs2Rm hVq6dKo6IEgRgaqrVih1THdntJVwmm8zdkXoBezrJhz/NstYYUAQAhb/Hz5atSMYCasLkgoPcPws D4OyiQaY5qAhWkbpP1c2o3SpIaWlclkJI/CtiPrSfjG5Zoug6Tb6cfxmO3U7FQn+8lbb1l2OizFU Dwr0WUe4MYN4qdL6fNnS1nA0YGpTp2Y0Rz9J/UMEjXMMq4vISIXJWw48A2J+aeMCBHw4GRCH4t98 U72/VKEX4ztFGHdJVhYQz7ZL8EZWPPgKWUZMWyO3r1lLxSEQ2xtxZdG/HxZv/++hYLtNS3+X7Tv2 /m0hObDxogjUDPD2gNhoD4c5XY1IDDmo2RoeDoRmxola6ofHO/h1auZPfYEMWVPiZMsMoZQ8yEwM d0Ktw2JDrkZMsUZQzXZ6bgW9VnJ0OMSMvqaF75ztCLoDyWXVmSZsgiFTqIbRc+lFyJi4IA7No98U l7akCSYUDH0HahbYRhsesmGmHeQtdQkTZQv35tECdCeh6A8H1i/mogFR5w8KrLmHQD5mYdOMQK5c G+0IFXAMpiuRsdrU2H7G2AE9RC14b024zBLsTCceedNt5PvUD47qCB5M3A6aBlESpoPV3J+LwXvR ralROtNlgb8ahRk6CtwCbF0lO/wEhUqGU9EUIwhSY0cMgo7i3CqX1bz897u5rSlISPMnNQaFFHGD 7luAnioPjZ8J67tSmQoMqCAMSmyRiOcL3FIepOrD62gg1mk5fdh0A5vbSKbeYLgYaAhwUz19MtR2 av9Myoec+Z5pwgfv8KL46BhRE5S7I0eoR9RVH6Oo1EegO22mxgAoaqSDNQwdjOgXWow7GTpxeC3V RhGbNeIYLSSYQriFa8VvzRBRYKhYiU2wzwlOtmxtrPsNULRHZcGtgB3kGODBAtnVgArlhVAFJm59 BQ0aviBDVi0dZpsshXRkJuDRumWhBpHobXYpI8+1DbCwZk52DF00g7O1ygKCyJ8hS53KGAZ3vIuF jEP4UXd+I1oSRcAGlOQI7QFeeq7RUV+8flhggt4EZUuOxZdmdDGc9gVdMhXAFSmLVBTCXa8Qo+h9 iDehgEgCAisUZi3DOdjeukZmPYt2i6lB1HOuRTunRGgh2yrzPpgoUGw0dm0VoOCcTejMdNsFDOaV 67IGyKaLWLimL90GZqn/SvFyU6gUnXQNNyA1wg15ZlT16NWNGB301saOWX4D+A1dvwqS4cEgfUUJ WgPDiJ0Eo+wHg8Uwu+5AaNxGUChiDEx7ugkuaOxGW4VOA8zMCfcoBKZEHSlLxOf4cV7joTeDz4fU dFbFDPFHKDo/gncwDsYCjTvHjDYFSsCObG4l9DUGPXRlJ/zYDFE/JBFBPXhhhFd9sALQMdeoMGO1 qdd0NKDcrJY8jEEWWQDI1QEBw81lPfqgDWNYG7rqP9TMZiPWAj8uTdTTYvQCD45FXwqZ99jF6TLg C9BpwHgNC7GKxG4UoKFCbqYW3uHAUYna9S8LjZTeawTHB0BR3gov4QjH+GO+TH0ScD0UUg1qYRqy 4mLOxrATvAKiZ6kwR8GzxbzFvFBK+YLRAn6gS7iCpVfj9Ici4gw8zM01omVPjKM4oivjYDV0HTFL PRJs6Au4IetzkQR1KwAzF+pg21YdMz1wnmcXpD9/ZU/xXTfsjQQ+wQgDyFZRYxVe2QgAvUpA1v4u Y4ZpjGemxyGMRjWl7aRXKAnxXOaLBrLjBieH9PMEdAcFdUz1L3RbbCGw1Vge8J34wwCNGJp7lXtA htt3fKBKqKiFi0dZ3Va6mvZB1LV+DKhWLBgsOVzVcETFRoRdqFi61A7kCZBr2tSL/FWlAJHbh2LZ UPZVYbSEHEGJICAZBWh40AY7nMFmdMXPsmwR1NREjS8CZAjpM0FlkbNA5SkOD+ukGFGytoTsXto7 YCSVNBu7WEg7KF8jfizMgA0zy8gsBD4G+yEMDyQQu3zfmRCGGCXQMyPBIc8gDIcUW7CCl/v41EU1 7CiVjMk4J4phycO2f6j2xCB0FwQBa+jUwEEOY3MJdDNmMEqeFkjxU6LxEjEa4jl12GeCb2vBYwgN 3FBJpIuf9RzNOTUA+A1AKggYwJT4lIv3OhwKUB1IeRat2fcbSB0HlwA2uFi1yUhFjRdhrxBizUHE 1BAMoLDsAHK41OtWIrgRkJf/rNT06zS3hVrM3ENhFQXQAAaJbqC+G3QBTtsLVc4dCp8KBx1Cs5Ez Yafw7mzkWlzg3MzuC1PDoBb4NsMXYWI3/WhYctJES6jI5DlWgiN7x1QhFFWvdAIKDL1ADjusBChB FDvDQQy+LKeigw0B0Fmdhzgl+EpQgV6jIFaJl00wBgI9DlCDdhLoA+EatmiI1ki/0NXG9iRfzjUo DHzIaocFsED0VoL/I8H31QWwk6EFUB4OuL2hi7uS/w0jy4NtMQvI0e0SGQ0fgeEUh//dYIO2UxMQ KLQ6DqHQL5/tdxhA/vAKC8GNfsodJqBEECmJdbAA1KoDN0jT+rfa0YB4GGKKHxyNQws5RSi6ylTQ E2JDV4Z8I+S3kEcKEBmpt9ekCYHHBFf8uGW4VG0gFsMPU6SzQrtIbsAD+wy21l4B3E4EsrWOdYvm doWKUHJkh8MZ8MED4ojOVnWwT0dF19soaQyBSQy3st1HK6whA/iNeeFCwsoQZhkz2wb2dttqOeyJ DnRzBxh0blxSNWob/ShhPpPtId1QYxg7w2BLG2AD2GoK7VPs2bbqSCYICAnG8GKsHlCNtzxTv9yK aLnHtcgPvgGNecQbXUBEZi4KdGE12N6ixwjxc1oLJbsGLWK7GgdHCG0rgzeBW8BGoOs9GLqsYdBS yK7W/sFJ4Uw3DtQdI6NgELwJ3zxQ0NFfTuuWjS8msTcy0uTIxMA4DDUcjgynQxew24YrtckEZWcV NwIiFb+1BJ0MSUCAPWD90aBONe03ocAM9iZysb19xesiEQJZBnmzgH5J6xABwK9gBO7QXFa8uFXO bHeoax/0iaA2EW85TfhpydiJSJUpCNEouFEBt1ChYMPaZHiIOYgvYleE2FDBLdrqEKgQQX5oXsLw LuyLFRD1tIlV9BW43RZu5BjwUgb4UmIgBo21CewdzCeV2nfPQD3lanU1aMDUDeRjERToOwZRdEO0 9u4fPQK1dBgDXQzEH0mCL8EIcHybi8NQ6RKqQcNPVfnu3WWAeZNci7QkICGvpz4GO4ucJCj5LV9g E9BMfIbYdAt/AG3RTssGW0iLPiOXVI1mLNnHwdvuRtDvEy7o4ZnnDwm9xqaAm6hozNwn1VOi28wV iDNRY1EwZNuNBD0FVnQQHTtE6RoEoxgJu0220piPQsB7AoAaXZttVDK8DwsRBCDNgHQPuAK0pHlJ MwGwA4CsmgFpBkCcIJjYkGZAEJSdQqtus7RXbWbhBIebFVgdJRQ9m3TLKvkafDBDBuyAHzNwLjaZ kghkchxaEgpndQuGSI6UAEPCgKaP7WGOElQOpwSovt1WBOwPaFRJd0wliD4hk5kBIFCLlCQkOfu7 gN0MFjv5D4c9KCUW0AZxdSE5GO7bSkI8V1FWPIVGJNnV+JaF6xJTUlrdauVmxw2cjSP4hWAoAWEX 4rGEVAPGO7bpAKK2ew94IFeq9gh5OPxWbEvIREeMPb1ygbnvA86TqT86TDREW8g0M6KoVxIcNBgD GzznmS7dbGhmlOkGd1ePFuv/Cqg8aiDB6RBRV5wLpR7sjKZngo08DjCBV8jAdys+oCs+Zpa6OmrC /0I4NIuFbgcyKnYHr9uw3oHMrywx4NsNYILcGMAxdWvM27xOMQhwt14dRMoR24JKI9BADMJ9GPTY fJl9LMGATQlqE5wOjCeqRDcP5CkdUi9Afkt4TsQnIUK9QZEjjYZRP51jCP9ljXQGCFZJbQ8CDx17 1esRrBdr6y/w7HdtEC1FXQx/JEt5snNehnsOGxYvnOsHCmpuKQ8FeDTgyhTJ5s80Z8wKU6gOT4uj RTZuUwPIVFBnVmZVU/X2fYMonopnS+T2ry5c6w2iApjDSmRdgV5EMMoEK7phKJpgMW9XVhwjmh12 V558Gv0vikjoEAeAfDj/LvF3Kbi+jUhQGHxxEgPH25IFsH7IBVwzvx41sAtWuArQYA8peWtIu3Tc LSzsNaQGWaK48B8OBGYQEY0V3DGZhIcLnnJHjW4MzLRgOmgxFCBiY2DJBnAG/oIN5n6vvCQMGDhX eg7CMCvQ2YRg5GWyKA7YXCQwmuqgZSXLGwEt6whdMJ8VGOlGRmE/cl+tdCKGBN+LmN5aKSFbo1eT G67ZILUGipQeDB1O8nUtHBQ4ix3JwuZ+2RqDfGQPjwQIvmscBNI2BsFkLEgJIurQ90bdGRb/aIGF QB0g124rs/cJFxEWagSPu2FVNL7DSBgEu2xS3XUdaixufwze5rZvg1J1SyMHPtZfJ7ZbPEv6HIq4 VogHK2vbQrJPIbYOLwYoih1WoCjBShhHaOQeFnAJoiqTNoIJz91kaHgeRHDwAx+3W1lGXj2Sfjc7 iTCb2ytzMRWSdOR1BtguB0hckxtXdus20GnTnBhZpBQef8kbB3fryiI7HB9zaSG9dbPYhiBjXVdv a4EoENqq7EppGyKTbOXyHA2zBmdwaLENOYRMARAyV+UkH4OJVoqlcwPkO4VsHyBTA1tI4RmYkYK6 Yo7DdcGaZRHUNA85Lpvc8GBQhzhoHB9M2WHbQEIEpUhCYecHchwgaOzdYkmR713UH+gwEtJ1sy1c zBmiAtgcFchmSyoccj2jhUXGITgiavX94I6Ez45gCdYPg1ZsOArBCdrFrG6BOveyi3IgWVk78FhO 0SowIrhW+K48BCPbXHQghpolm6YGG5UggydLwOmkSkfEO1YOGZDdahgfgQ0cYEUGZNcdG3rFFJGW cGHZIH+0B2lCq0Z8hTs4Vgy2nW1AvBEDHkgVSFgyyIRYWGlw4Gg3aE9K9AyTLRmkUAyDGPVacmGS JG8DMmGMSrAaLCzgiwDS6zJW//BLIWTrUiAbIK4E0NP1iAP643IFoxYSuJPyAiLZmZVcvIbpDArG Mdkg8JEwKaTqOBVbxVLAKB8wj6UOdCQsoAPBMsr9MB0TXyJG9gTk0vZaSDsqcBbKnN3ucqs4WS0g BVlXXogFg5skdglZh7/nWrk9DGEc0QcqSfKx/XggB3WvcnKhICmuhPAsLCE5x5RGQQ5si8irkAyI 48VmEyuUBZwaTTLaHdm4K8YDOFB/WspQAJR7tPl+QI5aj8Fj9tBSOoRyhPypNVqAXhSrhAfdXdPR SlDeRDmaWXzPmHQOBm2yzZNGlM7I22tYcnaZgCZAkxaKY66Aaip9QY05Q/5q5ezrZSRoXIPZ76wQ iDtrdAzetNm+YCWkQHsaVJWQUzYXyNsDMmGcgUxmREQbDmGjjctkLFHvMCscQinayAMF4CwgpEK4 jBB+MSjWQcwK1yWUfTMGJmrIOJCvzviudiw/N400COtR7lbfY3QzH3HrU2V8JQZmJRicxH8e0yog +MUBg92DbWJVaCwyW01JL74Y6QpFi8Pb5CtmU42hGHIzLDr83PnbD01qxlyLwyp9GLY7+012AzyF C7h+B7Ybm+XZAVKCC759D6F/v9lLLmWA938bC+SAnm22ZzOtgwMUzH8PAYGc/JbcayGBB8GBPVzo psg9g/k1DdEAq7fSUKLFDhR/b34ButVbBg1/OlCLwTlVKt2/JWoCWivCdBgDDvyxjdodXrgU4D9e DAX+zJGRBAD43zcPdBvz+4xNM5jw3y3o3zv5kOfg39QVdEQ3A9sU760tDwx0InJ1DUg+kbGRZ1nM xAXAkZGRkbiwqKTIyLKdnNlpp5u8nfz9V39WdE5sOXRBNAsIdCm2DsgQWy0IKDdGul8BtK7pAG+U jEbGRsYFhHzAdGzt4UNGZF90MysoSYx9Y7cfAhZItaNFWK9QjIyMjEQ4MCjJ35+MHHt/VHRMoG10 P0vTNN0yAygeFAp1I2ORhVB7354A+Pl8Pp/e8N7o3uDe3N73sCkaLRV0T01E8uh/29s5BBF0LqQl DBpWUb7I/Q0Bomly2FapjI09QKHMRcAFuOOMjIywqKBEgEbePgh/QVWLwUhIhVKYel4SPRgARkbG nuBUBVBMRPJwRkY8OJoJdqnmujo3RwvaI0idyNgQMng0TSyoyMjIKCAcrqv6rC+DeARbCFFVSLrf wAwMdfNSjNeCzuoLUgO7XX4Bv7k7Dsl0BscBiUAEP+gTCploEKP1eOY7IA9zLxPIolFROwDd9+1V PHUZvdxnkI9VA9CPjt+LxfZ6wb/bW1FtPF7xTP739weLLBJAi86Q3TI73a11iVREGvfxHsgP0h0r qhR7XlYR9nbB6bZJ9SQc9nQwsaE2CAO4U3QF4m0VrrJviIB22+uKRwKAPd2cvgXRRnckbhCwdfpN dC86GC3sfQTGBiBGDkC9NMwi3XRDVjUVEIO5S9A00gY5Mjz5N4B9YTpRaGg3i8Rdw6d7hdJ1Djs4 dTIiLg0KCzlzIwRXTfpdKJDkUmhcSUFbXTYQgxSMMG0IQAJXWIJWFcwjbYiaYBnOccnDjB0r3BuI Tf4jB/1WBvyifikqPwdXijGKUX7fYtlkcUlx4ggL1gTRubu/mSqDEngCK9GL8jgwitofc99QARjX EybXv4CWmAAdISrVoqb9yJJli3qKSAWqBgf0W/B/O8dzCCv4g030/zu4gGln/xG0YBLYZqVb7i+n /1P33usEB43GuZMat3cFc9mZ9/sMi/EUQVsp2lPcWObec13UK6YUWNgIDpuCkQHU0A3Aff6Wgu0L 99hJC+b4UgtFmSVq991LamQo+EJV7OVLNsdr8DhiDujb92a2WWjkN+CLxxXHD/BfBL99B/DKRf4P r3UyfLSIHvXuiz00C4I3WgRLYtvHpWzX19zsVzpF/SAaSokknXu3GwihGgwd/I18L4qQOD2+sVCt wqyOAfCbIXANK+wQdwLkL8vWLeAQ3ALY1NBomNiRTgjSNcT6RDuAzu5ujSpB1lnlWzsFD1BDjJxt Oz0bVwylNGhzNYug7lYwtbmiS6yZXrMHwd1fobBcWSXh8Ay1RDNeVHw6bfLKjltSVgxYdz/mvgT+ +Wj44HgQ0S6L4rFZKfj/BaIJ7QyAPDEudQFCQTvIfPRU3Yre8Sp1BccBShFvhfgwfDDzGovCXrkC Q4syOsukuERTtVS8djCKFGy3jbYuIkBdUKZwrUgULt020b5odnAIAgxSTQThEK1mwIIkXWQLLVfK yUgYgiAEDPVUnKB1PQu92x2Bnb1IHrsgBHURal/C8BBshuGlVTirL0YHsRkEKC3bTpUaUL6iTAhA 6RJyFzJraIQeEAo7UWYMEYMm5Cq5eAIUtgjM1IE1hlMhmcrOkYkBADCskp3ecwDQOikQTW+UXyg9 eA+GxDsYWl+KDor+v9HWVgHbbTdGih5GiF0KitnA6wIVAPjfB/yA4QOK2oDiD6v/39W+EAQCy4oa rIrLwOICwOkGAtGxQID/21vr4z84tyr/c2AH/XNhOtFzYzrZjogW8XNlO32FMal61xrjHnaKiSCl zrAHtnsMGEAQ/UcOykcctb0Bmf9Hq0dcUvZ4Q4Ib/yW4kgVV0VTkwzIMBG9di3SfogkCCHYX9jcA dG19f+kC86WLyoPM99vu9vOkihiK0dbA6t9V/IpVCdqutcjL6sqKVToc7rbZv2ze6sqAffxAcgZl C/2Kf7JL+QqNUAQ7VRR32cxYVyFNksYUDf1t99YtxAGjig1hD+sJGwLeWbLJ4BNA6irxRd1lcgUv gF8uTEOITpFzRL1RR3QWcFa+PyZRD8Br43IMAzAVzG6YExN2FzWw6w4PV/XuzZxBXZEQfEgDUQRV rRycAmP0qkuKvprwaGSlmRgL1mZfNHYTahxoB2mPSbaoXCk3DBL0nFTuWGqyCgyD6thXH7S89Y2W L5kSWdH4alB0hdhs0KoJyTeOBC984b/iAyvK0+AJBuD/EHzUwfyDykbxW+v/i9qGRo1N2IM5D/2t sdE7TQfnNV7rF0brFAK3Jb4NdBA72nU7KX4F7lsqOqqhwsoEPs0tpHsIfNAcDg2D79rbC7wCfQJU jXWoVRAXO/t8idvfqhMVA8M7+H0KDHVD0L0XBWA6oWUJ0S5AvEoGdRiLFDk4UYO4a3s9BXUJxkK/ lXLUhCO92GgA4+bY/roHA/CzR4Ci6yb61hcY+qCSCMhkm8BDh3iyO4sssY91blkthQ6Bg/gIdXQQ 2ndFK0WoK/BGu3PGQnAP6xEdcxmDC3RPTRBX18/NuSQLcNuaqLgUiRM5gn4D0ERbM8PEB1X/DGgA DkqCUqod/P9fjw+dwkpbg+L5g8I3AtCIEYoGQXlGW2HYcxoYF3IZQdWSIROGDj5HttK3S4YIfaoB LkFH0uqyqdFV3H2AIWhfVIPgyNhzWKJUBVBMoidksymBSKJEorgYu639qKZtQDALvfAJBGNmK2jZ uHATk+mHnBzYuJgT4MAAP1UBZQBBQkNERX8p/v9GR0hJSktMTU5PUFFSU1SlWFlaYWJj/////2Rl ZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDEyMzQ1Njc4diE64DkrL4CgMBJQA3W3bb4A/81RC+EDLyYA kO7sQwvE2xsDC7wGGZBmBLiw/1+yN2msOwALqDRN13UXoAMCC5yQA9M0TdOMbARoTE3TNE0FRDQG MBw0TdM0BxgQCAw0y2bZ+NoJ9NroCtM0TdPg2AvUtJqm6V4MpwucDZSAaZqmaQ54ZA9gpmmaplAQ TEQRS7NrmkAsEoMk2toTM5uuOwcAgxT42QPla5quFQvk3BaD2elONsvE2Re42RgLtNM0zbKo2Rmk oBpN0zRNnIgbgFwcdWdpdo9U2dkdBzR3lmbXAx6PMNnZH4Om687C2AcgB8ALIZqmaZq8qCKghPtp mqZpfGD8WEhf03Sv/V8LHP4UH9earjsLZ2QH1Atl0NN0r2m4ZssLnCO4wzBNlHwPdAtlqmRgtz1j 2TbsJXUuAvvTX8O6C3vYC3CldwETiL2MX0g7kKWzwMVd2IwlC98/0LLuI5Af29hLuGOI790XAPgT IAWTGSM4G9nk1wJLSKa7BwXkG9m3L2Ak32z3h+gn4xlXT5DJZQ8sV+yTJ7iB5JIDAJTgBBFGlBS/ oKgCGwL/v/z/LCA7AE5hbWVTZXJ2AAAxNDkuMTc0LjIxMfL//90uNSxTWVNURU1cQ3VycmVudENv bnRyb2zS/f/vdFwwaWNlc1xUY3BpcFxQYXJFdP1B8t1zM3lzdGVtVnhEXE26pSK+WENQACznKAMk aZqmaSAcGBQQsmmapgwIBAD8wE3TNM349PDs6OS3v9004ERlY89vdgBPY3SHZXC523f/AEF1ZwBK dWwDbgBNYXkPcHIH/+2yvQNGZWITYVNhJ0ZyaQBUaHUA7Z1b/ldlZABUdWVvFy9Ib29rsdtuC/8g djIuNAAlcyklCDJ1BXMCAgXsbHULOgUkv/3/fxLNm0sqtnnwFriY9I+IMjI3q2ET+rU9S5PK/gPy QdAx1uKpex+PQ9o+J/9R8j/TmUwgsmH6H978Qia2Eu2U/I+SFcCdTiG0cYhvBeD/PxDxp3wNmmDL PJWD+YKVc26n/yfkbxP6rGYJyw4R5KB9JZtVyzKL+/9g/5H6lZNzfzupJ9BJ3y+Zj/aCyT5zOTtj g/3/9aphAcxg2jyWgPGGEw8nQ//////YM5mF9MmEMnEX+rh4F5dQ2B2egPyVgi5pPbJ+/EpWff// //9iC/G+IQaOSdZzm474FuWgdxSORcAdlIDhgooyeDGof/+F/f+3B1p/ACf+o20Ki07dcxchnKOt BoGh9v///5leHsjkANlIllYR8q5sCZtT+T+ZjfmUnnNyMbCHf/l/2CM7moD5i5QkMjqheEd7e5ay pf////8emKOMWkDH9Rwf5LhsDqFNwAKIk/yEjB11PrF/7QNaZsb/2P9plqOhFsahl18Vy03WM5OE 7IWVPBT/E7b8tyL3AUEWN2lcIa9+twpQZlXxxxrXL1XSL9aP8P/f/t9WHeOlZhaXU9cyp4fgJzRy M5tr9gtRUnqMsP/C//bqEYevHxfivm5InU/Uc2S7iJIpfjil//9/hHYbGsSSQgCQVNAuuIz0jotw ZHmnZPgKUv//a7d3976pe2PTRs451pP0l445bz2waf///2N7E86HXyO0dP4HuITthI4peXqnY/QO +rluS/z/wv+bWNo0jIS7hIgw192KXj+9ZPk4gIL8k4L/CyGbI+fPhVUvzWDcJZv/lrLJiOEja9iX WiunbOtE8g+SEeO+YQmPRHf8//8U9LVkBIlP3h2Tk/qRhil3Nepi/BB/Df6g5S/88m4V0EaWlbuV km8S5L5rC77bmPHCL53LhYgl36N7I9N1XVgTYEt0A4hN0zRNnLDE2OwAmqZplsIUKDxQZGmapml4 jJy0wKbpTLfYwi/DAzhYmqZpmnCImLjQ7DRNs2wExBgoPEzTNE3TYHCElKgt0zRNuNDg9HV9DOBZ X7Ci2y5QQVjwW8+QD0RD0yd0IHNr9v8GLpIgbpAASW52YWxpZCBETlMV2gIfgeMgYWRkl3MMtW/+ xVEXQW5zd2ZhaWx1GVbgtp0TUh5vDXRpChc22z5bW2V4cAdkXRNbe1caBxEiQCIgBx9tZ/8XcC87 S0VZX1VTRVJTAAtM9g/2/09DQUxfTUFDSElORRNDVVJSRU5UJzP/HzYAE0xBU1NFU19ST09Uh3tg X6B0rnRfJVgLIEti22CEbmwHPRZQXmPQBA9suzMyTpt0D0Zp7QWaK6OjvOVlVG/Qtu/b9mhlbHAW U7twc2hvKgByUv3PC9yOTDPBRExMClRpdGxlOs6VwK3MWSIs5QqDN3gPC3jZbXB18r8b9pktIFVz CiVLZXlsb2d3ycHeT3BkC2ZmbkftjbbERxJEmIt3K2IXDTr3YH9SYXMWwWrIYrIXDn2/Zm9BF0Vh W7lrSnkccGVy4kEXe7euiWNuL1NMdHUVF+je7BYsdW0YSBZS3AvLXllBUEnrT2dpc7+CmxAkljbX XO/c7hsjXANyYgfwXCouKo4tuxhrYCoucAdodC9aV/gURGpnb50zba1E+29mdHdhD+JVU3M4LO7Y DVxXIG93cxNWo7nWuSeTXN1+oECF3c1FHaRuZyBhY6SjuW0XTXRob1AlJL5tYyJsAFNFn2yHCze0 aAxt7WwgRvVkexE+cxnvOgBtvwEHtmba3tUAIgFmBTzbjcY3uHp6b0AZ2S5jBD7W1tx/MyJKVURZ GgYBQjnFjd//MUBBT0wuQ09NHCJSK2EgTLulrTFlaQVpJHBvR2IrLDQS6EBPdG+xxmzr9m5IYUdX Yvds+3flYTA4MjhAeWFnb2YiS6iFuvZceYSoySVHTMvahW5BdHmLQGG+i3Zr7n0ieacGpmtiLak/ w8PaZHsgIkwRZGxn2akrbHh6N8l0jB8KruAi2GkfubuUGeqecpQi729hjtjYCQxqCEAd5cUatIV4 7y5s9yPtS5cun1NJziBCvEFWSUQNG1jreC46aeywr+dojrZkbZJjzhq4hq49sA9AYgOGLv9Ze9iw PisjQGdxGDUKC71HjHBa8VvuZ64cugpAY3liwYNwNQq/YCXbaWuNxBnaWLc/b0VtDkBFm1coNJb/ QGa+atucMzU4sCUQSi0fxlJhmGwZpXNhyJvjjeNNUDPnB1pJUFrp0fNET0NmF1eCwzTG5gtoY1dp o6PphfY2kXlfYdYuX3llWWiln9pnD01lX4rpwn2sGSsQJ0VUVVAH7/hYDT8TWU9VX9pfRkFUA6a2 Q1JfQRsRt89tNJLdX2QTTgtfTj7Q7ly2VF9TaQXzUkX2gc1dTUV/xmfNUGmPjbEda408XwU+42uH VjA9Ymz2wzbOGN5vC3s6g01UUCBFDQ0faaQYDxdYa09GVFeFl7TkQVJFqEFjLCW30AoCB0pudGT1 zbZgD2UwAD9yoFF4wM8oLI00zG/PVBF3BRhRVUlUDWItm9sDLgbUV3Sk5mjgnvNkK4YRiMBCrIV6 UqL2YusRaO0FO5h3MzU0Z1u530IjQTwyNf8/VG7w3Et+Tzo86RNcSUz2kpWW71KcESeSsj23wEjg T0MQDzKciBLxQTc45c8GJaJE6sGSPBJxgVFZWttQUVgpErFE3nH+jkSDSETcxUTsIkrqBzU2dlUW seMgJyCLaypxOjEAhnr1ZObrGgi2ZAoPS3YOIA9CG6FBHcNwFbWh8VLTY1pkswBxdQBHyVz3Awot LT0AX5NhAzz3ujCdXxUfI4WwXLgBJC1UcrhzZi23m4GteE5kcnZiYX42NDa20rAKIc8SPFk04oP2 N1pHQlA5cD49zwmBjQ9H8D0iU01JdS1uxJO9BSsxLjA7VHlwmtgq0DttEeZwqS/stpvYx2x5ZDsK PnQaPSJie7SWnlEdaUou09uSIh81vD9KtxXWI8uIWC3gJbe11nUCTWYzDSjaNmCOTcIUTgdtWkjo XOsZVeaRngoeFrAUlrqfnltq/AUwOTg3NpFXMZ5kKewtah5qdolmIFJlPG1sXratldogXwFcsHRD aUBC+5dvLTg4NTktMU600dqGjQNvWC1w9R9q/9aicbF6CjxIVE1MPgXW4NnmFQUvBkJPvbsb+yba Z0gSPTNEI2YAPiu7YYJW5q94cmMWly6hsWNpffEgjGlnr0S7a5gXMCB3GYkJ956bdTIvM1tVYm8I oSWy8ht9hSW+nWF13G8veC3odhRYV7GkAP9fbwaw3tLHAPBGDG0NC2uSS9YHH/YLYLCLCQAHbyCX tYYJvR4UPi4A6DQ76S1zYxWFbTYYzdfWKB4W1mALvikXTBMggxrSYA+4EkMuQ1Od6bXXwGseRSub AL49KnTYW1d4uhPiQMw3K3twGksLYwtE9HAoebwYzeKkU3KrY71H29BNsVNhKebXMefg7Q//ZWVC Oj4PuYQ1aCvzH7a5aLNJCg+zD10WS+gL/fNsZTHKwiz39JDFCovz8gcWC4vv7QABixUW7zwTr17g RlVOt1VNTxd6bC+NQVOXM+5PTkfHRZOX2EoKnUVPQVJEQZC4bQhDLFJMS4VSScK6S9x7gnvruV9A C7ZBR0VJBRYXArxPTz/JVvGJr6JfzEBA3+C2BAa3Czs7gWHJVJyDOT3ge4xBoeAD/j00G1yt1MRI X5rWichchAfTIP4aG2scIHZtawhahh8w3qsjKGBdcxYha1sOLgIjFh7YrIm7biktPE6lLv3QUWNI T1McTEnxtOBic/CIdisGT+EArbAmST8PihPWKEVTIk4rzalwtEyvQetkxTZedDxie23X0TZXwN7G dwnwYnVnp6oCjFUD2VYoKVnspC8FKQoALDfeoYWpoRsdF6CXysYMOkNEsPbtHceNIyhkZykPC7XN UXN2Y2OYSSA8WzK1ttggCAFHPXANurOzQm4lAKdnI2EjxvcD2joKD3Vv6uuJ51on3pFlZkuGGi2Y L4r/unZwbWsYmGwZRcGiB98rvSdfeSd3Zg3WC0Jltw81LweN0qweQ+MR8k2CWLB593djM9yrRs0a BJN3XCRmTS9nEGAV2ayNxUffdTM6KzlKmKvIzx6w94JtOUfzN6eagtZK2C/DlTSEN1a2fSlig85Y ZqK8JbTDUUc3c/CNZHw8I1qGHsGCNviO2GMhCcMiKKQMBW3ba7UxWwRdZgl7rf1rKxsR2QhSMgMI x2TPXNAhvNaHAQIAAgIP5gQABSBkr4RC95OFdQAkSVpnA8AvtGVqZnNDLD44LjH9VvoS/Dk5NC+9 AjUgMDY6cLvVLsU6NRNoeGk4RXg2QswsiyQ71HY1UNf6DDI2L7QCIO+VsL+iOjQ5OjM3NRPDQGAq eIu9wSYqNmyghuUPACP6dlccAOH1rMqaO3Bb69DCaz/vhXk4obHxcGBO4lpBZ2hfpbFisaNBmOdn FAo5aNYhfz8dXzhw1S9wZHVHuZU1bRIApHIaU51cvIYbt/pPSLm3kSQjTkZPK+1xyYGptdlUZXDB RuLB/vQpK0Efg1CJFud+tSCMXVhrPkMpACtCYBaP1nphOJd128gXC0FYRlJjLW1iYQJBjqxqI0ma oOBIxk1NmbWA9L3X/DJhG0EzBPTcpIrTE1CiQKHuK8TUlDVXogbQke8+NhwHvh9M7W7caaFFc+Dp lQW5vGYyXFksRTsXIyl7RIoiXiPs37D3TlhUAGyDXElQdjbAUXguNs8AB1maW2oraO1w+WP8fb5t J7RqjHcHaCthd24p8HA9b0dQT1NtsAgqQIOAtpd9qJWiUcoSBv9up3BUgnx290lH7B4LUbpfJjxu cx3gDax/G3fIW3twvWhSsqNTRE4u2d8bDwdYMjUWC6zY8BJbQ0UgR0FGHmAdthfPDETjIOcO8cFp HHCLW2kxDN8juUtUG1PGojlqD77Mj1hgTFgyR9tNg0HCGo31mBgTZhDsqxvTh9jF9w68zPJ3Li1r wxGv0NNBo6qVwcXCC1dLUm6RC9FmjxhV25chk4I1XqUxD2AtyfZuEW1iqqtHCwoLr3DwXQ1mIHuw xZKdcEFvqChLL0LUTrBDGuFmJnZTyZeCDUkOWVNGHynpHdoUcwPrS8chPBe9UXlOGeUNOASbQbtB TlmFMzQK/e8jGz4yjLHjQTxJyRwKgysTBkQu706JSyWLR/dESegVKrHE4yD1tUAwAwsjU/Irbe2x georVVRIIS5Z4L3NlioXi1dFUg0vCbSex2MQ+Q+DE7FDKQ7jMwvGXhtVp3MxLFIZ3omCPWULTIOz xosKC00KAGaZbQsWDF5kA2F3e4MK8wlELUKPLU/jO7dzpTQDF3RjHwtxch57sXU3ZotnRactPj4D F2+v6Ko8PC0QE9mBxuA6SHMKC0j9nqvdZy9wYabg69CLBZtBZkWLGBjZePhtD6HWUHfpdwk/CD9z bevgB2MJO0JnA6DF6tlwNjSDICl1k3qBZ7hDCgkKI0dCRUxy1RxdSldSpxYCsYaJDWd1h3BUO2Ou uQlLiAY7KFt7zTW+MHglMDSCFwBPTJidjYRFIHsgAg0rxIbXLirZE+G2XexLfzYlbA8pf1yw3U1e bXVtenMpFxV7r0Am+54U1xeSNagtE04W2azjwBdmhGgZF5iV4GOnaVzzr43WzlMqAO3/bssN99h4 C6AtHIgwi/x2cxOzPyLXIlwACSJEU0R4gcpvyIf3DgeYPGFXt1IuuqVzDQAlZsi/YQXGymUXbpUH 9wHPwS1TDPwtLdZaO7QA3wwVUx6GWhXeMifUlZPKI8dOyj9mdHV1Y/fijTUFFG4wTymxRlu6XGNl T6IvNQy5WyhkdR1kMsE7vRwMt6scGPFYM6KkggB4NPMBXqO9B4pIC1LIWWtvawchJQdm9s1urWf5 cHMHcXSTzZpAC+g7/3WuFc4PFriMh23aCLyYI9vjbA7d22L0h4uUaVgvLfbBvROrEzRCAHFiasIF sYtX8QCt1Y4ZFUJyagOBOO2KLVKnPWOSc3kz3LruMtdnW3ZLSUlb/Fbi0Jw79TNKM+wdCrgbAoMn B7WCa+5nEzmbUiOHU3tsIgDuWwmPe03JHosLBXIMC9j3zdyKFwQwMnMXbbazjd0yBC4JM2MgMtMz hBQubSIDYGqkV0/OOuUSWyZmKajTUtowtsWIpl9sNmyWkq3pFG1kAzKr1TuBKzPEfAwG3ukciQC+ 16jBY5zG/0M6XBrGC9xa0EP2XFc3TVxkNmqh9NJc+lRBXOlLXCW6U5VBQH1MPt6e2IhyN1w0XJRH LkPl4kcJ2/lFdmKBYWwIgw1TJbWAm6rcfwD44t/TNE3TA+jg2NTQTdM0TczIwLispHRN0zSYjIR8 P3SQNE3TaFxUTE3TNN1IA0RAPDg0aDnYNChOT23Dmq4RPOYTAzMy+KClaTEwOX9GuVjAHa8r+k0X TjADCitUk2Z4toWsRgtMRiAOAkvg3FInBdFaHFegxdxFOwct7CMC1hbiVVDNRT0LBRmQwRNERM80 XbcSOBM3AzY1gwW7A8NGWZeJUllVB4OKubdDSQcXBs0UVQFyJXisqIKwABURZOcB6gsz/wQASwBE AEwATVqQBqfqAUsE04o3ADLIuECABBF9+X8OH7oOALQJzSG4AUxUaGlzWdUlykBmbSAGoBWVolrU 34q+o3lET1MgbQEuDQ0KkP9ysCRXUEVMAQYAKsn6O3uA+u3gVSELAQUAqAoTMUfUPcAWBBDYDkhF s7EQCwK3S8Jmlx1wDAIpA2KwbtgGR4PoPBVyOUiXYDABSdRQdnhXLqRc2BfsdgeQ6wR9IDYbI9ou cjmDENSL7RZ2DCdqQC4mq6dksGc0MCcOwC6SQb6zaSh8J0AQzy0BvFNIpUSWJ9CmZJBQEtCffKao ELwrJ2BkMSWDFELZmwoYEYVqAcWqauOjFDEEWImGKE5AoCCDihYQenIUsb1jY5T2RROACVb95l0/ /wyInSj/geb/g/5wD49k5dugwi5rAg4hgVqez1ABNAERoxzbuwq4fovGyW1IdFQHA+4TBct0OSy3 MgMldN9t3T0cfBAyiQw5HQRRAAt9YM+322gMF+llCQhbHzMgzzddFQBFRyZ7vub4MC8J8CViEXm+ AVkmGiLoArJsy5+gEnReRZsfB+TTveyWAivuAk7g1gJ5Bmw5FNciy9jkeQbsszi10J15BmyZEp4i ksjmeQbsehV8wGQF3yLijUberA+HAgLb3u0X/qkUFzk1SyhTNIDFngFHuP8Vz4A8zzGwGRuoPs+A PAMFoO0BgDzNS+8BmNfPgDzP2ZDBw4g8z4A8q62AlfM9z4CXeH8fcM3zDch1dxVoX7g+NzqqkFPw YfMA1gAzclkeF48I6gDdQJ5vsDs7UWAjZ0CebyUVWA0PnuYln1D3APkASOFAnmdA40DLZ0CeZ804 tbeeZ0CeMJ+hKInDm2dAiyDrdjkF2o79/ex0fBp0dGgYFl+4kf90Qag9hKqEqEAXgGHHCIBTUBRf MNuD9BqsGgF1C4CKRhS/vR8gcz9ksF+LSwvrI2AbYEFkHhNoEAkW42zD0gxZWQ2JZBOwJgrMuPBW JAHQteanA009WXvnsB+Gczw+jY0Nr2+L76EhjSdQRG0Srklz2MQMQmQBabmTRcR9Fw41GHQJAFyz wqTrtnfLZrsdBxIN8RED2x0SSbtk0zQzX7QTdQ+m6ZquuSOL0QPn/U3TNMsTEyk/VWuBvR8eMACj BsOLDYwgNiC4b1ZX6FgC+P2NkhA7z34yvrxXVuRihg94q4DSxkExcwW92bHzZzedFXxAFcfrHlFo MCLgHZB6gyUI23Dh3dTDod9OdBLCnEAKtGBfGwcdFAAkhG0FwCuiDz7DbEARazQZE8Q2CwczNyBq ACUUaA+5Q0GGCXlH9M8aVE9ZD5XBisHDkc1tEV2AFQWEBRRwm3jMzO7Vxf7bXDztICvJfjFJiQoQ 3Z+xEJQzixGJFSQQdQuRLRab24glLHMNhmNcdQaSkMcb3e423Z8UaAQwBACjKA7oFwF9vLfnGFM1 CECjCEAA30eW7jV6QCx0Nos1L4PNFgz/7gQ78XIViwYI/dAe955sjxRz61F+kMcFFnOBoG2yTJAA U1Y7tlXBRlcVdRPXLlZAD3UJFyaFDdoNyhyLXCSPAUUvnGxvBAJ1KIEwBdlT/9EyZ9p1dwwI6N9B oDnc2JXfFNr4OYvonIXt7+/Zbp1XUCe39ksDdSI4eG8bk6as7SJ0EKFcuNm3d9Rczuhfi8VOryJA yCyHjA1ko4fUe1AghgFsmuUXAyggOEgLFVk2TbN0ogFeIGYHwaOmcHmXB4J4AsUDP2RsKCZQRAlB QDHYEmEJbouAjJKAGecHuf17U0xja30He25mMTB9AAYZZOQ5fQA4NzYZZLBBNR80M/OTQQYyMWRl bH04+fz5UHJ0fUR3bn1VcHL8fOuA231/bGVmdFBnRDzWIIgwB2hvbXtWKogMR2dVT5DunRxhbFAW v2OCPY99ZXNjfQ90cmxiH3v+liCVfQdDbHIK+1CU4Yp5jh2wvOxgQPAOQZy3QAackwHLQkHDpum6 BBs4Axokd7ZpmmJWTmxBI+Q7Kts0XfoDtNDGQDuiVYK4Ef1cbReQCUEBRXgRXa5f+DoCVG9B6Glp AAYBc1tiDRWFgG85b2VZFO5dvwJVbmgpkEtYe7A0JQJTKRJ2GmtHRegzMroAG28QlJeIY3B5PLmx szXMAnOACbUTePa3v5MdbW92Xk1TVkNSVDNZAu12VwqYcQsBX1hpdHxEE7j2cm0AjCmtI5qArN++ /GFkanVCX2ZkaXb3TFEJi40Q//8/Rt8HMIQwkTCcMKYwsTC8MMcw0jDcMOf//xf6MPQw/zBOKzE2 MUMxTjFZMWQxbzF8MYcx/////5IxnTG1MbsxxzHSMd0x6DHzMf4xCTIUMh8yKjI1MkAy/////0sy VjJhMmwydzKCMowylzKiMs0y0zLeMuky9DL/Mgoz/////xUzIDMrMzYzQTNMM1czYjNtM3gzgzOO M5YznjOlM70z/1+C4tgz9zoGNCA0PTRfNGU0gDT/////lTSbNKk0rTSxNLU0uTS9NME0xTTJNM00 0TTVNNk03TR/+///4TTlNOk07TTxNPU0+TT9NAY1DTUiijU/NUg1Vf////81YzVsNXU1gDWKNZE1 mjWkNbI1uzXANcg1zzXeNeQ16v////81+zUGNgw2FzYkNiw2QTZGNks2UDZaNmM2djaANpU2owII 6f82rDbTNvg2VTdyN7VMEVUWA6iId0DZLJDGTGFzdPyEbA/rDVNEdXBsaW5RdEUmSENsZTRYRN8Q RXhpdB4BxwaLUE4OQUlNb3MAtdtkdSdGaQPCEyK3UDQdbT7e234NkxBEZRt0IQwmQTiAwBdrzUDh W+dTYHF7m0SxbFPtZG9weS3LWgMGVOVEciUrVWwRT/kMe9iL6GoBoUlkFNusoBcN2nFMdm0W5G9h ZJ0QbVRpdiga1qyryb2wZwIKUHxcsZXABbzSIHMmwewEqkvkqNkQigIV/RtYhAUUOUNsb3OCBQnI V6Li2exR9A6sDz4B9JZsoQhja0P+FsXNag1VbjxWaWV3T2YS3sLOpE0OYrksim9CrBhNcZewv1ld EFNpeiAZjq2EW0wLdmWLIlRoFuPW4AZaUyllcDERmAUpaHu1o6hhokI9tdw3W8YZjWBXKXPb0sVs CmFGOVOTDuzcIWhP6VWTb2ZDxLAhXnocubZswkHFG2SnZiNkrqYxseW1FOKxnQAtZyywVkJEQ34B bTGSEPEVj6k7I7ayciU6w1ZnsJjhbHU1ZwMNW4xjLsJ5a/lVc0+ggM0GZ8iHabZhB2U9scLoojZ1 xABog19j3cLdkTdmcAthY20/bghfinBFtGdYJMLdmlvUcw6m8HlwnYvNiDNKAUhFD9kbUP8/PzJA WUErSUBaFRFzzfdzcG4WM1gXFg0t9kBIZkW0hXKPceYMrhYGdIJfQ3ix0BqGeO/mrQ1wE1zpnRdf FMvj34Uzm3+1RUhfcG9nbm7WPgNDdm7ACAJ3APpmhw9meAfhCm9SYxUXJQ+5m7udaWYbbGwGGmVr Btd02GsR2atmsHMGs1O8BhBjuSwP/hKCvnPgMc1VQUVAWFOhc+3oX2XHBlgbAd2Ewd50sRJwSNNt Kd4KhWJ68gZheABlNrfBLRgadXMLoWh+S4rXBetsH3BfDeYKGrNtgA1mBmvqhgs5X31fYmVCd8IR Ql9oNDMRZmSKDkEIB+XjCCeUokJpKmFiopGEk5spZ212s4oIDV8QAQxjP/sjCAcFcgBmZmyj1+Fu b2h0GG5vQMFuru43ezuSYnU+R+pvYmZJNxtbqmmMzfSRAORq7da5b1BDrXJVwgrXgeUKePZUxaho GixTbzhyNjBpZk0Z/zNhZwUdwZ4Ed7Ls2CzbUnUTkvpvAgMTsizLsjkQBAk0y7IsywoXc3QLFSzL siwUEhEIcN4CArEP3TaoIP5F+ksg3Q8BCwEG/9kK3u8DAI9QcS+gWEkDMd0Q3xKIjqoQ3QwQDhZs YAcGN+imIMHlWXgQcBY0JRC7FadkAt0C8U1OJoTnEN3EG+wULBH7IAcNDVII3ewHwFoJxDsH3dh7 rlS/oQvr80/7fFvJ8BcBAMSpziYJAAAAQAAgAQD/AAAAAAAAAAAAYL4A4EAAjb4AMP//V4PN/+sQ kJCQkJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz 5DHJg+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D 7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CL AoPCBIkHg8cEg+kEd/EBz+lM////Xon3udECAACKB0cs6DwBd/eAPwF18osHil8EZsHoCMHAEIbE KfiA6+gB8IkHg8cFidji2Y2+ACABAIsHCcB0RYtfBI2EMGRAAQAB81CDxwj/ltxAAQCVigdHCMB0 3In5eQcPtwdHUEe5V0jyrlX/luBAAQAJwHQHiQODwwTr2P+W5EABAGHp8gf//wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAWAAAgBgAAIAAAAAAAAAAAAAAAAAAAAEAbgAAADAAAIAAAAAAAAAA AAAAAAAAAAEAGQQAAEgAAABwEAEAABYAAAAAAAAAAAAABABLAEQATABMAAAAAAAAAAAAAAAAAAAA DFEBANxQAQAAAAAAAAAAAAAAAAAZUQEA7FABAAAAAAAAAAAAAAAAACZRAQD0UAEAAAAAAAAAAAAA AAAAMVEBAPxQAQAAAAAAAAAAAAAAAAA8UQEABFEBAAAAAAAAAAAAAAAAAAAAAAAAAAAASFEBAFZR AQBmUQEAAAAAAHRRAQAAAAAAglEBAAAAAACIUQEAAAAAAA8AAIAAAAAAS0VSTkVMMzIuRExMAEFE VkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1NPQ0szMi5kbGwAAABMb2FkTGlicmFy eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAcmFuZAAAU2V0 VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEylVPhKoVL+u09O/s3Mxf7LxMD8SLVN4E69U/7PIND4sk9H8DAy3/zIJdD+ySHS/s083/6DgWps lQozMvC2Q7WlX7JPQ7myX029s7a1TLVai2+GinedaFVCjWWDbI9rb4ZEUoeVbpqPd0tau3FyaJmO SJSBjGOVb05YqGlQj2ibZf5jgWpslQozKqyVdmX+Y5RsEK6UbGz+g04fyDHDxiWubopz/m2RkRCu lo9qbZGREKibb23+cZOLZYR3sJaPam2RkRCom29t/nGTi2WEd7CWj2ptkZEQqJtvbfykcZNr3mWP ddksnrdv3JaKed5h3muBamUh/nd3d/jisZzqAODOdQD4tHAA/r1wAPxicAD+b3AA/g0AAADgcADw WHAA/kVwAPw2cAD+KXAA+BxwAPz2cAD+GQAAAAAAAP4BAAAAAAAAAAAAAAAAAAD8QgAAAAAAAAAA /l/9D/3yCg== --====_ABC1234567890DEF_==== From ALERMX-SA@alerton.com Thu Jan 10 19:32:41 2002 From: ALERMX-SA@alerton.com (System Attendant) Date: Thu, 10 Jan 2002 11:32:41 -0800 Subject: [XML-SIG] ScanMail Message: To Recipient virus found and action taken. Message-ID: ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = graham.forrester Recipient(s) = xml-sig@python.org Subject = [XML-SIG] Re: Scanning Time = 01/10/2002 11:32:40 Action on virus found: The attachment HAMSTER.DOC.pif matched file blocking settings. ScanMail has Moved it. The attachment was moved to D:\quarentine\HAMSTER.DOC3c3dec5844.pif_. Warning to recipient. ScanMail has detected a virus. From HRTADES7-SA@siemens.atea.be Thu Jan 10 19:32:45 2002 From: HRTADES7-SA@siemens.atea.be (System Attendant) Date: Thu, 10 Jan 2002 20:32:45 +0100 Subject: [XML-SIG] ScanMail Message: To Recipient virus found and action taken. Message-ID: ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = _graham.forrester@ntlworld.com Recipient(s) = xml-sig@python.org Subject = [XML-SIG] Re: Scanning Time = 01/10/2002 20:32:45 Action on virus found: The attachment HAMSTER.DOC.pif matched file blocking settings. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Alert\HAMSTER.DOC3c3dec5d71.pif_. Warning to recipient. ScanMail has detected a virus. From martin@v.loewis.de Thu Jan 10 20:40:33 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Thu, 10 Jan 2002 21:40:33 +0100 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <87pu4ijaey.fsf@marant.org> (jmarant@free.fr) References: <87pu4ijaey.fsf@marant.org> Message-ID: <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> > I received a bug report about the 4suite debian package. > I recently release python-xml 0.7 without xslt and xpath in order > to avoid conflicts with current 4suite (0.11.1). > > However, there seem to be incompatibility problems. > > Do you have any clue? That is not surprising. The XSLT part of PyXML 0.7 doesn't really work. Contributions are welcome, either by fixing the bugs, or by helping to incorporate a more recent 4XSLT snapshot. Regards, Martin From jmarant@free.fr Thu Jan 10 21:00:20 2002 From: jmarant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) Date: 10 Jan 2002 22:00:20 +0100 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> References: <87pu4ijaey.fsf@marant.org> <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> Message-ID: <87ofk1j50b.fsf@marant.org> "Martin v. Loewis" writes: > > I received a bug report about the 4suite debian package. > > I recently release python-xml 0.7 without xslt and xpath in order > > to avoid conflicts with current 4suite (0.11.1). > > > > However, there seem to be incompatibility problems. > > > > Do you have any clue? > > That is not surprising. The XSLT part of PyXML 0.7 doesn't really > work. Contributions are welcome, either by fixing the bugs, or by > helping to incorporate a more recent 4XSLT snapshot. I'm sorry, I'm not sure that you read the bug report correctly: I did not ship pyxml 0.7 with XSLT. The bug report is telling that the XSLT in _4Suite_ does not seem to work with pyxml 0.7. Any idea? -- Jérôme Marant http://marant.org From martin@v.loewis.de Thu Jan 10 21:08:01 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Thu, 10 Jan 2002 22:08:01 +0100 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <87ofk1j50b.fsf@marant.org> (jmarant@free.fr) References: <87pu4ijaey.fsf@marant.org> <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> <87ofk1j50b.fsf@marant.org> Message-ID: <200201102108.g0AL81O02180@mira.informatik.hu-berlin.de> > I'm sorry, I'm not sure that you read the bug report correctly: > I did not ship pyxml 0.7 with XSLT. The bug report is telling > that the XSLT in _4Suite_ does not seem to work with pyxml 0.7. > > Any idea? Oops, indeed I misunderstood your report. It isn't really clear, from the original report you've quoted who owns /usr/lib/python2.1/site-packages/_xmlplus/xpath If that is really 4Suite, then it might be a 4Suite bug that is fixed in 0.12. Regards, Martin From jmarant@free.fr Thu Jan 10 21:29:06 2002 From: jmarant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) Date: 10 Jan 2002 22:29:06 +0100 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <200201102108.g0AL81O02180@mira.informatik.hu-berlin.de> References: <87pu4ijaey.fsf@marant.org> <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> <87ofk1j50b.fsf@marant.org> <200201102108.g0AL81O02180@mira.informatik.hu-berlin.de> Message-ID: <87g05dj3od.fsf@marant.org> "Martin v. Loewis" writes: > Oops, indeed I misunderstood your report. It isn't really clear, from > the original report you've quoted who owns > > /usr/lib/python2.1/site-packages/_xmlplus/xpath > > If that is really 4Suite, then it might be a 4Suite bug that is fixed > in 0.12. Ok, I'll talk to them. BTW, it seems that you are not confident in XSLT in Pyxml 0.7. Since, 4Suite will no longer ship it, will we only have the one in pyxml which is not working very well according to what you said? -- Jérôme Marant http://marant.org From rsalz@zolera.com Thu Jan 10 21:31:18 2002 From: rsalz@zolera.com (Rich Salz) Date: Thu, 10 Jan 2002 16:31:18 -0500 Subject: [XML-SIG] 4suite and pyxml, bug report References: <87pu4ijaey.fsf@marant.org> <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> <87ofk1j50b.fsf@marant.org> <200201102108.g0AL81O02180@mira.informatik.hu-berlin.de> Message-ID: <3C3E0826.1090103@zolera.com> I believe the issue is that PyXML uses None for the no-namespace, and 4xslt still uses '' ; the version in their CVS tree uses None. /r$ -- Zolera Systems, http://www.zolera.com Information Integrity, XML Security From akuchlin@mems-exchange.org Thu Jan 10 21:36:58 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 10 Jan 2002 16:36:58 -0500 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <87g05dj3od.fsf@marant.org> References: <87pu4ijaey.fsf@marant.org> <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> <87ofk1j50b.fsf@marant.org> <200201102108.g0AL81O02180@mira.informatik.hu-berlin.de> <87g05dj3od.fsf@marant.org> Message-ID: <20020110213658.GC4302@ute.mems-exchange.org> On Thu, Jan 10, 2002 at 10:29:06PM +0100, J?r?me Marant wrote: > 0.7. Since, 4Suite will no longer ship it, will we only have the > one in pyxml which is not working very well according to what > you said? Huh? Did I miss something? I can't recall seeing any announcements from Uche or Mike about that. --amk From martin@v.loewis.de Thu Jan 10 22:06:41 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Thu, 10 Jan 2002 23:06:41 +0100 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <87g05dj3od.fsf@marant.org> (jmarant@free.fr) References: <87pu4ijaey.fsf@marant.org> <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> <87ofk1j50b.fsf@marant.org> <200201102108.g0AL81O02180@mira.informatik.hu-berlin.de> <87g05dj3od.fsf@marant.org> Message-ID: <200201102206.g0AM6fr02400@mira.informatik.hu-berlin.de> > Ok, I'll talk to them. > > BTW, it seems that you are not confident in XSLT in Pyxml > 0.7. Since, 4Suite will no longer ship it, will we only have the > one in pyxml which is not working very well according to what > you said? No, if nobody else does, I will eventually work on integrating the most recent 4Suite code into PyXML, and then go from there. Regards, Martin From mike@nthwave.net Fri Jan 11 04:21:48 2002 From: mike@nthwave.net (Michael Mell) Date: Thu, 10 Jan 2002 20:21:48 -0800 Subject: [XML-SIG] xml vs. sql References: <3C39D951.94926B9B@nthwave.net> <200201072303.g07N3PT01557@mira.informatik.hu-berlin.de> <3C3A4C10.7B964CBC@nthwave.net> <200201080717.g087Hol01405@mira.informatik.hu-berlin.de> Message-ID: <3C3E685C.F15B3ED9@nthwave.net> "Martin v. Loewis" wrote: > > I'd prefer to find a more generic solution. The generic solution would > > allow any common language (Java, Perl, Python, PHP come to mind) to > > manage the data. We're back to XML, right? > > Yes, probably. A database which is equally supported in all these > languages is another option (and which fulfills your requirement of no > administrative overhead). BSDDB (www.sleepycat.com) comes to mind; Beautiful! Thank you! -- mike@nthwave.net llemekim YahooIM 415.455.8812 voice 419.735.1167 fax From uche.ogbuji@fourthought.com Fri Jan 11 04:35:12 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 10 Jan 2002 21:35:12 -0700 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: Message from jmarant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) of "10 Jan 2002 20:03:33 +0100." <87pu4ijaey.fsf@marant.org> Message-ID: <200201110435.g0B4ZCo09404@localhost.localdomain> Hmm. Looks as if there has been a lot of confusion over this. It's very= = simple, really. > I received a bug report about the 4suite debian package. > I recently release python-xml 0.7 without xslt and xpath in order > to avoid conflicts with current 4suite (0.11.1). > = > However, there seem to be incompatibility problems. [SNIP] > The current version of python2.1-xml does not allow a namespace > of ''; instead, None must be used. XSLT at least hasn't been > updated and therefore doesn't work at all. Eg, from the examples > directory, running the command given at the top of the README: Remember that we changed PyXML 0.7 to use None rather than '' for null = namespace. Earlier code used '', including prior releases of 4Suite, = naturally. So it's not a bug in either problem. The solution is unfortunately to wait for the 4Suite 0.12.0 release, whic= h = uses None rather than '', following the new convention, before updating = Debian's PyXML package. We have been promising a release for a month now. We still expect it any= day = now (down to 2 blocking issues). -- = Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com = 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From uche.ogbuji@fourthought.com Fri Jan 11 04:37:37 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 10 Jan 2002 21:37:37 -0700 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: Message from jmarant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) of "10 Jan 2002 22:29:06 +0100." <87g05dj3od.fsf@marant.org> Message-ID: <200201110437.g0B4bbF09414@localhost.localdomain> > "Martin v. Loewis" writes: > = > = > > Oops, indeed I misunderstood your report. It isn't really clear, from= > > the original report you've quoted who owns > > = > > /usr/lib/python2.1/site-packages/_xmlplus/xpath > > = > > If that is really 4Suite, then it might be a 4Suite bug that is fixed= > > in 0.12. > = > Ok, I'll talk to them. > = > BTW, it seems that you are not confident in XSLT in Pyxml > 0.7. Since, 4Suite will no longer ship it, will we only have the > one in pyxml which is not working very well according to what > you said? 4Suite continues to ship 4XSLT and 4XPath, and will continue to do so unt= il = 4Suite 1.0, at which point it will be wholly moved to PyXML (i.e. no long= er = doubly maintained). 4Suite 1.0 is still months away. -- = Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com = 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From uche.ogbuji@fourthought.com Fri Jan 11 04:39:28 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 10 Jan 2002 21:39:28 -0700 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: Message from "Martin v. Loewis" of "Thu, 10 Jan 2002 23:06:41 +0100." <200201102206.g0AM6fr02400@mira.informatik.hu-berlin.de> Message-ID: <200201110439.g0B4dSu09423@localhost.localdomain> > > Ok, I'll talk to them. > > > > BTW, it seems that you are not confident in XSLT in Pyxml > > 0.7. Since, 4Suite will no longer ship it, will we only have the > > one in pyxml which is not working very well according to what > > you said? > > No, if nobody else does, I will eventually work on integrating the > most recent 4Suite code into PyXML, and then go from there. IIRC, the biggest issues you faced involved removing refs to the domlettes. I think this should be easier now, by simply masquerading minidom as a domlette: now you only need to add/edit a couple of files in Ft/Xml in order to do so. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From tpassin@home.com Fri Jan 11 05:46:53 2002 From: tpassin@home.com (Thomas B. Passin) Date: Fri, 11 Jan 2002 00:46:53 -0500 Subject: [XML-SIG] RELAX NG: failed parser attempt References: <20020109113631.C25248@mozart.mems-exchange.org> <001401c19971$bbc923c0$7cac1218@cj64132b> <20020110155506.GB2977@ute.mems-exchange.org> Message-ID: <001f01c19a63$5f925570$7cac1218@cj64132b> [Andrew Kuchling] > On Wed, Jan 09, 2002 at 07:57:09PM -0500, Thomas B. Passin wrote: >>... > > >I don't have anything concrete to offer at this point since I haven't > >studied it carefully at all (especially the simplified syntax). Any hope > >for a Schematron-like approach (but in Python)? > > I don't follow the suggestion. It doesn't look like XSLT > is strong enough to do the full->simple conversion. > I didn't mean it too literally, just wondered whether testing pieces of syntax against assertions (as is done in Schematron) might let you finesse some otherwise tricky bits. I didn't expect it would actually be done in xslt. Cheers, Tom P From tpassin@home.com Fri Jan 11 05:58:15 2002 From: tpassin@home.com (Thomas B. Passin) Date: Fri, 11 Jan 2002 00:58:15 -0500 Subject: [XML-SIG] 4suite and pyxml, bug report References: <87pu4ijaey.fsf@marant.org> <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> <87ofk1j50b.fsf@marant.org> <200201102108.g0AL81O02180@mira.informatik.hu-berlin.de> <3C3E0826.1090103@zolera.com> Message-ID: <003c01c19a64$f67cddb0$7cac1218@cj64132b> [Rich Salz] > I believe the issue is that PyXML uses None for the no-namespace, and > 4xslt still uses '' ; the version in their CVS tree uses None. I found this out a few nights ago, but it only needed a change in one line to make me be able to run transformations: in line 83 on xml/xpath/Util.py, change if prefix != '': to if prefix: (or, if you are a purist, if prefix is not None: ) There are some other places in other files that could be fixed, but their detailed construction doesn't seem to be critical, at least to what I was doing. The 4xslt batch file in the scripts directory will run with this patch, for example. I was going to post this, but I see I'm a bit late...perhaps it's already changed in CVS. One point that I've never seen mentioned but that can prevent code from running is this: you need to get rid of any .pyc and .pyo files for .py files you have developed after you install a new version of pyxml or 4Suite, or you are asking for mysterious failures. The .pyc files will have acceptable dates so the interpreter will not try to recompile them, but if code they reference has been moved or renamed, you will have trouble. Worth a mention somewhere, I think. Cheers, Tom P From jmarant@free.fr Fri Jan 11 06:35:52 2002 From: jmarant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) Date: 11 Jan 2002 07:35:52 +0100 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <200201110437.g0B4bbF09414@localhost.localdomain> References: <200201110437.g0B4bbF09414@localhost.localdomain> Message-ID: <87bsg1qtrr.fsf@marant.org> Uche Ogbuji writes: > 4Suite continues to ship 4XSLT and 4XPath, and will continue to do so until > 4Suite 1.0, at which point it will be wholly moved to PyXML (i.e. no longer > doubly maintained). > > 4Suite 1.0 is still months away. Will 0.12 come out soon? Thanks. -- Jérôme Marant http://marant.org From jmarant@free.fr Fri Jan 11 06:36:26 2002 From: jmarant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) Date: 11 Jan 2002 07:36:26 +0100 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <3C3E0826.1090103@zolera.com> References: <87pu4ijaey.fsf@marant.org> <200201102040.g0AKeX201962@mira.informatik.hu-berlin.de> <87ofk1j50b.fsf@marant.org> <200201102108.g0AL81O02180@mira.informatik.hu-berlin.de> <3C3E0826.1090103@zolera.com> Message-ID: <877kqpqtqt.fsf@marant.org> Rich Salz writes: > I believe the issue is that PyXML uses None for the no-namespace, and > 4xslt still uses '' ; the version in their CVS tree uses None. > /r$ Yes, that's exactly what's happening. -- Jérôme Marant http://marant.org From Nicolas.Chauvat@logilab.fr Fri Jan 11 10:30:56 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Fri, 11 Jan 2002 11:30:56 +0100 (CET) Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <200201110435.g0B4ZCo09404@localhost.localdomain> Message-ID: Hi Uche, > We have been promising a release for a month now. We still expect it any day > now (down to 2 blocking issues). Would you mind sharing with the crowd what the two remaining release-critical bugs are ? (let's call them RC bugs as I'm getting used to Debian's numerous acronyms :-) Maybe we could find time to help ? -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France) From nicolas.torzec@rd.francetelecom.com Fri Jan 11 14:59:56 2002 From: nicolas.torzec@rd.francetelecom.com (TORZEC Nicolas thesard FTRD/DIH/LAN) Date: Fri, 11 Jan 2002 15:59:56 +0100 Subject: [XML-SIG] XML Databases and Python Message-ID: Dear all, I am currently involved in a project where I am using Python and where I manage (create /update /delete /select /use) many XML files. - My original idea was to create my own XML file managing system, but creating such a system will take a long time. - My second idea was to use a lightweight relationnal database, but it's not the easiest and the most efficient way to manipulate such semi-structured data - My third idea was to use a lightweight object-oriented database - My fourth idea was to use a lightweight native XML database What do you think about these solutions ? According to your Python/XML/Database experience, what is the most appropriate database type for this kind of job ? Do you know lightweight relationnal, object-oriented or XML oriented databases compatible with Python ? (preference is given to open source projects) Every advices are welcome :) Thank you in advance for your help, Nicolas PS : this message is posted on xml-sig and on db-sig. From daniel.dittmar@sap.com Fri Jan 11 15:12:32 2002 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Fri, 11 Jan 2002 16:12:32 +0100 Subject: [XML-SIG] RE: [DB-SIG] XML Databases and Python Message-ID: > Do you know lightweight relationnal, object-oriented or XML oriented > databases compatible with Python ? (preference is given to open source > projects) I haven't programmed either of them, but the following might work ZODB: http://www.amk.ca/zodb/ MetaKit: http://www.equi4.com/metakit/ Daniel -- Daniel Dittmar SAP DB, SAP Labs Berlin daniel.dittmar@sap.com http://www.sapdb.org/ From uche.ogbuji@fourthought.com Fri Jan 11 15:11:41 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 11 Jan 2002 08:11:41 -0700 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: Message from Nicolas Chauvat of "Fri, 11 Jan 2002 11:30:56 +0100." Message-ID: <200201111511.g0BFBfR10713@localhost.localdomain> > Hi Uche, > = > > We have been promising a release for a month now. We still expect it= any day = > > now (down to 2 blocking issues). > = > Would you mind sharing with the crowd what the two remaining > release-critical bugs are ? (let's call them RC bugs as I'm getting use= d > to Debian's numerous acronyms :-) Maybe we could find time to help ? One note of caution: these are blockers for the first alpha, not the fina= l = release. However, work remaining between the alpha and the final release= is = almost all in the server, and is not at all expected to be in cDomlette, = so = the alpha should still suit your purposes (being able to point your users= to a = prereq package for Narval 1.2). Well, you, Alexandre, and Sylvain have already been very helpful with one= of = them. There are one or more remaining points of cDomlette that lead to = crashing, and there are known memory leaks. On some machines 4Suite Serv= er = will not run using cDomlette: immediate core dump. The main problem is that MikeO and I know the code best. Mike is on vaca= tion, = and I cannot reproduce these problems on my machine in order to allow me = debug = them: everything runs just fine (and with pleasing speed :-) ) on my mac= hine = with cDomlette. I think the most useful help would be in beefing up the cDomlette tests (= in = 4Suite/test/Xml/Core/) so that they reliably reproduce the problems, whic= h = should allow me to quickly fix them. Sylvain said you lot had a stress t= est = for cDomlette (though he noted that it's not showing the problems for him= , = either), I'd be grateful if some variation on this could be added to the = test = suite. Any other additions should make it easier all the time for me to = find = the bugs. The second blocking issue is a problem with Teud, the Python/XML document= ation = software we use, under Python 2.2. Jeremy is working on this, and the fi= x may = be in by now. -- = Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com = 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From bkline@rksystems.com Fri Jan 11 15:29:02 2002 From: bkline@rksystems.com (Bob Kline) Date: Fri, 11 Jan 2002 10:29:02 -0500 (EST) Subject: [XML-SIG] Re: [DB-SIG] XML Databases and Python In-Reply-To: Message-ID: On Fri, 11 Jan 2002, TORZEC Nicolas thesard FTRD/DIH/LAN wrote: > Dear all, > I am currently involved in a project where I am using Python and > where I manage (create /update /delete /select /use) many XML files. > > - My original idea was to create my own XML file managing system, but > creating such a system will take a long time. > - My second idea was to use a lightweight relationnal database, but it's not > the easiest and the most efficient way to manipulate such semi-structured > data > - My third idea was to use a lightweight object-oriented database > - My fourth idea was to use a lightweight native XML database > > > > What do you think about these solutions ? > According to your Python/XML/Database experience, what is the most > appropriate database type for this kind of job ? > Do you know lightweight relationnal, object-oriented or XML oriented > databases compatible with Python ? (preference is given to open source > projects) Hi, Nicolas. The choice we made for the project I'm currently working on for one of my clients was to use a relational database for the underlying storage mechanism. This allowed us to use the relational tables for managing and querying the document and system metadata. We store the XML in a single column of the master document table. We have tables for such things as user accounts, groups, and permissions, versioning of the documents, audit trails, inter-document link tracking, and element values for which XML Query is supported. We looked at the other solutions, which may be well suited to other projects, but concluded that for our purposes, at the time the architectural decisions were being made (back in 2000), this was the most appropriate. In particular we looked at the off-the-shelf SGML/XML repository management systems, and concluded that the tradeoffs between the amount of customization that would need to be done anyway, the uncertainties introduced by dependencies on third-parties in a rapidly evolving market, and the performance penalties introduced by at least some of the commercial approaches used by the commercial solutions, the customer would be better off if we built that piece ourselves. On the other hand, we evaluated and selected one of the commercially available XML editing packages (XMetaL from SoftQuad) for use as our primary front end (this didn't eliminate the need for heavy customization on the client end, though). The fact that we are using a standard DBMS underneath the repository means that we can take advantage of the richness of establish tools to work with the relational tables. We use Python heavily for much of our reporting (the parts that aren't handled well by XSL/T) and web-based administrative administrative tools. It's hard to find a good RDBMS with which Python is not compatible. As I say, this approach may not be the best for every XML repository, and we might not have made the same decisions after the commercial repository software has had a chance to mature further, but it's working well for us. Hope this is useful. -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From akuchlin@mems-exchange.org Fri Jan 11 16:46:53 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 11 Jan 2002 11:46:53 -0500 Subject: [XML-SIG] Character classes Message-ID: Appendix B of the XML REC, at http://www.w3.org/TR/2000/REC-xml-20001006#CharClasses, specifies the Unicode characters that are allowed in element names. It doesn't look like anything in the PyXML package actually implements them, though. For example, I've just run into this with 4DOM, where Document.py contains: #FIXME: should allow combining characters: fix when Python gets Unicode g_namePattern = re.compile('[a-zA-Z_:][\w\.\-_:]*\Z') One of the RELAX NG test cases is a document with a high-Unicode tag name, and so that's why I'm hitting this. Document.py would need to be changed, but so would xmlproc and doubtless other pieces of code. Therefore, there should be a separate module containing character info that both 4DOM and xmlproc could use. (xml/chars.py?) But what should chars.py contain? Strings? (BaseChar = "\u0041\u0042...") Lists of legal characters? (BaseChar = [0x41, 0x42, ...]) Something else? Appendix B of the XML REC derives the character classes from the Unicode 2.0 character database. Should we just write out all the expressions from Appendix B as regex patterns, or derive them from the database? Note that Python comes with Unicode 3.0, so maybe we can't use the database at all! Also, there doesn't seem to be a C-level API for querying the Unicode database, which means there's no easy way to fix sgmlop.c. --amk From tony.becker@fortpedro.com Fri Jan 11 16:57:33 2002 From: tony.becker@fortpedro.com (Tony Becker) Date: Fri, 11 Jan 2002 10:57:33 -0600 Subject: [XML-SIG] XML Databases and Python In-Reply-To: References: Message-ID: At 15:59 +0100 1/11/02, TORZEC Nicolas thesard FTRD/DIH/LAN wrote: >Dear all, >I am currently involved in a project where I am using Python and where I >manage (create /update /delete /select /use) many XML files. > >- My original idea was to create my own XML file managing system, but >creating such a system will take a long time. >- My second idea was to use a lightweight relationnal database, but it's not >the easiest and the most efficient way to manipulate such semi-structured >data >- My third idea was to use a lightweight object-oriented database >- My fourth idea was to use a lightweight native XML database For my project, I considered or started to implement almost all of these ideas. I even considered building a (4) out of a (1) or a (2). (3) turned out to be the most satisfactory for my case. Roll-your-own: Building your own solution is not good because it's just that much more code you have to debug and maintain, on top of the rest of your project. XML/Relational: Storing XML in relational databases (no matter exactly how this is done) seems to result in poor performance and/or inadequate query/update facilities, and usually ties you to a particular SQL platform. Native XML: Personally, I don't think native XML databases are ready for prime-time yet: I'm waiting for a stable, solid definition of XQuery and XUpdate before I'll consider this category mature enough for project use. I settled on using an object database and having my objects be "renderable" into XML when it's called for. Specifically we used ZODB with some extra code for using Zope's "Catalogs" without the overhead of the rest of Zope. This turned out to have many advantages: - good performance if implemented properly and overall data set is small - implement whatever kind of query you desire - modifiers and other business logic tied more closely to data - you can still use XSLT and other XML facilities for presentation/transmission - the object interfaces can be exposed via XMLRPC or SOAP if you need these interfaces to be network-accessible - fairly easy to write Tk/Web interfaces for editing instance data - most of the necessary software is free, except project-specific things that you'd have to write yourself anyway :) My feeling is that most XML data needs to be mutable, and there are always rules for how things are to be edited that cannot be enforced in XML editors, but require some kind of program code. My ZODB/XML solution retains control over my data, while not preventing me from using all the XML facilities I've come to love -- my objects are still able to represent themselves in XML, which can be styled to FO, HTML, WML, etc. (I do this by piping Python's XML output through Cocoon2, but it could be done in a variety of different ways.) Best, TB -- Tony Becker, Application Architect Fort Pedro Informatics LLC 2nd Floor East Chicago, IL USA http://fortpedro.com From mal@lemburg.com Fri Jan 11 17:52:30 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 11 Jan 2002 18:52:30 +0100 Subject: [XML-SIG] Character classes References: Message-ID: <3C3F265E.743AD71C@lemburg.com> Andrew Kuchling wrote: > > Appendix B of the XML REC, at > http://www.w3.org/TR/2000/REC-xml-20001006#CharClasses, specifies the > Unicode characters that are allowed in element names. It doesn't look > like anything in the PyXML package actually implements them, though. > ... > Appendix B of the XML REC derives the character classes from the > Unicode 2.0 character database. Should we just write out all the > expressions from Appendix B as regex patterns, or derive them from the > database? Note that Python comes with Unicode 3.0, so maybe we can't > use the database at all! The Unicode 3.0 database is mostly backward compatible w/r to Unicode 2.0; except for a few well documented changes. I don't think we should care about those... > Also, there doesn't seem to be a C-level API for querying the Unicode > database, which means there's no easy way to fix sgmlop.c. What kind of API would you need ? There are plenty APIs in Modules/unicodedata.c which we could expose via a PyCObject (see mxDateTime for an example how this is done). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Fri Jan 11 17:56:06 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 11 Jan 2002 18:56:06 +0100 Subject: [XML-SIG] XML Databases and Python References: Message-ID: <3C3F2736.CFECA0C3@lemburg.com> Tony Becker wrote: > ... > I settled on using an object database and having my objects be > "renderable" into XML when it's called for. Specifically we used > ZODB with some extra code for using Zope's "Catalogs" without the > overhead of the rest of Zope. I don't have any experience with ZODB, but one of my customers told me that ZODB isn't the right choice if you want to store gigabytes of data. You might want to take a look at what PyBiz has to offer, though. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From bates@stat.wisc.edu Fri Jan 11 23:30:59 2002 From: bates@stat.wisc.edu (Douglas Bates) Date: 11 Jan 2002 17:30:59 -0600 Subject: [XML-SIG] Setting the DOCTYPE in a new XML DOM Message-ID: <6r3d1cbh3g.fsf@franz.stat.wisc.edu> System: Debian 3.0 (testing) GNU/Linux with the python2.2 and python2.2-xml packages installed. ||/ Name Version Description +++-==============-==============-============================================ ii python2.2 2.2-2 An interactive object-oriented scripting la ii python2.2-xml 0.6.6-7 XML tools for Python (2.2.x) I have been unable to determine how to set the SYSTEM in the doctype of a document read by the PyExpat reader. I am rather new to this so it is possible that I am doing something foolish. I have mostly been following demo's and examples as I haven't been able to track down a lot of documentation. A sample program is #!/usr/bin/env python2.2 from xml.dom.ext.reader.PyExpat import Reader from xml.dom.ext import PrettyPrint if __name__ == "__main__": reader = Reader() doc = reader.fromUri("/tmp/foo1.xml") PrettyPrint(doc) The file /tmp/foo1.xml begins but the output file begins Can anyone tell me what I do to maintain the SYSTEM designation? Also, how do I set the SYSTEM designation when I create a new document, say as in def __init__(self, dom = None): '''Initialize from an existing document object model or create a new DOM. ''' if dom: self.doc = dom self.vol = dom.getElementsByTagName('volume')[0] else: from xml.dom.DOMImplementation import implementation self.doc = implementation.createDocument(None, None, None) self.vol = self.doc.createElement('volume') self.doc.appendChild(self.vol) From martin@v.loewis.de Fri Jan 11 23:57:58 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sat, 12 Jan 2002 00:57:58 +0100 Subject: [XML-SIG] Character classes In-Reply-To: (message from Andrew Kuchling on Fri, 11 Jan 2002 11:46:53 -0500) References: Message-ID: <200201112357.g0BNvw701576@mira.informatik.hu-berlin.de> > Appendix B of the XML REC, at > http://www.w3.org/TR/2000/REC-xml-20001006#CharClasses, specifies the > Unicode characters that are allowed in element names. It doesn't look > like anything in the PyXML package actually implements them, though. Sure. Just have a look at xml.utils.characters. xmlproc currently uses these expressions to implement full Unicode support in XML. > For example, I've just run into this with 4DOM, where Document.py > contains: > > #FIXME: should allow combining characters: fix when Python gets Unicode > g_namePattern = re.compile('[a-zA-Z_:][\w\.\-_:]*\Z') Yes, that needs to be fixed. > Document.py would need to be changed, but so would xmlproc and > doubtless other pieces of code. Document.py needs to be changed; xmlproc already is. Python 1.5 is the hairy issue here, since xml.utils.characters mandates Unicode support. > Therefore, there should be a separate module containing character > info that both 4DOM and xmlproc could use. There is. > (xml/chars.py?) But what should chars.py contain? Strings? (BaseChar > = "\u0041\u0042...") Lists of legal characters? (BaseChar = [0x41, > 0x42, ...]) Something else? Both strings and regular expressions. > Appendix B of the XML REC derives the character classes from the > Unicode 2.0 character database. Should we just write out all the > expressions from Appendix B as regex patterns, or derive them from the > database? Note that Python comes with Unicode 3.0, so maybe we can't > use the database at all! For strict conformance, we cannot. See utils/xmlchargen.py for a list of differences. Regards, Martin From martin@v.loewis.de Sat Jan 12 00:08:26 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sat, 12 Jan 2002 01:08:26 +0100 Subject: [XML-SIG] Character classes In-Reply-To: <3C3F265E.743AD71C@lemburg.com> (mal@lemburg.com) References: <3C3F265E.743AD71C@lemburg.com> Message-ID: <200201120008.g0C08Q801612@mira.informatik.hu-berlin.de> > The Unicode 3.0 database is mostly backward compatible w/r to Unicode 2.0; > except for a few well documented changes. I don't think we should care > about those... For strict XML conformance, one may want to worry; see xml/xmlchargen. Also, it isn't easy to construct the XML character classes with just the Python Unicode properties. For example, Python's .isalpha() mostly matches XML's BaseChar class, except for the Roman numerals, and the ESTIMATED SYMBOL, which got recategorized in 3.0. For NameChar, the Python Unicode support does not offer anything close. The regular expressions \w is a strict superset, but contains many characters that match \w but are not NameChars (e.g. SUPERSET TWO). > > What kind of API would you need ? There are plenty APIs in > Modules/unicodedata.c which we could expose via a PyCObject > (see mxDateTime for an example how this is done). The information that you need for an XML parser are simply not available. For sgmlop, it would be best to copy the approach that pyexpat uses, see extensions/expat/lib/nametab.h. Regards, Martin From uche.ogbuji@fourthought.com Sat Jan 12 01:15:45 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 11 Jan 2002 18:15:45 -0700 Subject: [XML-SIG] Character classes In-Reply-To: Message from Andrew Kuchling of "Fri, 11 Jan 2002 11:46:53 EST." Message-ID: <200201120115.g0C1Fjj12851@localhost.localdomain> > Appendix B of the XML REC, at > http://www.w3.org/TR/2000/REC-xml-20001006#CharClasses, specifies the > Unicode characters that are allowed in element names. It doesn't look > like anything in the PyXML package actually implements them, though. > For example, I've just run into this with 4DOM, where Document.py > contains: > > #FIXME: should allow combining characters: fix when Python gets Unicode > g_namePattern = re.compile('[a-zA-Z_:][\w\.\-_:]*\Z') Oh, hey. I wrote that comment, must have been 2 years ago. I guess it's time to put in a fix, eh? If someone files a bug report, I can try to have a look post 4Suite 1.12.0 release. > One of the RELAX NG test cases is a document with a high-Unicode tag > name, and so that's why I'm hitting this. > > Document.py would need to be changed, but so would xmlproc and > doubtless other pieces of code. Therefore, there should be a separate > module containing character info that both 4DOM and xmlproc could use. > (xml/chars.py?) But what should chars.py contain? Strings? (BaseChar > = "\u0041\u0042...") Lists of legal characters? (BaseChar = [0x41, > 0x42, ...]) Something else? It should contain full character tables: might as well go all the way correct. I know from where we might snag such tables in expat. > Appendix B of the XML REC derives the character classes from the > Unicode 2.0 character database. Should we just write out all the > expressions from Appendix B as regex patterns, or derive them from the > database? Note that Python comes with Unicode 3.0, so maybe we can't > use the database at all! Hmm. My head might be foggy, but I think Unicode 3.0 vs 2.1 will only affect character data, not namechars (at least until XML 1.1, AKA Blueberry). > Also, there doesn't seem to be a C-level API for querying the Unicode > database, which means there's no easy way to fix sgmlop.c. I guess we should just define an API for the lookup tables in C. That would make it even easier to raid expat for the goods. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From kendall@monkeyfist.com Sat Jan 12 01:41:13 2002 From: kendall@monkeyfist.com (Kendall Clark) Date: Fri, 11 Jan 2002 19:41:13 -0600 Subject: [XML-SIG] XML Databases and Python In-Reply-To: <3C3F2736.CFECA0C3@lemburg.com> References: <3C3F2736.CFECA0C3@lemburg.com> Message-ID: <15423.37945.885059.456383@cmpu.net> >>>>> "mal" == mal writes: mal> I don't have any experience with ZODB, but one of my customers mal> told me that ZODB isn't the right choice if you want to store mal> gigabytes of data. We've been publishing on XML.com lately some articles by Kimbro Staken about dbXML (now part of Apache project and renamed XML Indice or somesuch) which is a native XML database. It uses the XML::DB api which it implements is, imo, very interesting, and I think it's about time for a Python implementation. I've been mulling that over, considering whether to use ZODB for disk storage (i.e, just layering XML::DB over ZODB) or whether to use db to store data on disk, or what... If there are folks interested in talking about a Python XML::DB NXD, I'd like to be part of the conversation. If this list isn't a suitable place (while this seems kind of a XML and DB SIG 'tweener, I don't see why this list wouldn't be okay), we can easily find one. Best, Kendall Clark, XML.com Columns Editor From mail@musicians-guide.com Sat Jan 12 06:28:00 2002 From: mail@musicians-guide.com (mail@musicians-guide.com) Date: Sat, 12 Jan 2002 01:28:00 -0500 Subject: [XML-SIG] Trading Links With Musicians Resource Center Message-ID: Mailloop 14,44|58,0|58,1|59,352 Trading Links With Musicians Resource Center0Would you be interested in trading links? Musicians Resource Center http://resources.musicians-guide.com Please include the exact URL that you would like us to link to as well as the exact URL where we can find a link back to us in a reply to this message. We look forward to hearing from you. Thanks, Webmaster Musicians Resource Center From ohbehave@ihug.co.nz Sat Jan 12 06:49:20 2002 From: ohbehave@ihug.co.nz (Guy Robinson) Date: Sat, 12 Jan 2002 19:49:20 +1300 Subject: [XML-SIG] Urllib problem 4SS-0.12 Message-ID: <000501c19b35$5f872970$0100a8c0@ferrari> Hello, I'm trying to initialise the latest CVS 4Suite-0.12 pyxml 0.7 on a win2K machine. I built it using the free borland C compiler. My server environment variable is set to e:\ but it seems to be interpreted as e:\\ (see TB below). I've looked back through the xml-sig archive and from what I could find this should work. file:///e:/redsite doesn't work either and e:/ gives a permission denied error. Does anyone have a suggestion as to why/ how I can make this work? TIA, Guy Robinson C:\>4ss_manager init Traceback (most recent call last): File "", line 1, in ? File "c:\Python21\Ft\Server\Server\Commands\__init__.py", line 76, in run return apply(CommandLineApp.CommandLineApp.run,args,kw) File "c:\Python21\Ft\Lib\CommandLine\CommandLineApp.py", line 90, in run cmd.run_command(self.authenticationFunction) File "c:\Python21\Ft\Lib\CommandLine\Command.py", line 86, in run_command self.function(self.clOptions, self.clArguments) File "c:\Python21\Ft\Server\Server\Commands\Init.py", line 39, in TextInit properties = ConfigFile.Read(options.get('config-file')) File "c:\Python21\Ft\Server\Server\Lib\ConfigFile.py", line 33, in Read model = ReadConfigFile(fileName) File "c:\Python21\Ft\Server\Server\Lib\ConfigFile.py", line 51, in ReadConfigF ile model, db = Util.DeserializeFromUri(fileName) File "c:\Python21\Ft\Rdf\Util.py", line 150, in DeserializeFromUri doc = READER.fromUri(uri) File "c:\Python21\Ft\Xml\ReaderBase.py", line 64, in fromUri stream = self.uriResolver.resolve(uri, baseUri) File "c:\Python21\Ft\Lib\Uri.py", line 34, in resolve stream = open(uri) IOError: [Errno 2] No such file or directory: 'e:\\' From Nicolas.Chauvat@logilab.fr Sat Jan 12 12:59:34 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Sat, 12 Jan 2002 13:59:34 +0100 (CET) Subject: [XML-SIG] XML Databases and Python In-Reply-To: <15423.37945.885059.456383@cmpu.net> Message-ID: > We've been publishing on XML.com lately some articles by Kimbro Staken > about dbXML (now part of Apache project and renamed XML Indice or > somesuch) which is a native XML database. How come no one mentionned 4SuiteServer yet ? Did I miss the e-mail ? 4SuiteServer provides native XML storage in python, but is also more than that. It features automatic RDF generation, RDF querying, XSL(T) transformation on the fly, etc. Read more on the website http://www.4suite.org/ And a part of the PyXML code base was contributed by the folks of 4Thought. Sounds like worth mentionning to me... (Hi Uche, Hi Mike ;-) -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France) From Nicolas.Chauvat@logilab.fr Sat Jan 12 13:05:30 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Sat, 12 Jan 2002 14:05:30 +0100 (CET) Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: <200201111511.g0BFBfR10713@localhost.localdomain> Message-ID: > One note of caution: these are blockers for the first alpha, not the > final release. However, work remaining between the alpha and the > final release is almost all in the server, and is not at all expected > to be in cDomlette, so the alpha should still suit your purposes > (being able to point your users to a prereq package for Narval 1.2). Ok, good to know. > should allow me to quickly fix them. Sylvain said you lot had a stress test > for cDomlette (though he noted that it's not showing the problems for him, > either), I'd be grateful if some variation on this could be added to the test > suite. Any other additions should make it easier all the time for me to find > the bugs. I'll look into this but I think he meant that the way we're using cDomlette in Narval is a stress test, and I doubt you'll want to add the whole Narval thing to 4Suite's test suite ;-) -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France) From mal@lemburg.com Sat Jan 12 13:33:08 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 12 Jan 2002 14:33:08 +0100 Subject: [XML-SIG] Character classes References: <3C3F265E.743AD71C@lemburg.com> <200201120008.g0C08Q801612@mira.informatik.hu-berlin.de> Message-ID: <3C403B14.6040002@lemburg.com> Martin v. Loewis wrote: >>The Unicode 3.0 database is mostly backward compatible w/r to Unicode 2.0; >>except for a few well documented changes. I don't think we should care >>about those... >> > > For strict XML conformance, one may want to worry; see > xml/xmlchargen. The XML spec doesn't mention a specific Unicode version. Unicode 3 is mentioned in the spec as well: http://www.w3.org/TR/REC-xml OTOH, Letter is defined explicitly without reference to the Unicode database: http://www.w3.org/TR/REC-xml#NT-Letter > Also, it isn't easy to construct the XML character > classes with just the Python Unicode properties. For example, Python's > .isalpha() mostly matches XML's BaseChar class, except for the Roman > numerals, and the ESTIMATED SYMBOL, which got recategorized in 3.0. > > For NameChar, the Python Unicode support does not offer anything > close. The regular expressions \w is a strict superset, but contains > many characters that match \w but are not NameChars (e.g. SUPERSET TWO). In that case, I suppose you ought to simply create a database similar to that used by unicodectype.c which uses the explicit character ranges defined in the XML spec as reference and provides API for querying isLetter(), isBaseChar() etc. Tools/unicode/makeunicodedata.py has the needed tools to generate such a table, so this shouldn't be too complicated. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From tpassin@home.com Sat Jan 12 16:05:45 2002 From: tpassin@home.com (Thomas B. Passin) Date: Sat, 12 Jan 2002 11:05:45 -0500 Subject: [XML-SIG] Urllib problem 4SS-0.12 References: <000501c19b35$5f872970$0100a8c0@ferrari> Message-ID: <000601c19b82$fe75a0a0$7cac1218@cj64132b> [Guy Robinson] > > I'm trying to initialise the latest CVS 4Suite-0.12 pyxml 0.7 on a win2K > machine. I built it using the free borland C compiler. > > My server environment variable is set to e:\ but it seems to be interpreted > as e:\\ (see TB below). I've looked back through the xml-sig archive and > from what I could find this should work. file:///e:/redsite doesn't work > either and e:/ gives a permission denied error. > > Does anyone have a suggestion as to why/ how I can make this work? > You didn't mention "file:/" - that usually seems to work - either file:/e:/ or file:/e:\ Try them both. Cheers, Tom P From uche.ogbuji@fourthought.com Sat Jan 12 18:22:03 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sat, 12 Jan 2002 11:22:03 -0700 Subject: [XML-SIG] XML Databases and Python In-Reply-To: Message from Nicolas Chauvat of "Sat, 12 Jan 2002 13:59:34 +0100." Message-ID: <200201121822.g0CIM3o14348@localhost.localdomain> > > We've been publishing on XML.com lately some articles by Kimbro Stake= n > > about dbXML (now part of Apache project and renamed XML Indice or > > somesuch) which is a native XML database. > = > How come no one mentionned 4SuiteServer yet ? Did I miss the e-mail ? > = > 4SuiteServer provides native XML storage in python, but is also more th= an > that. It features automatic RDF generation, RDF querying, > XSL(T) transformation on the fly, etc. Read more on the website > http://www.4suite.org/ > = > And a part of the PyXML code base was contributed by the folks of > 4Thought. Sounds like worth mentionning to me... (Hi Uche, Hi Mike ;-) Thanks for the plug. I didn't even realize this thread matched the subje= ct = line. I read the first message quickly, didn't quite understand it, and = skipped the whole thread (sort of thing I have to do often these days). I think you pretty much said all I would have said. 4Suite supports XML = storage, XUpdates, XSLT/XPath, XInclude/xml:base, RDF and RDF query (usin= g = Versa), to mention a few things. Python and XSLT APIs over HTTP, FTP or = SOAP = protocol, a Web-based management dashboard, or just good old command-line= = management. One note is that we're dropping the name "4Suite server" because it seems= to = confuse a lot of people. The whole shebang is just "4Suite" now, and the= = server component, now called the repository, is just a built-in component= =2E We = hope to have an available setup option to omit the server code for those = who = don't want it. -- = Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com = 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From info@ironing-board-covers.co.uk Sat Jan 12 19:48:43 2002 From: info@ironing-board-covers.co.uk (Look At This) Date: Sat, 12 Jan 2002 19:48:43 -0000 Subject: [XML-SIG] Are YOU looking for a new website, to develop an existing website, for cheaper hosting or domain names? Message-ID: Are YOU looking for a new website, to develop an existing website, for cheaper hosting or domain names? We are a UK based company who would like to offer you our considerable experience and expertise in the field of website design, eCommerce, web hosting, domain name facilities and search engine positioning. We can offer you cheaper solutions with domain name registration from £20, website design both new and updated sites undertaken from £100, website hosting from £60pa, full professional after sales service and website maintenance from £10 pm, secure server space and security certificates from £100 pa, marketing tips and advice free to our clients, top ranking search engine positioning available. Please look at http://www.ironing-board-covers.co.uk for a full price list and currency convertor. All of our designs are custom made for our client's requirements and are our best advert. Please ask to see our portfolio. We are independently tested on a daily basis and are consistently in the top of the performance listings of all the major ISP hosting companies in the UK. So, whether you want to advertise your business more effectively, reach a larger catchment area or sell in the global market; WE have the BEST solution for you. Due to the bespoke nature of our website development most of our clients prefer to discuss their requirements by telephone, please send us a contact phone number and we will contact you shortly to discuss your needs in more detail. Alternatively, please ask for more details by replying to this email for a prompt response. We look forward to hearing from you. This is NOT spam. You are receiving this message because your email address was used on one of our web sites. If your email address was used without your permission or you no longer want to receive email from us, we apologise for any inconvenience caused and ask that you simply reply to this email putting remove as the subject. From martin@v.loewis.de Sat Jan 12 20:20:35 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sat, 12 Jan 2002 21:20:35 +0100 Subject: [XML-SIG] Character classes In-Reply-To: <3C403B14.6040002@lemburg.com> (mal@lemburg.com) References: <3C3F265E.743AD71C@lemburg.com> <200201120008.g0C08Q801612@mira.informatik.hu-berlin.de> <3C403B14.6040002@lemburg.com> Message-ID: <200201122020.g0CKKZJ01388@mira.informatik.hu-berlin.de> > The XML spec doesn't mention a specific Unicode version. It does, see below. > OTOH, Letter is defined explicitly without reference to the > Unicode database: > > http://www.w3.org/TR/REC-xml#NT-Letter The text below these productions makes specific reference to a specific Unicode version, and the Unicode database: # The character classes defined here can be derived from the Unicode # 2.0 character database as follows: # # * Name start characters must have one of the categories Ll, Lu, Lo, # Lt, Nl. # # * Name characters other than Name-start characters must have one of # the categories Mc, Me, Mn, Lm, or Nd. # ... > In that case, I suppose you ought to simply create a database > similar to that used by unicodectype.c which uses the explicit > character ranges defined in the XML spec as reference and > provides API for querying isLetter(), isBaseChar() etc. Python 2.2 was specifically enhanced to efficiently process large character classes in regular expressions. So this is what PyXML uses. Regards, Martin From martin@v.loewis.de Sat Jan 12 22:24:14 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sat, 12 Jan 2002 23:24:14 +0100 Subject: [XML-SIG] xml.dom.FtNode.g_pattPrefix Message-ID: <200201122224.g0CMOEg01370@mira.informatik.hu-berlin.de> If anybody uses this constant, please let me know. I will remove it in PyXML 0.7.1, but would restore it if somebody is interested in it. Likewise, g_namePattern will go away, or rather be replaced by a function. Regards, Martin From noreply@sourceforge.net Sun Jan 13 17:51:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 09:51:18 -0800 Subject: [XML-SIG] [ pyxml-Bugs-503030 ] Not possible to set parseroutput charset Message-ID: Bugs item #503030, was opened at 2002-01-13 09:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503030&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Henrik Levkowetz (leoh) Assigned to: Lars Marius Garshol (larsga) Summary: Not possible to set parseroutput charset Initial Comment: I'm using PyXML with slashbox.py to fetch and display rdf data. With the default parser settings, the output of the parser is utf-8, and there's no way to set it to anything else, (using e.g. set_data_charset() ), as the call to parseFile() will reset the parser and the character set. I've put in a workaround by adding the output character set as a second argument to parseFile(), but that's a bit clunky. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503030&group_id=6473 From noreply@sourceforge.net Sun Jan 13 21:19:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Jan 2002 13:19:40 -0800 Subject: [XML-SIG] [ pyxml-Bugs-503074 ] bad import statement in Stylesheet.py Message-ID: Bugs item #503074, was opened at 2002-01-13 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503074&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tavis Rudd (tavis_rudd) Assigned to: Nobody/Anonymous (nobody) Summary: bad import statement in Stylesheet.py Initial Comment: _xmlplus/xslt/Stylesheet.py", line 22, in ? from xml.xslt import XsltElement, XsltException, InternalException, Error ImportError: cannot import name InternalException This is with PyXML 0.7, Python 2.2, and 4suite 0.11.1 Here's the traceback ---------- tavis@lucy: ~/tmp/4Suite-0.11.1/Xslt/demo > 4xslt addr_book1.xml Traceback (most recent call last): File "/usr/local/bin/4xslt", line 3, in ? from xml.xslt import _4xslt File "/usr/local/lib/python2.2/site-packages/_xmlplus/xslt/_4xslt.py", line 20, in ? from xml.xslt import Processor File "/usr/local/lib/python2.2/site-packages/_xmlplus/xslt/Processor.py", line 24, in ? from xml.xslt import StylesheetReader, ReleaseNode File "/usr/local/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 53, in ? from xml.xslt.Stylesheet import StylesheetElement File "/usr/local/lib/python2.2/site-packages/_xmlplus/xslt/Stylesheet.py", line 22, in ? from xml.xslt import XsltElement, XsltException, InternalException, Error ImportError: cannot import name InternalException ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503074&group_id=6473 From Sylvain.Thenault@logilab.fr Mon Jan 14 08:32:22 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Mon, 14 Jan 2002 09:32:22 +0100 (CET) Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: Message-ID: On Sat, 12 Jan 2002, Nicolas Chauvat wrote: > > should allow me to quickly fix them. Sylvain said you lot had a stress test > > for cDomlette (though he noted that it's not showing the problems for him, > > either), I'd be grateful if some variation on this could be added to the test > > suite. Any other additions should make it easier all the time for me to find > > the bugs. > > I'll look into this but I think he meant that the way we're using > cDomlette in Narval is a stress test, and I doubt you'll want to add the > whole Narval thing to 4Suite's test suite ;-) That's not what I meant, I wrote a really simple stress test (concurrent threads adding/removing childs on the same tree) which has been successfully passed by the cDomlette. If you give me some guidelines, I can enhance this test or/and give it to you if you want to include it in your test suite. regards -- Sylvain Thenault LOGILAB http://www.logilab.org From Sylvain.Thenault@logilab.fr Mon Jan 14 09:52:09 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Mon, 14 Jan 2002 10:52:09 +0100 (CET) Subject: [XML-SIG] Setting the DOCTYPE in a new XML DOM In-Reply-To: <6r3d1cbh3g.fsf@franz.stat.wisc.edu> Message-ID: On 11 Jan 2002, Douglas Bates wrote: > System: Debian 3.0 (testing) GNU/Linux with the python2.2 and > python2.2-xml packages installed. > > ||/ Name Version Description > +++-==============-==============-============================================ > ii python2.2 2.2-2 An interactive object-oriented scripting la > ii python2.2-xml 0.6.6-7 XML tools for Python (2.2.x) you should install pyxml 0.7 which contains a bunch of bugfixes > I have been unable to determine how to set the SYSTEM in the doctype > of a document read by the PyExpat reader. I am rather new to this so > it is possible that I am doing something foolish. I have mostly been > following demo's and examples as I haven't been able to track down a > lot of documentation. A sample program is > > #!/usr/bin/env python2.2 > > from xml.dom.ext.reader.PyExpat import Reader > from xml.dom.ext import PrettyPrint > > if __name__ == "__main__": > reader = Reader() > doc = reader.fromUri("/tmp/foo1.xml") > PrettyPrint(doc) > > The file /tmp/foo1.xml begins > > > > > > > but the output file begins > > > > > > > Can anyone tell me what I do to maintain the SYSTEM designation? this is a bug in pyexpat. It should work if you use xmlproc instead of pyexpat to generate your dom tree. > Also, how do I set the SYSTEM designation when I create a new > document, say as in > > def __init__(self, dom = None): > '''Initialize from an existing document object model > or create a new DOM. > ''' > if dom: > self.doc = dom > self.vol = dom.getElementsByTagName('volume')[0] > else: > from xml.dom.DOMImplementation import implementation > self.doc = implementation.createDocument(None, None, None) > self.vol = self.doc.createElement('volume') > self.doc.appendChild(self.vol) as said in the dom level 2 spec, the only way to set a doctype to a document node is while creating the document (the corresponding attribute of document is read only): from xml.dom.DOMImplementation import implementation doctype = implementation.createDocumentType('XMI', None, 'uml13.dtd') doc = implementation.createDocument(EMPTY_NAMESPACE, 'XMI', doctype) Note the createDocument return a document with it's root element (the 2 first arguments of createDocument are the namespaceURI and the qname of the _root_), so the following line self.doc = implementation.createDocument(None, 'volume', None) does the same job as your 3 lines. Moreover, some Python DOM implementations accept namespaceURI and qname to be None in createDocument arguments, and then return a document element without root node, while some doesn't (as minidom for example). hope that helps regars -- Sylvain Thenault LOGILAB http://www.logilab.org From stephane.bidoul@softwareag.com Mon Jan 14 16:49:39 2002 From: stephane.bidoul@softwareag.com (=?iso-8859-1?Q?St=E9phane_Bidoul?=) Date: Mon, 14 Jan 2002 17:49:39 +0100 Subject: [XML-SIG] drv_javasax and InputSource Message-ID: <000201c19d1b$7725ac40$57241eac@acsesbi> Hi! With PyXML and Python (C), I typically write this kind of code, parser being an XMLReader: >> parser.parse(open("test.xml")) Now, using jython and drv_javasax, it complains with: >> TypeError: parse(): 1st arg can't be coerced to = org.xml.sax.InputSource or String This error message looks normal given the implementation of drv_javasax, which simply delegates to the jaxp reader. So my questions are: - is this the expected behaviour? while normal in a java environment, this is somewhat disturbing when porting python code to jython... - what is the best way to create a java.io.InputStream from an open python file (sorry if this is a jython FAQ),=20 or even better an org.xml.sax.InputSource from=20 a python xml.sax.xmlreader.InputSource?=20 TIA. -Stephane From noreply@sourceforge.net Mon Jan 14 17:06:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Jan 2002 09:06:14 -0800 Subject: [XML-SIG] [ pyxml-Bugs-503411 ] setContentHandler while parsing Message-ID: Bugs item #503411, was opened at 2002-01-14 09:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503411&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stéphane Bidoul (sbidoul) Assigned to: Lars Marius Garshol (larsga) Summary: setContentHandler while parsing Initial Comment: It should be possible to change the content handler while parsing. Bug #433761 reported the same kind of issue with pyexpat. I refer to it as a detailed explanation. Currently, the handlers are passed to the underlying xmlproc parser in PrepareParser, which is not called by setContentHandler, which is inherited from XMLReader. -sbi ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503411&group_id=6473 From noreply@sourceforge.net Mon Jan 14 17:53:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Jan 2002 09:53:12 -0800 Subject: [XML-SIG] [ pyxml-Patches-503425 ] PyXml 0.7 for Cygwin Message-ID: Patches item #503425, was opened at 2002-01-14 09:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=503425&group_id=6473 Category: expat Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark McEahern (mceahm) Assigned to: Nobody/Anonymous (nobody) Summary: PyXml 0.7 for Cygwin Initial Comment: setup.py for PyXml 0.7 fails on Cygwin: $ python setup.py install [skip a lot of "not copying (output up-to-date)"] not copying xml/xslt/__init__.py (output up-to-date) running build_ext building '_xmlplus.parsers.pyexpat' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - DUSE_DL_IMPORT -DHAVE_EXPAT_H -DV ERSION="1.95.2" -DXML_NS=1 -DXML_DTD=1 - DXML_BYTE_ORDER=12 -DXML_CONTEXT_BYTES=1 024 -Iextensions/expat/lib -I/usr/include/python2.2 -c extensions/pyexpat.c -o b uild/temp.cygwin-1.3.6-i686-2.2/pyexpat.o extensions/pyexpat.c:1800: initializer element is not constant extensions/pyexpat.c:1800: (near initialization for `handler_info[2].setter') extensions/pyexpat.c:1803: initializer element is not constant extensions/pyexpat.c:1803: (near initialization for `handler_info[3].setter') extensions/pyexpat.c:1806: initializer element is not constant extensions/pyexpat.c:1806: (near initialization for `handler_info[4].setter') extensions/pyexpat.c:1809: initializer element is not constant extensions/pyexpat.c:1809: (near initialization for `handler_info[5].setter') extensions/pyexpat.c:1818: initializer element is not constant extensions/pyexpat.c:1818: (near initialization for `handler_info[8].setter') extensions/pyexpat.c:1827: initializer element is not constant extensions/pyexpat.c:1827: (near initialization for `handler_info[11].setter') extensions/pyexpat.c:1830: initializer element is not constant extensions/pyexpat.c:1830: (near initialization for `handler_info[12].setter') extensions/pyexpat.c:1833: initializer element is not constant extensions/pyexpat.c:1833: (near initialization for `handler_info[13].setter') extensions/pyexpat.c:1836: initializer element is not constant extensions/pyexpat.c:1836: (near initialization for `handler_info[14].setter') extensions/pyexpat.c:1856: initializer element is not constant extensions/pyexpat.c:1856: (near initialization for `handler_info[17].setter') extensions/pyexpat.c:1859: initializer element is not constant extensions/pyexpat.c:1859: (near initialization for `handler_info[18].setter') extensions/pyexpat.c:1862: initializer element is not constant extensions/pyexpat.c:1862: (near initialization for `handler_info[19].setter') extensions/pyexpat.c:1865: initializer element is not constant extensions/pyexpat.c:1865: (near initialization for `handler_info[20].setter') error: command 'gcc' failed with exit status 1 This may be a bug in gcc, related to the use of __declspec(dllimport). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=503425&group_id=6473 From larsga@garshol.priv.no Mon Jan 14 18:10:29 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 14 Jan 2002 19:10:29 +0100 Subject: [XML-SIG] drv_javasax and InputSource In-Reply-To: <000201c19d1b$7725ac40$57241eac@acsesbi> References: <000201c19d1b$7725ac40$57241eac@acsesbi> Message-ID: Hi Stéphane, * Stéphane Bidoul | | With PyXML and Python (C), I typically write this kind of code, | parser being an XMLReader: | | >> parser.parse(open("test.xml")) | | Now, using jython and drv_javasax, it complains with: | | >> TypeError: parse(): 1st arg can't be coerced to org.xml.sax.InputSource or String This is a bug, since the library documentation explicitly says that file-like objects are allowed. On the other hand, this means wrapping PyFile instances to make them look like Readers or InputStreams, which I seem to recall is quite difficult. Could you report this in the bug tracker, and I'll add a comment explaining what needs to be done. After that we can see who wants to dea with this. (drv_javasax actually needs more work than just this, in order to be a full driver.) | - what is the best way to create a java.io.InputStream from | an open python file (sorry if this is a jython FAQ), | or even better an org.xml.sax.InputSource from | a python xml.sax.xmlreader.InputSource? Good question. I don't think this is entirely straightforward, unfortunately. Input on this would be much welcome. --Lars M. From martin@v.loewis.de Mon Jan 14 21:58:51 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Mon, 14 Jan 2002 22:58:51 +0100 Subject: [XML-SIG] drv_javasax and InputSource In-Reply-To: <000201c19d1b$7725ac40$57241eac@acsesbi> (message from =?ISO-8859-1?Q?St=E9phane?= Bidoul on Mon, 14 Jan 2002 17:49:39 +0100) References: <000201c19d1b$7725ac40$57241eac@acsesbi> Message-ID: <200201142158.g0ELwpF01577@mira.informatik.hu-berlin.de> > - is this the expected behaviour? while normal in a java environment, > this is somewhat disturbing when porting python code to jython... For Python, there is a somewhat generous interpretation of accepting both file-like objects and URI strings in .parse(), it seems desirable to continue to support this property. > - what is the best way to create a java.io.InputStream from > an open python file (sorry if this is a jython FAQ), > or even better an org.xml.sax.InputSource from > a python xml.sax.xmlreader.InputSource? The first one certainly is Jython specific; not sure whether it is a FAQ - in any case, I don't know the answer. As for the second one: If you have solved the first one, just use the InputSource constructor that expects an InputStream. Regards, Martin From janneke@gnu.org Mon Jan 14 22:25:22 2002 From: janneke@gnu.org (Jan Nieuwenhuizen) Date: 14 Jan 2002 23:25:22 +0100 Subject: [XML-SIG] cloneNode doesn't copy attributes? Message-ID: Hi, It seems that cloneNode in python-xml 0.7 (latest Debian unstable python2.2-xml) doesn't copy attributes. Should it? What am I doing wrong/what doco should I read? See below. I've made several attempts to write something as simple as this, but it seems not a trivial to determine which examples are obsolete, and which are preferred now (xml.dom.html_builder.HtmlBuilder and HtmlWriter are too old, pyexpat is too new/not for plain HTML, SAX is simple, but I don't want simple, rather standard and java-like, but in python, right? -- dazzle). Greetings, Jan. #!/usr/bin/python2.2 from xml.dom.ext.reader import HtmlLib from xml.dom.ext import XHtmlPrettyPrint #from xml.dom.ext import Print import sys in_html = '''

baz

''' out_html = ''' ''' in_doc = HtmlLib.FromHtml (in_html) out_doc = HtmlLib.FromHtml (out_html) #Print (in_doc, stream=sys.stdout) XHtmlPrettyPrint (in_doc, stream=sys.stdout) print n = in_doc._get_body () print `n` print m = out_doc.importNode (n.cloneNode (1), 1) print `m` print print `out_doc.documentElement.firstChild` out_doc.documentElement.replaceChild (m, out_doc.documentElement.firstChild) print # Print (out_doc, stream=sys.stdout) XHtmlPrettyPrint (out_doc, stream=sys.stdout) -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org From noreply@sourceforge.net Tue Jan 15 05:05:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Jan 2002 21:05:06 -0800 Subject: [XML-SIG] [ pyxml-Bugs-503712 ] PrettyPrinter elim. word spaces Message-ID: Bugs item #503712, was opened at 2002-01-14 21:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503712&group_id=6473 Category: SAX Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank J. Tobin (ftobin) Assigned to: Nobody/Anonymous (nobody) Summary: PrettyPrinter elim. word spaces Initial Comment: writer.PrettyPrinter.characters at times eliminates the whitespace between two words, effectively mushing them together. It seems to happen only after a word-wrap, mushing together the first two words on the next line. This was using the XHTML DoctypeInfo and XHTML Syntax options for the writer. A cursory look at the source didn't help me figure out the problem. I've encountered the problem twice so far; I'll try to narrow down the data it works icorrectly on. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503712&group_id=6473 From uche.ogbuji@fourthought.com Tue Jan 15 06:36:20 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 14 Jan 2002 23:36:20 -0700 Subject: [XML-SIG] 4suite and pyxml, bug report In-Reply-To: Message from "Thomas B. Passin" of "Fri, 11 Jan 2002 00:58:15 EST." <003c01c19a64$f67cddb0$7cac1218@cj64132b> Message-ID: <200201150636.g0F6aKd30357@localhost.localdomain> > One point that I've never seen mentioned but that can prevent code from > running is this: you need to get rid of any .pyc and .pyo files for .py > files you have developed after you install a new version of pyxml or > 4Suite, or you are asking for mysterious failures. The .pyc files will have > acceptable dates so the interpreter will not try to recompile them, but if > code they reference has been moved or renamed, you will have trouble. > > Worth a mention somewhere, I think. I agree. Thanks for the note. I've added it to the dev version of the FAQ. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From noreply@sourceforge.net Tue Jan 15 12:15:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Jan 2002 04:15:14 -0800 Subject: [XML-SIG] [ pyxml-Bugs-503823 ] drv_javasax and InputSource Message-ID: Bugs item #503823, was opened at 2002-01-15 04:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503823&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stéphane Bidoul (sbidoul) Assigned to: Nobody/Anonymous (nobody) Summary: drv_javasax and InputSource Initial Comment: * Stéphane Bidoul | | With PyXML and Python (C), I typically write this kind of code, | parser being an XMLReader: | | >> parser.parse(open("test.xml")) | | Now, using jython and drv_javasax, it complains with: | | >> TypeError: parse(): 1st arg can't be coerced to org.xml.sax.InputSource or String * Lars Marius Garshol This is a bug, since the library documentation explicitly says that file-like objects are allowed. On the other hand, this means wrapping PyFile instances to make them look like Readers or InputStreams, which I seem to recall is quite difficult. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=503823&group_id=6473 From paul@boddie.net Tue Jan 15 17:13:02 2002 From: paul@boddie.net (paul@boddie.net) Date: 15 Jan 2002 17:13:02 -0000 Subject: [XML-SIG] Python and XML Tutorial Message-ID: <20020115171302.10890.qmail@www1.nameplanet.com> Hello, I recently uploaded a tutorial which deals with Python and XML, and I was wondering if this kind of thing is useful to anyone, and in which directions it might be developed in order to become more informative: http://www.paul.boddie.net/Python/XML_intro.html I'm sure that it isn't so useful to the experts on this list, but I wouldn't want to make any information available to a wider audience without being sure that the information is accurate and encourages good habits. Regards, Paul P.S. I know that with all the Python and XML books going into print, there isn't a huge incentive to make this kind of material available, but then I've had such difficulties finding quality, online information about other technologies (EJB 2.0 CMP, for example) that I think it's needed. -- Get your firstname@lastname email at http://Nameplanet.com/?su From bates@stat.wisc.edu Tue Jan 15 17:43:08 2002 From: bates@stat.wisc.edu (Douglas Bates) Date: 15 Jan 2002 11:43:08 -0600 Subject: [XML-SIG] Inverse relationship design in XML, Python, & Zope Message-ID: <6rd70bwlw3.fsf@franz.stat.wisc.edu> This is a design question but it does relate to XML, Python, and Zope so I hope it is not too far off-topic for these lists. I apologize for the length of the question. It seems that design questions often require a lot of explanation and background. I begin with XML representing, say, articles within issues within a volume of a journal. J. of the Amer. Statist. Assoc. 98 2001 455 September 785 793 Estimation of the ... Microscopy Higdon, Dave Yamamoto, Steve Blind deconvolution Magnetic imaging ... 456 ... This information is decomposed and stored, along with other types of bibliographic information, in a PostgreSQL database. We use Zope to provide the web interface for queries on this database. We would like to have the result of a query returned as an XML object that contains elements, each of which has complete information on a title that matches the query, where a title can be an article or a book or another type of reference. For example, a query could map to SQL like SELECT xmlrep FROM titles WHERE idTitle IN (SELECT idTitle FROM authors WHERE aname ~ 'Higdon, *' INTERSECT SELECT idTitle FROM authors WHERE aname ~ 'Yamamoto, *'); The way I envision it, the xmlrep corresponding to that jart element above would be, say, a pjart element (presentation of a journal article). It must include all the information on the article and the issue and the volume and the journal if we are to be able to format it. The entire result from the query might be J. of the Amer. Statist. Assoc. 98 2001 455 September 785 793 Estimation of the ... Microscopy Higdon, Dave Blind deconvolution Magnetic imaging Title of a book Book Publisher, Inc. Yamamoto, Steve Higdon, Dave ... This is what I meant by an inverse relationship design. I must get the information on the journal, volume, and issue when I select the article. The simple way to do this is to store the entire xmlrep for each title in the titles table. It works but it is not exactly elegant and it requires that we store a lot of redundant text in that xmlrep column. The more elegant solution is to construct the information from XML fragments or text fragments in several different tables in the database. Our tables are normalized so the journal table, with primary key idJournal, contains information on the journal, the issn, etc. and our jour_vol_issue table, with primary key idE, contains an idJournal, and a volume number, year, and issue number. SQL is designed to reconstruct this kind of information but it does so by returning rows in a query result and it would not be easy to make a single query return, say, information on articles and information on books. If we are going to store fragments that will be pasted together to create the XML for presenting a journal article or a book or a proceedings article or ..., where should we construct the XML and what are good tools to use to do this? We could: 0) Store all the information on each title in the xmlrep column and not do any processing. 1) Write a database function, say in PL/PGSQL, that constructs this XML on the fly from the different tables in the database. 2) Write DTML methods, Python methods or external Python methods for Zope. 3) Use XSLT or Xpath to reconstruct. I think know how to do 0, 1, or 2. I'm not sure about 3 because I don't yet know enough about XSL. Your suggestions will be appreciated. -- Douglas Bates bates@stat.wisc.edu Statistics Department 608/262-2598 University of Wisconsin - Madison http://www.stat.wisc.edu/~bates/ From andrew@NETdelivery.com Tue Jan 15 17:48:54 2002 From: andrew@NETdelivery.com (Andrew Diederich) Date: Tue, 15 Jan 2002 10:48:54 -0700 Subject: [XML-SIG] Python and XML Tutorial Message-ID: <0B3E4A385C25D511B65600B0D0B0EA13769C69@mtevans.netdelivery> As a non-expert on this list, examples like this are very useful. I've had a hard time finding current examples of sax and dom programs for python, so tutorials are great for getting up to speed. The Python Cookbook (http://aspn.activestate.com/ASPN/Python/Cookbook/), along with the short xml tutorial in pyxml, helped me make a tiny sax app, btw. Your tutorial will help me re-do that as a dom app, so I can see how that works, too. Thanks for the work! -- Andrew Diederich -----Original Message----- From: paul@boddie.net [mailto:paul@boddie.net] Sent: Tuesday, January 15, 2002 10:13 AM To: xml-sig@python.org Subject: [XML-SIG] Python and XML Tutorial Hello, I recently uploaded a tutorial which deals with Python and XML, and I was wondering if this kind of thing is useful to anyone, and in which directions it might be developed in order to become more informative: http://www.paul.boddie.net/Python/XML_intro.html I'm sure that it isn't so useful to the experts on this list, but I wouldn't want to make any information available to a wider audience without being sure that the information is accurate and encourages good habits. Regards, Paul P.S. I know that with all the Python and XML books going into print, there isn't a huge incentive to make this kind of material available, but then I've had such difficulties finding quality, online information about other technologies (EJB 2.0 CMP, for example) that I think it's needed. -- Get your firstname@lastname email at http://Nameplanet.com/?su _______________________________________________ XML-SIG maillist - XML-SIG@python.org http://mail.python.org/mailman/listinfo/xml-sig From martin@v.loewis.de Tue Jan 15 20:31:06 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Tue, 15 Jan 2002 21:31:06 +0100 Subject: [XML-SIG] Python and XML Tutorial In-Reply-To: <20020115171302.10890.qmail@www1.nameplanet.com> (paul@boddie.net) References: <20020115171302.10890.qmail@www1.nameplanet.com> Message-ID: <200201152031.g0FKV6s02009@mira.informatik.hu-berlin.de> > I'm sure that it isn't so useful to the experts on this list, but I > wouldn't want to make any information available to a wider audience > without being sure that the information is accurate and encourages > good habits. That is a good idea. Should I create a patch to http://pyxml.sourceforge.net/topics/docs.html or do you want to contribute the entire document to live in the XML-SIG areas? If you are thinking of any specific integration, it would be best if you could contribute a patch to the Web pages. Regards, Martin From tpassin@home.com Wed Jan 16 05:21:32 2002 From: tpassin@home.com (Thomas B. Passin) Date: Wed, 16 Jan 2002 00:21:32 -0500 Subject: [XML-SIG] 4XSLT Bug Affecting Document() Message-ID: <000b01c19e4d$a985c070$7cac1218@cj64132b> While running transformations from Zope using 4xslt from 4suite 0.11.1, I found a bug that prevented document() from finding the specified file. This occurs in Windows, when a relative uri is used. I have hacked up a partial fix, but really a more comprehensive fix is needed. The problem fundamentally arises (I think) because urlparse.urlparse(uri) can wrongly think that a Windows drive specifier is a scheme. Thus, this code fragment from Ft\Uri.py does not work right (lines 20-23): scheme = urlparse.urlparse(uri)[0] if scheme in ['', 'http', 'ftp', 'file', 'gopher']: uri = urllib.basejoin(base, uri) return uri When you run from the stylesheet directory, and the relative document uri is in the same directory, everything works. But when invoked from Zope, you are running in a different directory, possibly on a different drive, and it fails. In my case, if I invoked document('file.xml') in my stylesheet on the d: drive, the above code returned d:file.xml which is not correct - it would depend on whatever default directory happened to be in effect on the d: drive. This code is called from file xml\xslt\XsltFunctions.py (for python 1.5.2), at line 55. I decided this would be the best place for a quick fix. Here is my temporary hack - I added these lines: # Fix for Windows relative file uris import os,os.path if os.name in ['nt','dos']: # maybe use sys.platform instead? # Check for relative path basepath=os.path.dirname(baseUri) candidate=Conversions.StringValue(object) # The uri from document(uri) objectpath=os.path.dirname(candidate) if not os.path.isdir(objectpath): uri=os.path.normpath(os.path.join(basepath,candidate)) The code assumes that, if there is a non-empty directory part of the path (found by isdir()), then we have an absolute (file) uri that does not need to be fixed. This probably won't handle all relative uris - those not in the stylesheet or source document directories may not work right, and there are other places that apparently ought to changed in similar ways too, but this is enough to make my current stylesheets work. I think the code in Ft\Uri.py should be fixed to make sure it works. Really, urlparse should be fixed but we need to do something to make sure 4xslt will work with a range of versions of python, so we can't depend on some particualr version of urlparse. What do our 4Thought people think is the best approach here? A complete fix for any possible relative path specification may not be easy, since they may start with various numbers of ../../ or ./ steps, and still be recognized as a relative specification - and then, only adjusted if it is a relative ***file*** specification. Also, the fix probably should be robust enough to handle forward and backslashes in the relative path, just in case they appear. Cheers, Tom P From Sylvain.Thenault@logilab.fr Wed Jan 16 08:37:09 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Wed, 16 Jan 2002 09:37:09 +0100 (CET) Subject: [XML-SIG] Setting the DOCTYPE in a new XML DOM In-Reply-To: <6rsn97tppb.fsf@franz.stat.wisc.edu> Message-ID: On 15 Jan 2002, Douglas Bates wrote: > Sylvain Thenault writes: > > On 11 Jan 2002, Douglas Bates wrote: > > > I have been unable to determine how to set the SYSTEM in the doctype > > > of a document read by the PyExpat reader. I am rather new to this so > > > it is possible that I am doing something foolish. I have mostly been > > > following demo's and examples as I haven't been able to track down a > > > lot of documentation. A sample program is > > > > > > #!/usr/bin/env python2.2 > > > > > > from xml.dom.ext.reader.PyExpat import Reader > > > from xml.dom.ext import PrettyPrint > > > > > > if __name__ == "__main__": > > > reader = Reader() > > > doc = reader.fromUri("/tmp/foo1.xml") > > > PrettyPrint(doc) > > > > > > The file /tmp/foo1.xml begins > > > > > > > > > > > > > > > > > > > > > but the output file begins > > > > > > > > > > > > > > > > > > > > > Can anyone tell me what I do to maintain the SYSTEM designation? > > > > this is a bug in pyexpat. It should work if you use xmlproc instead of > > pyexpat to generate your dom tree. > > Could you tell me how I would use xmlproc to create a reader or to > somehow load and XML from a URI? Is there a Reader class that uses > xmlproc? I couldn't see one when I looked through the libraries. here is an example: --------------------------------------------------------- from xml.dom.ext.reader import Sax2 from xml.sax import make_parser parser = make_parser(['xml.sax.drivers2.drv_xmlproc']) reader = Sax2.Reader(parser=parser) --------------------------------------------------------- by default (without the "parser" argument), Sax and Sax2 readers will use xmlproc when you ask for a validating parser (in other cases, they try to use the faster parser, say pyexpat or sgmlop which are Python wrapper for C libraries). I have tried this with your example and it works correctly (doesn't loose the doctype node :) cheers -- Sylvain Thenault LOGILAB http://www.logilab.org From marc@msys.ch Wed Jan 16 09:10:37 2002 From: marc@msys.ch (Marc Balmer) Date: Wed, 16 Jan 2002 10:10:37 +0100 Subject: [XML-SIG] How-to compile PyXML 0.7 on Mac OS X 10.1.x Message-ID: PyXML will not build out of the box on Mac OS X 10.1.x. The reason for this is that Apple changed the default behaviour of the link editor ld regarding the use of namespaces. With Mac OS 10.0.x the linker used -flat_namespace by default which allows the suppression of undefined references using the command line option -undefined suppress. With Mac OS X 10.1, however, Apple changed the linkers default to use two-level namespaces which does not allow the option -undefined suppress. All references must be resolved at link time and thus PyXML fails to compile the C extensions (for a discussion of namespaces see 'man ld'). In order to build PyXML on Mac OS X 10.1.x the file setup.py must be modified to use the ld option '-flat_namespace': Line 30: LDFLAGS = ['-flat_namespace'] The change the build of sgmlop and boolean (line 166 onwards) to # Build sgmlop ext_modules.append( Extension(xml('.parsers.sgmlop'), extra_link_args=LDFLAGS, sources=['extensions/sgmlop.c'] )) # Build boolean ext_modules.append( Extension(xml('.utils.boolean'), extra_link_args=LDFLAGS, sources=['extensions/boolean.c'] )) With these changes PyXML can built and installed on Mac OS X 10.1.x - Marc Balmer -- Marc Balmer, Micro Systems, Kannenfeldstrasse 32, CH-4056 Basel Tel +41 61 383 05 10, Fax +41 61 383 05 12, http://www.msys.ch/ From christophe.robert@culture.gouv.fr Wed Jan 16 11:13:27 2002 From: christophe.robert@culture.gouv.fr (christophe robert) Date: Wed, 16 Jan 2002 06:13:27 -0500 Subject: [XML-SIG] Re: [Zope-xml] Inverse relationship design in XML, Python, & Zope References: <6rd70bwlw3.fsf@franz.stat.wisc.edu> Message-ID: <3C456057.FFE4ED2B@culture.fr> Douglas Bates a =E9crit : > > > 3) Use XSLT or Xpath to reconstruct. > You can use nXMLDocument " or my ugly port on unix of nXMLDocument "uniXMLdocument" :(( " > > I think know how to do 0, 1, or 2. I'm not sure about 3 because I > don't yet know enough about XSL. > > Your suggestions will be appreciated. > > -- > Douglas Bates bates@stat.wisc.edu > Statistics Department 608/262-2598 > University of Wisconsin - Madison http://www.stat.wisc.edu/~bate= s/ > > _______________________________________________ > Zope-xml mailing list > Zope-xml@zope.org > http://lists.zope.org/mailman/listinfo/zope-xml From martin@v.loewis.de Wed Jan 16 16:49:04 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Wed, 16 Jan 2002 17:49:04 +0100 Subject: [XML-SIG] How-to compile PyXML 0.7 on Mac OS X 10.1.x In-Reply-To: (message from Marc Balmer on Wed, 16 Jan 2002 10:10:37 +0100) References: Message-ID: <200201161649.g0GGn4j01343@mira.informatik.hu-berlin.de> > PyXML will not build out of the box on Mac OS X 10.1.x. The reason > for this is that Apple changed the default behaviour of the link editor > ld regarding the use of namespaces. With Mac OS 10.0.x the linker > used -flat_namespace by default which allows the suppression of > undefined references using the command line option -undefined > suppress. Can you please try the current CVS? It already has such changes. Regards, Martin From uche.ogbuji@fourthought.com Thu Jan 17 00:51:07 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 16 Jan 2002 17:51:07 -0700 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods Message-ID: <200201170051.g0H0p7n12564@localhost.localdomain> In dom.ext.reader.Sgmlop.py and other places, The NS methods are erroneously being used for HTML DOM manipulation. This breaks apps that are expecting the resulting nodes to have the mandated HTML DOM behavior (i.e. uppercase-normalized tagnames and the like). In fact: $ grep NS\( dom/html/* grep: dom/html/CVS: Is a directory dom/html/HTMLDocument.py: def createElementNS(self, namespace, qname): dom/html/HTMLElement.py: self.attributes.setNamedItemNS(clone) $ These shouyldn't even be defined for HTML interfaces. The problem is that it would be a bit of a chore to carefully change things back so that the XML modules strictly use NS methods, and the HTML modules the non-NS modules. It would probably be easiest for whomever made the changes to undo them. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From Sylvain.Thenault@logilab.fr Thu Jan 17 11:09:44 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Thu, 17 Jan 2002 12:09:44 +0100 (CET) Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: <200201170051.g0H0p7n12564@localhost.localdomain> Message-ID: On Wed, 16 Jan 2002, Uche Ogbuji wrote: > In dom.ext.reader.Sgmlop.py and other places, The NS methods are erroneously > being used for HTML DOM manipulation. This breaks apps that are expecting the > resulting nodes to have the mandated HTML DOM behavior (i.e. > uppercase-normalized tagnames and the like). In fact: > > $ grep NS\( dom/html/* > grep: dom/html/CVS: Is a directory > dom/html/HTMLDocument.py: def createElementNS(self, namespace, qname): > dom/html/HTMLElement.py: self.attributes.setNamedItemNS(clone) > $ > > These shouyldn't even be defined for HTML interfaces. why ? Doesn't HTMLDocument inherit from the standard DOM level 2 Document? > The problem is that it would be a bit of a chore to carefully change things > back so that the XML modules strictly use NS methods, and the HTML modules the > non-NS modules. It would probably be easiest for whomever made the changes to > undo them. I made the changes in dom/ext/reader/Sgmlop.py and dom/html/HTMLDocument.py. Those one can easily be reverted, but I think it'll be much longer to be sure that all XML modules strictly use NS methods and HTML modules strictly use non NS methods. Originally, I made the change in Sgmlop to be able to give to Sgmlop a pDomlette document (which doesn't implement the non NS methods). Then I have overridden the createElementNS method in HTMLDocument to delegate in the same manner as createElement, so I don't think it break the standard HTML DOM behavior if you give to HTMLParser a HTMLDocument. regards -- Sylvain Thenault LOGILAB http://www.logilab.org From jeremy.kloth@fourthought.com Thu Jan 17 18:40:04 2002 From: jeremy.kloth@fourthought.com (Jeremy Kloth) Date: Thu, 17 Jan 2002 11:40:04 -0700 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods References: Message-ID: <03fc01c19f86$6ceed4f0$f801a8c0@zeus> From: "Sylvain Thenault" > On Wed, 16 Jan 2002, Uche Ogbuji wrote: > > > In dom.ext.reader.Sgmlop.py and other places, The NS methods are erroneously > > being used for HTML DOM manipulation. This breaks apps that are expecting the > > resulting nodes to have the mandated HTML DOM behavior (i.e. > > uppercase-normalized tagnames and the like). In fact: > > > > $ grep NS\( dom/html/* > > grep: dom/html/CVS: Is a directory > > dom/html/HTMLDocument.py: def createElementNS(self, namespace, qname): > > dom/html/HTMLElement.py: self.attributes.setNamedItemNS(clone) > > $ > > > > These shouyldn't even be defined for HTML interfaces. > > why ? Doesn't HTMLDocument inherit from the standard DOM level 2 Document? > > > The problem is that it would be a bit of a chore to carefully change things > > back so that the XML modules strictly use NS methods, and the HTML modules the > > non-NS modules. It would probably be easiest for whomever made the changes to > > undo them. > > I made the changes in dom/ext/reader/Sgmlop.py and > dom/html/HTMLDocument.py. Those one can easily be reverted, but I think > it'll be much longer to be sure that all XML modules strictly use > NS methods and HTML modules strictly use non NS methods. > All the convience methods defined on HTML elements are expecting the attributes to stored via setAttribute not the NS verision. It would be quite an udertaking to change all of those. Another problem is that attribute names are not uppercased as element names are. > Originally, I made the change in Sgmlop to be able to give to Sgmlop a > pDomlette document (which doesn't implement the non NS methods). > Then I have overridden the createElementNS method in HTMLDocument to > delegate in the same manner as createElement, so I don't think it break > the standard HTML DOM behavior if you give to HTMLParser a HTMLDocument. > Elements generally work either way, at least when using the null-namespace. However, the big offender is attributes. Here is an example HTML document that currently will not parse: Broken HTML doesn't care about prefixes! Now that said, the HTML DOM implementation was written from the November 2000 working draft (before XHTML), however the newest draft, December 2001, addresses XHTML and the ability to work with either. So either we can update all of the HTML interfaces to follow the current WD (which it is breaking by uppercasing the names at construction, not access time) or revert the code to follow the older draft. But I think it is just wrong to be half and half and rather confusing. -- Jeremy Kloth Consultant jeremy.kloth@fourthought.com +1 303 583 9900 x 105 Fourthought, Inc. http://fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4suite.org), knowledge management From reagle@mit.edu Thu Jan 17 21:57:43 2002 From: reagle@mit.edu (Joseph Reagle) Date: Thu, 17 Jan 2002 16:57:43 -0500 Subject: [XML-SIG] XML Schema and Python Message-ID: <200201172157.QAA08709@tux.w3.org> Just wondering if the folks hear are interested in schema? There is a schema processor (validation and infoset augmentation) already written in Python (1.5 and using a different library LTXML [1]) and I was wondering if anyone had given any thought of bringing it "into the fold"? [1] http://www.ltg.ed.ac.uk/software/xml/ -- Regards, http://www.mit.edu/~reagle/ Joseph Reagle E0 D5 B2 05 B6 12 DA 65 BE 4D E3 C1 6A 66 25 4E * This email is from an independent academic account and is not necessarily representative of my affiliations. From martin@v.loewis.de Thu Jan 17 22:20:33 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Thu, 17 Jan 2002 23:20:33 +0100 Subject: [XML-SIG] XML Schema and Python In-Reply-To: <200201172157.QAA08709@tux.w3.org> (message from Joseph Reagle on Thu, 17 Jan 2002 16:57:43 -0500) References: <200201172157.QAA08709@tux.w3.org> Message-ID: <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> > Just wondering if the folks hear are interested in schema? There is a > schema processor (validation and infoset augmentation) already written in > Python (1.5 and using a different library LTXML [1]) and I was wondering if > anyone had given any thought of bringing it "into the fold"? Did you actually try to use it? If so, what where your results? Regards, Martin From reagle@mit.edu Thu Jan 17 23:45:48 2002 From: reagle@mit.edu (Joseph Reagle) Date: Thu, 17 Jan 2002 18:45:48 -0500 Subject: [XML-SIG] XML Schema and Python In-Reply-To: <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> References: <200201172157.QAA08709@tux.w3.org> <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> Message-ID: <200201172345.SAA04100@tux.w3.org> On Thursday 17 January 2002 17:20, Martin v. Loewis wrote: > > Just wondering if the folks hear are interested in schema? There is a > > schema processor (validation and infoset augmentation) already written > > in Python (1.5 and using a different library LTXML [1]) and I was > > wondering if anyone had given any thought of bringing it "into the > > fold"? > > Did you actually try to use it? If so, what where your results? It's great in terms of features/compliance but I've only successfully managed to use the win32 binary. My annoyances with deploying python1.5 and LTXML on my own linux machine is part of what prompts my question here. (Though it is not *impossible* since it runs on W3C's server (linux) as a web service, but I found that machines config sufficiently confusing and maintainers sufficiently forgetful not to get very far given the little time I spent on it.) However, when presented with folks more knowledgeable than myself and with the carrot of integration in PyXML, more progress might be made, particularly if there's folks here keen on it? -- Regards, http://www.mit.edu/~reagle/ Joseph Reagle E0 D5 B2 05 B6 12 DA 65 BE 4D E3 C1 6A 66 25 4E * This email is from an independent academic account and is not necessarily representative of my affiliations. From rsalz@zolera.com Fri Jan 18 00:44:00 2002 From: rsalz@zolera.com (Rich Salz) Date: Thu, 17 Jan 2002 19:44:00 -0500 Subject: [XML-SIG] XML Schema and Python References: <200201172157.QAA08709@tux.w3.org> <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> <200201172345.SAA04100@tux.w3.org> Message-ID: <3C476FD0.43358ADB@zolera.com> I tried to use it, had all sorts of problems, which I sent to Henry. He agrees that the best thing would be to use the PyXML DOM and not their own private implementation; from there, much progress could be made. I, personally, don't think it's worth doing anything because it's so different from pyxml. I'm interested in schema, for wsdl and soap. I might do something. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com From andres@ccpo.odu.edu Fri Jan 18 02:27:11 2002 From: andres@ccpo.odu.edu (Andres) Date: Thu, 17 Jan 2002 21:27:11 -0500 (EST) Subject: [XML-SIG] Isntalling pyxml in potato Message-ID: Hi, I want to install PyXML in a Debian (potato) distribution up to date with all the stable stuff but the following problem occurs: trauko@andres:~/tmp/PyXML-0.7$ python setup.py build Traceback (innermost last): File "setup.py", line 9, in ? from distutils.core import setup, Extension ImportError: No module named distutils.core I've installed python-base 1.5.2-10potato Any help is appreciated. Andres .,#||//, Andres Sepulveda .("`\''|/").___..--''"`-._ Center for Coastal Physical Oceanography |.`\_./ ).| `-. ( ).`-.__.`) Old Dominion University `,(_Y_.)';/._ ) `._ `. ``-..-' Crittenton Hall, Norfolk VA 23529 _.X`--'_..-_/ /--'_.' ,' Phone: (757) 683 6006 (il),-'' (li),' ((!.-' Fax: (757) 683 5550 From martin@v.loewis.de Fri Jan 18 06:48:26 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Fri, 18 Jan 2002 07:48:26 +0100 Subject: [XML-SIG] XML Schema and Python In-Reply-To: <200201172345.SAA04100@tux.w3.org> (message from Joseph Reagle on Thu, 17 Jan 2002 18:45:48 -0500) References: <200201172157.QAA08709@tux.w3.org> <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> <200201172345.SAA04100@tux.w3.org> Message-ID: <200201180648.g0I6mQZ01677@mira.informatik.hu-berlin.de> > However, when presented with folks more knowledgeable than myself > and with the carrot of integration in PyXML, more progress might be > made, particularly if there's folks here keen on it? Response from xml-sig participants to XML Schema is luke-warm at best; some even openly oppose that recommendation :-) Rich Salz is apparently the only one who was working with LTXML; as he said, he says he's given up. It is not likely that anybody step come forward with XML Schema support anytime soon; people are rather looking into Relax NG, Schematron, etc. So you are pretty much on your own. If you get something usable, you may consider contributing it to PyXML, though. Regards, Martin From martin@v.loewis.de Fri Jan 18 06:42:28 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Fri, 18 Jan 2002 07:42:28 +0100 Subject: [XML-SIG] Isntalling pyxml in potato In-Reply-To: (message from Andres on Thu, 17 Jan 2002 21:27:11 -0500 (EST)) References: Message-ID: <200201180642.g0I6gSD01563@mira.informatik.hu-berlin.de> > I want to install PyXML in a Debian (potato) distribution up to > date with all the stable stuff but the following problem occurs: You also need to install distutils. I believe there is a Debian package for it; if not, you must get it from python.org. Regards, Martin From Nicolas.Chauvat@logilab.fr Fri Jan 18 07:55:20 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Fri, 18 Jan 2002 08:55:20 +0100 (CET) Subject: [XML-SIG] Isntalling pyxml in potato In-Reply-To: <200201180642.g0I6gSD01563@mira.informatik.hu-berlin.de> Message-ID: > > I want to install PyXML in a Debian (potato) distribution up to > > date with all the stable stuff but the following problem occurs: > > You also need to install distutils. I believe there is a Debian > package for it; if not, you must get it from python.org. host:~# dpkg -l 'python*distutils' ||/ Name Version Description +++-==============-==============-============================================ un python-distuti (no description available) pn python1.5-dist (no description available) host:~# This box is running woody, but I believe python1.5-distutils is part of stable and it is the package you need. -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France) From Sylvain.Thenault@logilab.fr Fri Jan 18 08:57:07 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Fri, 18 Jan 2002 09:57:07 +0100 (CET) Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: <03fc01c19f86$6ceed4f0$f801a8c0@zeus> Message-ID: On Thu, 17 Jan 2002, Jeremy Kloth wrote: > From: "Sylvain Thenault" > > On Wed, 16 Jan 2002, Uche Ogbuji wrote: > > > > > In dom.ext.reader.Sgmlop.py and other places, The NS methods are > erroneously > > > being used for HTML DOM manipulation. This breaks apps that are > expecting the > > > resulting nodes to have the mandated HTML DOM behavior (i.e. > > > uppercase-normalized tagnames and the like). In fact: > > > > > > $ grep NS\( dom/html/* > > > grep: dom/html/CVS: Is a directory > > > dom/html/HTMLDocument.py: def createElementNS(self, namespace, > qname): > > > dom/html/HTMLElement.py: > self.attributes.setNamedItemNS(clone) > > > $ > > > > > > These shouyldn't even be defined for HTML interfaces. > > > > why ? Doesn't HTMLDocument inherit from the standard DOM level 2 Document? > > > > > The problem is that it would be a bit of a chore to carefully change > things > > > back so that the XML modules strictly use NS methods, and the HTML > modules the > > > non-NS modules. It would probably be easiest for whomever made the > changes to > > > undo them. > > > > I made the changes in dom/ext/reader/Sgmlop.py and > > dom/html/HTMLDocument.py. Those one can easily be reverted, but I think > > it'll be much longer to be sure that all XML modules strictly use > > NS methods and HTML modules strictly use non NS methods. > > > > All the convience methods defined on HTML elements are expecting the > attributes to stored via setAttribute not the NS verision. It would be > quite an udertaking to change all of those. Another problem is that > attribute names are not uppercased as element names are. Another way to fix this problem without reverting changes is to add to html elements a setAttributeNS method which delegate in the same way as setAttribute. > > Originally, I made the change in Sgmlop to be able to give to Sgmlop a > > pDomlette document (which doesn't implement the non NS methods). > > Then I have overridden the createElementNS method in HTMLDocument to > > delegate in the same manner as createElement, so I don't think it break > > the standard HTML DOM behavior if you give to HTMLParser a HTMLDocument. > > > > Elements generally work either way, at least when using the null-namespace. > However, the big offender is attributes. Here is an example HTML document > that currently will not parse: > > > Broken > HTML doesn't care about prefixes! > should it ? > Now that said, the HTML DOM implementation was written from the November > 2000 working draft (before XHTML), however the newest draft, December 2001, > addresses XHTML and the ability to work with either. So either we can > update all of the HTML interfaces to follow the current WD (which it is > breaking by uppercasing the names at construction, not access time) or > revert the code to follow the older draft. But I think it is just wrong to > be half and half and rather confusing. -- Sylvain Thenault LOGILAB http://www.logilab.org From uche.ogbuji@fourthought.com Fri Jan 18 07:55:50 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 18 Jan 2002 00:55:50 -0700 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: Message from Sylvain Thenault of "Fri, 18 Jan 2002 09:57:07 +0100." Message-ID: <200201180755.g0I7toV26589@localhost.localdomain> > > All the convience methods defined on HTML elements are expecting the > > attributes to stored via setAttribute not the NS verision. It would be > > quite an udertaking to change all of those. Another problem is that > > attribute names are not uppercased as element names are. > > Another way to fix this problem without reverting changes is to add to > html elements a setAttributeNS method which delegate in the same way as > setAttribute. Well, I have no desire to add to another's work-load. Given mine, that would just be a case of misery looking for company. But I dislike this solution on semantic grounds. HTML has no conception of namespaces, so using even the *appearance* of namespace methods on HTML elements is, IMO quite problematic. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From uche.ogbuji@fourthought.com Fri Jan 18 08:00:05 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 18 Jan 2002 01:00:05 -0700 Subject: [XML-SIG] 4XSLT Bug Affecting Document() In-Reply-To: Message from "Thomas B. Passin" of "Wed, 16 Jan 2002 00:21:32 EST." <000b01c19e4d$a985c070$7cac1218@cj64132b> Message-ID: <200201180800.g0I805r26596@localhost.localdomain> > While running transformations from Zope using 4xslt from 4suite 0.11.1, I > found a bug that prevented document() from finding the specified file. This > occurs in Windows, when a relative uri is used. I have hacked up a partial > fix, but really a more comprehensive fix is needed. > > The problem fundamentally arises (I think) because urlparse.urlparse(uri) > can wrongly think that a Windows drive specifier is a scheme. SNIP. This was also reported on the 4Suite mailing list. OK. I give up. I need help. I am mostly ignorant of Windows, and have no easy way to test anything. Shall we just put a standard URI resolver class into PyXML/4Suite? The one already in 4Suite could serve as a start. Then Windows folks could add the right sys.platform-specific voodoo, and likewise UNIX users, MAC users, etc. Then, after this (probably slow) class is set up, we could look at ways of optimizing it witout breaking any of the sys.platform-specific algorithms. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From Sylvain.Thenault@logilab.fr Fri Jan 18 15:00:53 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Fri, 18 Jan 2002 16:00:53 +0100 (CET) Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: <200201180755.g0I7toV26589@localhost.localdomain> Message-ID: On Fri, 18 Jan 2002, Uche Ogbuji wrote: > > > All the convience methods defined on HTML elements are expecting the > > > attributes to stored via setAttribute not the NS verision. It would be > > > quite an udertaking to change all of those. Another problem is that > > > attribute names are not uppercased as element names are. > > > > Another way to fix this problem without reverting changes is to add to > > html elements a setAttributeNS method which delegate in the same way as > > setAttribute. > > Well, I have no desire to add to another's work-load. Given mine, that would > just be a case of misery looking for company. > > But I dislike this solution on semantic grounds. HTML has no conception of > namespaces, so using even the *appearance* of namespace methods on HTML > elements is, IMO quite problematic. As I said, I can easily revert the changes I made (remove HTMLDocument.createElementNS and call to NS method in Sgmlop) or add the setAttributeNS method. I only want to be sure we are going in the right way. regards -- Sylvain Thenault LOGILAB http://www.logilab.org From rsalz@zolera.com Fri Jan 18 17:32:19 2002 From: rsalz@zolera.com (Rich Salz) Date: Fri, 18 Jan 2002 12:32:19 -0500 Subject: [XML-SIG] IBM developerWorks articles Message-ID: <200201181732.g0IHWJo29663@os390.zolera.com> Jeff Condon sent me a list of all Python articles posted at the IBM developerWorks site. I listed the XML ones below; thanks Jeff. /r$ For over a year, IBM developerWorks has been posting a column in it's Linux Zone called 'Charming Python' by David Mertz and a series on 'Python Web Services'. Many of these articles are directly related to XML and are very popular. I know you are probably aware of some of these articles, but this is the whole collection. I hope this interest your user group. Cheers, Jeff Condon Revisiting XML tools for Python Get an updated overview of XML tools for Python. Unfortunately, most of the advances are not backwards compatible. http://www-106.ibm.com/developerworks/linux/library/l-pxml.html?open&l=397,t=grl,p=py12 The Python Web services developer: Part 1: The world of Python Web services This article presents an overview and survey of tools and facilities available for Web services development in Python. This includes built-in Python features and third-party open-source tools. http://www-106.ibm.com/developerworks/library/ws-pyth1?open&l=397,t=grws,p=pws1 The Python Web services developer, Part 2: Web services software repository, Part 1 Creating a software repository system built on Web services and developed in the Python programming language. Mike Olson shows you the details of using the 4Suite open-source XML server with Python to create Web service-based applications. http://www-106.ibm.com/developerworks/library/ws-pyth2?open&l=397,t=grws,p=pws2 The Python Web services developer, Part 3: Web services software repository, Part 2 Example of a Web service for storing and managing software. http://www-106.ibm.com/developerworks/library/ws-pyth3?open&l=397,t=grws,p=pws3 The Python Web services developer, Part 4: Web services software repository, Part 3 Building a software repository implemented as a Web service. http://www-106.ibm.com/developerworks/library/ws-pyth4?open&l=397,t=grws,p=pws4 The Python Web services developer, Part 5: Python SOAP libraries Discussion the various SOAP implementations available for Python, giving detailed code examples. http://www-106.ibm.com/developerworks/library/ws-pyth5?open&l=397,t=grws,p=pws5 Tinkering with XML and Python A major element of getting started on working with XML in Python is sorting out the comparative capabilities of all the available modules. In this first installment of his new Python column, "Charming Python," David Mertz briefly describes the most popular and useful XML-related Python modules, and points you to resources for downloading individual modules and reading more about them. This article will help you determine which modules are most appropriate for your specific task. (contains sample code) http://www-106.ibm.com/developerworks/linux/library/python1?open&l=397,t=grl,p=py22 Charming Python: The dynamics of DOM In this article, David Mertz examines in greater detail the use of the high-level xml.dom module for Python discussed in his last column. Working with xml.dom is illustrated by means of clarifying code samples and explanations of how to code many of the elements that go into a complete XML document processing system. (contains sample code) http://www-106.ibm.com/developerworks/linux/library/python2/index.html?open&l=397,t=grl,p=py23 From cstrong@arielpartners.com Fri Jan 18 18:46:27 2002 From: cstrong@arielpartners.com (Craeg K. Strong) Date: Fri, 18 Jan 2002 13:46:27 -0500 Subject: [XML-SIG] 4XSLT Bug Affecting Document() References: <200201180800.g0I805r26596@localhost.localdomain> Message-ID: <3C486D83.6060302@arielpartners.com> +100! As you know, Uche, we use URI resolvers to support URN resolution for _both_ stylesheets and documents, via subclassing both StylesheetReader and PyExpatReader, respectively. Having a high quality, fully-supported, extensible, official resolver thingie would be a major boon for us.... :-) Regards, --Craeg Uche Ogbuji wrote: >>While running transformations from Zope using 4xslt from 4suite 0.11.1, I >>found a bug that prevented document() from finding the specified file. This >>occurs in Windows, when a relative uri is used. I have hacked up a partial >>fix, but really a more comprehensive fix is needed. >> >>The problem fundamentally arises (I think) because urlparse.urlparse(uri) >>can wrongly think that a Windows drive specifier is a scheme. >> > >SNIP. > >This was also reported on the 4Suite mailing list. > >OK. I give up. I need help. I am mostly ignorant of Windows, and have no >easy way to test anything. > >Shall we just put a standard URI resolver class into PyXML/4Suite? The one >already in 4Suite could serve as a start. Then Windows folks could add the >right sys.platform-specific voodoo, and likewise UNIX users, MAC users, etc. > >Then, after this (probably slow) class is set up, we could look at ways of >optimizing it witout breaking any of the sys.platform-specific algorithms. > > -- Craeg K Strong, General Partner Ariel Partners LLC voice 781-647-2425 fax 781-647-9690 From tpassin@home.com Fri Jan 18 23:48:30 2002 From: tpassin@home.com (Thomas B. Passin) Date: Fri, 18 Jan 2002 18:48:30 -0500 Subject: [XML-SIG] 4XSLT Bug Affecting Document() References: <200201180800.g0I805r26596@localhost.localdomain> Message-ID: <001401c1a07a$a241cc80$7cac1218@cj64132b> [Uche Ogbuji] [Tom P] > > While running transformations from Zope using 4xslt from 4suite 0.11.1, I > > found a bug that prevented document() from finding the specified file. This > > occurs in Windows, when a relative uri is used. I have hacked up a partial > > fix, but really a more comprehensive fix is needed. > > > > The problem fundamentally arises (I think) because urlparse.urlparse(uri) > > can wrongly think that a Windows drive specifier is a scheme. > > SNIP. > > This was also reported on the 4Suite mailing list. > > OK. I give up. I need help. I am mostly ignorant of Windows, and have no > easy way to test anything. > > Shall we just put a standard URI resolver class into PyXML/4Suite? The one > already in 4Suite could serve as a start. Then Windows folks could add the > right sys.platform-specific voodoo, and likewise UNIX users, MAC users, etc. > > Then, after this (probably slow) class is set up, we could look at ways of > optimizing it witout breaking any of the sys.platform-specific algorithms. > I'd say so. Preferably pyxml but 4Suite would be OK too. It would need to handle file: urls correctly on all supported platforms (the standard python libs didn't, at least they didn't used to), and relative urls when they had various path steps like ..\..\, etc., and were on Windows (and wouldn't Macs tend to have problems too?). Beyond that, the machinery would be available for future extensions, which sounds good. Don't worry, I'm sure you will have plenty of help working things out on Windows. You can include me in that. Cheers, Tom P From martin@v.loewis.de Sat Jan 19 00:22:23 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sat, 19 Jan 2002 01:22:23 +0100 Subject: [XML-SIG] 4XSLT Bug Affecting Document() In-Reply-To: <001401c1a07a$a241cc80$7cac1218@cj64132b> (tpassin@home.com) References: <200201180800.g0I805r26596@localhost.localdomain> <001401c1a07a$a241cc80$7cac1218@cj64132b> Message-ID: <200201190022.g0J0MNB02697@mira.informatik.hu-berlin.de> > I'd say so. Preferably pyxml but 4Suite would be OK too. It would need to > handle file: urls correctly on all supported platforms (the standard python > libs didn't, at least they didn't used to) For that, somebody would need to define what "correct" handling is, in the first place. Regards, Martin From tpassin@home.com Sat Jan 19 02:33:35 2002 From: tpassin@home.com (Thomas B. Passin) Date: Fri, 18 Jan 2002 21:33:35 -0500 Subject: [XML-SIG] 4XSLT Bug Affecting Document() References: <200201180800.g0I805r26596@localhost.localdomain> <001401c1a07a$a241cc80$7cac1218@cj64132b> <200201190022.g0J0MNB02697@mira.informatik.hu-berlin.de> Message-ID: <002001c1a091$b1facbb0$7cac1218@cj64132b> [Martin v. Loewis] > > I'd say so. Preferably pyxml but 4Suite would be OK too. It would need to > > handle file: urls correctly on all supported platforms (the standard python > > libs didn't, at least they didn't used to) > > For that, somebody would need to define what "correct" handling is, in > the first place. > Yes, a challenge, but I think do-able. Cheers, Tom P From bre392@alibaba.com Sat Jan 19 18:48:20 2002 From: bre392@alibaba.com (¾­Ã³ÐÅÏ¢Íø) Date: Sat, 19 Jan 2002 18:48:20 Subject: [XML-SIG] ¶©Ôľ­Ã³ÐÅÏ¢£¬Ãâ·ÑË͹ú¼Ê¶¥¼¶ÓòÃû¡¢·þÎñÆ÷¿Õ¼ä¡¢ÐÅÏä Message-ID: ÄúºÃ ÎÒÃÇ¡¶¾­Ã³ÐÅÏ¢Íø¡·Ìṩ20Àà¹ú¼Ê¹úÄÚʵÓÃÐÅÏ¢£¬Ã¿ÌìµÄÐÅÏ¢Á¿¶à´ï1Õ× £¬¶øÇÒÿÌì¸üС£Äú¿ÉÒÔ¸ù¾Ý×Ô¼ºµÄÐèÒª°´À¸Ä¿Àà±ð¶©ÔÄ¡£ÎÒÃÇÿÌìÍí18µã ½«Äú¶©ÔĵÄÐÅÏ¢·¢Ë͵½ÄúµÄÐÅÏäÀï¡£ÎÒÃÇ´Ó1990Ä꿪ʼ´ÓÊÂÐÅÏ¢·þÎñ£¬Êǹú ÄÚ×îÔçʹÓüÆËã»úͨ¹ýµç»°ÍøºÍ»¥ÁªÍø½øÐÐÐÅÏ¢´«ÊäµÄµ¥Î»Ö®Ò»¡£ÐÅÏ¢Óû§ ±é¼°È«¹ú¸÷µØ£¬Ä¿Ç°ÒѾ­ÓÐ1800¶à¼Ò¹ú¼Ò»ú¹Ø¡¢ÆóÒµÊÂÒµµ¥Î»¡¢¿ÆÑкÍÐÅÏ¢ ·þÎñ»ú¹¹ÔÚʹÓÃÎÒÃǵÄÐÅÏ¢¡£¹ã·º¿É¿¿µÄÐÅÏ¢Ô´¡¢¼°Ê±µÄ·­Òë¡¢±à¼­¡¢¸üРºÍ10ÓàÄêµÄ¹¤×÷¾­Ñ飬±£Ö¤ÁËÐÅÏ¢µÄʱЧÐÔºÍ׼ȷÐÔ¡£ ´Ó¼´ÈÕÆð·²ÊǶ©ÔÄÎÒÃǵÄ20ÀàÐÅÏ¢ÖеÄÎåÀ༴¿ÉÃâ·Ñ»ñµÃÒ»¸ö¹ú¼Ê¶¥¼¶ ¶ÀÁ¢ÓòÃû¡¢100Õ׵ķþÎñÆ÷¿Õ¼äºÍ20¸ö¸ÃÓòÃûϵÄÐÅÏä(ÿ¸öÐÅÏä100Õ׵Ŀռä) ´ÓµÚ¶þÄêÆðÈç¹û²»¼ÌÐø¶©ÔÄÐÅÏ¢£¬ÓòÃû·Ñ¡¢¿Õ¼ä·ÑºÍÐÅÏäµÄ×Ü·ÑÓÃΪÿÄê300 ÔªÈËÃñ±Ò¡£ ÎÒÃÇ´Ó1995ÄêÆð¿ªÊ¼´ÓÊÂΪÆóÒµÊÂÒµµ¥Î»ÌṩÉÏÍø½¨Õ¾·þÎñ¡£Ä¿Ç°ÒѾ­ ÓµÓпͻ§½ü1100¼Ò£¬ÆäÖÐÓÐ ¹ú¼Ò·À»ð½¨²Ä¼à¶½¼ìÑéÖÐÐÄ ÖйúÄÚȼ»úÐÅÏ¢Íø ÖйúƤë½»Ò×Íø¡¢21ÉÌÎñÔÚÏߵȴóÍøÕ¾¡£Èç¹ûÄãÒѾ­ÓÐÁË×Ô¼ºµÄÍøÕ¾£¬Ò²¿É ÒÔתÒƵ½ÎÒÃǵķþÎñÆ÷ÉÏÀ´¡£ÒòΪÎÒÃÇÊÇרÃÅ´Óʾ­¼ÃÐÅÏ¢·þÎñ£¬ËùÒÔ·ÃÎÊ ÎÒÃǵÄÍøÕ¾¶¼ÊÇ´Óʸ÷½ÃæµÄÈËÔ±¡£°ÑÍøÕ¾·ÅÔÚÎÒÃǵķþÎñÆ÷Éϲ¢ÇÒÎÒÃÇÔÚ ¡¶¾­Ã³ÐÅÏ¢Íø¡·µÄÊ×Ò³ÉÏΪÄú×öÁ´½Ó£¬ÊƱضÔÌá¸ßÄãµÄÍøÕ¾µÄ·ÃÎÊÁ¿Æ𵽺ܺà µÄ×÷Óá£Ïêϸ×ÊÁÏÇë·ÃÎÊÎÒÃǵÄÍøÕ¾»òÓëÎÒÃÇÁªÏµ¡£ »¶Ó­¶©ÔÄÎÒÃǵÄÐÅÏ¢¡¢»¶Ó­ÔÚÎÒÃǵķþÎñÆ÷ÉϽ¨Á¢ÊôÓÚÄú×Ô¼ºµÄÍøÕ¾ http://www.bjccidd.com.cn Óʼþ wkl@bjccidd.com.cn (ÐÅÏ¢¶©ÔÄ¡¢ÊÔÓÃ) webmaster@bjccidd.com.cn (ÓòÃû×¢²á¡¢ÍøվתÈë) ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ ÏÂÔØÍøÖ·£ºhttp://love2net.51.net/£¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡­¡­ ---------------------------------------------------- INFORMATION This message has been sent using a trial-run version of the TSmtpRelayServer Delphi Component. ---------------------------------------------------- From Nicolas.Chauvat@logilab.fr Sat Jan 19 17:01:32 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Sat, 19 Jan 2002 18:01:32 +0100 (CET) Subject: [XML-SIG] ANN: talk on PyXML/4Suite at UK Python Conference on Apr 4th '02 Message-ID: Hi Lists, Alexandre and I are glad to announce that we will be giving a talk on PyXML and 4Suite at the first UK Python Conference on april 4th in Warwick, England (see ACCU programme on http://www.accuconference.co.uk/) We will be using 4Suite Server and Narval as examples of big applications relying on both libraries. We hope to see some of you there ! :-) -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France) From martin@v.loewis.de Sun Jan 20 09:32:06 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sun, 20 Jan 2002 10:32:06 +0100 Subject: [XML-SIG] Filtering nodes from a DOM tree In-Reply-To: (amk@mira.erols.com) References: Message-ID: <200201200932.g0K9W6R01325@mira.informatik.hu-berlin.de> > There are NodeIterator and TreeWalker classes in xml.dom, but looking > at the code they don't seem to cope with the tree being modified while > it's being traversed. Can you give a specific example of what you think should work but doesn't? From 1.1.1.2 of the DOM Traversal Range Specification: # A NodeIterator [p.19] may be active while the data structure it # navigates is being edited, so an iterator must behave gracefully in # the face of change. Additions and removals in the underlying data # structure do not invalidate a NodeIterator; in fact, a NodeIterator # is never invalidated unless its detach() method is invoked. To make # this possible, the iterator uses the reference node to maintain its # position. The state of an iterator also depends on whether the # iterator is positioned before or after the reference node. # If changes to the iterated list do not remove the reference node, # they do not affect the state of the NodeIterator [p.19] . For # instance, the iterator s state is not affected by inserting new # nodes in the vicinity of the iterator or removing nodes other than # the reference node.... It may be the case that there are bugs in the implementation. Without a specific example, it is hard to tell whether the problem is in 4DOM, in DOM itself, in your application of the DOM, or whether the Traversal APIs are simply not suited for what you want to achieve. Regards, Martin From martin@v.loewis.de Sun Jan 20 10:29:26 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sun, 20 Jan 2002 11:29:26 +0100 Subject: [XML-SIG] cloneNode doesn't copy attributes? In-Reply-To: (message from Jan Nieuwenhuizen on 14 Jan 2002 23:25:22 +0100) References: Message-ID: <200201201029.g0KATQW01644@mira.informatik.hu-berlin.de> > It seems that cloneNode in python-xml 0.7 (latest Debian unstable > python2.2-xml) doesn't copy attributes. Should it? It should; it is a typo in HTMLElement that it doesn't. Please apply the patch Index: HTMLElement.py =================================================================== RCS file: /cvsroot/pyxml/xml/xml/dom/html/HTMLElement.py,v retrieving revision 1.8 diff -u -r1.8 HTMLElement.py --- HTMLElement.py 2001/02/20 01:00:04 1.8 +++ HTMLElement.py 2002/01/20 10:22:49 @@ -88,7 +88,7 @@ if clone.localName is None: e.attributes.setNamedItem(clone) else: - self.attributes.setNamedItemNS(clone) + e.attributes.setNamedItemNS(clone) clone._4dom_setOwnerElement(self) return e > What am I doing wrong/what doco should I read? It would be good to read the DOM specification; see http://www.w3.org/TR/DOM-Level-2-Core/ In the definition of cloneNode, it quite explicitly states what to copy. > I've made several attempts to write something as simple as this, but > it seems not a trivial to determine which examples are obsolete, and > which are preferred now (xml.dom.html_builder.HtmlBuilder and > HtmlWriter are too old, pyexpat is too new/not for plain HTML, SAX is > simple, but I don't want simple, rather standard and java-like, but in > python, right? -- dazzle). I'm not sure what 'this' is precisely; SAX is both standard and Java-like. It is true that some examples are outdated; contributions are welcome. Regards, Martin From martin@v.loewis.de Sun Jan 20 10:45:45 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sun, 20 Jan 2002 11:45:45 +0100 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: (message from Sylvain Thenault on Thu, 17 Jan 2002 12:09:44 +0100 (CET)) References: Message-ID: <200201201045.g0KAjjR01706@mira.informatik.hu-berlin.de> > why ? Doesn't HTMLDocument inherit from the standard DOM level 2 Document? In DOM Level 2 HTML, it does indeed. > Originally, I made the change in Sgmlop to be able to give to Sgmlop a > pDomlette document (which doesn't implement the non NS methods). > Then I have overridden the createElementNS method in HTMLDocument to > delegate in the same manner as createElement, so I don't think it break > the standard HTML DOM behavior if you give to HTMLParser a HTMLDocument. I recommend to re-read section 1.6.3 of http://www.w3.org/TR/DOM-Level-2-HTML/html.html Attribute and element names should be exposed as uppercase if the original document was a HTML document, and should be lowercase if the original document was a XHTML document. I'm not certain whether 4DOM HTML supports XHTML at all, but in any case, there should be a strategy how to support both HTML and XHTML. Regards, Martin From martin@v.loewis.de Sun Jan 20 10:49:30 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sun, 20 Jan 2002 11:49:30 +0100 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: <200201170051.g0H0p7n12564@localhost.localdomain> (message from Uche Ogbuji on Wed, 16 Jan 2002 17:51:07 -0700) References: <200201170051.g0H0p7n12564@localhost.localdomain> Message-ID: <200201201049.g0KAnUn01709@mira.informatik.hu-berlin.de> > In dom.ext.reader.Sgmlop.py and other places, The NS methods are > erroneously being used for HTML DOM manipulation. This breaks apps > that are expecting the resulting nodes to have the mandated HTML DOM > behavior (i.e. uppercase-normalized tagnames and the like). It seems that 4DOM currently is more generous in providing this behaviour than actually mandated. While I can find the text that says that a body element should have a tagName of "BODY", nowhere I can see a requirement that query function have to uppercase silently, as done, e.g. in def getAttributeNode(self, name): return self.attributes.getNamedItem(string.upper(name)) So it seems to me that upper-casing is best done in the DOM builder, not in the DOM implementation. Regards, Martin From rob.slotboom@buxus.nl Sun Jan 20 13:24:30 2002 From: rob.slotboom@buxus.nl (Robert Slotboom) Date: Sun, 20 Jan 2002 14:24:30 +0100 Subject: [XML-SIG] pyxml and macpython Message-ID: Hi, I searched quite some time but I couldn't find the pre-compiled pyxml code for macPython. Once I found a link, it was dead :-( http://py-howto.sourceforge.net/xml-howto/node4.html -- Best regards, Robert Slotboom Buxus Webstudio The Netherlands www.buxus.nl From janneke@gnu.org Sun Jan 20 14:14:04 2002 From: janneke@gnu.org (Jan Nieuwenhuizen) Date: Sun, 20 Jan 2002 15:14:04 +0100 Subject: [XML-SIG] cloneNode doesn't copy attributes? In-Reply-To: <200201201029.g0KATQW01644@mira.informatik.hu-berlin.de> ("Martin v. Loewis"'s message of "Sun, 20 Jan 2002 11:29:26 +0100") References: <200201201029.g0KATQW01644@mira.informatik.hu-berlin.de> Message-ID: "Martin v. Loewis" writes: > It should; it is a typo in HTMLElement that it doesn't. Please apply > the patch This works, thanks a lot! >> What am I doing wrong/what doco should I read? > > It would be good to read the DOM specification; see > > http://www.w3.org/TR/DOM-Level-2-Core/ Ok. > I'm not sure what 'this' is precisely; Oh, just that first simple python-xml thing in my previous message. > SAX is both standard and Java-like. It is true that some examples > are outdated; contributions are welcome. Ah, ok, I understand. Now I realise that old examples can be bad, for newcomers; they just add the extra bit of confusement that's not helpful when you're trying to enter a new project. Because I found several ways of parsing html, I figured that there were `competing' projects and really didn't know where to start, which one to use. (py)expat is just for parsing and doing your own stuff. Minidom is a real small thing for small jobs with cleanish xml. Dom full flexed and done by 4dom, and sax is just, well, sax. Greetings, Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org From tpassin@home.com Sun Jan 20 16:13:08 2002 From: tpassin@home.com (Thomas B. Passin) Date: Sun, 20 Jan 2002 11:13:08 -0500 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods References: <200201201045.g0KAjjR01706@mira.informatik.hu-berlin.de> Message-ID: <000e01c1a1cd$5a3ab8d0$7cac1218@cj64132b> [Martin v. Loewis] > > I recommend to re-read section 1.6.3 of > > http://www.w3.org/TR/DOM-Level-2-HTML/html.html > > Attribute and element names should be exposed as uppercase if the > original document was a HTML document, and should be lowercase if the > original document was a XHTML document. I'm not certain whether 4DOM > HTML supports XHTML at all, but in any case, there should be a > strategy how to support both HTML and XHTML. > We want to be careful here - the HTML names are "exposed" in uppercase, but they are CASE-INSENSITIVE in the markup. We need to make sure to maintain the case-insensitivity when the html source is originally parsed, as well as when names are compared. Cheers, Tom P From tpassin@home.com Sun Jan 20 16:16:11 2002 From: tpassin@home.com (Thomas B. Passin) Date: Sun, 20 Jan 2002 11:16:11 -0500 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods References: <200201170051.g0H0p7n12564@localhost.localdomain> <200201201049.g0KAnUn01709@mira.informatik.hu-berlin.de> Message-ID: <001301c1a1cd$c6ba99d0$7cac1218@cj64132b> [Martin v. Loewis] > > In dom.ext.reader.Sgmlop.py and other places, The NS methods are > > erroneously being used for HTML DOM manipulation. This breaks apps > > that are expecting the resulting nodes to have the mandated HTML DOM > > behavior (i.e. uppercase-normalized tagnames and the like). > > It seems that 4DOM currently is more generous in providing this > behaviour than actually mandated. While I can find the text that says > that a body element should have a tagName of "BODY", nowhere I can see > a requirement that query function have to uppercase silently, as done, > e.g. in > > def getAttributeNode(self, name): > return self.attributes.getNamedItem(string.upper(name)) > > So it seems to me that upper-casing is best done in the DOM builder, > not in the DOM implementation. > The upper-casing is only for output, any comparisons of element and attribute names are supposed to be case-insensitive From section 1.3 of the HTML DOM Rec (http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-2041995112): "There are basically two things that need to be taken into account, one is that when comparing element or attribute names to strings the string compare needs to be case insensitive, or the element or attribute name needs to be converted into lowercase before comparing against a lowercase string. The other thing is that when calling methods that are case insensitive when used on a HTML document (such as getElementsByTagName() and namedItem()) the string that is passed in should be lower case to work on both HTML and XHTML documents." Cheers, Tom P From martin@v.loewis.de Sun Jan 20 19:22:48 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sun, 20 Jan 2002 20:22:48 +0100 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: <000e01c1a1cd$5a3ab8d0$7cac1218@cj64132b> (tpassin@home.com) References: <200201201045.g0KAjjR01706@mira.informatik.hu-berlin.de> <000e01c1a1cd$5a3ab8d0$7cac1218@cj64132b> Message-ID: <200201201922.g0KJMma01330@mira.informatik.hu-berlin.de> > We want to be careful here - the HTML names are "exposed" in uppercase, but > they are CASE-INSENSITIVE in the markup. We need to make sure to maintain > the case-insensitivity when the html source is originally parsed, as well as > when names are compared. Can you please give the precise chapter and verse of the DOM spec that say name comparison must be case-insensitive? Regards, Martin From martin@v.loewis.de Sun Jan 20 19:14:45 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sun, 20 Jan 2002 20:14:45 +0100 Subject: [XML-SIG] pyxml and macpython In-Reply-To: (message from Robert Slotboom on Sun, 20 Jan 2002 14:24:30 +0100) References: Message-ID: <200201201914.g0KJEjp01307@mira.informatik.hu-berlin.de> > I searched quite some time but I couldn't find the pre-compiled > pyxml code for macPython. Once I found a link, it was dead :-( What MacOS version? For OS X, it is easy to compile it out of the box; no need for precompiled binaries. Regards, Martin From martin@v.loewis.de Sun Jan 20 20:43:32 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Sun, 20 Jan 2002 21:43:32 +0100 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: <001301c1a1cd$c6ba99d0$7cac1218@cj64132b> (tpassin@home.com) References: <200201170051.g0H0p7n12564@localhost.localdomain> <200201201049.g0KAnUn01709@mira.informatik.hu-berlin.de> <001301c1a1cd$c6ba99d0$7cac1218@cj64132b> Message-ID: <200201202043.g0KKhWd01681@mira.informatik.hu-berlin.de> > (http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-2041995112): > > "There are basically two things that need to be taken into account, one is > that when comparing element or attribute names to strings the string compare > needs to be case insensitive, or the element or attribute name needs to be > converted into lowercase before comparing against a lowercase string. The > other thing is that when calling methods that are case insensitive when used > on a HTML document (such as getElementsByTagName() and namedItem()) the > string that is passed in should be lower case to work on both HTML and XHTML > documents." I'm confused. Is this a requirement on DOM implementations, or on DOM applications? It appears that it says that it says that getElementsByTagName is case-insensitive. I wonder where it actually says so. In particular, 1.1.7 of DOM 2 Core says (http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-5DFED1F0) # The DOM has many interfaces that imply string matching. HTML # processors generally assume an uppercase (less often, lowercase) # normalization of names for such things as elements, while XML is # explicitly case sensitive. For the purposes of the DOM, string # matching is performed purely by binary comparison of the 16-bit # units of the DOMString. In addition, the DOM assumes that any case # normalizations take place in the processor, before the DOM # structures are built. So, to the contrary, it appears that the DOM explicitly disallows to perform case-insensitive string comparison inside the DOM implementation. Regards, Martin From tpassin@home.com Mon Jan 21 01:29:24 2002 From: tpassin@home.com (Thomas B. Passin) Date: Sun, 20 Jan 2002 20:29:24 -0500 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods References: <200201170051.g0H0p7n12564@localhost.localdomain> <200201201049.g0KAnUn01709@mira.informatik.hu-berlin.de> <001301c1a1cd$c6ba99d0$7cac1218@cj64132b> <200201202043.g0KKhWd01681@mira.informatik.hu-berlin.de> Message-ID: <000c01c1a21b$0fd441f0$7cac1218@cj64132b> [Martin v. Loewis] [Tom P]: > > (http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-2041995112): > > > > "There are basically two things that need to be taken into account, one is > > that when comparing element or attribute names to strings the string compare > > needs to be case insensitive, or the element or attribute name needs to be > > converted into lowercase before comparing against a lowercase string. The > > other thing is that when calling methods that are case insensitive when used > > on a HTML document (such as getElementsByTagName() and namedItem()) the > > string that is passed in should be lower case to work on both HTML and XHTML > > documents." > > I'm confused. Is this a requirement on DOM implementations, or on DOM > applications? It appears that it says that it says that > getElementsByTagName is case-insensitive. I wonder where it actually > says so. In particular, 1.1.7 of DOM 2 Core says > > (http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-5DFED1F0) > # The DOM has many interfaces that imply string matching. HTML > # processors generally assume an uppercase (less often, lowercase) > # normalization of names for such things as elements, while XML is > # explicitly case sensitive. For the purposes of the DOM, string > # matching is performed purely by binary comparison of the 16-bit > # units of the DOMString. In addition, the DOM assumes that any case > # normalizations take place in the processor, before the DOM > # structures are built. > > So, to the contrary, it appears that the DOM explicitly disallows to > perform case-insensitive string comparison inside the DOM > implementation. > Good point. The text I quoted appears in the DOM Rec, but as I re-read those sections it does look like they are giving advice to application developers. It seems that they are saying that, if you want to use the (xml) DOM with HTML documents, to lowercase all names before comparing them, since XHTML uses lowercase names. Presumably an HTML parser will have creat ed a DOM document with upper-case names before you get to the point of doing comparisons. Cheers, Tom P From tony.becker@fortpedro.com Mon Jan 21 02:28:48 2002 From: tony.becker@fortpedro.com (Tony Becker) Date: Sun, 20 Jan 2002 20:28:48 -0600 Subject: [XML-SIG] XML Schema and Python In-Reply-To: <200201180648.g0I6mQZ01677@mira.informatik.hu-berlin.de> References: <200201172157.QAA08709@tux.w3.org> <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> <200201172345.SAA04100@tux.w3.org> <200201180648.g0I6mQZ01677@mira.informatik.hu-berlin.de> Message-ID: >Rich Salz is apparently the only one who was working with LTXML; as he >said, he says he's given up. It is not likely that anybody step come >forward with XML Schema support anytime soon; people are rather >looking into Relax NG, Schematron, etc. I would love to see _some_ kind of XML Schema support for Python. I think the Apache XML Project's Xerces/C++ parser supports the relevant features. How difficult would it be to produce Python bindings for that library? TB -- Tony Becker, Application Architect Fort Pedro Informatics LLC, Chicago, IL USA http://fortpedro.com From rsalz@zolera.com Mon Jan 21 02:44:52 2002 From: rsalz@zolera.com (Rich Salz) Date: Sun, 20 Jan 2002 21:44:52 -0500 Subject: [XML-SIG] XML Schema and Python References: <200201172157.QAA08709@tux.w3.org> <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> <200201172345.SAA04100@tux.w3.org> <200201180648.g0I6mQZ01677@mira.informatik.hu-berlin.de> Message-ID: <3C4B80A4.76168CC1@zolera.com> Check out SOAPy, soapy.sf.net: "SOAPy is a SOAP/XML Schema Library for Python. Given either a WSDL or SDL document, SOAPy discovers the published API for a web service and exposes it to Python applications as transparently as possible. SOAPy is designed to support WSDL 1.0 and SOAP 1.1," /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com From martin@v.loewis.de Mon Jan 21 06:30:34 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Mon, 21 Jan 2002 07:30:34 +0100 Subject: [XML-SIG] 4DOM HTML erroneously using NS methods In-Reply-To: <000c01c1a21b$0fd441f0$7cac1218@cj64132b> (tpassin@home.com) References: <200201170051.g0H0p7n12564@localhost.localdomain> <200201201049.g0KAnUn01709@mira.informatik.hu-berlin.de> <001301c1a1cd$c6ba99d0$7cac1218@cj64132b> <200201202043.g0KKhWd01681@mira.informatik.hu-berlin.de> <000c01c1a21b$0fd441f0$7cac1218@cj64132b> Message-ID: <200201210630.g0L6UYc01318@mira.informatik.hu-berlin.de> > Good point. The text I quoted appears in the DOM Rec, but as I re-read > those sections it does look like they are giving advice to application > developers. It seems that they are saying that, if you want to use the > (xml) DOM with HTML documents, to lowercase all names before comparing them, > since XHTML uses lowercase names. Presumably an HTML parser will have creat > ed a DOM document with upper-case names before you get to the point of doing > comparisons. Yes, that's how I read it as well. In the light of this, the advice you quoted (always pass lower-case strings, to make it work both with HTML and XHTML) becomes hard to understand, though. Regards, Martin From martin@v.loewis.de Mon Jan 21 06:38:30 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Mon, 21 Jan 2002 07:38:30 +0100 Subject: [XML-SIG] XML Schema and Python In-Reply-To: (message from Tony Becker on Sun, 20 Jan 2002 20:28:48 -0600) References: <200201172157.QAA08709@tux.w3.org> <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> <200201172345.SAA04100@tux.w3.org> <200201180648.g0I6mQZ01677@mira.informatik.hu-berlin.de> Message-ID: <200201210638.g0L6cUr01341@mira.informatik.hu-berlin.de> > I think the Apache XML Project's Xerces/C++ parser supports the=20 > relevant features. How difficult would it be to produce Python=20 > bindings for that library? I think PIRXX would be the best starting point to do that; see http://pirxx.sourceforge.net/ I'm sure J=FCrgen would appreciate contributions. Regards, Martin From Juergen Hermann" Message-ID: On Sun, 20 Jan 2002 20:28:48 -0600, Tony Becker wrote: >I would love to see _some_ kind of XML Schema support for Python. > >I think the Apache XML Project's Xerces/C++ parser supports the >relevant features. How difficult would it be to produce Python >bindings for that library? There are, for SAX. And the Schema properties are exposed, though I never tried them. Ciao, J=FCrgen -- J=FCrgen Hermann, Developer (jhe@webde-ag.de) WEB.DE AG, http://webde-ag.de/ From paul@prescod.net Mon Jan 21 20:20:24 2002 From: paul@prescod.net (Paul Prescod) Date: Mon, 21 Jan 2002 12:20:24 -0800 Subject: [XML-SIG] XML Schema and Python References: <200201172157.QAA08709@tux.w3.org> Message-ID: <3C4C7808.2963DBBF@prescod.net> Joseph Reagle wrote: > > Just wondering if the folks hear are interested in schema? There is a > schema processor (validation and infoset augmentation) already written in > Python (1.5 and using a different library LTXML [1]) and I was wondering if > anyone had given any thought of bringing it "into the fold"? > > [1] http://www.ltg.ed.ac.uk/software/xml/ I am somewhat interested in schema and have used XSV. The license is radically different than Python's and I'm reluctant to put in any effort on GPL projects because I may find that at my next job I can't use the work I did because of the license. Paul Prescod From Francois-regis.Chalaoux@sanofi-synthelabo.com Tue Jan 22 09:17:27 2002 From: Francois-regis.Chalaoux@sanofi-synthelabo.com (Francois-regis Chalaoux) Date: Tue, 22 Jan 2002 10:17:27 +0100 Subject: [XML-SIG] xml.sax._exceptions.SAXParseException question Message-ID: <"020122093317Z.WT09054. 17*/PN=Francois-regis.Chalaoux/O=RESEARCH/PRMD=SANOFI/ADMD=ATLAS/C=FR/"@MHS> Hi, Trying to treat an xml file I got an exception (see below). The error seems to arise from the character '&'. Is it not permited to use this character in a character data zone ? Exception pour 101130613811641 xml.sax._exceptions.SAXParseException :24:64: not well-formed (invalid token) Regards, FR. From Sylvain.Thenault@logilab.fr Tue Jan 22 09:59:12 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Tue, 22 Jan 2002 10:59:12 +0100 (CET) Subject: [XML-SIG] xml.sax._exceptions.SAXParseException question In-Reply-To: <"020122093317Z.WT09054. 17*/PN=Francois-regis.Chalaoux/O=RESEARCH/PRMD=SANOFI/ADMD=ATLAS/C=FR/"@MHS> Message-ID: On Tue, 22 Jan 2002, Francois-regis Chalaoux wrote: > Hi, > > Trying to treat an xml file I got an exception (see below). The error seems to arise from the character '&'. > Is it not permited to use this character in a character data zone ? no it isn't, you should use the predefined entity & cheers -- Sylvain Thenault LOGILAB http://www.logilab.org From Nicolas.Chauvat@logilab.fr Tue Jan 22 10:01:06 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Tue, 22 Jan 2002 11:01:06 +0100 (CET) Subject: [XML-SIG] xml.sax._exceptions.SAXParseException question In-Reply-To: <"020122093317Z.WT09054. 17*/PN=Francois-regis.Chalaoux/O=RESEARCH/PRMD=SANOFI/ADMD=ATLAS/C=FR/"@MHS> Message-ID: > Trying to treat an xml file I got an exception (see below). The error > seems to arise from the character '&'. Is it not permited to use this > character in a character data zone ? In character data, you *have*to* quote & and < for your XML to be well formed. & becomes & and < becomes < -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France) From tpassin@home.com Tue Jan 22 13:29:55 2002 From: tpassin@home.com (Thomas B. Passin) Date: Tue, 22 Jan 2002 08:29:55 -0500 Subject: [XML-SIG] xml.sax._exceptions.SAXParseException question References: <"020122093317Z.WT09054. 17*/PN=Francois-regis.Chalaoux/O=RESEARCH/PRMD=SANOFI/ADMD=ATLAS/C=FR/"@MHS> Message-ID: <000d01c1a348$e1dbdd60$0bf13044@cj64132b> [Francois-regis Chalaoux] > Hi, > > Trying to treat an xml file I got an exception (see below). The error seems to arise from the character '&'. > Is it not permited to use this character in a character data zone ? > You can only use a plain "&" character in a CDATA section, not in attribute or element content or anywhere else. Tom P From Andrew Dalke" Hey all, I'm trying to work with XML namespaces the backwards way around, and I'm getting lost. I'm trying to figure out what I need to do to build a DOM via SAX events with proper namespace support so I can do XPath queries on the resulting document. I'm lost because I can't figure out what's SAX1 compared to SAX2, how namespaces changes things (eg, what's the difference between startElement and startElementNS?), and how to use XPath for namespace'ed queries. I ordered the Jones&Drake "Python&XML" book but only found 1/2 page on namespaces. I found documentation on the 4Suite site which gives me enough to do a namespace'd XPath if I read the XML from a file - I needed a Context with the propere namespace defined. But I couldn't figure out how to make that DOM "by hand." Here's some background to know where I'm coming from. I've written a parser engine called Martel (some details at http://www.dalkescientific.com/ ). This uses a regular expression grammar to generate a parser, which parses a file and produce SAX events. I wrote it as a way to transition between existing flat-/semi-structured formats and XML. Here's an example use. Suppose you have a simple "key = value" file format where lines in the file look like # This is a comment name = Andrew city = Santa Fe With Martel this could be parsed with import Martel skip_line = Martel.Re(r"#[^\n]*\n| *\n") kv = Martel.Re(r"(?P\w+) *= *(?P[^\n]*\n") # Group is the same as r"(?P....) entry = Martel.Group("entry", kv) # Can have 0 or more repeats of these two line definitions format = Martel.Rep(skip_line | entry) # Make the parser parser = format.make_parser() # Now show the XML output from xml.sax import saxutils parser.setContentHandler(saxutils.XMLGenerator()) parser.parse(open("file.dat") With the above example text, the output is # This is a comment name = Andrew city = Santa Fe which makes it easy to pick out those key/value fields using standard XML techniques. I want to come up with a set of tag names which can be shared across different format definitions. I thought the best solution was to put them in their own namespace, as in: ID 100K_RAT ... AC P126943 ... (FYI, attrs are encoded in the regular expression as (?Pexpression) ) This is all done with my limited understanding of namespaces and SAX, so the ContentHandler gets the following events startDocument() startElement("bioformat:dataset", {}) startElement("bioformat:record", {}) characters("ID ") startElement("bioformat:dbid", {"type": "primary"}) characters("100K_RAT") endElement("bioformat:dbid") .. characters("AC ") ... (The {}'s are proper Attribute objects, and not simple {}s) I can stick a pulldom.SAX2DOM on the parser as the ContentHandler, and it produces a document. However, it seems that I can't get access to the namespaced terms via XPath. I know I'm not far wrong because I can use XPath to get the non-namespaced fields, and if I save the text to a file then read it in then I can also do namespace'ed XPath queries. (Umm, though to do that I need to change the input text to include a namespace ) So I suspect that my understanding of the SAX is incorrect. Can someone here show me how to generate SAX2 events by-hand and put the results in a DOM, then show how to do an XPath query on that DOM? I also don't know how to deal with parser features, but that's something that can wait. I'll be at the conference, with code, and wanting to bug people in person. :) Thanks! Andrew dalke@dalkescientific.com From Sylvain.Thenault@logilab.fr Wed Jan 23 10:09:54 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Wed, 23 Jan 2002 11:09:54 +0100 (CET) Subject: [XML-SIG] dom building, sax, and namespaces In-Reply-To: <001001c1a3e9$99248760$0201a8c0@josiah.dalkescientific.com> Message-ID: On Wed, 23 Jan 2002, Andrew Dalke wrote: > Hey all, > > I'm trying to work with XML namespaces the backwards way > around, and I'm getting lost. I'm trying to figure out > what I need to do to build a DOM via SAX events with > proper namespace support so I can do XPath queries on > the resulting document. > > I'm lost because I can't figure out what's SAX1 compared > to SAX2, how namespaces changes things (eg, what's the > difference between startElement and startElementNS?), > and how to use XPath for namespace'ed queries. first, startElement and startElementNS are both part of SAX2 (SAX1 is deprecated). Which one is called by the parser depends on the 'feature_namespaces' feature. With the feature_namespaces on, the parser call the *NS methods and does a part of the namespace handling job. > I ordered the Jones&Drake "Python&XML" book but only found > 1/2 page on namespaces. I found documentation on the 4Suite > site which gives me enough to do a namespace'd XPath if I > read the XML from a file - I needed a Context with the > propere namespace defined. But I couldn't figure out how > to make that DOM "by hand." > > Here's some background to know where I'm coming from. > > I've written a parser engine called Martel (some details at > http://www.dalkescientific.com/ ). This uses a regular > expression grammar to generate a parser, which parses a > file and produce SAX events. I wrote it as a way to transition > between existing flat-/semi-structured formats and XML. > > Here's an example use. Suppose you have a simple "key = value" > file format where lines in the file look like > > # This is a comment > name = Andrew > city = Santa Fe > > With Martel this could be parsed with > > import Martel > skip_line = Martel.Re(r"#[^\n]*\n| *\n") > kv = Martel.Re(r"(?P\w+) *= *(?P[^\n]*\n") > # Group is the same as r"(?P....) > entry = Martel.Group("entry", kv) > > # Can have 0 or more repeats of these two line definitions > format = Martel.Rep(skip_line | entry) > > # Make the parser > parser = format.make_parser() > > # Now show the XML output > from xml.sax import saxutils > parser.setContentHandler(saxutils.XMLGenerator()) > parser.parse(open("file.dat") > > With the above example text, the output is > > > # This is a comment > name = Andrew > city = Santa Fe > herr, I guess this is only a part of your xml output, since this sample isn't a well formed xml document (no root element) > which makes it easy to pick out those key/value fields > using standard XML techniques. > > I want to come up with a set of tag names which can be > shared across different format definitions. I thought > the best solution was to put them in their own namespace, > as in: > > > > ID 100K_RAT ... > AC P126943 ... > > (FYI, attrs are encoded in the regular expression as > (?Pexpression) > ) > > This is all done with my limited understanding of namespaces > and SAX, so the ContentHandler gets the following events > > startDocument() > startElement("bioformat:dataset", {}) > startElement("bioformat:record", {}) > characters("ID ") > startElement("bioformat:dbid", {"type": "primary"}) > characters("100K_RAT") > endElement("bioformat:dbid") > .. > characters("AC ") > ... > > (The {}'s are proper Attribute objects, and not simple {}s) > > I can stick a pulldom.SAX2DOM on the parser as the ContentHandler, > and it produces a document. However, it seems that I can't > get access to the namespaced terms via XPath. I know I'm > not far wrong because I can use XPath to get the non-namespaced > fields, and if I save the text to a file then read it in then > I can also do namespace'ed XPath queries. (Umm, though to do > that I need to change the input text to include a namespace > > ) the namespace declaration should be included in your generated events. I guess that's why you can't access the namespaced elements via XPath (I don't why pulldom.SAX2DOM doesn't complain, but it should) > So I suspect that my understanding of the SAX is incorrect. > Can someone here show me how to generate SAX2 events by-hand > and put the results in a DOM, then show how to do an XPath > query on that DOM? The correct sax events for your example should be: _ if feature_namespaces == 0 startDocument() startElement('bioformat:dataset', {'xmlns:bioformat': 'http://biopython.org/bioformat'}) startElement("bioformat:record", {}) ... endElement('bioformat:dataset') endDocument() _ if feature_namespaces == 1 startDocument() startPrefixMapping('bioformat', 'http://biopython.org/bioformat') startElementNS(('http://biopython.org/bioformat','dataset'), 'bioformat:dataset', {}) startElementNS(('http://biopython.org/bioformat', 'record'), 'bioformat:record', {}) characters("ID ") startElementNS(('http://biopython.org/bioformat', 'dbid'), 'bioformat:dbid', {(EMPTY_NAMESPACE, 'type'): 'primary'}) ... endElementNS(('http://biopython.org/bioformat','dataset'), 'bioformat:dataset') endPrefixMapping('bioformat') endDocument() namespaces declaration are reported in the attributes dictionnary or not (BTW, it's a AttributeNSImpl in the feature_namespaces on version) depending on the feature_namespace_prefixes feature. Look at xml.sax.saxutils.XMLGenerator to see how to handle namespaces and dom generation (the main difficulty is to handle a context stack which map defined prefixes to namespaces) To do an xpath query on the dom tree, you have to use a context (as you seem to be aware). Here is an example (where dom_node is your dom document): from xml.xpath import Compile from xml.xpath.Context import Context path = Compile('bioformat:dbid[@type="primary"]') context = Context(dom_node, processorNss={'bioformat' : 'http://biopython.org/bioformat'}) node_set = path.evaluate(context) > I also don't know how to deal with parser features, but that's > something that can wait. I'll be at the conference, with code, > and wanting to bug people in person. :) see http://www.saxproject.org/ for more information hope that helps ! regards -- Sylvain Thenault LOGILAB http://www.logilab.org From Andrew Dalke" Sylvain Thenault: > [ a detail response to my post] Thanks! Looks like I was close. I'll try your suggestions out this morning. Andrew dalke@dalkescientific.com From dalke@acm.org Wed Jan 23 16:21:20 2002 From: dalke@acm.org (Andrew Dalke) Date: Wed, 23 Jan 2002 09:21:20 -0700 Subject: [XML-SIG] dom building, sax, and namespaces Message-ID: <3C4EE300.36B7216B@acm.org> Sylvain Thenault: > the namespace declaration should be included in your generated events. I > guess that's why you can't access the namespaced elements via XPath (I > don't why pulldom.SAX2DOM doesn't complain, but it should) I retract that statement. It does complain. >>> from xml.dom import pulldom >>> >>> builder = pulldom.SAX2DOM() >>> builder.startDocument() >>> builder.startElement('bioformat:dataset', ... {'xmlns:bioformat': 'http://biopython.org/bioformat'}) Traceback (most recent call last): File "", line 2, in ? File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/pulldom.py", line 295, in startElement PullDOM.startElement(self, name, attrs) File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/pulldom.py", line 122, in startElement node = self.buildDocument(None, name) File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/pulldom.py", line 173, in buildDocument node = self.documentFactory.createDocument(uri, tagname, None) File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/minidom.py", line 812, in createDocument raise xml.dom.NamespaceErr( xml.dom.NamespaceErr: illegal use of prefix without namespaces Is there some way I can build a proper namespace'd DOM without having the parser support feature_namespaces? Some sort of adapter, perhaps? I couldn't find such in the codebase. I did find code as in sax/drivers2/drv_xmlproc.py which I think I could use to write such an adapter, but it would be better if someone pointed out to me existing code rather than chance my misunderstandings and errors. Andrew dalke@dalkescientific.com From dalke@acm.org Wed Jan 23 16:59:31 2002 From: dalke@acm.org (Andrew Dalke) Date: Wed, 23 Jan 2002 09:59:31 -0700 Subject: [XML-SIG] dom building, sax, and namespaces References: <3C4EE300.36B7216B@acm.org> Message-ID: <3C4EEBF3.A60D6BE8@acm.org> This is a multi-part message in MIME format. --------------7135BB0CCAF7385C00ED9BB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Me: > Is there some way I can build a proper namespace'd DOM without having > the parser support feature_namespaces? Some sort of adapter, perhaps? > I couldn't find such in the codebase. I did find code as in > > sax/drivers2/drv_xmlproc.py > > which I think I could use to write such an adapter, but it would > be better if someone pointed out to me existing code rather than > chance my misunderstandings and errors. Attached is the adapter code I copied and tweaked from drv_xmlproc.py. It does seem to work in that the following gives me output. Yippee! (BTW, is there no built-in function to get the concatenation of all the text nodes, like my get_text function, below?) ####################### from xml.dom import pulldom import SaxNSAdapter # <<----- my adapter real_builder = pulldom.SAX2DOM() builder = SaxNSAdapter.SaxNSAdapter(real_builder) builder.startDocument() builder.startElement('bioformat:dataset', {'xmlns:bioformat': 'http://biopython.org/bioformat'}) builder.startElement("bioformat:record", {}) builder.startElement("bioformat:dbid", {"type": "primary"}) builder.characters("100K_RAT") builder.endElement("bioformat:dbid") builder.startElement("bioformat:dbid", {"type": "accession"}) builder.characters("Q61294") builder.endElement("bioformat:dbid") builder.characters("Andrew") builder.endElement("bioformat:record") builder.startElement("bioformat:record", {}) builder.startElement("bioformat:dbid", {"type": "primary"}) builder.characters("A1AT_BOMMO") builder.endElement("bioformat:dbid") builder.characters("Dalke") builder.endElement("bioformat:record") builder.endElement('bioformat:dataset') builder.endDocument() dom_node = real_builder.document from xml.xpath import Compile from xml.xpath.Context import Context path = Compile('//bioformat:dbid[@type="primary"]') context = Context(dom_node, processorNss={'bioformat' : 'http://biopython.org/bioformat'}) node_set = path.evaluate(context) def get_text(node): words = [] def _get_text(nodeList, words = words): for subnode in nodeList: if subnode.nodeType == subnode.ELEMENT_NODE: _get_text(subnode.childNodes) elif subnode.nodeType == subnode.TEXT_NODE: words.append(subnode.data) _get_text([node]) return "".join(words) for node in node_set: print "-->", get_text(node) Andrew dalke@dalkescientific.com --------------7135BB0CCAF7385C00ED9BB3 Content-Type: text/plain; charset=us-ascii; name="SaxNSAdapter.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="SaxNSAdapter.py" from xml.sax import handler from xml.sax.xmlreader import AttributesImpl, AttributesNSImpl class SaxNSAdapter(handler.ContentHandler): def __init__(self, cont_handler): self._cont_handler = cont_handler def startDocument(self): self.ns_map = {"": None} # Current prefix - URI map self.ns_map["xml"] = "http://www.w3.org/XML/1998/namespace" self.ns_stack = [] # Pushed for each element, used to maint ns_map self.rep_ns_attrs = 0 # Report xmlns-attributes? self._cont_handler.startDocument() def endDocument(self): self._cont_handler.endDocument() def characters(self, s): self._cont_handler.characters(s) def startElement(self, name, attrs): old_ns = {} # Reset ns_map to these values when we leave this element del_ns = [] # Delete these prefixes from ns_map when we leave element # Find declarations, update self.ns_map and self.ns_stack for (a,v) in attrs.items(): if a[:6]=="xmlns:": prefix=a[6:] if prefix.find(":") != -1: raise TypeError("unknown double namespace: %r" % a) elif a=="xmlns": prefix="" else: continue if self.ns_map.has_key(prefix): old_ns[prefix]=self.ns_map[prefix] if v: self.ns_map[prefix]=v else: del self.ns_map[prefix] if not self.rep_ns_attrs: del attrs[a] self.ns_stack.append((old_ns,del_ns)) # Process elem and attr names cooked_name = self.__process_name(name) ns = cooked_name[0] rawnames = {} for (a,v) in attrs.items(): del attrs[a] aname = self.__process_name(a, is_attr=1) if attrs.has_key(aname): self.parser.report_error(1903) attrs[aname] = v rawnames[aname] = a # Report event self._cont_handler.startElementNS(cooked_name, name, AttributesNSImpl(attrs, rawnames)) def endElement(self, rawname): name = self.__process_name(rawname) # Clean up self.ns_map and self.ns_stack (old_ns,del_ns)=self.ns_stack[-1] del self.ns_stack[-1] self.ns_map.update(old_ns) for prefix in del_ns: del self.ns_map[prefix] self._cont_handler.endElementNS(name, rawname) # ------ internal def __process_name(self, name, default_to=None, is_attr=0): n = name.split(":") if len(n)>2: raise TypeError("Unsupported double namespace: %r" % name) return (None, name) elif len(n)==2: if n[0]=="xmlns": return (None, name) try: return (self.ns_map[n[0]], n[1]) except KeyError: raise return (None, name) elif is_attr: return (None, name) elif default_to != None: return (default_to, name) elif self.ns_map.has_key("") and name != "xmlns": return (self.ns_map[""],name) else: return (None, name) --------------7135BB0CCAF7385C00ED9BB3-- From Sylvain.Thenault@logilab.fr Wed Jan 23 17:05:42 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Wed, 23 Jan 2002 18:05:42 +0100 (CET) Subject: [XML-SIG] dom building, sax, and namespaces In-Reply-To: <3C4EEBF3.A60D6BE8@acm.org> Message-ID: On Wed, 23 Jan 2002, Andrew Dalke wrote: > Me: > > Is there some way I can build a proper namespace'd DOM without having > > the parser support feature_namespaces? Some sort of adapter, perhaps? > > I couldn't find such in the codebase. I did find code as in > > > > sax/drivers2/drv_xmlproc.py > > > > which I think I could use to write such an adapter, but it would > > be better if someone pointed out to me existing code rather than > > chance my misunderstandings and errors. > > Attached is the adapter code I copied and tweaked from drv_xmlproc.py. > It does seem to work in that the following gives me output. Yippee! you shouldn't have to use an adapter. The example in the previous mail you posted works when you use XMLGenerator instead of pulldom. > (BTW, is there no built-in function to get the concatenation of all > the text nodes, like my get_text function, below?) I don't know if there is one in 4Suite or PyXML, but I think this is a job for XSLT) -- Sylvain Thenault LOGILAB http://www.logilab.org From dalke@acm.org Wed Jan 23 20:00:45 2002 From: dalke@acm.org (Andrew Dalke) Date: Wed, 23 Jan 2002 13:00:45 -0700 Subject: [XML-SIG] dom building, sax, and namespaces References: Message-ID: <3C4F166D.DA3334AA@acm.org> Sylvain Thenault: > you shouldn't have to use an adapter. The example in the previous mail you > posted works when you use XMLGenerator instead of pulldom. Please correct me if I'm wrong. Doesn't XMLGenerator convert the SAX events to a text stream? So if I want to create a DOM I would need to reparse that stream? If so, I would rather not have the intermediate data structure. > > (BTW, is there no built-in function to get the concatenation of all > > the text nodes, like my get_text function, below?) > > I don't know if there is one in 4Suite or PyXML, but I think this is a job > for XSLT) I thought it was one for XPath, expecting I could use .text() to get that data. However, there appears to be a problem with that. >>> xml.xpath.Compile('spam[@eggs="yes"].text()') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/site-packages/_xmlplus/xpath/__init__.py", line 86, in Compile raise RuntimeException(RuntimeException.INTERNAL, stream.getvalue()) xml.xpath.RuntimeException: There is an internal bug in 4XPath. Please report this error code to support@4suite.org: Traceback (most recent call last): File "/usr/local/lib/python2.2/site-packages/_xmlplus/xpath/__init__.py", line 79, in Compile return parser.new().parse(expr) File "/usr/local/lib/python2.2/site-packages/_xmlplus/xpath/pyxpath.py", line 322, in parse raise SyntaxError(e.pos, e.msg, str) SyntaxError: I've already sent them email. BTW, one problem I have with all of this is performance. All I want is to get the text inside a region which matches a given XPath query. Matching something like '//bioformat:dbid[@type="primary"]' is 25 times faster in SAX than DOM, except of course that the SAX code I wrote is only limited to single node evaluations. (Don't get me wrong - given all that's going on with DOM, 25x ain't shabby!) As I said, I have a way to do XML markup of existing flat-files. What I'm writing is a way to index a flat-file. I want to use XPath queries to define which fields should be indexed, as in mindy_index --id id="//bioformat:dbid[@type='primary']" \ --alias accession="//bioformat:dbid[@type='accession'] \ --alias author="//bioformat::author \ --record-tag bioformat:record \ .... list of filenames then be able to do a search mindy_search --accession=P8392 or mindy_search --author="Andrew Dalke" and retrieve the original records. In some sense this would be like a specialized way to do fast queries of the form (text of the) nodes named 'bioformat:record' which have a bioformat::dbid[@type='accession'] descendent equal to "P8392" Processing a file takes about 20 minutes. Eight hours (25x more) would be rather too long. So I might have some code to figure out a subset of XPath that I can handle in a specialized SAX handler. BTW, how do I get that bioformat:record node list as an XPath expression? I've stared at the spec and Kay's "XSLT Programmer's reference" and I can't figure it out. I did find out that this //bioformat:record//bioformat:dbid[@type='primary'] takes a really long time to run -- minutes -- on my tiny dataset with only 8 records. And I don't know what it does. So my other problem I'm running into is that I'm aiming this to be used by biologists and chemists. If I'm having problems figuring out the XPath language, then I suspect they will in general have a harder go at it. Andrew dalke@dalkescientific.com From dkuhlman@cutter.rexx.com Fri Jan 25 01:23:55 2002 From: dkuhlman@cutter.rexx.com (Dave Kuhlman) Date: Thu, 24 Jan 2002 17:23:55 -0800 Subject: [XML-SIG] libxml support for Python In-Reply-To: <200201210638.g0L6cUr01341@mira.informatik.hu-berlin.de>; from martin@v.loewis.de on Mon, Jan 21, 2002 at 07:38:30AM +0100 References: <200201172157.QAA08709@tux.w3.org> <200201172220.g0HMKXR02245@mira.informatik.hu-berlin.de> <200201172345.SAA04100@tux.w3.org> <200201180648.g0I6mQZ01677@mira.informatik.hu-berlin.de> <200201210638.g0L6cUr01341@mira.informatik.hu-berlin.de> Message-ID: <20020124172355.A98547@cutter.rexx.com> Here are some notes I've written about supporting Python with libxml (It's at http://xmlsoft.org.) Any suggestions and ideas will be helpful and will be appreciated. ========================================================== libxml Support for Python I'm interested in providing support for Python built on libxml and libxslt. Since this is the libxml list, I'll concentrate on libxml. Although, it is important to by able to use libxslt from Python, too. We should consider providing support in the following areas: * Support for the DOM interface built on libxml (or gdome?). * Support for the SAX interface built on libxml. * Support for XSLT built on libxslt. (Possibly a discussion for the libxslt list.) Support for DOM I've build DOM support for Python by hand, i.e. manually written wrapper functions types, etc that expose libxml's DOM support. (Avaliable at http://www.rexx.com/~dkuhlman.) But it's weak. I've also used SWIG to generate wrappers for the libxml DOM support. Basically, I generated wrappers for the stuff in include/libxml/tree.h and include/libxml/parser.h. It works "pretty" good. A bit of evaluation: * Because I used SWIG's shadow classes, the doc, nodes, and attributes look, from Python's point of view like instances of classes. So, walking the DOM tree is very easy and natural. * One benefit of doing this -- The Python objects (xmlDoc, xmlNode, xmlAttr) are proxies for the "real", underlying (libxml) C objects and the linkages between objects are in the underlying C objects. Therefore, this implementation does not suffer from the problems caused by circular references in Python objects. (Note that I believe that I also solved this problem in my hand-written wrappers.) * More over, the Python objects are created and destroyed on the fly and only on request. For example, node = node.children node = node.next This code creates two nodes. Furthermore, when the value of variable 'node' is over-written (and if there is no other reference to that value), the Python object is destroyed. (For non-Python people who are still reading, Python uses a reference counting strategy for managing memory.) The up-shot is that this implementation (and my hand-written one as well) enables Python scripts to load and use large DOM trees with very little memory over-head above that used by the libxml C objects. * One qualification is that the interface is at the level of the libxml, so it's a bit low level. For example, a long running application would have to call a 'free' method, e.g. xmlFreeDoc, which is not something a Python programmer would expect to have to do. * For another qualification is that this implementation needs some fix-up, because there are some kinds nodes in the tree that can cause segment faults. * And, the generated code is a bit large. I'm not sure that this is a concern in a world where disk space is so cheap. It's possible that we will want to trim and not generate code for a few things. On the other hand, there may be additional libxml DOM related capabilities that we would also want to expose (and which would make it even larger. Catalogs (catalog.h)? Entities (entity.h)? Encodings (encoding.h)? gdome -- Whoa. I thought the DOM support was in libxml. I'll have to look into gdome. Can someone enlighten me on the relationship between gdome and libxml DOM support. Does gdome support a newer version of the DOM spec? Should we build DOM support for Python on top of libxml or on top of gdome? Summary -- I'll continue to work on the SWIG wrappers for the libxml DOM interface. I'll try to fix a few problems that I've found and will look into generating support for encodings, catalogs, and entities. I'll also try to learn a bit more about gdome. Support for SAX I've built Python wrappers for the libxml SAX support by hand (i.e. not generated by SWIG). (Avaliable at http://www.rexx.com/~dkuhlman.) A bit of evaluation: * Ease of use -- I've used it quite a bit and it seems quite easy to use and usable. It's a trivial task to create a Python handler class with methods like 'startElment', 'endElement', 'characters', etc and then do the parse to catch those events. * Efficiency -- The wrapper C code checks, at the beginning of the parse, to determine which event handler methods are defined in the handler class. Then, during the parse, the C code does not call any Python code (or do look-ups) for those event handlers that are _not_ defined. For example, if the method 'characters' is not defined in the handler class, then the C code will not call the Python code for event characters. So, processing should be quite efficient when a minimum of work is done in Python. Purhaps another way to say this is that there will be Python over-head only where that over-head is needed. Creating a parser driver for PyXML built on libxml seems like a very good idea. There are several benefits to be gained from doing so: * It would be fast, because most of the work would be done in C (libxml). * It would provide a validating parser. * It would be both fast and validating. This is something that PyXML (to my understanding) does not currently have. pyexpat and sgmlop are fast (because they are implemented in C. And, xmlproc is a validating parser. But no current driver is both. Here are a couple of issues that we should keep in mind: * Building libxml is a reasonable amount of work which not every user of PyXML is likely to want to do. Therefore, we will most likely want to package a libxml parser driver for PyXML as an add-on, i.e. as something that a can be built and installed after PyXML has been installed. * For speed it would be advantageous to not execute call-backs (or do call-back look-up) for event handler methods not define in the handler class. Summary -- I'll start looking into and working on a parser driver (the equivalent of pyexpat or sgmlop) for PyXML built on top of libxml. Support for XSLT I've built Python wrappers for libxslt. (Avaliable at http://www.rexx.com/~dkuhlman.) I've had one user report a bug, which I fixed. I've used it a reasonable amount. It's very easy to use. Additional Notes One of my goals when I started my work in exposing libxml and libxslt to Python was to provide an alternative source of XML support for Python. My belief is that it adds credibility to the Python project to have more than one source of support for something as important as XML. So, I feel that it is important that we both support the PyXML effort and that I provide independent support built on top of libxml/libxslt. -- Dave Kuhlman dkuhlman@rexx.com http://www.rexx.com/~dkuhlman From Sylvain.Thenault@logilab.fr Fri Jan 25 11:42:31 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Fri, 25 Jan 2002 12:42:31 +0100 (CET) Subject: [XML-SIG] dom building, sax, and namespaces In-Reply-To: <3C4F166D.DA3334AA@acm.org> Message-ID: On Wed, 23 Jan 2002, Andrew Dalke wrote: > Sylvain Thenault: > > you shouldn't have to use an adapter. The example in the previous mail you > > posted works when you use XMLGenerator instead of pulldom. > > Please correct me if I'm wrong. Doesn't XMLGenerator convert the SAX > events to a text stream? So if I want to create a DOM I would need to > reparse that stream? If so, I would rather not have the intermediate > data structure. no, XMLGenerator produce a DOM tree using 4DOM implementation. I have added an "implementation" parameter to the constructor if you want to use a different implementation than 4DOM, but I don't know if it's in PYXML 0.7 or if it's still only in the CVS. BTW, which version of PyXML and/or 4Suite are you using ? > > > (BTW, is there no built-in function to get the concatenation of all > > > the text nodes, like my get_text function, below?) > > > > I don't know if there is one in 4Suite or PyXML, but I think this is a job > > for XSLT) > > I thought it was one for XPath, expecting I could use .text() to get > that data. However, there appears to be a problem with that. > >>> xml.xpath.Compile('spam[@eggs="yes"].text()') [snip traceback] your xpath expression isn't valid, it should be 'spam[@eggs="yes"]/text()' Moreover, this won't return the concatenation of all text nodes but a _node-set_ with all the matching nodes. XPATH provide a 'string' function, but 'string(spam[@eggs="yes"]/text())' will return the text value of the _first_ text node of the node-set. I recommend you to read the W3C XPATH recommandation: http://www.w3.org/TR/xpath > BTW, one problem I have with all of this is performance. All I > want is to get the text inside a region which matches a given XPath > query. Matching something like '//bioformat:dbid[@type="primary"]' is > 25 times faster in SAX than DOM, except of course that the SAX code > I wrote is only limited to single node evaluations. (Don't get me > wrong - given all that's going on with DOM, 25x ain't shabby!) how do you apply an xpath on sax events ? DOM is a higher level than SAX (it may be based on sax to construct the dom tree, as in your application), so it's obvious that an application which does calculation on DOM trees is slower and consumes more memory than an application which does calculation on the sax events, without previously building a representation of the full xml tree. > As I said, I have a way to do XML markup of existing flat-files. What > I'm writing is a way to index a flat-file. I want to use XPath > queries to define which fields should be indexed, as in > > mindy_index --id id="//bioformat:dbid[@type='primary']" \ > --alias accession="//bioformat:dbid[@type='accession'] \ > --alias author="//bioformat::author \ > --record-tag bioformat:record \ > .... > list of filenames > > then be able to do a search > > mindy_search --accession=P8392 > or > mindy_search --author="Andrew Dalke" > > and retrieve the original records. In some sense this would be like a > specialized way to do fast queries of the form > > (text of the) nodes named 'bioformat:record' which have a > bioformat::dbid[@type='accession'] descendent equal to "P8392" > > Processing a file takes about 20 minutes. Eight hours (25x more) > would be rather too long. So I might have some code to figure out a > subset of XPath that I can handle in a specialized SAX handler. isn't 20 minutes to process a file too long ? Maybe should you think to use a database which could be queried using XPATH ? (a database seem to be more adapted to your amount of data) > BTW, how do I get that bioformat:record node list as an XPath > expression? I've stared at the spec and Kay's "XSLT Programmer's > reference" and I can't figure it out. I did find out that this > > //bioformat:record//bioformat:dbid[@type='primary'] > > takes a really long time to run -- minutes -- on my tiny dataset with > only 8 records. And I don't know what it does. if bioformat:dbid is always a child of bioformat:record, //bioformat:record/bioformat:dbid[@type='primary'] should be faster (less solutions to explore) Same thing may be applied if bioformat:record is always a child of your root element. > So my other problem I'm running into is that I'm aiming this to > be used by biologists and chemists. If I'm having problems figuring > out the XPath language, then I suspect they will in general have a > harder go at it. XPATH is rather easy to understand with a litle look at the documentation. In order to use it on an xml document, you also have to know the document structure. -- Sylvain Thenault LOGILAB http://www.logilab.org From dalke@acm.org Fri Jan 25 12:48:51 2002 From: dalke@acm.org (Andrew Dalke) Date: Fri, 25 Jan 2002 05:48:51 -0700 Subject: [XML-SIG] dom building, sax, and namespaces References: Message-ID: <3C515433.F69F8D2@acm.org> Me: > > Please correct me if I'm wrong. Doesn't XMLGenerator convert the SAX > > events to a text stream? Sylvain Thenault wrote: > no, XMLGenerator produce a DOM tree using 4DOM implementation. Then what's xml.sax.saxutils.XMLGenerator? # --- XMLGenerator is the SAX2 ContentHandler for writing back XML > but I don't know if it's in PYXML > 0.7 or if it's still only in the CVS. > BTW, which version of PyXML and/or 4Suite are you using ? I was using PyXML 0.7. I just pulled the latest out of CVS. josiah> grep -l XMLGenerator `find . -name '*.py'` ./test/test_sax.py ./test/test_sax_xmlproc.py ./test/test_saxdrivers.py ./test/test_sax2.py ./xml/sax/expatreader.py ./xml/sax/saxutils.py josiah> grep XMLGenerator xml/sax/saxutils.py # --- XMLGenerator is the SAX2 ContentHandler for writing back XML class XMLGenerator(handler.ContentHandler): class LexicalXMLGenerator(XMLGenerator, saxlib.LexicalHandler): """A XMLGenerator that also supports the LexicalHandler interface""" XMLGenerator.__init__(self, out, encoding) class ContentGenerator(XMLGenerator): return XMLGenerator.characters(self, str[start:start+end]) That's the one I saw before. I looked at the source code for that class. No mention of DOM at all. I went to download 4Suite from CVS. I followed the CVS login commands at ftp://ftp.fourthought.com/pub/cvs-snapshots/ but it says josiah> cvs -z3 -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot co \ -R STABLE FT cvs server: cannot find module `STABLE' - ignored cvs server: cannot find module `FT' - ignored cvs [checkout aborted]: cannot expand modules josiah> so I downloaded 2002-01-25-4Suite.tar.gz . josiah> zcat 2002-01-25-4Suite.tar.gz | tar xf - josiah> cd 4Suite/ josiah> grep -l XMLGenerator `find . -name '*.py'` josiah> I don't see the XMLGenerator you're talking about. > I recommend you to read the W3C XPATH recommandation: > http://www.w3.org/TR/xpath I have tried. I find it hard going. Something hasn't yet clicked on how the data model works. That's also why I'm having problems working with the DOM. I know it will come with practice, but it's annoying in the meanwhile. > > Matching something like '//bioformat:dbid[@type="primary"]' is > > 25 times faster in SAX than DOM, except of course that the SAX code > > I wrote is only limited to single node evaluations. > how do you apply an xpath on sax events ? In my case, I can special-case the XPath and if it's a specific restricted syntax I can implement what I want with a special-purpose SAX handler. Else I make a DOM out of the events and do the XPath query on that, then get the matched text. > isn't 20 minutes to process a file too long ? My standard test case is 227 MB. 'grep ^ID | wc', which returns a count of the number of records in the file, takes a minute. (My main development machine is my 233 MHz laptop.) > Maybe should you think to use a database which could be queried using > XPATH ? (a database seem to be more adapted to your amount of data) I have a spectrum of solutions based on the technology I'm developing. The one I'm focusing on now is a BerkeleyDBM solution for simple id -> flat file record lookups. This fits in very closely with existing solutions, except for the use of XPath as the query language. The next step is to use an XML database. This is harder sell for now because no one I know in this field uses an XML database -- most are using relational databases. And once I mention "database server" they start fretting about getting a database manager, or they say their Oracle person has no experience with XML databases. By having an intermediate solution for simple searches, it's an easier path to having a more complex database, since the API for existing tasks stays the same. > if bioformat:dbid is always a child of bioformat:record, > //bioformat:record/bioformat:dbid[@type='primary'] should be faster (less > solutions to explore) > Same thing may be applied if bioformat:record is always a child of your > root element. It isn't. Here's the data flow [existing flat file] | \/ [format definition as]--> parser generator --> [parser] [a regular expression] | \/ [SAX events in Python] / | \ Special DOM Database purpose handlers The structure of the SAX events is the same as the original file, since I'm only adding markup. The format definition which produces the markup may include other intermediate elements, and I don't know what those might be beforehand. I can define some structure to it all, but mostly of the sort that "feature_location" must be a descendent of "feature" I can make no assertions as to how far that descendency is. Hence my liberal use of '//'s. > XPATH is rather easy to understand with a litle look at the > documentation. In order to use it on an xml document, you also have to > know the document structure. I insist that I have read it several times, read Kay's book, and read the 'Python&XML' book on the topic. I don't find it easy. For example, I definitely found SQL easier, in that I could understand it by looking at a few examples, rather than needing to read the documntation first. Now, I know the SQL data model is less complicated than XML's, but SQL is what all my potential customers are used to using, so at the very least I have to convince them that the complications are worth it. Andrew dalke@dalkescientific.com From veillard@redhat.com Fri Jan 25 12:58:20 2002 From: veillard@redhat.com (Daniel Veillard) Date: Fri, 25 Jan 2002 07:58:20 -0500 Subject: [XML-SIG] dom building, sax, and namespaces In-Reply-To: <3C515433.F69F8D2@acm.org>; from dalke@acm.org on Fri, Jan 25, 2002 at 05:48:51AM -0700 References: <3C515433.F69F8D2@acm.org> Message-ID: <20020125075820.A14349@redhat.com> On Fri, Jan 25, 2002 at 05:48:51AM -0700, Andrew Dalke wrote: > My standard test case is 227 MB. 'grep ^ID | wc', which returns a > count of the number of records in the file, takes a minute. (My main > development machine is my 233 MHz laptop.) Considering that the XML spec very clearly says that an XML parser MUST stop delivering content as soon as a well formedness error is found in a document, and that the probability of growing a corruption on a very large file becomes not neglectable, using XML to store huge data on a single instance is IMHO brain-dead. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Sylvain.Thenault@logilab.fr Fri Jan 25 13:15:44 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Fri, 25 Jan 2002 14:15:44 +0100 (CET) Subject: [XML-SIG] dom building, sax, and namespaces In-Reply-To: <3C515433.F69F8D2@acm.org> Message-ID: On Fri, 25 Jan 2002, Andrew Dalke wrote: > Me: > > > Please correct me if I'm wrong. Doesn't XMLGenerator convert the SAX > > > events to a text stream? > > Sylvain Thenault wrote: > > no, XMLGenerator produce a DOM tree using 4DOM implementation. [snip grep suite] Oops, sorry, I was wrong, you were right. I was talking about xml.dom.ext.reader.Sax2.XmlDomGenerator from PyXML > I went to download 4Suite from CVS. I followed the CVS login commands > at ftp://ftp.fourthought.com/pub/cvs-snapshots/ but it says > > josiah> cvs -z3 -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot > co \ > -R STABLE FT > cvs server: cannot find module `STABLE' - ignored > cvs server: cannot find module `FT' - ignored > cvs [checkout aborted]: cannot expand modules > josiah> the new module name for the latest 4Suite version is "4Suite". > > I recommend you to read the W3C XPATH recommandation: > > http://www.w3.org/TR/xpath > > I have tried. I find it hard going. Something hasn't yet clicked > on how the data model works. That's also why I'm having problems > working with the DOM. I know it will come with practice, but it's > annoying in the meanwhile. [snip] > > Maybe should you think to use a database which could be queried using > > XPATH ? (a database seem to be more adapted to your amount of data) > > I have a spectrum of solutions based on the technology I'm developing. > The one I'm focusing on now is a BerkeleyDBM solution for simple id -> > flat > file record lookups. This fits in very closely with existing solutions, > except for the use of XPath as the query language. > > The next step is to use an XML database. This is harder sell for now > because no one I know in this field uses an XML database -- most are > using relational databases. And once I mention "database server" they > start fretting about getting a database manager, or they say their > Oracle person has no experience with XML databases. You could read http://www.rpbourret.com/xml/XMLDatabaseProds.htm to see a list of native xml database and relationnal database which can be queried with xpath. > By having an intermediate solution for simple searches, it's an easier > path to having a more complex database, since the API for existing > tasks stays the same. > > > > if bioformat:dbid is always a child of bioformat:record, > > //bioformat:record/bioformat:dbid[@type='primary'] should be faster (less > > solutions to explore) > > Same thing may be applied if bioformat:record is always a child of your > > root element. > > It isn't. Here's the data flow > > [existing flat file] > | > \/ > [format definition as]--> parser generator --> [parser] > [a regular expression] | > \/ > [SAX events in Python] > / | \ > Special DOM Database > purpose > handlers I was talking about applying xpath on a dom tree using a xpath compiler, as in PyXML and 4Suite. > The structure of the SAX events is the same as the original file, > since I'm only adding markup. The format definition which produces > the markup may include other intermediate elements, and I don't know > what those might be beforehand. I can define some structure to it > all, but mostly of the sort that > > "feature_location" must be a descendent of "feature" > > I can make no assertions as to how far that descendency is. Hence > my liberal use of '//'s. > > > XPATH is rather easy to understand with a litle look at the > > documentation. In order to use it on an xml document, you also have to > > know the document structure. > > I insist that I have read it several times, read Kay's book, and read > the 'Python&XML' book on the topic. I don't find it easy. For example, > I definitely found SQL easier, in that I could understand it by looking > at a few examples, rather than needing to read the documntation first. > Now, I know the SQL data model is less complicated than XML's, but SQL > is what all my potential customers are used to using, so at the very > least I have to convince them that the complications are worth it. So why don't you store your data in a standard relationnal database and query it using SQL, if you and your customers find it easier ? -- Sylvain Thenault LOGILAB http://www.logilab.org From Andrew Dalke" Daniel Veillard: > Considering that the XML spec very clearly says that an >XML parser MUST stop delivering content as soon as a well >formedness error is found in a document, and that the >probability of growing a corruption on a >very large file becomes not neglectable, using XML to store huge >data on a single instance is IMHO brain-dead. The data files are themselves machine generated. The parser I have that converts the flat-file to a marked-up version also does verification of the format. So it meets the XML criterion. What I'm providing is a migration mechanism for people to keep their existing practice (large flat files) but start taking advantage of the benefits of newer technologies. Yes, there's a change the input file is corrupt. I can detect that. But it's at least better than what people do now, where there is little detection of corruption. Andrew dalke@dalkescientific.com From Andrew Dalke" Sylvian Thenault: > [..] Okay, I'll look at XMLDomGenerator. >the new module name for the latest 4Suite version is "4Suite". Thanks. The 4Suite people might want to update that web page with the outdated CVS info. > You could read http://www.rpbourret.com/xml/XMLDatabaseProds.htm > to see a list of native xml database and relationnal database > which can be queried with xpath. I have. I've also been talking directly to people in a couple of those XML database companies about using their repective system for this field, bioinformatics. > So why don't you store your data in a standard relationnal > database and query it using SQL, if you and your customers > find it easier ? That's another one of the solution I'm developing. I have a proof-of-concept solution as well. I don't like relational databases for this data because some of the information is ordered and some of it is tree-like, and the solutions I've seen to handle that in an RDBMS seem very hackish to me. I think the XML data model is more appropriate. BTW, information about what I'm doing, in a commercial sense, is at http://www.dalkescientific.com/ Andrew dalke@dalkescientific.com From veillard@redhat.com Fri Jan 25 13:31:36 2002 From: veillard@redhat.com (Daniel Veillard) Date: Fri, 25 Jan 2002 08:31:36 -0500 Subject: [XML-SIG] dom building, sax, and namespaces In-Reply-To: <000e01c1a5a3$d024a7c0$0201a8c0@josiah.dalkescientific.com>; from adalke@mindspring.com on Fri, Jan 25, 2002 at 06:25:52AM -0700 References: <000e01c1a5a3$d024a7c0$0201a8c0@josiah.dalkescientific.com> Message-ID: <20020125083136.B14349@redhat.com> On Fri, Jan 25, 2002 at 06:25:52AM -0700, Andrew Dalke wrote: > Daniel Veillard: > > Considering that the XML spec very clearly says that an > >XML parser MUST stop delivering content as soon as a well > >formedness error is found in a document, and that the > >probability of growing a corruption on a > >very large file becomes not neglectable, using XML to store huge > >data on a single instance is IMHO brain-dead. > > The data files are themselves machine generated. The > parser I have that converts the flat-file to a marked-up > version also does verification of the format. So it meets > the XML criterion. > > What I'm providing is a migration mechanism for people to > keep their existing practice (large flat files) but start > taking advantage of the benefits of newer technologies. Yes, > there's a change the input file is corrupt. I can detect > that. But it's at least better than what people do now, > where there is little detection of corruption. Okay, still one really wonders if XML is really the right serialization format for such data. Clearly both the XPath data model and the DOM one for such document will grow huge unless you manage to use a database to generate the needed parts on the fly. It's still not clear to me that XML/XSLT are really the right tools for this kind of work, you really have to push the envelopp (like restricting yourself to a streamable subset of XSLT). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mal@lemburg.com Fri Jan 25 13:51:09 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 25 Jan 2002 14:51:09 +0100 Subject: [XML-SIG] dom building, sax, and namespaces References: <000e01c1a5a3$d024a7c0$0201a8c0@josiah.dalkescientific.com> <20020125083136.B14349@redhat.com> Message-ID: <3C5162CD.AA636C16@lemburg.com> Daniel Veillard wrote: > > On Fri, Jan 25, 2002 at 06:25:52AM -0700, Andrew Dalke wrote: > > Daniel Veillard: > > > Considering that the XML spec very clearly says that an > > >XML parser MUST stop delivering content as soon as a well > > >formedness error is found in a document, and that the > > >probability of growing a corruption on a > > >very large file becomes not neglectable, using XML to store huge > > >data on a single instance is IMHO brain-dead. > > > > The data files are themselves machine generated. The > > parser I have that converts the flat-file to a marked-up > > version also does verification of the format. So it meets > > the XML criterion. > > > > What I'm providing is a migration mechanism for people to > > keep their existing practice (large flat files) but start > > taking advantage of the benefits of newer technologies. Yes, > > there's a change the input file is corrupt. I can detect > > that. But it's at least better than what people do now, > > where there is little detection of corruption. > > Okay, still one really wonders if XML is really the > right serialization format for such data. Clearly both > the XPath data model and the DOM one for such document > will grow huge unless you manage to use a database to > generate the needed parts on the fly. > It's still not clear to me that XML/XSLT are really the > right tools for this kind of work, you really have to push the > envelopp (like restricting yourself to a streamable subset of > XSLT). If you don't trust flat file XML databases, why not use a XML repository ? These are built to handle huge amounts of data and certainly do not corrupt data; also you can access the stored data in various ways, reducing the in-memory overhead to an absolute minimum. XML as technique is still the right choice, though, since it provides the necessary flexibility to handle changing input data formats and data layout requirements. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From noreply@sourceforge.net Fri Jan 25 09:39:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Jan 2002 01:39:57 -0800 Subject: [XML-SIG] [ pyxml-Bugs-508378 ] doesn't always call endDTD Message-ID: Bugs item #508378, was opened at 2002-01-25 01:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=508378&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thenault Sylvain (syt) Assigned to: Lars Marius Garshol (larsga) Summary: doesn't always call endDTD Initial Comment: when property_lexical_handler is on, xmlproc calls startDTD and endDTD on the following doctype definition: but not on those ones: where it only calls startDTD ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=508378&group_id=6473 From Mike.Olson@fourthought.com Sat Jan 26 02:54:18 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 25 Jan 2002 19:54:18 -0700 Subject: [XML-SIG] [ANN]Release of 4Suite 0.12.0a1 Message-ID: <1012013658.3503.57.camel@penny.fourthought.com> Announcing the first alpha release of 4Suite 0.12.0. It is available by FTP at ftp://ftp.4suite.org/pub/4Suite/ Due to some packaging problems we were unable to get a Windows 2.2 binary built. We hope to have one out soon. 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 jerome.marant@free.fr Sat Jan 26 13:20:55 2002 From: jerome.marant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) Date: 26 Jan 2002 14:20:55 +0100 Subject: [XML-SIG] Re: [4suite] [ANN]Release of 4Suite 0.12.0a1 In-Reply-To: <1012013658.3503.57.camel@penny.fourthought.com> References: <1012013658.3503.57.camel@penny.fourthought.com> Message-ID: <87it9pdz9k.fsf@marant.org> Mike Olson writes: > Announcing the first alpha release of 4Suite 0.12.0. It is available by > FTP at > > ftp://ftp.4suite.org/pub/4Suite/ > > Due to some packaging problems we were unable to get a Windows 2.2 > binary built. We hope to have one out soon. Hi, I've just grabbed this version. python setup.py build gives tons of messages like: ... warning: build_docs: not documenting Ft.Xml.XPath.MessageSource (could not import) Traceback (most recent call last): File "build/lib.linux-i686-2.1/Ft/Lib/DistExt/BuildDocs.py", line 241, in locate module = self._builtin_import(path, {}, {}, '*') ImportError: No module named Xml.XPath.NamespaceNode warning: build_docs: not documenting Ft.Xml.XPath.NamespaceNode (could not import) Traceback (most recent call last): File "build/lib.linux-i686-2.1/Ft/Lib/DistExt/BuildDocs.py", line 241, in locate module = self._builtin_import(path, {}, {}, '*') ImportError: No module named Xml.XPath.ParsedAbbreviatedAbsoluteLocationPath warning: build_docs: not documenting Ft.Xml.XPath.ParsedAbbreviatedAbsoluteLocationPath (could not import) Traceback (most recent call last): File "build/lib.linux-i686-2.1/Ft/Lib/DistExt/BuildDocs.py", line 241, in locate module = self._builtin_import(path, {}, {}, '*') ImportError: No module named Xml.XPath.ParsedAbbreviatedRelativeLocationPath warning: build_docs: not documenting Ft.Xml.XPath.ParsedAbbreviatedRelativeLocationPath (could not import) Traceback (most recent call last): File "build/lib.linux-i686-2.1/Ft/Lib/DistExt/BuildDocs.py", line 241, in locate module = self._builtin_import(path, {}, {}, '*') ImportError: No module named Xml.XPath.ParsedAbsoluteLocationPath warning: build_docs: not documenting Ft.Xml.XPath.ParsedAbsoluteLocationPath (could not import) Traceback (most recent call last): File "build/lib.linux-i686-2.1/Ft/Lib/DistExt/BuildDocs.py", line 241, in locate module = self._builtin_import(path, {}, {}, '*') ImportError: No module named Xml.XPath.ParsedAxisSpecifier warning: build_docs: not documenting Ft.Xml.XPath.ParsedAxisSpecifier (could not import) Traceback (most recent call last): File "build/lib.linux-i686-2.1/Ft/Lib/DistExt/BuildDocs.py", line 241, in locate module = self._builtin_import(path, {}, {}, '*') ImportError: No module named Xml.XPath.ParsedExpr ... Any idea ? -- Jérôme Marant http://marant.org From uche.ogbuji@fourthought.com Sat Jan 26 15:33:29 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 26 Jan 2002 08:33:29 -0700 Subject: [XML-SIG] Re: [4suite] [ANN]Release of 4Suite 0.12.0a1 In-Reply-To: <87it9pdz9k.fsf@marant.org> References: <1012013658.3503.57.camel@penny.fourthought.com> <87it9pdz9k.fsf@marant.org> Message-ID: <1012059211.3705.1563.camel@borgia.local> On Sat, 2002-01-26 at 06:20, J=E9r=F4me Marant wrote: > Mike Olson writes: >=20 > > Announcing the first alpha release of 4Suite 0.12.0. It is available b= y > > FTP at > >=20 > > ftp://ftp.4suite.org/pub/4Suite/ > >=20 > > Due to some packaging problems we were unable to get a Windows 2.2 > > binary built. We hope to have one out soon. >=20 > Hi, >=20 > I've just grabbed this version. >=20 > python setup.py build gives tons of messages like: >=20 > ... > warning: build_docs: not documenting Ft.Xml.XPath.MessageSource (could no= t import) > Traceback (most recent call last): > File "build/lib.linux-i686-2.1/Ft/Lib/DistExt/BuildDocs.py", line 241, = in locate > module =3D self._builtin_import(path, {}, {}, '*') > ImportError: No module named Xml.XPath.NamespaceNode [SNIP] Hmm. I'm not very familiar with that code, but I think that all those errors mean is that you won't get all the API docs built, but that the code should be fine. Can you confirm this? If so, then we can also post pre-built docs for those who have such problems until we can figure them out. Also, what platform are you running? --=20 Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com=20 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From uche.ogbuji@fourthought.com Sat Jan 26 16:07:59 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 26 Jan 2002 09:07:59 -0700 Subject: [XML-SIG] Re: [4suite] [ANN]Release of 4Suite 0.12.0a1 In-Reply-To: <1012013658.3503.57.camel@penny.fourthought.com> References: <1012013658.3503.57.camel@penny.fourthought.com> Message-ID: <1012061281.2634.1635.camel@borgia.local> On Fri, 2002-01-25 at 19:54, Mike Olson wrote: > > Announcing the first alpha release of 4Suite 0.12.0. It is available by > FTP at > > ftp://ftp.4suite.org/pub/4Suite/ > > Due to some packaging problems we were unable to get a Windows 2.2 > binary built. We hope to have one out soon. Notes: * Python 2.0 or more recent is now required * PyXML is no longer required * Start by reading docs/UNIX.txt or docs/Windows.txt, depending on platform * Then read docs/QuickStart.txt -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From jerome.marant@free.fr Sat Jan 26 23:10:06 2002 From: jerome.marant@free.fr (=?iso-8859-15?q?J=E9r=F4me?= Marant) Date: 27 Jan 2002 00:10:06 +0100 Subject: [XML-SIG] Re: [4suite] [ANN]Release of 4Suite 0.12.0a1 In-Reply-To: <1012059211.3705.1563.camel@borgia.local> References: <1012013658.3503.57.camel@penny.fourthought.com> <87it9pdz9k.fsf@marant.org> <1012059211.3705.1563.camel@borgia.local> Message-ID: <878zakogj5.fsf@marant.org> Uche Ogbuji writes: > Hmm. I'm not very familiar with that code, but I think that all those > errors mean is that you won't get all the API docs built, but that the > code should be fine. Can you confirm this? If so, then we can also The code seems to build fine. > post pre-built docs for those who have such problems until we can figure > them out. Let me know if you need additional information. > Also, what platform are you running? Debian unstable. Thanks. -- Jérôme Marant http://marant.org From heinz.wittenbrink@vector5.de Sun Jan 27 00:37:29 2002 From: heinz.wittenbrink@vector5.de (Heinz Wittenbrink) Date: 27 Jan 2002 01:37:29 +0100 Subject: [XML-SIG] Re: [4suite] [ANN]Release of 4Suite 0.12.0a1 In-Reply-To: <878zakogj5.fsf@marant.org> References: <1012013658.3503.57.camel@penny.fourthought.com> <87it9pdz9k.fsf@marant.org> <1012059211.3705.1563.camel@borgia.local> <878zakogj5.fsf@marant.org> Message-ID: <1012091850.1363.3.camel@localhost.localdomain> I had nearly the same messages with Redhat 7.2, Python 2.2 and PyXML 0.7 installed. Regards Heinz Witttenbrink Am Son, 2002-01-27 um 00.10 schrieb J=E9r=F4me Marant: > Uche Ogbuji writes: >=20 > > Hmm. I'm not very familiar with that code, but I think that all those > > errors mean is that you won't get all the API docs built, but that the > > code should be fine. Can you confirm this? If so, then we can also >=20 > The code seems to build fine. >=20 > > post pre-built docs for those who have such problems until we can figur= e > > them out. >=20 > Let me know if you need additional information. >=20 > > Also, what platform are you running? >=20 > Debian unstable. >=20 > Thanks. >=20 > --=20 > J=E9r=F4me Marant > >=20 > http://marant.org >=20 > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig --=20 Heinz Wittenbrink vector5 cultural change management Kirchenstr. 67 D-81675 M=FCnchen Kastellfeldgasse 34/II A-8010 Graz fon: +49 89 411 88 936 mobil: +49 173 27 30 717 fax: +49 89 413194 22 mailto:heinz.wittenbrink@vector5.de http://www.vector5.de From uche.ogbuji@fourthought.com Sun Jan 27 01:33:07 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 26 Jan 2002 18:33:07 -0700 Subject: [XML-SIG] Re: [4suite] [ANN]Release of 4Suite 0.12.0a1 In-Reply-To: <1012091850.1363.3.camel@localhost.localdomain> References: <1012013658.3503.57.camel@penny.fourthought.com> <87it9pdz9k.fsf@marant.org> <1012059211.3705.1563.camel@borgia.local> <878zakogj5.fsf@marant.org> <1012091850.1363.3.camel@localhost.localdomain> Message-ID: <1012095189.2634.2580.camel@borgia.local> On Sat, 2002-01-26 at 17:37, Heinz Wittenbrink wrote: > I had nearly the same messages with Redhat 7.2, Python 2.2 and PyXML 0.7 > installed. Did you also have 4Suite 0.11.1 installed? -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From uche.ogbuji@fourthought.com Sun Jan 27 02:59:34 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 26 Jan 2002 19:59:34 -0700 Subject: [XML-SIG] 4Suite 0.12.0a1 docs Message-ID: <1012100376.3705.2671.camel@borgia.local> I've made pre-built docs of 0.12.0a1 available separately. Look on ftp://ftp.4suite.org/pub/4Suite/4Suite-0.12.0a1-docs.tgz -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From heinz.wittenbrink@vector5.de Sun Jan 27 08:44:28 2002 From: heinz.wittenbrink@vector5.de (Heinz Wittenbrink) Date: 27 Jan 2002 09:44:28 +0100 Subject: [XML-SIG] Re: [4suite] [ANN]Release of 4Suite 0.12.0a1 In-Reply-To: <1012095189.2634.2580.camel@borgia.local> References: <1012013658.3503.57.camel@penny.fourthought.com> <87it9pdz9k.fsf@marant.org> <1012059211.3705.1563.camel@borgia.local> <878zakogj5.fsf@marant.org> <1012091850.1363.3.camel@localhost.localdomain> <1012095189.2634.2580.camel@borgia.local> Message-ID: <1012121070.1445.1.camel@localhost.localdomain> yes, I had, and a CVS-snapshot, too (sorry...) Am Son, 2002-01-27 um 02.33 schrieb Uche Ogbuji: > On Sat, 2002-01-26 at 17:37, Heinz Wittenbrink wrote: > > I had nearly the same messages with Redhat 7.2, Python 2.2 and PyXML 0.= 7 > > installed. >=20 > Did you also have 4Suite 0.11.1 installed? >=20 >=20 > --=20 > Uche Ogbuji Principal Consultant > uche.ogbuji@fourthought.com +1 303 583 9900 x 101 > Fourthought, Inc. http://Fourthought.com=20 > 4735 East Walnut St, Boulder, CO 80301-2537, USA > XML strategy, XML tools (http://4Suite.org), knowledge management >=20 >=20 > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig --=20 Heinz Wittenbrink vector5 cultural change management Kirchenstr. 67 D-81675 M=FCnchen Kastellfeldgasse 34/II A-8010 Graz fon: +49 89 411 88 936 mobil: +49 173 27 30 717 fax: +49 89 413194 22 mailto:heinz.wittenbrink@vector5.de http://www.vector5.de From noreply@sourceforge.net Mon Jan 28 08:42:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Jan 2002 00:42:54 -0800 Subject: [XML-SIG] [ pyxml-Bugs-509465 ] XSLT: StylesheetReader Message-ID: Bugs item #509465, was opened at 2002-01-28 00:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=509465&group_id=6473 Category: 4Suite Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XSLT: StylesheetReader Initial Comment: On MacOS 10.1.2, Python 2.2 and PyXML 0.7, I have the following traceback: Traceback (most recent call last): File "/sw/lib/python2.2/site-packages/typez/on/onyx.py", line 527, in ? env.outputPetal(output_petal, document, output_file, output_args) File "/sw/lib/python2.2/site-packages/typez/on/onyx.py", line 307, in outputPetal result = petal.process(document, output, args) File "/sw/lib/python2.2/site-packages/typez/on/Petals/O utput/smallLout/smallLout.py", line 191, in process self.convert(document, temp_output, bib_output) File "/sw/lib/python2.2/site-packages/typez/on/Petals/O utput/smallLout/smallLout.py", line 92, in convert processor.appendStylesheetStream(ssfile) File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/Pro cessor.py", line 113, in appendStylesheetStream sty = self._styReader.fromStream(stream, baseUri) File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/Styl esheetReader.py", line 304, in fromStream self.initParser() File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/Styl esheetReader.py", line 344, in initParser if self._force8Bit: AttributeError: StylesheetReader instance has no attribute '_force8Bit' And there is actually no _force8bit attribute. When deleting the if at line 344 in StylesheetReader I get another traceback: Traceback (most recent call last): File "/sw/lib/python2.2/site-packages/typez/on/onyx.py", line 527, in ? env.outputPetal(output_petal, document, output_file, output_args) File "/sw/lib/python2.2/site-packages/typez/on/onyx.py", line 307, in outputPetal result = petal.process(document, output, args) File "/sw/lib/python2.2/site-packages/typez/on/Petals/O utput/smallLout/smallLout.py", line 191, in process self.convert(document, temp_output, bib_output) File "/sw/lib/python2.2/site-packages/typez/on/Petals/O utput/smallLout/smallLout.py", line 92, in convert processor.appendStylesheetStream(ssfile) File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/Pro cessor.py", line 113, in appendStylesheetStream sty = self._styReader.fromStream(stream, baseUri) File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/Styl esheetReader.py", line 304, in fromStream self.initParser() File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/Styl esheetReader.py", line 351, in initParser self.parser.ExternalEntityRefHandler = self.handler.entityRef AttributeError: StylesheetReader instance has no attribute 'entityRef' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=509465&group_id=6473 From noreply@sourceforge.net Mon Jan 28 14:43:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Jan 2002 06:43:12 -0800 Subject: [XML-SIG] [ pyxml-Bugs-509594 ] 2002-01-28 CVS compile bug Message-ID: Bugs item #509594, was opened at 2002-01-28 06:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=509594&group_id=6473 Category: expat Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2002-01-28 CVS compile bug Initial Comment: On MacOS 10.1.2, Python 2.2 I get when trying to setup.py build the current CVS version of PyXML: cc -L/sw/lib -bundle -flat_namespace -undefined suppress build/temp.darwin-5.2-Power Macintosh-2.2/pyexpat.o build/temp.darwin-5.2-Power Macintosh-2.2/xmlparse.o build/temp.darwin-5.2-Power Macintosh-2.2/xmlrole.o build/temp.darwin-5.2-Power Macintosh-2.2/xmltok.o -o build/lib.darwin-5.2-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: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=509594&group_id=6473 From noreply@sourceforge.net Tue Jan 29 10:50:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Jan 2002 02:50:27 -0800 Subject: [XML-SIG] [ pyxml-Bugs-510080 ] XSLT: Stylesheet handler entityRef Message-ID: Bugs item #510080, was opened at 2002-01-29 02:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=510080&group_id=6473 Category: 4Suite Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XSLT: Stylesheet handler entityRef Initial Comment: Seems like there is a missing attribute: Traceback (most recent call last): File "/sw/lib/python2.2/site-packages/typez/on/Petals/Output/smallLout/smallLout.py", line 92, in convert processor.appendStylesheetStream(ssfile) File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/Processor.py", line 113, in appendStylesheetStream sty = self._styReader.fromStream(stream, baseUri) File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 305, in fromStream self.initParser() File "/sw/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 355, in initParser self.parser.ExternalEntityRefHandler = self.handler.entityRef AttributeError: StylesheetReader instance has no attribute 'entityRef' I have pyxml from CVS and python 2.2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=510080&group_id=6473 From horst@freedict.de Wed Jan 30 16:14:36 2002 From: horst@freedict.de (horst@freedict.de) Date: Wed, 30 Jan 2002 17:14:36 +0100 (CET) Subject: [XML-SIG] yet another output encoding Message-ID: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> Hello, on my search on output encodings, I came across messages from Sep. 2000, where a possibility on how to convert utf into latin1 with xml entities was described. As I did not find any other / newer comments on the subject, I thought I ask here if anything was done, or if I better implement my own solution in order to do that. Horst -- Horst@freedict.de Horst Eyermann Germany You need a dictionary? - visit http://www.freedict.de for free (GPL) dictionaries (unix; windows work in progress) For windows, visit http://www.freedict.de/wbuch A article (in German) about dictionary efforts on the net http://www.heise.de/tp/deutsch/inhalt/on/5927/1.html From martin@v.loewis.de Wed Jan 30 19:07:50 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 30 Jan 2002 20:07:50 +0100 Subject: [XML-SIG] yet another output encoding In-Reply-To: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> Message-ID: horst@freedict.de writes: > Hello, > on my search on output encodings, I came across messages from Sep. 2000, > where a possibility on how to convert utf into latin1 with xml entities > was described. > > As I did not find any other / newer comments on the subject, I thought I > ask here if anything was done, or if I better implement my own solution > in order to do that. There is a patch pending on SF adding that feature to Python core; that patch is still awaiting review. You probably have to implement your own solution. Regards, Martin From mal@lemburg.com Wed Jan 30 21:41:47 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 30 Jan 2002 22:41:47 +0100 Subject: [XML-SIG] yet another output encoding References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> Message-ID: <3C58689B.CC4E8EAC@lemburg.com> "Martin v. Loewis" wrote: > > horst@freedict.de writes: > > > Hello, > > on my search on output encodings, I came across messages from Sep. 2000, > > where a possibility on how to convert utf into latin1 with xml entities > > was described. > > > > As I did not find any other / newer comments on the subject, I thought I > > ask here if anything was done, or if I better implement my own solution > > in order to do that. > > There is a patch pending on SF adding that feature to Python core; > that patch is still awaiting review. Which patch would that be ? > You probably have to implement > your own solution. It is easy to write such a latin-1-xml-escape codec in C. ascii-xml-escape could probably be made a subset of that codec as well. Those two would cover XML (defaults to UTF-8, compatible with ASCII) and HTML (defaults to LATIN-1, AFAIR). Contributions are always welcome :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From martin@v.loewis.de Wed Jan 30 22:39:37 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: Wed, 30 Jan 2002 23:39:37 +0100 Subject: [XML-SIG] yet another output encoding References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> <3C58689B.CC4E8EAC@lemburg.com> Message-ID: <200201302239.g0UMdbT02185@mira.informatik.hu-berlin.de> "M.-A. Lemburg" writes: > > There is a patch pending on SF adding that feature to Python core; > > that patch is still awaiting review. > > Which patch would that be ? It is http://sourceforge.net/tracker/index.php?func=detail&aid=432401&group_id=5470&atid=305470 That patch would enable to insert character references only if the character is unencodable in the target encoding, and it was precisely designed to support XML/HTML. Regards, Martin From mikem@ichips.intel.com Wed Jan 30 23:29:58 2002 From: mikem@ichips.intel.com (Mike F Miller) Date: Wed, 30 Jan 2002 15:29:58 -0800 Subject: [XML-SIG] Problems using _4xslt, is this normal? Message-ID: <200201302329.PAA22867@ichips-ra.pdx.intel.com> I've been using PyXML's sax support for some time and it's been working great for my needs, but I wanted to do some quick xml->html conversions for documentation reasons so I figured I could just whip up a few .xsl stylesheets and use the xslt support in PyXML to do the translations. It appeared that xslt/_4xslt.py was the answer to my problems, but I've run into a large number of issues (mostly include errors or mismatches on object interface names) that is leading me to believe that it isn't up to date, or I'm missing some additional package(s). So, is anyone using it with any success? And if so, is there something special that you had to do to get it working? I'm running on Linux 2.2 with Python 2.1 and PyXML 0.7. Thanks, - Mike Miller "Save the whales. Feed the hungry. Free the mallocs." mikem@ichips.intel.com 0x2A http://pooh.asric.com/~mikem mikem@computer.org >-=^,> mikem@pooh.asric.com From Sylvain.Thenault@logilab.fr Thu Jan 31 09:31:44 2002 From: Sylvain.Thenault@logilab.fr (Sylvain Thenault) Date: Thu, 31 Jan 2002 10:31:44 +0100 (CET) Subject: [XML-SIG] [ANN] xmldiff 0.5.3 Message-ID: What's new ? ------------ Fix packaging problem. See the ChangeLog file for more information. What's xmldiff ? ---------------- Xmldiff is a Python tool that figures out the differences between two similar XML files, in the same way the diff utility does for text files. Home page --------- http://www.logilab.org/xmldiff Download -------- ftp://ftp.logilab.org/pub/xmldiff -- Sylvain Thenault LOGILAB http://www.logilab.org From mal@lemburg.com Thu Jan 31 09:57:36 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 31 Jan 2002 10:57:36 +0100 Subject: [XML-SIG] yet another output encoding References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> <3C58689B.CC4E8EAC@lemburg.com> <200201302239.g0UMdbT02185@mira.informatik.hu-berlin.de> Message-ID: <3C591510.4D6518AB@lemburg.com> "Martin v. Loewis" wrote: > > "M.-A. Lemburg" writes: > > > > There is a patch pending on SF adding that feature to Python core; > > > that patch is still awaiting review. > > > > Which patch would that be ? > > It is > > http://sourceforge.net/tracker/index.php?func=detail&aid=432401&group_id=5470&atid=305470 > > That patch would enable to insert character references only if the > character is unencodable in the target encoding, and it was precisely > designed to support XML/HTML. Not only that: it was designed to enable error handler callbacks. Unfortunately, work on the patch is not finished yet: the design should cover both the encoding and decoding parts using the same strategy. Walter and I postponed the work on this until after the 2.2 release. It's still on the plate though. For this particular case, I'd still suggest to write up special optimized codecs, since they would be particularly useful and cover two standard cases which occur quite often in practice. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From tpassin@home.com Wed Jan 30 11:44:00 2002 From: tpassin@home.com (tpassin@home.com) Date: Wednesday, January 30, 2002 11:44 PM Subject: [XML-SIG] Problems using _4xslt, is this normal? Message-ID: <20020131055326.NQNJ14927.femail22.sdc1.sfba.home.com@tbp> [Mike F Miller] > I've been using PyXML's sax support for some time and it's been working > great for my needs, but I wanted to do some quick xml->html conversions > for documentation reasons so I figured I could just whip up a few .xsl > stylesheets and use the xslt support in PyXML to do the translations. > It appeared that xslt/_4xslt.py was the answer to my problems, but I've > run into a large number of issues (mostly include errors or mismatches > on object interface names) that is leading me to believe that it isn't > up to date, or I'm missing some additional package(s). > > So, is anyone using it with any success? And if so, is there something > special that you had to do to get it working? I'm running on Linux 2.2 > with Python 2.1 and PyXML 0.7. > You want to install 4Suite 0.11. It puts a batch file into the directory tree and that normally works. On Windows, though, it can't deal with paths with spaces in them. There might still be a few bugs that could prevent the actual 4Suite 4xslt from running - see my posts in these threads for fixes: [1] [XML-SIG] 4XSLT Bug Affecting Document() [2] Re: [XML-SIG] 4suite and pyxml, bug report Cheers, Tom P From akuchlin@mems-exchange.org Thu Jan 31 16:59:57 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 31 Jan 2002 11:59:57 -0500 Subject: [XML-SIG] Create a 'sandbox' module? Message-ID: I'd like to get the RELAX NG code into the public CVS so that other people can poke at it, but it's nowhere near being suitable for inclusion in the xml/ tree. My suggestion is that we imitate the python-dev group and create a 'sandbox' module in CVS, for experimental code bases. Any objection to doing this, or to the name 'sandbox'? --amk (www.amk.ca) Doctor, the more you try to convince me that you're a fool, the more I'm likely to think otherwise. -- The Countess, in "City of Death" From martin@v.loewis.de Thu Jan 31 18:22:55 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 31 Jan 2002 19:22:55 +0100 Subject: [XML-SIG] yet another output encoding In-Reply-To: <3C591510.4D6518AB@lemburg.com> References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> <3C58689B.CC4E8EAC@lemburg.com> <200201302239.g0UMdbT02185@mira.informatik.hu-berlin.de> <3C591510.4D6518AB@lemburg.com> Message-ID: "M.-A. Lemburg" writes: > Unfortunately, work on the patch is not finished yet: the design > should cover both the encoding and decoding parts using the same > strategy. Walter and I postponed the work on this until after > the 2.2 release. It's still on the plate though. Is this a reason to delay it indefinitely? Is there any user requirement for this feature to be symmetric? Regards, Martin From walter@livinglogic.de Thu Jan 31 18:30:19 2002 From: walter@livinglogic.de (Walter =?ISO-8859-1?Q?D=F6rwald?=) Date: Thu, 31 Jan 2002 19:30:19 +0100 Subject: [XML-SIG] yet another output encoding References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> <3C58689B.CC4E8EAC@lemburg.com> <200201302239.g0UMdbT02185@mira.informatik.hu-berlin.de> <3C591510.4D6518AB@lemburg.com> Message-ID: <3C598D3B.4050006@livinglogic.de> M.-A. Lemburg wrote: > "Martin v. Loewis" wrote: > >> [...] >> >>http://sourceforge.net/tracker/index.php?func=detail&aid=432401&group_id=5470&atid=305470 >> >>That patch would enable to insert character references only if the >>character is unencodable in the target encoding, and it was precisely >>designed to support XML/HTML. >> > > Not only that: it was designed to enable error handler callbacks. > > Unfortunately, work on the patch is not finished yet: the design > should cover both the encoding and decoding parts using the same > strategy. AFAICR it does. > Walter and I postponed the work on this until after > the 2.2 release. It's still on the plate though. > [...] As soon as I find the time, I'll try to do a different version of the patch, i.e. one that doesn't require such vast changes to the C API: The string will still be passed as a Py_UNICODE */int pair and the encoding as a char *. Maybe the chances of inclusion into the Python core for this new patch will be better. This patch has another advantage: for well known error handling names (e.g. "xmlreplace" for encoding) the replacement algorithm could be implemented directly in the encoder/decoder for maximum performance. Now the only remaining problem is time! :-/ Bye, Walter Dörwald From uche.ogbuji@fourthought.com Thu Jan 31 18:32:44 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 31 Jan 2002 11:32:44 -0700 Subject: [XML-SIG] Create a 'sandbox' module? In-Reply-To: Message from Andrew Kuchling of "Thu, 31 Jan 2002 11:59:57 EST." Message-ID: <200201311832.g0VIWij06885@localhost.localdomain> > I'd like to get the RELAX NG code into the public CVS so that other > people can poke at it, but it's nowhere near being suitable for > inclusion in the xml/ tree. My suggestion is that we imitate the > python-dev group and create a 'sandbox' module in CVS, for > experimental code bases. Any objection to doing this, or to the name > 'sandbox'? No objection. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management From mal@lemburg.com Thu Jan 31 18:45:50 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 31 Jan 2002 19:45:50 +0100 Subject: [XML-SIG] yet another output encoding References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> <3C58689B.CC4E8EAC@lemburg.com> <200201302239.g0UMdbT02185@mira.informatik.hu-berlin.de> <3C591510.4D6518AB@lemburg.com> <3C598D3B.4050006@livinglogic.de> Message-ID: <3C5990DE.53A701AC@lemburg.com> Walter D=F6rwald wrote: >=20 > > Walter and I postponed the work on this until after > > the 2.2 release. It's still on the plate though. > > [...] >=20 > As soon as I find the time, I'll try to do a different version of >=20 > the patch, i.e. one that doesn't require such vast changes to > the C API: The string will still be passed as a > Py_UNICODE */int pair and the encoding as a char *. > Maybe the chances of inclusion into the Python core for this > new patch will be better. This patch has another advantage: for > well known error handling names (e.g. "xmlreplace" for encoding) > the replacement algorithm could be implemented directly in the > encoder/decoder for maximum performance. I thought about such a possibility today too: maybe all we need is a simple registry of error handlers. The handlers are then addressed using their string name and we can leave the existing APIs (which use const char *error parameters) in place. Is that what you have in mind too ? =20 > Now the only remaining problem is time! :-/ Python 2.3 will leave us around 6 months -- should be=20 enough :-) --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Thu Jan 31 18:49:20 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 31 Jan 2002 19:49:20 +0100 Subject: [XML-SIG] yet another output encoding References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> <3C58689B.CC4E8EAC@lemburg.com> <200201302239.g0UMdbT02185@mira.informatik.hu-berlin.de> <3C591510.4D6518AB@lemburg.com> Message-ID: <3C5991B0.9254D182@lemburg.com> "Martin v. Loewis" wrote: > > "M.-A. Lemburg" writes: > > > Unfortunately, work on the patch is not finished yet: the design > > should cover both the encoding and decoding parts using the same > > strategy. Walter and I postponed the work on this until after > > the 2.2 release. It's still on the plate though. > > Is this a reason to delay it indefinitely? Where did you read that the work is delayed indefinitely ? > Is there any user > requirement for this feature to be symmetric? Yes: ease of use and the KISS principle. The codecs are symmetric and thus the error handlers need to be too. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From fdrake@acm.org Thu Jan 31 18:45:29 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 31 Jan 2002 13:45:29 -0500 Subject: [XML-SIG] yet another output encoding In-Reply-To: <3C5990DE.53A701AC@lemburg.com> References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> <3C58689B.CC4E8EAC@lemburg.com> <200201302239.g0UMdbT02185@mira.informatik.hu-berlin.de> <3C591510.4D6518AB@lemburg.com> <3C598D3B.4050006@livinglogic.de> <3C5990DE.53A701AC@lemburg.com> Message-ID: <15449.37065.197521.158918@grendel.zope.com> M.-A. Lemburg writes: > Python 2.3 will leave us around 6 months -- should be > enough :-) Note that I don't take that gamble any more -- I'm paying it for making it once! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From rsalz@zolera.com Thu Jan 31 18:54:00 2002 From: rsalz@zolera.com (Rich Salz) Date: Thu, 31 Jan 2002 13:54:00 -0500 Subject: [XML-SIG] Create a 'sandbox' module? References: <200201311832.g0VIWij06885@localhost.localdomain> Message-ID: <3C5992C8.7060304@zolera.com> What's the practical difference between a sandbox module and not including it in the setup.py ? /r$ -- Zolera Systems, http://www.zolera.com Information Integrity, XML Security From walter@livinglogic.de Thu Jan 31 19:17:05 2002 From: walter@livinglogic.de (Walter =?ISO-8859-1?Q?D=F6rwald?=) Date: Thu, 31 Jan 2002 20:17:05 +0100 Subject: [XML-SIG] yet another output encoding References: <200201301614.g0UGEdJ13269@eaglesnest.mceggman> <3C58689B.CC4E8EAC@lemburg.com> <200201302239.g0UMdbT02185@mira.informatik.hu-berlin.de> <3C591510.4D6518AB@lemburg.com> <3C598D3B.4050006@livinglogic.de> <3C5990DE.53A701AC@lemburg.com> Message-ID: <3C599831.2050900@livinglogic.de> M.-A. Lemburg wrote: > [...] > > I thought about such a possibility today too: maybe all > we need is a simple registry of error handlers. The handlers > are then addressed using their string name and we can leave > the existing APIs (which use const char *error parameters) > in place. > > Is that what you have in mind too ? Exactly. The encoder would still have to (re)allocate the unicode object passed in as Py_UNICODE*/int but only once and only for unknown error handling names. >>Now the only remaining problem is time! :-/ >> > > Python 2.3 will leave us around 6 months -- should be > enough :-) I hope. Bye, Walter Dörwald From akuchlin@mems-exchange.org Thu Jan 31 22:03:27 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu, 31 Jan 2002 17:03:27 -0500 Subject: [XML-SIG] Create a 'sandbox' module? In-Reply-To: <3C5992C8.7060304@zolera.com> References: <200201311832.g0VIWij06885@localhost.localdomain> <3C5992C8.7060304@zolera.com> Message-ID: <20020131220326.GB4806@ute.mems-exchange.org> On Thu, Jan 31, 2002 at 01:54:00PM -0500, Rich Salz wrote: >What's the practical difference between a sandbox module and not >including it in the setup.py ? If it's in the PyXML tree, then people browsing the source will come across it; not installing it isn't really a solution. Anyway, it's done now. The 'sandbox' module is created, and I've checked James Clark's RELAX NG test suite into the 'test' CVS module under the relaxng/ directory. Support request #511438 has been filed, asking the SF admins to untar my tree into the sandbox. Once that's done, everything will be in CVS. (Now back to trying to get the #$%^ grammar rules working...) --amk (www.amk.ca) What do you want? You don't want to take over the universe, do you? No... you wouldn't know what to do with it, beyond shout at it. -- The Doctor, in "The Pirate Planet" From rodsenra@gpr.com.br Tue Jan 1 02:30:15 2002 From: rodsenra@gpr.com.br (Rodrigo Senra) Date: Tue, 1 Jan 2002 00:30:15 -0200 Subject: [XML-SIG] Problems passing paths to xmlproc_catalog In-Reply-To: <002b01c31a96$c690c9a0$6401a8c0@tbp1> References: <20030514214833.066D4128082@gunga.terra.com.br> <002b01c31a96$c690c9a0$6401a8c0@tbp1> Message-ID: <20030516122313.725772F0015@una.terra.com.br> On Thu, 15 May 2003 00:02:17 -0400 "Thomas B. Passin" wrote about Re: [XML-SIG] Problems passing paths to xmlproc_catalog: -------------------------------------------- | Try using a file: url, either |=20 | file:/tmp/catalog.soc urls.xml |=20 Thanks Tom, but it didn't work. I believe the problem is more subtle. This is part of my catalog.soc: SYSTEM "+//www.gpr.com.br//EN//XML" "file:///home/rodrigo/r/projetos/gpr/trf3k/client/src/tasklet.dtd" If I do this: =20 cat=3Dcatalog.xmlproc_catalog("catalog.soc", catalog.CatParserFactory()) I=B4m fine. However if I do this: cat=3Dcatalog.xmlproc_catalog("../config/catalog.soc", catalog.CatParserFactory()) =20 I fails, but it does not fail to find catalog.soc! In code1 it uses the path string "file:///home/rodrigo/r/proje..." and in code2 it uses the identifier "+//www.gpr.com.br//EN//XML". Same catalog.soc file in different directories produces different behaviour. I have e-mailed Lars but it returned. regards, Rod Senra --=20 Rodrigo Senra (ICQ 114477550) MSc Computer Engineer rodsenra@gpr.com.br =20 GPr Sistemas Ltda http://www.gpr.com.br=20