From andy@reportlab.com Mon Apr 1 03:28:38 2002 From: andy@reportlab.com (Andy Robinson) Date: Mon, 1 Apr 2002 04:28:38 +0100 Subject: [XML-SIG] The fastest XML parser around Message-ID: ReportLab (www.reportlab.com) are proud to announce the release of pyRXP, the fastest XML parsing toolkit for python, and possibly for any other language anywhere: http://www.reportlab.com/xml/pyrxp.html pyRXP is a wrapper around the excellent RXP parser developed by Richard Tobin at the University of Edinburgh. Our goal is very simple: get an entire XML document into memory, and validated, as quickly and efficiently as possible. You can parse and validate Hamlet in a tenth of a second on a standard PC. pyRXP constructs a tree of tuples in memory with a single API call; the tree is easy to navigate in standard Python code and can be wrapped up with DOM-like 'lazy accessor' nodules. It is standards-compliant and validating, and is at least 30x faster and 6x more memory efficient than the (non-validating) minidom parser in the standard Python distribution. It also comfortably beats the Microsoft and Java (Xerces) parsers in our tests. Enjoy! Andy Robinson CEO/Chief Architect, ReportLab Inc. April 1st 2001 From hannu@tm.ee Mon Apr 1 07:46:16 2002 From: hannu@tm.ee (Hannu Krosing) Date: 01 Apr 2002 09:46:16 +0200 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: References: Message-ID: <1017647181.17956.28.camel@taru.tm.ee> On Mon, 2002-04-01 at 05:28, Andy Robinson wrote: > ReportLab (www.reportlab.com) are proud to announce the release of pyRXP, > the fastest XML parsing toolkit for python, and possibly for any other > language > anywhere: > > http://www.reportlab.com/xml/pyrxp.html > > pyRXP is a wrapper around the excellent RXP parser developed by Richard > Tobin at the University of Edinburgh. Our goal is very simple: get an > entire Have you tested this against libxml2 (http://www.xmlsoft.org/) On my 850MHz Athlon it parsed the test doc in 0.27sec with memory factor of 8.3. It also is validating. ------------ Hannu From veillard@redhat.com Mon Apr 1 08:34:12 2002 From: veillard@redhat.com (Daniel Veillard) Date: Mon, 1 Apr 2002 03:34:12 -0500 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: ; from andy@reportlab.com on Mon, Apr 01, 2002 at 04:28:38AM +0100 References: Message-ID: <20020401033412.N31848@redhat.com> On Mon, Apr 01, 2002 at 04:28:38AM +0100, Andy Robinson wrote: > ReportLab (www.reportlab.com) are proud to announce the release of pyRXP, > the fastest XML parsing toolkit for python, and possibly for any other > language > anywhere: > > http://www.reportlab.com/xml/pyrxp.html > > pyRXP is a wrapper around the excellent RXP parser developed by Richard > Tobin at the University of Edinburgh. Our goal is very simple: get an > entire > XML document into memory, and validated, as quickly and efficiently > as possible. You can parse and validate Hamlet in a tenth of a second on a > standard PC. Last time I checked (i.e. when I was still a W3C staff member and we asked Henry Thompson and Richard Tobin to make RXP open source), the licence for RXP was GPL. As far as I can tell it still is: http://www.cogsci.ed.ac.uk/~richard/rxp.html So it is hardly usable for any commercial or non-GPL framework. > (non-validating) minidom parser in the standard Python distribution. It > also > comfortably beats the Microsoft and Java (Xerces) parsers in our tests. Which are not the only parser out there. Libxml2 also ship with a Python interface as part of the recent releases and apparently also beats both Microsoft and Xerces (Java and C) parsers for raw parsing speed. So your claim is a bit "light". Libxml2 is also released under the MIT Licence making it suitable for any use. For the record, libxml2 parsing speed on a 1.2GHz Duron was: - 16 MBytes/s generating empty SAX callbacks - 6 MBytes/s when building a full DOM tree. - the conformance against the W3C/NIST regression test suite made of 1800+ documents is done as a Python script calling the libxml2 bindings and takes approximately 3.5 seconds. Considering validating a stream, RXP may have an edge at the moment, because libxml validation currently requires to build the DOM tree. 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 hannu@tm.ee Mon Apr 1 09:19:55 2002 From: hannu@tm.ee (Hannu Krosing) Date: 01 Apr 2002 11:19:55 +0200 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: <20020401033412.N31848@redhat.com> References: <20020401033412.N31848@redhat.com> Message-ID: <1017652800.17956.56.camel@taru.tm.ee> On Mon, 2002-04-01 at 10:34, Daniel Veillard wrote: > > Which are not the only parser out there. Libxml2 also ship with a Python > interface as part of the recent releases and apparently also beats both > Microsoft and Xerces (Java and C) parsers for raw parsing speed. So your > claim is a bit "light". for libxml2 it ran > 50 times faster than minidom when building an in-memory DOM tree > Libxml2 is also released under the MIT Licence making it suitable for any use. > > For the record, libxml2 parsing speed on a 1.2GHz Duron was: > - 16 MBytes/s generating empty SAX callbacks > - 6 MBytes/s when building a full DOM tree. > - the conformance against the W3C/NIST regression test suite made > of 1800+ documents is done as a Python script calling the libxml2 > bindings and takes approximately 3.5 seconds. Is this test script available anywhere ? ------------ Hannu From veillard@redhat.com Mon Apr 1 10:08:02 2002 From: veillard@redhat.com (Daniel Veillard) Date: Mon, 1 Apr 2002 05:08:02 -0500 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: <1017652800.17956.56.camel@taru.tm.ee>; from hannu@tm.ee on Mon, Apr 01, 2002 at 11:19:55AM +0200 References: <20020401033412.N31848@redhat.com> <1017652800.17956.56.camel@taru.tm.ee> Message-ID: <20020401050802.R31848@redhat.com> --/Uq4LBwYP4y1W6pO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 01, 2002 at 11:19:55AM +0200, Hannu Krosing wrote: > On Mon, 2002-04-01 at 10:34, Daniel Veillard wrote: > > - the conformance against the W3C/NIST regression test suite made > > of 1800+ documents is done as a Python script calling the libxml2 > > bindings and takes approximately 3.5 seconds. > > Is this test script available anywhere ? Well it's in libxml CVS, and should be in the distribution tarballs, it's called check-xml-test-suite.py . It requires a checkout of the W3C/OASIS/NIST test suite from the W3C CVS base under a xml-test-suite subdir. I don't know if the announcement of the suite has been done yet at least the list is public as well as W3C CVS base :-) http://lists.w3.org/Archives/Public/public-xml-testsuite/ http://dev.w3.org/cvsweb/ ---- paphio:~/XML -> cat xml-test-suite/CVS/Root dev.w3.org:/sources/public paphio:~/XML -> cat xml-test-suite/CVS/Repository 2001/XML-Test-Suite paphio:~/XML -> ---- I enclose a copy of the script to this mail, here is the output: ----------------------------------------------------- paphio:~/XML -> ./check-xml-test-suite.py OASIS draft v1.0 Second Edition; with 15 March updates by Mary Brady) => James Clark XMLTEST cases, 18-Nov-1998 Test xml-test-suite/xmlconf/xmltest/invalid/009.xml missing: base xml-test-suite/xmlconf/xmltest/ uri invalid/009.xml Test xml-test-suite/xmlconf/xmltest/invalid/010.xml missing: base xml-test-suite/xmlconf/xmltest/ uri invalid/010.xml Test xml-test-suite/xmlconf/xmltest/invalid/011.xml missing: base xml-test-suite/xmlconf/xmltest/ uri invalid/011.xml invalid-not-sa-022: error: Validity error not detected Ran 363 tests: 362 suceeded, 1 failed and 0 generated an error => Fuji Xerox Japanese Text Tests Ran 12 tests: 12 suceeded, 0 failed and 0 generated an error => Sun Microsystems XML Tests sa03: warning: valid document reported an error sa04: warning: valid document reported an error Test xml-test-suite/xmlconf/sun/invalid/pe01.xml missing: base xml-test-suite/xmlconf/sun/ uri invalid/pe01.xml uri01: warning: failed to parse the document but accepted Ran 164 tests: 164 suceeded, 0 failed and 0 generated an error => OASIS/NIST TESTS, 1-Nov-1998 o-p57pass1: error: Validity check failed o-p58pass1: error: Validity check failed Ran 347 tests: 345 suceeded, 2 failed and 0 generated an error => IBM XML Tests => IBM XML Conformance Test Suite - invalid tests => IBM XML Conformance Test Suite - not-wf tests => IBM XML Conformance Test Suite - valid tests ibm-valid-P11-ibm11v01.xml: warning: valid document reported an error ibm-valid-P11-ibm11v02.xml: warning: valid document reported an error ibm-valid-P56-ibm56v08.xml: warning: valid document reported an error Ran 928 tests: 928 suceeded, 0 failed and 0 generated an error Ran 1814 tests: 1811 suceeded, 3 failed and 0 generated an error in 3.35 s. paphio:~/XML -> ----------------------------------------------------- Seems there is a few document which have been removed from the suite o-p57pass1 and o-p58pass1 are actually not valid, invalid-not-sa-022 status was changed it seems, and I didn't yet had a look at it. Sometimes libxml will report errors but keep the well formedness or validity status of the document, for example it complains when Windows style paths are used for URIs (of course that doesn't pass libxml RFC2396 internal implementation). 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/ --/Uq4LBwYP4y1W6pO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="check-xml-test-suite.py" #!/usr/bin/python import sys import time import os import string sys.path.append("python") import libxml2 # # the testsuite description # CONF="xml-test-suite/xmlconf/xmlconf.xml" LOG="check-xml-test-suite.log" log = open(LOG, "w") # # Error and warning handlers # error_nr = 0 error_msg = '' def errorHandler(ctx, str): global error_nr global error_msg if string.find(str, "error:") >= 0: error_nr = error_nr + 1 if len(error_msg) < 300: if len(error_msg) == 0 or error_msg[-1] == '\n': error_msg = error_msg + " >>" + str else: error_msg = error_msg + str libxml2.registerErrorHandler(errorHandler, None) #warning_nr = 0 #warning = '' #def warningHandler(ctx, str): # global warning_nr # global warning # # warning_nr = warning_nr + 1 # warning = warning + str # #libxml2.registerWarningHandler(warningHandler, None) # # Used to load the XML testsuite description # def loadNoentDoc(filename): ctxt = libxml2.createFileParserCtxt(filename) if ctxt == None: return None ctxt.replaceEntities(1) ctxt.parseDocument() try: doc = ctxt.doc() except: doc = None if ctxt.wellFormed() != 1: doc.freeDoc() return None return doc # # The conformance testing routines # def testNotWf(filename, id): global error_nr global error_msg global log error_nr = 0 error_msg = '' ctxt = libxml2.createFileParserCtxt(filename) if ctxt == None: return -1 ctxt.parseDocument() try: doc = ctxt.doc() except: doc = None if error_nr == 0 or ctxt.wellFormed() != 0: print "%s: error: Well Formedness error not detected" % (id) log.write("%s: error: Well Formedness error not detected\n" % (id)) doc.freeDoc() return 0 return 1 def testNotWfEnt(filename, id): global error_nr global error_msg global log error_nr = 0 error_msg = '' ctxt = libxml2.createFileParserCtxt(filename) if ctxt == None: return -1 ctxt.replaceEntities(1) ctxt.parseDocument() try: doc = ctxt.doc() except: doc = None if error_nr == 0 or ctxt.wellFormed() != 0: print "%s: error: Well Formedness error not detected" % (id) log.write("%s: error: Well Formedness error not detected\n" % (id)) doc.freeDoc() return 0 return 1 def testNotWfEntDtd(filename, id): global error_nr global error_msg global log error_nr = 0 error_msg = '' ctxt = libxml2.createFileParserCtxt(filename) if ctxt == None: return -1 ctxt.replaceEntities(1) ctxt.loadSubset(1) ctxt.parseDocument() try: doc = ctxt.doc() except: doc = None if error_nr == 0 or ctxt.wellFormed() != 0: print "%s: error: Well Formedness error not detected" % (id) log.write("%s: error: Well Formedness error not detected\n" % (id)) doc.freeDoc() return 0 return 1 def testWfEntDtd(filename, id): global error_nr global error_msg global log error_nr = 0 error_msg = '' ctxt = libxml2.createFileParserCtxt(filename) if ctxt == None: return -1 ctxt.replaceEntities(1) ctxt.loadSubset(1) ctxt.parseDocument() try: doc = ctxt.doc() except: doc = None if ctxt.wellFormed() == 0: print "%s: error: wrongly failed to parse the document" % (id) log.write("%s: error: wrongly failed to parse the document\n" % (id)) return 0 if error_nr != 0: print "%s: warning: WF document generated an error msg" % (id) log.write("%s: error: WF document generated an error msg\n" % (id)) doc.freeDoc() return 2 doc.freeDoc() return 1 def testError(filename, id): global error_nr global error_msg global log error_nr = 0 error_msg = '' ctxt = libxml2.createFileParserCtxt(filename) if ctxt == None: return -1 ctxt.replaceEntities(1) ctxt.loadSubset(1) ctxt.parseDocument() try: doc = ctxt.doc() except: doc = None if ctxt.wellFormed() == 0: print "%s: warning: failed to parse the document but accepted" % (id) log.write("%s: warning: failed to parse the document but accepte\n" % (id)) return 2 if error_nr != 0: print "%s: warning: WF document generated an error msg" % (id) log.write("%s: error: WF document generated an error msg\n" % (id)) doc.freeDoc() return 2 doc.freeDoc() return 1 def testInvalid(filename, id): global error_nr global error_msg global log error_nr = 0 error_msg = '' ctxt = libxml2.createFileParserCtxt(filename) if ctxt == None: return -1 ctxt.validate(1) ctxt.parseDocument() try: doc = ctxt.doc() except: doc = None valid = ctxt.isValid() if doc == None: print "%s: error: wrongly failed to parse the document" % (id) log.write("%s: error: wrongly failed to parse the document\n" % (id)) return 0 if valid == 1: print "%s: error: Validity error not detected" % (id) log.write("%s: error: Validity error not detected\n" % (id)) doc.freeDoc() return 0 if error_nr == 0: print "%s: warning: Validity error not reported" % (id) log.write("%s: warning: Validity error not reported\n" % (id)) doc.freeDoc() return 2 doc.freeDoc() return 1 def testValid(filename, id): global error_nr global error_msg error_nr = 0 error_msg = '' ctxt = libxml2.createFileParserCtxt(filename) if ctxt == None: return -1 ctxt.validate(1) ctxt.parseDocument() try: doc = ctxt.doc() except: doc = None valid = ctxt.isValid() if doc == None: print "%s: error: wrongly failed to parse the document" % (id) log.write("%s: error: wrongly failed to parse the document\n" % (id)) return 0 if valid != 1: print "%s: error: Validity check failed" % (id) log.write("%s: error: Validity check failed\n" % (id)) doc.freeDoc() return 0 if error_nr != 0 or valid != 1: print "%s: warning: valid document reported an error" % (id) log.write("%s: warning: valid document reported an error\n" % (id)) doc.freeDoc() return 2 doc.freeDoc() return 1 test_nr = 0 test_succeed = 0 test_failed = 0 test_error = 0 def runTest(test): global test_nr global test_failed global test_error global test_succeed global error_msg global log uri = test.prop('URI') id = test.prop('ID') if uri == None: print "Test without ID:", uri return -1 if id == None: print "Test without URI:", id return -1 base = test.getBase(None) URI = libxml2.buildURI(uri, base) if os.access(URI, os.R_OK) == 0: print "Test %s missing: base %s uri %s" % (URI, base, uri) return -1 type = test.prop('TYPE') if type == None: print "Test %s missing TYPE" % (id) return -1 extra = None if type == "invalid": res = testInvalid(URI, id) elif type == "valid": res = testValid(URI, id) elif type == "not-wf": extra = test.prop('ENTITIES') # print URI #if extra == None: # res = testNotWfEntDtd(URI, id) #elif extra == 'none': # res = testNotWf(URI, id) #elif extra == 'general': # res = testNotWfEnt(URI, id) #elif extra == 'both' or extra == 'parameter': res = testNotWfEntDtd(URI, id) #else: # print "Unknow value %s for an ENTITIES test value" % (extra) # return -1 elif type == "error": res = testError(URI, id) else: # TODO skipped for now return -1 test_nr = test_nr + 1 if res > 0: test_succeed = test_succeed + 1 elif res == 0: test_failed = test_failed + 1 elif res < 0: test_error = test_error + 1 # Log the ontext if res != 1: log.write(" File: %s\n" % (URI)) content = string.strip(test.content) while content[-1] == '\n': content = content[0:-1] if extra != None: log.write(" %s:%s:%s\n" % (type, extra, content)) else: log.write(" %s:%s\n\n" % (type, content)) if error_msg != '': log.write(" ----\n%s ----\n" % (error_msg)) error_msg = '' log.write("\n") return 0 def runTestCases(case): profile = case.prop('PROFILE') if profile != None and \ string.find(profile, "IBM XML Conformance Test Suite - Production") < 0: print "=>", profile test = case.children while test != None: if test.name == 'TEST': runTest(test) if test.name == 'TESTCASES': runTestCases(test) test = test.next conf = loadNoentDoc(CONF) if conf == None: print "Unable to load %s" % CONF sys.exit(1) testsuite = conf.getRootElement() if testsuite.name != 'TESTSUITE': print "Expecting TESTSUITE root element: aborting" sys.exit(1) profile = testsuite.prop('PROFILE') if profile != None: print profile start = time.time() case = testsuite.children while case != None: global test_nr global test_succeed global test_failed global test_error if case.name == 'TESTCASES': old_test_nr = test_nr old_test_succeed = test_succeed old_test_failed = test_failed old_test_error = test_error runTestCases(case) print " Ran %d tests: %d suceeded, %d failed and %d generated an error" % ( test_nr - old_test_nr, test_succeed - old_test_succeed, test_failed - old_test_failed, test_error - old_test_error) case = case.next conf.freeDoc() log.close() print "Ran %d tests: %d suceeded, %d failed and %d generated an error in %.2f s." % ( test_nr, test_succeed, test_failed, test_error, time.time() - start) --/Uq4LBwYP4y1W6pO-- From magnus@hetland.org Mon Apr 1 14:46:39 2002 From: magnus@hetland.org (Magnus Lie Hetland) Date: Mon, 1 Apr 2002 16:46:39 +0200 Subject: [XML-SIG] Re: [reportlab-users] The fastest XML parser around In-Reply-To: ; from andy@reportlab.com on Mon, Apr 01, 2002 at 04:28:38AM +0100 References: Message-ID: <20020401164639.A2954@idi.ntnu.no> Andy Robinson : > > You can parse and validate Hamlet in a tenth of a second on a > standard PC. [snip] > Andy Robinson > CEO/Chief Architect, ReportLab Inc. > April 1st 2001 Does this date have anything to do with this claim? ;) -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org From ht@cogsci.ed.ac.uk Mon Apr 1 14:51:39 2002 From: ht@cogsci.ed.ac.uk (Henry S. Thompson) Date: 01 Apr 2002 15:51:39 +0100 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: <20020401033412.N31848@redhat.com> References: <20020401033412.N31848@redhat.com> Message-ID: Daniel Veillard writes: > On Mon, Apr 01, 2002 at 04:28:38AM +0100, Andy Robinson wrote: > > ReportLab (www.reportlab.com) are proud to announce the release of pyRXP, > > the fastest XML parsing toolkit for python, and possibly for any other > > language > > anywhere: > > > > http://www.reportlab.com/xml/pyrxp.html > > > > pyRXP is a wrapper around the excellent RXP parser developed by Richard > > Tobin at the University of Edinburgh. Our goal is very simple: get an > > entire > > XML document into memory, and validated, as quickly and efficiently > > as possible. You can parse and validate Hamlet in a tenth of a second on a > > standard PC. > > Last time I checked (i.e. when I was still a W3C staff member and we asked > Henry Thompson and Richard Tobin to make RXP open source), the licence for > RXP was GPL. > As far as I can tell it still is: > http://www.cogsci.ed.ac.uk/~richard/rxp.html > > So it is hardly usable for any commercial or non-GPL framework. ReportLab paid the University of Edinburgh for a non-GPL license, enabling it to distribute pyRXP on flexible terms, as long as they preclude unbundling RXP and distributing it on its own. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2002, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] From veillard@redhat.com Mon Apr 1 15:11:04 2002 From: veillard@redhat.com (Daniel Veillard) Date: Mon, 1 Apr 2002 10:11:04 -0500 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: ; from ht@cogsci.ed.ac.uk on Mon, Apr 01, 2002 at 03:51:39PM +0100 References: <20020401033412.N31848@redhat.com> Message-ID: <20020401101104.W31848@redhat.com> On Mon, Apr 01, 2002 at 03:51:39PM +0100, Henry S. Thompson wrote: > Daniel Veillard writes: Hi Henry, > > Last time I checked (i.e. when I was still a W3C staff member and we asked > > Henry Thompson and Richard Tobin to make RXP open source), the licence for > > RXP was GPL. > > As far as I can tell it still is: > > http://www.cogsci.ed.ac.uk/~richard/rxp.html > > > > So it is hardly usable for any commercial or non-GPL framework. > > ReportLab paid the University of Edinburgh for a non-GPL license, enabling it > to distribute pyRXP on flexible terms, as long as they preclude > unbundling RXP and distributing it on its own. Okay so basically, they are trying to get people to buy their product. Fine, but they should say so :-) It's very similar to the position of Qt/Trolltech, so it's not an abnormally suprizing model, but not really the one expected in the Python community as I understood. Anyway it's good to know you got some funding from this. 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 andy@reportlab.com Mon Apr 1 16:09:52 2002 From: andy@reportlab.com (Andy Robinson) Date: Mon, 1 Apr 2002 17:09:52 +0100 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: <20020401033412.N31848@redhat.com> Message-ID: > > (non-validating) minidom parser in the standard Python distribution. It > > also > > comfortably beats the Microsoft and Java (Xerces) parsers in our tests. > > Which are not the only parser out there. Libxml2 also ship with a Python > interface as part of the recent releases and apparently also beats both > Microsoft and Xerces (Java and C) parsers for raw parsing speed. So your > claim is a bit "light". Libxml2 is also released under the MIT Licence > making it suitable for any use. Thanks, I genuinely did not know about this! I briefly reviewed libxml some time ago but I think it was a different version under a different license (or I may have assumed that anything with 'gn...' was GPL). I'll try to build it and assemble some benchmark data. If we can get the same speeds AND validation from libxml2 without license hassles, we could use it in our framework. I submit that many others can't know about libxml2 either, as I've had a fair bit of fan mail in the last few hours, and have personally visited several Python firms who work extensively with XML and not heard it mentioned. For me the 'end goal' would be to have a standard extension module in the main Python distribution which did DOM, SAX, XSLT etc., all at C-like speeds. If libxml2 is a candidate, we should help you package it and promote it a bit better :-) - Andy Robinson From andy@reportlab.com Mon Apr 1 16:09:52 2002 From: andy@reportlab.com (Andy Robinson) Date: Mon, 1 Apr 2002 17:09:52 +0100 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: <20020401101104.W31848@redhat.com> Message-ID: > Okay so basically, they are trying to get people to buy their product. > Fine, but they should say so :-) We are trying to standardize and release some very useful tools under the most generous terms we can. ReportLab needs fast and standardized XML processing for both our free PDF and graphics products, and for our server-side products which target enterprise audiences. I am more concerned with minimizing our costs - the cost of packaging up software, supporting customer installations which get out of synch or give weird results due to different parsers etc. etc. - than with revenue. If RXP was available under a Python-style license then pyRXP would be too; we have a track record of giving away good Open Source software, and use the FreeBSD license for most stuff. I surveyed all the OS licenses and picked the one with the least words :-) But our restrictions have to mirror those imposed on us. > It's very similar to the position of Qt/Trolltech, so it's not an > abnormally suprizing model, but not really the one expected in the Python > community as I understood. Anyway it's good to know you got some funding > from this. Out of curiosity, would you be happy if ReportLab ever got some funding from this, or are we the evil empire now? :-) - Andy From veillard@redhat.com Mon Apr 1 16:26:31 2002 From: veillard@redhat.com (Daniel Veillard) Date: Mon, 1 Apr 2002 11:26:31 -0500 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: ; from andy@reportlab.com on Mon, Apr 01, 2002 at 05:09:52PM +0100 References: <20020401101104.W31848@redhat.com> Message-ID: <20020401112631.Y31848@redhat.com> On Mon, Apr 01, 2002 at 05:09:52PM +0100, Andy Robinson wrote: > > It's very similar to the position of Qt/Trolltech, so it's not an > > abnormally suprizing model, but not really the one expected in the Python > > community as I understood. Anyway it's good to know you got some funding > > from this. > > Out of curiosity, would you be happy if ReportLab ever got some funding > from this, or are we the evil empire now? :-) Heh, I didn't say that. Selling software is fine. It's just surprizing as a licence for Python modules from what I have seen so far. 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 veillard@redhat.com Mon Apr 1 16:41:28 2002 From: veillard@redhat.com (Daniel Veillard) Date: Mon, 1 Apr 2002 11:41:28 -0500 Subject: [XML-SIG] The fastest XML parser around In-Reply-To: ; from andy@reportlab.com on Mon, Apr 01, 2002 at 05:09:52PM +0100 References: <20020401033412.N31848@redhat.com> Message-ID: <20020401114128.Z31848@redhat.com> On Mon, Apr 01, 2002 at 05:09:52PM +0100, Andy Robinson wrote: > Thanks, I genuinely did not know about this! I briefly reviewed > libxml some time ago but I think it was a different version under > a different license (or I may have assumed that anything with 'gn...' > was GPL). I'll try to build it and assemble some benchmark data. > If we can get the same speeds AND validation from libxml2 without license > hassles, we could use it in our framework. It was dual licenced under the LGPL or W3C IPR. Since people argued about restrictions in both, I rereleased it under the MIT Licence. Both were actually allowing reuse in closed source products anyway, that didn't changed. > I submit that many others can't know about libxml2 either, as I've > had a fair bit of fan mail in the last few hours, and have personally > visited several Python firms who work extensively with XML and not heard > it mentioned. The Python bindings are recent, well at least the ones I maintain, and not part until now of any large distribution, I expect this to change. > For me the 'end goal' would be to have a standard extension > module in the main Python distribution which did DOM, SAX, XSLT etc., all > at C-like speeds. If libxml2 is a candidate, we should help you package it > and promote it a bit better :-) Well for the packaging it is part of the Linux distributions, and the BSD ones, it's a Cygwin prepackaged libraries and getting included in a well known Unix brand. The python bindings are a layer on top of it. As well as the XSLT engine (and its own Python bindings). There is certainly a need for improvements of the python bindings to make them fit better in the architecture and provide similar APIs as the other parsers. Help is certainly welcome. http://xmlsoft.org/python.html http://xmlsoft.org/XSLT/python.html 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 jmarant@free.fr Mon Apr 1 20:39:05 2002 From: jmarant@free.fr (=?iso-8859-1?q?J=E9r=F4me?= Marant) Date: Mon, 01 Apr 2002 22:39:05 +0200 Subject: [XML-SIG] Are you interested in bug reports? Message-ID: <87wuvri26u.fsf@marant.org> Hi, Is anyone here interested in bug reports? I've forwarded to the list a couple of them, and it seems that none of you even bother fix them or apply patches in the CVS. All of them have simply been ignored (it happens the same with 4Suite but I'm not surprised since there are quite the same persons). I'm only the Debian packager of PyXML and I'm getting bug reports from users ; they are also _your users_ and they do bother reporting bugs in order to improve the software. Ignoring them is not a good way to thank them. Now, if you want bug reports and patches, I can provide some more. Please speak up! -- Jérôme Marant http://marant.org From fdrake@acm.org Mon Apr 1 20:52:29 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 1 Apr 2002 15:52:29 -0500 Subject: [XML-SIG] Are you interested in bug reports? In-Reply-To: <87wuvri26u.fsf@marant.org> References: <87wuvri26u.fsf@marant.org> Message-ID: <15528.51341.409276.353420@grendel.zope.com> =?iso-8859-1?Q?J=E9r=F4me?= Marant writes: > Is anyone here interested in bug reports? I've forwarded to > the list a couple of them, and it seems that none of you > even bother fix them or apply patches in the CVS. Only some people are the same; there are many more people involved in PyXML than in 4Suite. The problem is the same, though; we're all really busy, and most of us aren't paid to work on PyXML. > I'm only the Debian packager of PyXML and I'm getting bug reports > from users ; they are also _your users_ and they do bother > reporting bugs in order to improve the software. Ignoring > them is not a good way to thank them. I agree. > Now, if you want bug reports and patches, I can provide > some more. Please speak up! We do have a bug database set up on SourceForge; that's probably the best place to report bugs. Things that land on a mailing list get lost too easily. The tracker on SF doesn't give us any more time to fix problems or review bugs, but we won't lose them! The tracker can be found at: http://sourceforge.net/projects/pyxml/ -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From jmarant@free.fr Mon Apr 1 21:00:20 2002 From: jmarant@free.fr (=?iso-8859-1?q?J=E9r=F4me?= Marant) Date: Mon, 01 Apr 2002 23:00:20 +0200 Subject: [XML-SIG] Are you interested in bug reports? In-Reply-To: <15528.51341.409276.353420@grendel.zope.com> ("Fred L. Drake, Jr."'s message of "Mon, 1 Apr 2002 15:52:29 -0500") References: <87wuvri26u.fsf@marant.org> <15528.51341.409276.353420@grendel.zope.com> Message-ID: <87r8lzi17f.fsf@marant.org> "Fred L. Drake, Jr." writes: > =?iso-8859-1?Q?J=E9r=F4me?= Marant writes: > > Is anyone here interested in bug reports? I've forwarded to > > the list a couple of them, and it seems that none of you > > even bother fix them or apply patches in the CVS. > > Only some people are the same; there are many more people involved in > PyXML than in 4Suite. The problem is the same, though; we're all > really busy, and most of us aren't paid to work on PyXML. I'm neither payed as a Debian maintainer. But I'm trying to inform bug submiters about the status of the bug report and I'm doing it on my own. > > Now, if you want bug reports and patches, I can provide > > some more. Please speak up! > > We do have a bug database set up on SourceForge; that's probably the > best place to report bugs. Things that land on a mailing list get > lost too easily. The tracker on SF doesn't give us any more time to > fix problems or review bugs, but we won't lose them! I agreed but they've been seen by every subscriber and noone neither reacted nor asked to report bug to the sourceforge project. > The tracker can be found at: > > http://sourceforge.net/projects/pyxml/ Alright :| -- Jérôme Marant http://marant.org From martin@v.loewis.de Mon Apr 1 23:19:19 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 02 Apr 2002 01:19:19 +0200 Subject: [XML-SIG] Are you interested in bug reports? In-Reply-To: <87wuvri26u.fsf@marant.org> References: <87wuvri26u.fsf@marant.org> Message-ID: jmarant@free.fr (J=E9r=F4me Marant) writes: > Is anyone here interested in bug reports? I've forwarded to > the list a couple of them I still have your message <87n0wtoh7k.fsf@marant.org> in my in-box, but I'm not sure whether I can find the time to look at it this year :-( > and it seems that none of you even bother fix them or apply > patches in the CVS. Please do not post patches or bug reports to the list; they are easily lost. Instead, post them to sf.net/projects/pyxml. > Now, if you want bug reports and patches, I can provide > some more. Please speak up! On SF, yes, please. On the list, no. Regards, Martin From Alexandre.Fayolle@logilab.fr Tue Apr 2 08:09:44 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Tue, 2 Apr 2002 10:09:44 +0200 Subject: [XML-SIG] xml.dom.ext.reader in pyxml-0.7.1 and 4Suite-0.12 In-Reply-To: <200203300357.g2U3vYb19175@localhost.localdomain> References: <200203300357.g2U3vYb19175@localhost.localdomain> Message-ID: <20020402080944.GC18321@orion.logilab.fr> On Fri, Mar 29, 2002 at 08:57:34PM -0700, Uche Ogbuji wrote: > > Alexandre writes: > > > > > Are there any plans to synchronize pyxml reader so that they match the > > > API in 4Suite 0.12 by pyxml-0.7.1 ? > > > > I'm not aware of any action needed, so: no. > > I'm guessing Alexandre means the readers in the 4xpath/4xslt bundled with > pyxml (or correct me if I'm wrong). Actually, I was thinking about thoses used to build Domlettes compared to thoses used to build 4DOMs. Using fromStream with Domlette causes a Warning, and using parseStream with 4DOM causes an AttributeError. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From Alexandre.Fayolle@logilab.fr Tue Apr 2 09:31:54 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Tue, 2 Apr 2002 11:31:54 +0200 Subject: [XML-SIG] Re: [reportlab-users] The fastest XML parser around In-Reply-To: <20020401164639.A2954@idi.ntnu.no> References: <20020401164639.A2954@idi.ntnu.no> Message-ID: <20020402093154.GD18321@orion.logilab.fr> On Mon, Apr 01, 2002 at 04:46:39PM +0200, Magnus Lie Hetland wrote: > Andy Robinson : > > > > You can parse and validate Hamlet in a tenth of a second on a > > standard PC. > [snip] > > Andy Robinson > > CEO/Chief Architect, ReportLab Inc. > > April 1st 2001 > > Does this date have anything to do with this claim? ;) Nope. I've seen it. It's quite impressing (even though there are no attributes in Hamlet). Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From Alexandre.Fayolle@logilab.fr Tue Apr 2 09:59:40 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Tue, 2 Apr 2002 11:59:40 +0200 Subject: [XML-SIG] ["Fernando =?iso-8859-1?Q?Tr?= =?iso-8859-1?B?aWNhcyBHYXJj7WEiIDxmdHJpY2FzQGFtb24uY3BzLnVuaXphci5lcz5d?= =?iso-8859-1?Q?_Bug#133548=3A_python2=2E1-xml=3A_=2Fusr=2Fdoc=2Fpython2?= =?iso-8859-1?Q?=2E1-xml=2Fxmlproc=2Fxmlproc=2Ehtml?= links are not correct In-Reply-To: <87adt9y104.fsf@marant.org> References: <87g031y1rp.fsf@marant.org> <87adt9y104.fsf@marant.org> Message-ID: <20020402095940.GE18321@orion.logilab.fr> On Fri, Mar 15, 2002 at 10:28:11PM +0100, Jérôme Marant wrote: > jmarant@free.fr (Jérôme Marant) writes: > > > Hi, > > > > A small bug report. Sorry for the delay. > > Better : Thanks. I've applied the patch to the CVS. 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 noreply@sourceforge.net Tue Apr 2 10:07:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Apr 2002 02:07:46 -0800 Subject: [XML-SIG] [ pyxml-Bugs-538245 ] dom.ext.Print fails on quoted namespaces Message-ID: Bugs item #538245, was opened at 2002-04-02 12:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=538245&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Nobody/Anonymous (nobody) Summary: dom.ext.Print fails on quoted namespaces Initial Comment: See http://mail.python.org/pipermail/xml-sig/2002-March/007495.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=538245&group_id=6473 From jacobs@darwin.epbi.cwru.edu Tue Apr 2 11:51:48 2002 From: jacobs@darwin.epbi.cwru.edu (Kevin Jacobs) Date: Tue, 2 Apr 2002 06:51:48 -0500 (EST) Subject: [XML-SIG] Re: [reportlab-users] The fastest XML parser around In-Reply-To: Message-ID: Congrats on the new XML parser! On Mon, 1 Apr 2002, Andy Robinson wrote: > pyRXP constructs a tree of tuples in memory with a single API call; the tree > is easy to navigate in standard Python code and can be wrapped up with > DOM-like 'lazy accessor' nodules. Why bother with lazy accessors? If you are willing to consider using some of the new Python 2.2 features, you can get all the speed and efficiency of tuples with a true DOM interface. Also, is it fair to make comparisons with other parsers, since it doesn't look like RXPpy computes tag sets to answer queries like getElementsByTagName or getElementById efficiently? -Kevin -- -----------> Kevin Jacobs <-----------|-------> (216) 986-0710 <-------- Informatics Consultant | Department of Epidemiology Primary mail: jacobs@theopalgroup.com | & Biostatistics Alternate mail: jacobs@darwin.cwru.edu | Case Western Reserve University ---------------------------------------------------------------------------- From Alexandre.Fayolle@logilab.fr Tue Apr 2 12:24:53 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Tue, 2 Apr 2002 14:24:53 +0200 Subject: [XML-SIG] Re: [reportlab-users] The fastest XML parser around In-Reply-To: References: Message-ID: <20020402122453.GA20675@orion.logilab.fr> On Tue, Apr 02, 2002 at 06:51:48AM -0500, Kevin Jacobs wrote: > Congrats on the new XML parser! > > On Mon, 1 Apr 2002, Andy Robinson wrote: > > pyRXP constructs a tree of tuples in memory with a single API call; the tree > > is easy to navigate in standard Python code and can be wrapped up with > > DOM-like 'lazy accessor' nodules. > > Why bother with lazy accessors? If you are willing to consider using some > of the new Python 2.2 features, you can get all the speed and efficiency of > tuples with a true DOM interface. I doubt you'll get as low a memory footprint. > Also, is it fair to make comparisons with > other parsers, since it doesn't look like RXPpy computes tag sets to answer > queries like getElementsByTagName or getElementById efficiently? It's probably not fair, but then, so what ? If pyRXP doesn't do what you need, just forget it, and use whatever parser you feel like using. I personnaly have never ever used getElementsByXXX, so this is not an important functionnality for me. OTOH, being able to load and manipulate in memory a 10MB XML document is something I'd like to do which is awkward with current DOM implementation I'm aware of. 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 jacobs@darwin.epbi.cwru.edu Tue Apr 2 12:35:15 2002 From: jacobs@darwin.epbi.cwru.edu (Kevin Jacobs) Date: Tue, 2 Apr 2002 07:35:15 -0500 (EST) Subject: [XML-SIG] Re: [reportlab-users] The fastest XML parser around In-Reply-To: <20020402122453.GA20675@orion.logilab.fr> Message-ID: On Tue, 2 Apr 2002, Alexandre wrote: > On Tue, Apr 02, 2002 at 06:51:48AM -0500, Kevin Jacobs wrote: > > Congrats on the new XML parser! > > > > On Mon, 1 Apr 2002, Andy Robinson wrote: > > > pyRXP constructs a tree of tuples in memory with a single API call; the tree > > > is easy to navigate in standard Python code and can be wrapped up with > > > DOM-like 'lazy accessor' nodules. > > > > Why bother with lazy accessors? If you are willing to consider using some > > of the new Python 2.2 features, you can get all the speed and efficiency of > > tuples with a true DOM interface. > > I doubt you'll get as low a memory footprint. The overhead is typically per-class not per-instance (nodes, in this case), so I don't see why. The major gain is achieved by not allocating per-instance dictionaries, which can be done quite handily with Python 2.2's new-style-object slots. > > Also, is it fair to make comparisons with > > other parsers, since it doesn't look like RXPpy computes tag sets to answer > > queries like getElementsByTagName or getElementById efficiently? > > It's probably not fair, but then, so what ? If pyRXP doesn't do what you > need, just forget it, and use whatever parser you feel like using. I > personnaly have never ever used getElementsByXXX, so this is not an > important functionnality for me. OTOH, being able to load and manipulate > in memory a 10MB XML document is something I'd like to do which is > awkward with current DOM implementation I'm aware of. I believe it is important to be clear about limitations and caveats when making comparisons, especially when comparing apples and oranges. Of course the applicability of pyRXP is undiminished by such qualifications, and if it gets the job done for you, all the better. Personally, I'm not into advocacy and will be looking into using pyRXP for things that it does well. -Kevin -- -----------> Kevin Jacobs <-----------|-------> (216) 986-0710 <-------- Informatics Consultant | Department of Epidemiology Primary mail: jacobs@theopalgroup.com | & Biostatistics Alternate mail: jacobs@darwin.cwru.edu | Case Western Reserve University ---------------------------------------------------------------------------- From eliot@isogen.com Tue Apr 2 15:33:15 2002 From: eliot@isogen.com (W. Eliot Kimber) Date: Tue, 02 Apr 2002 09:33:15 -0600 Subject: [XML-SIG] Re: [reportlab-users] The fastest XML parser around References: <20020402122453.GA20675@orion.logilab.fr> Message-ID: <3CA9CF3B.6457B578@isogen.com> Alexandre wrote: > > Also, is it fair to make comparisons with > > other parsers, since it doesn't look like RXPpy computes tag sets to answer > > queries like getElementsByTagName or getElementById efficiently? > > It's probably not fair, but then, so what ? If pyRXP doesn't do what you > need, just forget it, and use whatever parser you feel like using. I > personnaly have never ever used getElementsByXXX, so this is not an > important functionnality for me. Just as a data point--most of the DOM code I write is in the service of extracting data from XML config files. For that I use getElementsByXXX because it's the easiest way to get the elements you want without worrying about issues like non-element nodes. These applications are also not particularly concerned about efficiency because the DOM processing is a tiny fraction of some larger process. Cheers, Eliot -- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 From reagle@w3.org Tue Apr 2 20:09:02 2002 From: reagle@w3.org (Joseph Reagle) Date: Tue, 2 Apr 2002 15:09:02 -0500 Subject: [XML-SIG] Question: where is pyxml documentation? Message-ID: <200204022009.PAA23830@tux.w3.org> >>> print xml.xpath.__doc__ WWW: http://4suite.org/4XPath e-mail: support@4suite.org http://4suite.org/4XPath --> 404 -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ From reagle@w3.org Tue Apr 2 21:06:02 2002 From: reagle@w3.org (Joseph Reagle) Date: Tue, 2 Apr 2002 16:06:02 -0500 Subject: [XML-SIG] default namespace prefixes in xpath's processorNss Message-ID: <200204022106.QAA00849@tux.w3.org> --------------Boundary-00=_2ALYPYF3T0MATXN0XNX8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello, I'm trying to tweak test_c14n.py and c14n.py to accomodate the attached exc-c14n test which entails default namespace prefix. I've tweaked test_c14n.py to process additional namespace prefixes with the "-n" argument: xmlsec-python> test_c14n.py -i iaikTests.example2.xml -n "default http://foo.com" -x "(//. | //@* | //namespace::*)[self::Parent or (parent::Parent and not(self::default:Child)) or self::GrandChild or parent::GrandChild]" However, there is a problem, the result: This includes "default" as an ordinary namespace prefix and it emits. The result is not correct according to c14n which has a particular treatment for default namespaces. If there was some way in which I could set the default namespace via the processorNss I think this would be remedied. However [1] states, "Note: don't try to set an empty string as a prefix: this is illegal." How do I set the defalt namespace in this case? -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ --------------Boundary-00=_2ALYPYF3T0MATXN0XNX8 Content-Type: text/xml; charset="iso-8859-1"; name="iaikTests.example2.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="iaikTests.example2.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KCjwhLS0gWFBhdGg9InNlbGY6 OlBhcmVudCBvciAocGFyZW50OjpQYXJlbnQgYW5kIG5vdChzZWxmOjpkZWZhdWx0OkNoaWxkKSkg b3Igc2VsZjo6R3JhbmRDaGlsZCBvciBwYXJlbnQ6OkdyYW5kQ2hpbGQiIC0tPgo8IS0tIGFkZGl0 aW9uYWxOU1ByZWZpeGVzPSJkZWZhdWx0IGh0dHA6Ly9mb28uY29tIiAtLT4KCjwhLS0gUmVzdWx0 IEMxNE46CjxQYXJlbnQ+CiAgICA8R3JhbmRDaGlsZD48L0dyYW5kQ2hpbGQ+CiAgPC9QYXJlbnQ+ Ci0tPgoKPCEtLSBBbm5vdGF0aW9uIEMxNE46CjEuIFRoZSB4bWxucz0iIiBvZiBQYXJlbnQgaXMg bm90IHJlbmRlcmVkLCBhbHRob3VnaCBpdCBpcyBleHBsaWNpdGx5IGRlY2xhcmVkLgogICBUaGlz IGlzIGJlY2F1c2UgUGFyZW50IGhhcyBubyBvdXRwdXQgcGFyZW50IHdpdGggYSBkZWZhdWx0IG5h bWVzcGFjZSBkZWNsYS0KICAgcmF0aW9uIHRoYXQgaXMgaW4gdGhlIG5vZGUgc2V0LgoyLiBUaGUg eG1sbnM9IiIgb2YgR3JhbmRDaGlsZCBpcyBub3QgcmVuZGVyZWQsIGFsdGhvdWdoIGl0IGlzIGV4 cGxpY2l0bHkKICAgZGVjbGFyZWQuIFRoaXMgaXMgYmVjYXVzZSBHcmFuZENoaWxkIGhhcyBubyBv dXRwdXQgcGFyZW50IHdpdGggYSBkZWZhdWx0CiAgIG5hbWVzcGFjZSBkZWNsYXJhdGlvbiB0aGF0 IGlzIGluIHRoZSBub2RlIHNldC4KLS0+Cgo8IS0tIFJlc3VsdCBFQzE0TjoKPFBhcmVudD4KICAg IDxHcmFuZENoaWxkPjwvR3JhbmRDaGlsZD4KICA8L1BhcmVudD4KLS0+Cgo8IS0tIEFubm90YXRp b24gRUMxNE46ClNlZSBBbm5vdGF0aW9uIEMxNE4uCi0tPgoKPEdyYW5kUGFyZW50PgogIDxQYXJl bnQgeG1sbnM9IiI+CiAgICA8Q2hpbGQgeG1sbnM9Imh0dHA6Ly9mb28uY29tIj4KICAgICAgPEdy YW5kQ2hpbGQgeG1sbnM9IiIvPgogICAgPC9DaGlsZD4KICA8L1BhcmVudD4KPC9HcmFuZFBhcmVu dD4= --------------Boundary-00=_2ALYPYF3T0MATXN0XNX8-- From stigmata@blackangel.net Wed Apr 3 04:15:41 2002 From: stigmata@blackangel.net (Gregor Mosheh) Date: Tue, 2 Apr 2002 20:15:41 -0800 (PST) Subject: [XML-SIG] SAX, escape problem Message-ID: It appears that something in SAX is failing to convert quote marks and some other characters into their entities. How do I correct this? ### This test program... import xml.sax, xml.sax.writer, xml.sax.handler import cStringIO import re def encode(hash): buffer = cStringIO.StringIO() saxout = xml.sax.writer.PrettyPrinter(buffer) saxout.startDocument() saxout.startElement("objects",{}) saxout.startElement("object",hash) saxout.endElement("object") saxout.endElement("objects") saxout.endDocument() return buffer.getvalue() print encode( { 'keyword' : '< \"this is in quotes\" >' } )+"\n\n" ### ...generates this output, indicating that quote characters are ### not escaped, though <, >, and & characters are escaped. This ### also occurs for half-quote characters and for >128 Unicode ### characters. ### So, I tried inserting some code to do the ### quote-to-" substitutions myself. ### And this test program... import xml.sax, xml.sax.writer, xml.sax.handler import cStringIO import re def encode(hash): buffer = cStringIO.StringIO() saxout = xml.sax.writer.PrettyPrinter(buffer) saxout.startDocument() saxout.startElement("objects",{}) for thiskey in hash.keys(): thisval = hash[thiskey] thisval = re.sub('"','"',thisval) thisval = re.sub("'",''',thisval) hash[thiskey] = thisval saxout.startElement("object",hash) saxout.endElement("object") saxout.endElement("objects") saxout.endDocument() return buffer.getvalue() print encode( { 'keyword' : '< \"this is in quotes\" >' } )+"\n\n" ### ...generates the following output, indicating that the escaped ### quote mark entity is re-escaped by something in SAX. This same ### effect occurs, of course, if I do similar subs for >128 Unicode ### characters or for half-quote marks. From stigmata@blackangel.net Wed Apr 3 04:25:27 2002 From: stigmata@blackangel.net (Gregor Mosheh) Date: Tue, 2 Apr 2002 20:25:27 -0800 (PST) Subject: [XML-SIG] SAX, freeze problem Message-ID: I am unable to freeze Python programs that use SAX, apparently due to failed imports. I saw an article (and in the reeze docs) mentioning that some extension modules, such as SAX, don't have enough explicit import statements for the freezer to find and import everything. I'm trying to freeze the program below (the goal: take an array of objects and XML-encode their attributes), and I'd much appreciate it if someone has a list/reference of the changes I can make to allow this program to be frozen. The problem seems to be in xml.sax.writer, specifically. I do have another question, incidentally: is SAX portable to Windows? That is, has anyone using Win32/MSVC++ ever successfully compiled expat and used it with SAX/Python? import xml.sax, xml.sax.writer, xml.sax.handler import cStringIO import re from re import sub from re import match privateattribute = re.compile("^_") # encode() takes a list of objects and encodes their attributes class XMLEncoder(xml.sax.writer.PrettyPrinter): def startDocument(self): pass def encode(objectlist,includeprivate=0): # use a StringIO buffer to hold the string, cuz the XML stuff requires streams (bleh) buffer = cStringIO.StringIO() saxout = XMLEncoder(buffer) saxout.startDocument() saxout.startElement("objects",{}) # go thru the list of objects... for thisobject in objectlist: # populate thisobjecthash with the object's attributes, skipping privates if necessary thisobjecthash = {} for property in dir(thisobject): if not match(privateattribute,property) or includeprivate: content = str(getattr(thisobject,property)) thisobjecthash[property] = content # it was empty? must not not have been interesting, so skip it if not thisobjecthash: continue saxout.startElement("object",thisobjecthash) saxout.endElement("object") saxout.endElement("objects") saxout.endDocument() return buffer.getvalue() # decode() takes an XML string and returns a tuple of hashes. the hashes represent the attributes of objects class XMLDecoder(xml.sax.handler.ContentHandler): def __init__(self): self.objectlist = [] def startElement(self, name, attrs): if name=='object': newDict = {} for key, value in attrs.items(): newDict[str(key)] = value self.objectlist.append(newDict) def decode(xmlstring): try: xmlhandler = XMLDecoder() xml.sax.parseString(xmlstring, xmlhandler) return tuple(xmlhandler.objectlist) except: return # an example, if this module is executed def runexample(): # create an array of instances of this class, then encode it class Example: def __init__(self,x,y): self.X = x self.Y = y self.ObjectClass = 'Example' objectlist = [ Example(1,'this has "quote marks" in it') , Example(2,'abc>& Message-ID: <007201c1dad6$9695a2d0$0bf13044@tbp> [Gregor Mosheh] > > I do have another question, incidentally: is SAX portable to Windows? That > is, has anyone using Win32/MSVC++ ever successfully compiled expat and > used it with SAX/Python? > Yes, there are Windows binaries that work fine on Windows. So you ought to be able to do it too, if that is what you are really asking. Cheers, Tom P From fdrake@acm.org Wed Apr 3 06:13:16 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 3 Apr 2002 01:13:16 -0500 Subject: [XML-SIG] Are you interested in bug reports? In-Reply-To: <200204030510.g335Alu02772@localhost.localdomain> References: <15528.51341.409276.353420@grendel.zope.com> <200204030510.g335Alu02772@localhost.localdomain> Message-ID: <15530.40316.517467.963042@grendel.zope.com> Uche Ogbuji writes: > Is that so? I'm surprised to hear it. But then again, it doesn't r= eally=20 > matter. Well, I thought so, for some relative interpretation of "many". I've not undertaken a survey, though. > Very good point, Fred, and I'll make the same pointer to the tracker= s at >=20 > http://sourceforge.net/projects/foursuite/ Excellent! > J=E9r=F4me, thanks so much for all your hard work as Debian maintain= er. > I'm just getting into Debian, and I am extremely chuffed at how > easy it is to maintain, after the god-awful pain that it is to > install. I've been a Red Hatter for four years, now, and I Yeah, that's why I haven't actually used Debian. I *really* like the swirly logo, though. ;-) -Fred --=20 Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Wed Apr 3 06:45:58 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 03 Apr 2002 08:45:58 +0200 Subject: [XML-SIG] SAX, escape problem In-Reply-To: References: Message-ID: Gregor Mosheh writes: > It appears that something in SAX is failing to convert quote marks > and some other characters into their entities. How do I correct this? It's a bug. Please apply this patch. Regards, Martin Index: writer.py =================================================================== RCS file: /cvsroot/pyxml/xml/xml/sax/writer.py,v retrieving revision 1.7 diff -u -r1.7 writer.py --- writer.py 30 Dec 2001 22:46:44 -0000 1.7 +++ writer.py 3 Apr 2002 06:44:55 -0000 @@ -61,6 +61,7 @@ dsc = "]" # declaration subset close ero = "&" # entity reference open lit = '"' # literal start or end + lit_quoted = '"' # quoted literal lita = "'" # literal start or end (alternative) mdo = "" # markup declaration close @@ -268,6 +269,7 @@ stag = "%s%s%s" % (prefix, self.__syntax.stago, tag) prefix = "%s %s" % (prefix, (len(tag) * " ")) lit = self.__syntax.lit + lita = self.__syntax.lita vi = self.__syntax.vi a = '' if self._flowing != self.__stack[-1][0]: @@ -285,7 +287,15 @@ for k, v in attrs.items(): if v is None: continue - a = ' %s%s%s%s%s' % (k, vi, lit, escape(str(v)), lit) + v = str(v) + if string.find(v, lit) == -1: + a = ' %s%s%s%s%s' % (k, vi, lit, escape(str(v)), lit) + elif string.find(v, lita) == -1: + a = ' %s%s%s%s%s' % (k, vi, lita, escape(str(v)), lita) + else: + a = ' %s%s%s%s%s' % (k, vi, lita, + escape(str(v), {lit:self.__syntax.lit_quoted}), + lita) if (self._offset + len(a)) > self.lineLength: self._write(line + "\n") line = prefix + a From uche.ogbuji@fourthought.com Wed Apr 3 05:10:47 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 02 Apr 2002 22:10:47 -0700 Subject: [XML-SIG] Are you interested in bug reports? In-Reply-To: Message from "Fred L. Drake, Jr." of "Mon, 01 Apr 2002 15:52:29 EST." <15528.51341.409276.353420@grendel.zope.com> Message-ID: <200204030510.g335Alu02772@localhost.localdomain> > = > =3D?iso-8859-1?Q?J=3DE9r=3DF4me?=3D Marant writes: > > Is anyone here interested in bug reports? I've forwarded to > > the list a couple of them, and it seems that none of you > > even bother fix them or apply patches in the CVS. > = > Only some people are the same; there are many more people involved in > PyXML than in 4Suite. Is that so? I'm surprised to hear it. But then again, it doesn't really= = matter. > > Now, if you want bug reports and patches, I can provide > > some more. Please speak up! > = > We do have a bug database set up on SourceForge; that's probably the > best place to report bugs. Things that land on a mailing list get > lost too easily. The tracker on SF doesn't give us any more time to > fix problems or review bugs, but we won't lose them! > = > The tracker can be found at: > = > http://sourceforge.net/projects/pyxml/ Very good point, Fred, and I'll make the same pointer to the trackers at http://sourceforge.net/projects/foursuite/ But I do want to add one thing: J=E9r=F4me, thanks so much for all your hard work as Debian maintainer. = I'm just = getting into Debian, and I am extremely chuffed at how easy it is to main= tain, = after the god-awful pain that it is to install. I've been a Red Hatter f= or = four years, now, and I discovered Python through Red Hat, but I'm quite = tempted to switch to Debian (sorrt Trond :-) ). Anyway, I gather Debia= n is = as solid as it is because of the mases of unpaid volunteers such as you a= re. = I'll try to be better about checking out your bug reports. -- = Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com = 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): = http://www.xmlconference.com/ From uche.ogbuji@fourthought.com Wed Apr 3 05:18:27 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 02 Apr 2002 22:18:27 -0700 Subject: [XML-SIG] Question: where is pyxml documentation? In-Reply-To: Message from Joseph Reagle of "Tue, 02 Apr 2002 15:09:02 EST." <200204022009.PAA23830@tux.w3.org> Message-ID: <200204030518.g335IRw02930@localhost.localdomain> > >>> print xml.xpath.__doc__ > WWW: http://4suite.org/4XPath e-mail: support@4suite.org > > http://4suite.org/4XPath --> > 404 The good news is that this stuff is actually being generated again, these days, at least in 4Suite, thanks to Matt Gushee, Chime, Mike Brown and co. The bad news is that no one has had the time to update 4Suite.org with it all, or to update 4Suite.org, period. http://prdownloads.sourceforge.net/foursuite/4Suite-docs-0.12.0a2.tar.gz Might have what you seek (under the "modules" dir) -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ From Alexandre.Fayolle@logilab.fr Wed Apr 3 07:29:03 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 3 Apr 2002 09:29:03 +0200 Subject: [XML-SIG] Question: where is pyxml documentation? In-Reply-To: <200204030518.g335IRw02930@localhost.localdomain> References: <200204022009.PAA23830@tux.w3.org> <200204030518.g335IRw02930@localhost.localdomain> Message-ID: <20020403072902.GE21615@orion.logilab.fr> On Tue, Apr 02, 2002 at 10:18:27PM -0700, Uche Ogbuji wrote: > > >>> print xml.xpath.__doc__ > > WWW: http://4suite.org/4XPath e-mail: support@4suite.org > > > > http://4suite.org/4XPath --> > > 404 > > The good news is that this stuff is actually being generated again, these > days, at least in 4Suite, thanks to Matt Gushee, Chime, Mike Brown and co. > The bad news is that no one has had the time to update 4Suite.org with it all, > or to update 4Suite.org, period. > > http://prdownloads.sourceforge.net/foursuite/4Suite-docs-0.12.0a2.tar.gz > > Might have what you seek (under the "modules" dir) Be careful, though, since this specific documentation is for 4Suite, and not PyXML. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From martin@v.loewis.de Wed Apr 3 07:29:34 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 03 Apr 2002 09:29:34 +0200 Subject: [XML-SIG] SAX, escape problem In-Reply-To: References: Message-ID: martin@v.loewis.de (Martin v. Loewis) writes: > + a = ' %s%s%s%s%s' % (k, vi, lita, > + escape(str(v), {lit:self.__syntax.lit_quoted}), Actually, this should be (k, vi, lit; not lita. Regards, Martin From Nicolas.Chauvat@logilab.fr Wed Apr 3 11:48:04 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Wed, 3 Apr 2002 13:48:04 +0200 (CEST) Subject: [XML-SIG] Are you interested in bug reports? In-Reply-To: <200204030510.g335Alu02772@localhost.localdomain> Message-ID: > Jérôme, thanks so much for all your hard work as Debian maintainer. I'm just > getting into Debian, and I am extremely chuffed at how easy it is to maintain, > after the god-awful pain that it is to install. I've been a Red Hatter for > four years, now, and I discovered Python through Red Hat, but I'm quite > tempted to switch to Debian (sorrt Trond :-) ). Anyway, I gather Debian is > as solid as it is because of the mases of unpaid volunteers such as you are. > I'll try to be better about checking out your bug reports. FWIW, I eventually (re)discovered Debian after 7 years using Linux (I took the wrong path long ago when picking up a RedHat 4.0 CD instead of a Debian one) and got so impressed that I switched all our boxes from RedHat to Debian. Sorry RedHat et al., but even if RPM and DPKG are very much alike, your software repository is absent whereas hundreds of maintainers are taking care of Debian stable/testing/unstable and make my sysadmin life so much easier... I look forward to having the same for python packages! -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France) From ssweeney@idiosync.net Thu Apr 4 00:24:45 2002 From: ssweeney@idiosync.net (Scott Sweeney) Date: Wed, 3 Apr 2002 16:24:45 -0800 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing Message-ID: Announcing... SLiP 0.1: a "Sorta Like Python" shorthand syntax for XML SLIDE 0.1: a "Sorta Like an IDE" lightweight windows exe for SLiP editing SLiPpy 0.1: a SLiP package for Python, including a SLiP->XML library (sliplib.py) and source for SLIDE (slide.py) http://www.scottsweeney.com/projects/slip [Description] SLiP is a quick, alternative shorthand syntax for creating and editing XML data by hand and if you know Python, it should also be familiar. Great for taking notes. [Benefits] * Less typing - provides a quicker and easier means for creating or editing XML * Easier to read - creates a pleasant layout for the data with indentation and spacing * Benefits of XML - allow for hierarchical data, unlike tabbed or other character delimited data files * Cheap - provides a free XML editing alternative * Editor-agnostic and Keyboard-oriented - provide a quicker, more hacker-friendly way to create XML over point-and-click alternatives * Works in existing editors - most Python editors (IDLE, Scintilla, etc) should accept and make working with this syntax easy [Example] This portion of SLiP: my:addresses(xmlns:my="http://example.org/my"): #some random comment address(type="home"): street(): "123 Sesame Street" city(): "Wonderland" state(): "CA" zipCode(): "90012" comment(): """ Please leave packages with Grouch in garbage can next door. """ .. would convert to this XML:
123 Sesame Street Wonderland CA 90012 Please leave packages with Grouch in garbage can next door.
I've created some free (MIT license) tools including a Python library for translating between XML and SLiP (SLiPpy), a lightweight editor wrapper (SLIDE), and some brief documentation - all available at the website, http://www.scottsweeney.com/projects/slip This is my first release of these tools so they are a little rough and they need more input, so let me know what you think. Thanks, Scott Sweeney [Contact] ssweeney@idiosync.net From uche.ogbuji@fourthought.com Thu Apr 4 03:55:06 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 03 Apr 2002 20:55:06 -0700 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing In-Reply-To: Message from "Scott Sweeney" of "Wed, 03 Apr 2002 16:24:45 PST." Message-ID: <200204040355.g343t6209823@localhost.localdomain> > Announcing... > > SLiP 0.1: a "Sorta Like Python" shorthand syntax for XML > SLIDE 0.1: a "Sorta Like an IDE" lightweight windows exe for SLiP editing > SLiPpy 0.1: a SLiP package for Python, including a SLiP->XML library > (sliplib.py) and source for SLIDE (slide.py) Cor! This is seriously neat. I have a feeling this wil become a favorite tool in short order. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ From tpassin@comcast.net Thu Apr 4 04:42:57 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Wed, 03 Apr 2002 23:42:57 -0500 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing References: Message-ID: <005801c1db93$316d80e0$0bf13044@tbp> [Scott Sweeney] > Announcing... > > SLiP 0.1: a "Sorta Like Python" shorthand syntax for XML > SLIDE 0.1: a "Sorta Like an IDE" lightweight windows exe for SLiP editing > SLiPpy 0.1: a SLiP package for Python, including a SLiP->XML library > (sliplib.py) and source for SLIDE (slide.py) > > http://www.scottsweeney.com/projects/slip This is nice work, Scott. It's somewhat like a format I made up awhile ago, although I don't use the "()". I wrote a parser that throws SAX events so you can serialize or build DOM trees with standard SAX handlers. Here's the example from Scott's web page in my format - test:: bookmark:: url::http://www.google.com title::Google bookmark:: url::http://www.idiosync.net title::idiosync ; This is a comment line ; PCDATA content starts on the same line, after the "::" I use "::" instead of ":" so you can use prefixed names. You can put attributes in by prefixing them with "@", like so: location:: @xlink:href::http://www.example.com Either way, these little indented text formats are wonderful for whipping out hand-authored XML. I've done topic maps among other things with my flavor. Should be good for RELAX NG too. Cheers, Tom P From veillard@redhat.com Thu Apr 4 09:06:11 2002 From: veillard@redhat.com (Daniel Veillard) Date: Thu, 4 Apr 2002 04:06:11 -0500 Subject: [XML-SIG] Are you interested in bug reports? In-Reply-To: ; from Nicolas.Chauvat@logilab.fr on Wed, Apr 03, 2002 at 01:48:04PM +0200 References: <200204030510.g335Alu02772@localhost.localdomain> Message-ID: <20020404040611.E15606@redhat.com> On Wed, Apr 03, 2002 at 01:48:04PM +0200, Nicolas Chauvat wrote: > FWIW, I eventually (re)discovered Debian after 7 years using Linux (I took > the wrong path long ago when picking up a RedHat 4.0 CD instead of a > Debian one) and got so impressed that I switched all our boxes from RedHat > to Debian. Sorry RedHat et al., but even if RPM and DPKG are very much > alike, your software repository is absent whereas hundreds of maintainers > are taking care of Debian stable/testing/unstable and make my sysadmin > life so much easier... Except a rant, is there anything productive we could extract from your message. I.e. what exactly went wrong ? What could have fixed it ? I can't make sense of "your software repository is absent". It is clear that Red Hat is focusing on professionnal computing services where the goal is to provide a clearly identified set of working packages who have been tested, and does not try to integrate every possible package. The goal is to select and cleanup, not to aggregate an infinite set of package without the possibility to do quality insurance. 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 gherman@darwin.in-berlin.de Thu Apr 4 12:27:19 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Thu, 04 Apr 2002 14:27:19 +0200 (CEST) Subject: [XML-SIG] Conditions for using XLink Message-ID: <1017923239.3cac46a7bd076@webmail.in-berlin.de> Hi, I'm trying to read XML files with FromXmlFile() that contain XLink attri- butes like this: . This results in the following traceback below. I'm using the following environment: OS name: posix, platform: darwin Python version: 2.2.0 final 0 PyXML version: 0.7 4Suite version: 0.11.1 Is there anything else needed to work with XLink or do I need to upgrade something? Thanks, Dinu [...] File "foo.py", line 727, in foo doc = FromXmlFile(path) File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/ext/reader/Sax2.py", line 401, in FromXmlFile saxHandlerClass, parser) File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/ext/reader/Sax2.py", line 386, in FromXmlStream return reader.fromStream(stream, ownerDocument) File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/ext/reader/Sax2.py", line 372, in fromStream self.parser.parse(s) File "/usr/local/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py", line 58, in parse xmlreader.IncrementalParser.parse(self, source) File "/usr/local/lib/python2.2/site-packages/_xmlplus/sax/xmlreader.py", line 123, in parse self.feed(buffer) File "/usr/local/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py", line 143, in feed self._parser.Parse(data, isFinal) File "/usr/local/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py", line 217, in start_element self._cont_handler.startElement(name, AttributesImpl(attrs)) File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/ext/reader/Sax2.py", line 72, in startElement attr = self._ownerDoc.createAttributeNS(namespace, qname) File "/usr/local/lib/python2.2/site-packages/_xmlplus/dom/Document.py", line 149, in createAttributeNS raise NamespaceErr() xml.dom.NamespaceErr: Invalid or illegal namespace operation From uche.ogbuji@fourthought.com Thu Apr 4 16:48:55 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 04 Apr 2002 09:48:55 -0700 Subject: [XML-SIG] Conditions for using XLink In-Reply-To: Message from Dinu Gherman of "Thu, 04 Apr 2002 14:27:19 +0200." <1017923239.3cac46a7bd076@webmail.in-berlin.de> Message-ID: <200204041648.g34GmtJ13072@localhost.localdomain> > I'm trying to read XML files with FromXmlFile() that contain XLink attri- > butes like this: . This results in the following > traceback below. I'm using the following environment: This is almost certainly a bug in your XML. Can you post the whole thing? Or perhaps a smaller subset of it that demonstrates the problem, but is complete in itself. Thanks. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ From gherman@darwin.in-berlin.de Thu Apr 4 18:37:10 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Thu, 04 Apr 2002 20:37:10 +0200 (CEST) Subject: [XML-SIG] Conditions for using XLink In-Reply-To: <200204041648.g34GmtJ13072@localhost.localdomain> References: <200204041648.g34GmtJ13072@localhost.localdomain> Message-ID: <1017945430.3cac9d562f871@webmail.in-berlin.de> Uche Ogbuji : > > I'm trying to read XML files with FromXmlFile() that contain XLink > > attributes like this: . This results in the > > following traceback below. I'm using the following environment: > > This is almost certainly a bug in your XML. Can you post the whole > thing? Or perhaps a smaller subset of it that demonstrates the prob- > lem, but is complete in itself. I found that adding the following xmlsn-attribute to the root element: things work much better and there is no more traceback. But then I need to access the attribute value for, say, And after looking into the test suite I'm able to get it, but *only* in this way: xlink_href = node.getAttributeNS('http://www.w3.org/1999/xlink', 'href') but not as I had liked, e.g. like this: xlink_href = node.getAttributeNS('xlink', 'href') So, I wonder if I really need to give the full URI, because that would mean I need to store this at the beginning for the root element. I'm feeling like I must be doing or getting something wrong about it... Thanks for shedding some light into this, if you please! Regards, Dinu From fredrik@pythonware.com Thu Apr 4 20:26:32 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 4 Apr 2002 22:26:32 +0200 Subject: [XML-SIG] Conditions for using XLink References: <200204041648.g34GmtJ13072@localhost.localdomain> <1017945430.3cac9d562f871@webmail.in-berlin.de> Message-ID: <03a001c1dc17$04d21580$ced241d5@hagrid> dinu wrote: > And after looking into the test suite I'm able to get it, but *only* > in this way: > > xlink_href = node.getAttributeNS('http://www.w3.org/1999/xlink', 'href') > > but not as I had liked, e.g. like this: > > xlink_href = node.getAttributeNS('xlink', 'href') > > So, I wonder if I really need to give the full URI, because that would > mean I need to store this at the beginning for the root element. I'm > feeling like I must be doing or getting something wrong about it... you're confused. the XLink specification defines the URI, not the prefix. whoever creates your XML file can use whatever prefix they like, as long as they map it to the right URI (see section 4 of the XLink specification for details). in your code, do NS_XLINK = 'http://www.w3.org/1999/xlink' xlink_href = node.getAttributeNS(NS_XLINK, 'href') and forget about the prefix. :: you might also wish to read up on XML namespaces. this article by james clark might help: http://www.jclark.com/xml/xmlns.htm hope this helps! From r.salz@verizon.net Thu Apr 4 23:27:28 2002 From: r.salz@verizon.net (Rich Salz) Date: Thu, 04 Apr 2002 18:27:28 -0500 Subject: [XML-SIG] Conditions for using XLink References: <200204041648.g34GmtJ13072@localhost.localdomain> <1017945430.3cac9d562f871@webmail.in-berlin.de> Message-ID: <3CACE160.8030801@verizon.net> > Yup, you have to do this. Only the "xml" and "xmlns" prefixes are special; all others must be declared and -- as you found in your getAttributeNS call -- you must use the URI internally. You might want to look at the ns.py module, which defines symbolic names for many well-known XML uri's. We can always add more, too. /r$ From reagle@w3.org Fri Apr 5 16:34:33 2002 From: reagle@w3.org (Joseph Reagle) Date: Fri, 5 Apr 2002 11:34:33 -0500 Subject: [XML-SIG] default namespace prefixes in xpath's processorNss Message-ID: <200204051634.LAA24488@tux.w3.org> I did a little more poking about with respect to my question of how to pass a defalut namespace value to the XPath evaluation via processorNss [1]. I didn't find any documentation or code that indicated there was a way (maybe I'm still missing it.) I also wondered whether such a think is even supposed to be possible; XPath says the context includes, "The namespace declarations consist of a mapping from prefixes to namespace URIs." [2] I presume a legitimate mapping includes the null prefix for the default namespace? Gregor, was this supported by your library, did you add it,have you seen other evidence of this? (Any other interop on those examples?) I also did some newbie tinkering [3] to Context.py with poor results. Something would have to be tweaked in the evaluation part as well but I'm not familiar enough with the code... [1] http://mail.python.org/pipermail/xml-sig/2002-April/007527.html [2] http://www.w3.org/TR/xpath#section-Introduction [3] /usr/lib/python2.1/site-packages/_xmlplus/xpath/Context.py if self.processorNss.has_key('#default'): defaultNS = self.processorNss['#default'] del self.processorNss['#default'] self.processorNss[''] = defaultNS From fdrake@acm.org Fri Apr 5 17:11:33 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 5 Apr 2002 12:11:33 -0500 Subject: [XML-SIG] Re: [XML-checkins]CVS: xml/xml/sax expatreader.py,1.19,1.20 In-Reply-To: References: Message-ID: <15533.56005.220538.326333@grendel.zope.com> [Responding to a message sent to the checkins list...] Martin v. Loewis writes: > Unfortunately, that breaks 1.5 support, which is still a goal for > 0.7.1. Even after we give up 1.5 support, I don't know whether we can > drop 2.0 support. Good point! > IOW, I'd appreciate if you could emulate weakref.ref with a strong > wrapper object if it is not present. Done. I've also switched to using a weakref.proxy, which simplifies the code for the new locator a little as well. One problem I still have with ExpatParser is that it implements the Locator interface itself, and the tests actually rely on that. I've not spent the time to figure out a better approach yet, but it would be nice if it didn't conflate the interfaces like that. Applications can do as they please, but being strict in the libraries is good since we ensure that we don't rely on the conflated interfaces ourselves. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From lloyd@lancaster.lib.pa.us Wed Apr 3 14:12:06 2002 From: lloyd@lancaster.lib.pa.us (Eron Lloyd) Date: 03 Apr 2002 09:12:06 -0500 Subject: [XML-SIG] Question: where is pyxml documentation? In-Reply-To: <20020403072902.GE21615@orion.logilab.fr> References: <200204022009.PAA23830@tux.w3.org> <200204030518.g335IRw02930@localhost.localdomain> <20020403072902.GE21615@orion.logilab.fr> Message-ID: <1017843127.999.3.camel@linux> Actually, here in front of me I have O'Reilly's "Python and XML", which covers PyXML from cover to cover. It's exactly what you need. Regards, Eron On Wed, 2002-04-03 at 02:29, Alexandre wrote: > On Tue, Apr 02, 2002 at 10:18:27PM -0700, Uche Ogbuji wrote: > > > >>> print xml.xpath.__doc__ > > > WWW: http://4suite.org/4XPath e-mail: support@4suite.org > > > > > > http://4suite.org/4XPath --> > > > 404 > > > > The good news is that this stuff is actually being generated again, these > > days, at least in 4Suite, thanks to Matt Gushee, Chime, Mike Brown and co. > > The bad news is that no one has had the time to update 4Suite.org with it all, > > or to update 4Suite.org, period. > > > > http://prdownloads.sourceforge.net/foursuite/4Suite-docs-0.12.0a2.tar.gz > > > > Might have what you seek (under the "modules" dir) > > Be careful, though, since this specific documentation is for > 4Suite, and not PyXML. > > 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). > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig > --- > [This E-mail scanned for viruses by Declude Virus] > > --- [This E-mail scanned for viruses by Declude Virus] From fdrake@acm.org Fri Apr 5 20:52:33 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 5 Apr 2002 15:52:33 -0500 Subject: [XML-SIG] Question: where is pyxml documentation? In-Reply-To: <1017843127.999.3.camel@linux> References: <200204022009.PAA23830@tux.w3.org> <200204030518.g335IRw02930@localhost.localdomain> <20020403072902.GE21615@orion.logilab.fr> <1017843127.999.3.camel@linux> Message-ID: <15534.3729.358657.551773@grendel.zope.com> Eron Lloyd writes: > Actually, here in front of me I have O'Reilly's "Python and XML", which > covers PyXML from cover to cover. It's exactly what you need. Well, there are a few other things in there. PyXML has grown a bit since the planning for that book, so there are things in PyXML that aren't covered in the book as well. It does cover a lot of it, though. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From bbaxter@wadsworth.org Fri Apr 5 21:34:50 2002 From: bbaxter@wadsworth.org (William Baxter) Date: Fri, 05 Apr 2002 16:34:50 -0500 Subject: [XML-SIG] Hopefully a quick question Message-ID: <3CAE187A.7359957C@wadsworth.org> I would like to access the elements themselves from a document. The SAX and DOM interfaces allow one to extract the text inside the markup, but I don't see how to recover the original markup. E.g., can I obtain a string like "text stuff" from a DOM tree? I can see how to get all the pieces - the tag name, the attributes, the text - but not how to get the entire element. Or do I have to walk through the tree getting all the parts, and reconstructing the element as I go? That seems like a lot of trouble, when somewhere the parser must have this thing already. Thanks, Bill Baxter From martin@v.loewis.de Fri Apr 5 23:15:21 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 06 Apr 2002 01:15:21 +0200 Subject: [XML-SIG] Hopefully a quick question In-Reply-To: <3CAE187A.7359957C@wadsworth.org> References: <3CAE187A.7359957C@wadsworth.org> Message-ID: William Baxter writes: > E.g., can I obtain a string like "text > stuff" from a DOM tree? Yes. In minidom, invoke .toxml(). Similar API exists for other DOM implementations. Regards, Martin From dwallace23@comcast.com Sat Apr 6 03:27:11 2002 From: dwallace23@comcast.com (Dave) Date: Fri, 05 Apr 2002 22:27:11 -0500 Subject: [XML-SIG] Does this code segfault for you? Message-ID: <3CAE6B0F.8020202@comcast.com> The following code (painstakingly adapted from a similar pattern used in ZSI) causes a segfault with PyXML built from cvs HEAD & v070 but seems to run ok with v066 and earlier. This is with Python 2.2.1rc2 on Linux. (I tested also with Python 1.5 w/ PyXML 0.5.2, it worked there with no problems) Does anyone else get similar results? Dave. --------------------------------------cut here-------------------------------------------------------------------- ''' if "IN_BAD" is parsed, a segfault is triggered at exit. This appears to be a result of further cleanup code running after the unicode object stuff has been freed by Python ''' IN_BAD=''' ''' IN_OK=''' ''' # # Change this to IN_BAD to get a segfault # No problems occur with IN_OK # #IN = IN_OK IN = IN_BAD from xml.dom.ext.reader import PyExpat class Reader: def __init__(self,reader): self.reader = reader def __del__(self): print "cleaning" # This triggers the segfault self.reader.releaseNode(self.d) r = Reader(PyExpat.Reader()) r.d=r.reader.fromString(IN) print "done" From r.salz@verizon.net Sat Apr 6 04:03:52 2002 From: r.salz@verizon.net (Rich Salz) Date: Fri, 05 Apr 2002 23:03:52 -0500 Subject: [XML-SIG] Does this code segfault for you? References: <3CAE6B0F.8020202@comcast.com> Message-ID: <3CAE73A8.5060807@verizon.net> yup. see https://sourceforge.net/tracker/?func=detail&aid=528620&group_id=5470&atid=105470 From Nicolas.Chauvat@logilab.fr Sat Apr 6 17:48:37 2002 From: Nicolas.Chauvat@logilab.fr (Nicolas Chauvat) Date: Sat, 6 Apr 2002 19:48:37 +0200 (CEST) Subject: [OFF-TOPIC] Re: [XML-SIG] Are you interested in bug reports? In-Reply-To: <20020404040611.E15606@redhat.com> Message-ID: > Except a rant, is there anything productive we could extract from your > message. I.e. what exactly went wrong ? What could have fixed it ? Part of it is clearly a rant. I forgot to add the tag, though. What went wrong is that once a box is installed, it is a pain to maintain it and upgrade the software that's there. And adding new software is harder than it is with other distros. What could have fixed it is something like RH-Update combined with http://www.logilab.org/newrpm, combined with frequent updates of packages. I eventually realized that what I was after when writing newrpm was in fact called Debian and had been working for a long time. > I can't make sense of "your software repository is absent". Using the network to keep my installed software up to date, I cannot just go to rpm.org and download what I need for it's too messy. I would have to pay for a rh-update service to keep my software up to date after installation. This is not the case with Debian. > It is clear that Red Hat is focusing on professionnal computing > services where the goal is to provide a clearly identified set of > working packages who have been tested, and does not try to integrate > every possible package. The goal is to select and cleanup, not to > aggregate an infinite set of package without the possibility to do > quality insurance. Fine. I won't spend more time advocating Debian here, it's not the right place for that and others would do it better than me. RedHat is great, I used it for most of my Linux years so far, but I found something that better fits my needs. End of the story (for me). -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France) From Peter.L.Nordlund@telia.com Sun Apr 7 09:01:49 2002 From: Peter.L.Nordlund@telia.com (Peter Nordlund) Date: Sun, 07 Apr 2002 10:01:49 +0200 Subject: [XML-SIG] Looking for JAXB-like XML python binding References: Message-ID: <3CAFFCED.39750876@telia.com> Hi all, Here comes a python-xml newbie question: Is there any framwork in the spirit of JAXB available for python? For more info on JAXB, see http://java.sun.com/xml/jaxb/index.html which I have cited below: -------- JAXB makes XML easy to use by compiling an XML schema (currently only DTDs are supported) into one or more Java technology classes. The generated classes handle all the details of XML parsing and formatting. Similarly, the generated classes ensure that the constraints expressed in the schema are enforced in the resulting methods and Java technology language data types. -------- JAXB fulfills all my needs except that is Java and not Python... Best regards, Peter From uche.ogbuji@fourthought.com Sun Apr 7 18:00:54 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sun, 07 Apr 2002 11:00:54 -0600 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing In-Reply-To: Message from "Thomas B. Passin" of "Wed, 03 Apr 2002 23:42:57 EST." <005801c1db93$316d80e0$0bf13044@tbp> Message-ID: <200204071700.g37H0s301734@localhost.localdomain> > [Scott Sweeney] > > > Announcing... > > > > SLiP 0.1: a "Sorta Like Python" shorthand syntax for XML > > SLIDE 0.1: a "Sorta Like an IDE" lightweight windows exe for SLiP editing > > SLiPpy 0.1: a SLiP package for Python, including a SLiP->XML library > > (sliplib.py) and source for SLIDE (slide.py) > > > > http://www.scottsweeney.com/projects/slip > > This is nice work, Scott. It's somewhat like a format I made up awhile ago, > although I don't use the "()". I wrote a parser that throws SAX events so > you can serialize or build DOM trees with standard SAX handlers. > > Here's the example from Scott's web page in my format - > > test:: > bookmark:: > url::http://www.google.com > title::Google > bookmark:: > url::http://www.idiosync.net > title::idiosync > ; This is a comment line > ; PCDATA content starts on the same line, after the "::" > > I use "::" instead of ":" so you can use prefixed names. You can put > attributes in by prefixing them with "@", like so: > > location:: > @xlink:href::http://www.example.com > > Either way, these little indented text formats are wonderful for whipping > out hand-authored XML. I've done topic maps among other things with my > flavor. Should be good for RELAX NG too. It feels as if you two must have fundamental implementation differences in our systems, but is there a way to merge them, and put together a standard XML-SIG proposal for an indented short-hand for XML? If so, I suspect we could have another XBEL-grade success on our hands. I think the people who have to deal with editing XML by hand are profusely scattered far beyond te Python community. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ From uche.ogbuji@fourthought.com Sun Apr 7 18:05:13 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sun, 07 Apr 2002 11:05:13 -0600 Subject: [XML-SIG] default namespace prefixes in xpath's processorNss In-Reply-To: Message from Joseph Reagle of "Fri, 05 Apr 2002 11:34:33 EST." <200204051634.LAA24488@tux.w3.org> Message-ID: <200204071705.g37H5DY01752@localhost.localdomain> > > I did a little more poking about with respect to my question of how to pass a > defalut namespace value to the XPath evaluation via processorNss [1]. I > didn't find any documentation or code that indicated there was a way > (maybe I'm still missing it.) I also wondered whether such a think is > even supposed to be possible; It is not. Unlike some other specs, XPath forbids the application of default namespace to unqualified names in expressions. > XPath says the context includes, "The > namespace declarations consist of a mapping from prefixes to > namespace URIs." [2] I presume a legitimate mapping includes the > null prefix for the default namespace? No. I'll look up the precise passage when I have a moment, but in implementing XPath, I and the other XPath developers made ourselves very clear aboout the prescriptions of XPath 1.0 in this regard. Why do you think you need to apply the default namespace within XPath expressions? -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ From r.salz@verizon.net Sun Apr 7 18:13:42 2002 From: r.salz@verizon.net (Rich Salz) Date: Sun, 07 Apr 2002 13:13:42 -0400 Subject: [XML-SIG] Looking for JAXB-like XML python binding References: <3CAFFCED.39750876@telia.com> Message-ID: <3CB07E46.3000400@verizon.net> Based on the excerpt you posted, ZSI comes close. The biggest limitation right now is that it does not have a WSDL compiler; you have to write the definitions (called typecodes) by hand. See http://pywebsvcs.sf.net /r$ From noreply@sourceforge.net Sun Apr 7 19:53:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Apr 2002 11:53:48 -0700 Subject: [XML-SIG] [ pyxml-Bugs-540663 ] ns_parse parsing error for titles Message-ID: Bugs item #540663, was opened at 2002-04-07 11:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=540663&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan W. Irwin (airwin) Assigned to: Nobody/Anonymous (nobody) Summary: ns_parse parsing error for titles Initial Comment: This bug has also been reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=141549&repeatmerged=yes but the maintainer there suggested I forward it to upstream which is here! Here is a fragment of a bookmarks.html file that generates the problem.

Online Stores and Commercial Stuff

<sort order="normal">title</sort>.

Here is the xbel result fragment generated by ns_parse Online Stores and Commercial Stuf f The "Stuff" in the title of the folder has been split into two folders, ...Stuf and f. Later there is a closing for the "f" folder. So to fix the problem I have to apply the patch (not for general use) below to my specific xbel file which gives another view of the effect of the error. I am a sax newbie, but I think the effect of the p=saxexts.SGMLParserFactory.make_parser() call in ns_parse is to let the system use a default parser. So it may be that this problem can be worked around by specifying a particular parser without this 33 character limitation on the title length. Please let me know if you have a parser suggestion which I could try. BTW, the bookmarks file that triggers the error has 3000+ bookmarks in it and is the data that generates the Loads of Linux Links site at loll.sf.net/linux/links. It's 0.6 MB, uncompressed. Let me know if you would like me to send you a compressed version of this file by e-mail to help verify this bug. ***********diff between hand-corrected and generated xbel file. --- bookmarks.xbel Sat Apr 6 15:26:43 2002 +++ bookmarks.xbel_fixed Sat Apr 6 15:39:41 2002 @@ -8132,9 +8132,7 @@ - Online Stores and Commercial Stuf - - f + Online Stores and Commercial Stuff MontaVista Software - Company @@ -10307,6 +10305,5 @@ Linux.com : Links - Software: X_Window_System - *********** ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=540663&group_id=6473 From noreply@sourceforge.net Sun Apr 7 20:02:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Apr 2002 12:02:19 -0700 Subject: [XML-SIG] [ pyxml-Bugs-540666 ] ns_parse should support annotation Message-ID: Bugs item #540666, was opened at 2002-04-07 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=540666&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan W. Irwin (airwin) Assigned to: Nobody/Anonymous (nobody) Summary: ns_parse should support annotation Initial Comment: This bug has also been reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=141553&repeatmerged=yes but the maintainer there suggested I forward it to upstream which is here! The full summary (for which there is no room above) should say: ns_parse and xbel2html should support annotations This wishlist bug is related to folder and bookmark annotations. The mozilla-style bookmark file element is

while the corresponding xbel element is called Here is the rationale for quoted from http://pyxml.sourceforge.net/topics/xbel/docs/html/top-level.html: Many Internet browsers support simple annotation of bookmark data with human readable text. This element is required to support exchange of this data. I have left this wishlist rather than normal because you can limp along without annotations for normal bookmark use. However, the problem is if you attempt to generate a website from your bookmarks file with, e.g., bk2site, it absolutely requires annotations. The workaround is to always keep your bookmarks in mozilla-style form (which does support annotations), but I am very much looking forward to using xbel-style bookmarks as soon as annotations become supported by ns_parse and xbel2html. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=540666&group_id=6473 From Matt Gushee Sun Apr 7 20:39:24 2002 From: Matt Gushee (Matt Gushee) Date: Sun, 7 Apr 2002 13:39:24 -0600 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing In-Reply-To: <200204071700.g37H0s301734@localhost.localdomain> References: <005801c1db93$316d80e0$0bf13044@tbp> <200204071700.g37H0s301734@localhost.localdomain> Message-ID: <20020407193924.GA386@swordfish.havenrock.com> On Sun, Apr 07, 2002 at 11:00:54AM -0600, Uche Ogbuji wrote: > > [Scott Sweeney] > > > > > Announcing... > > > > > > SLiP 0.1: a "Sorta Like Python" shorthand syntax for XML > > > SLIDE 0.1: a "Sorta Like an IDE" lightweight windows exe for SLiP editing > > > SLiPpy 0.1: a SLiP package for Python, including a SLiP->XML library > > > > Either way, these little indented text formats are wonderful for whipping > > out hand-authored XML. Still too heavy for prose composition, IMNSHO. I've been working on a *really* simple alternative intended mainly for writing documentation; alpha implementation should be out in a couple of days. Oh, I'm doing it in Ruby, though. For the time being. No, Uche, I haven't gone over to the other side. Just broadening my horizons a bit. -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ From uche.ogbuji@fourthought.com Mon Apr 8 02:57:59 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sun, 07 Apr 2002 19:57:59 -0600 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing In-Reply-To: Message from Matt Gushee of "Sun, 07 Apr 2002 13:39:24 MDT." <20020407193924.GA386@swordfish.havenrock.com> Message-ID: <200204080157.g381vxk03550@localhost.localdomain> > On Sun, Apr 07, 2002 at 11:00:54AM -0600, Uche Ogbuji wrote: > > > [Scott Sweeney] > > > > > > > Announcing... > > > > > > > > SLiP 0.1: a "Sorta Like Python" shorthand syntax for XML > > > > SLIDE 0.1: a "Sorta Like an IDE" lightweight windows exe for SLiP editing > > > > SLiPpy 0.1: a SLiP package for Python, including a SLiP->XML library > > > > > > Either way, these little indented text formats are wonderful for whipping > > > out hand-authored XML. > > Still too heavy for prose composition, IMNSHO. I've been working on a > *really* simple alternative intended mainly for writing documentation; > alpha implementation should be out in a couple of days. For writing strictly documentation, there is already structured text NG. These projects are more general. For example, can I edit RDF/XML in your format? -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Latest article: Managing structured Web service metadata - http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/ Next presentation: XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From tpassin@comcast.net Mon Apr 8 04:28:58 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Sun, 07 Apr 2002 23:28:58 -0400 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing References: <200204080157.g381vxk03550@localhost.localdomain> Message-ID: <002301c1dead$85576410$0bf13044@tbp> [Uche Ogbuji] > > For example, can I edit RDF/XML in your format? > > Straight out of the (original) M&S [1]: rdf:RDF:: rdf:Description:: @about::http://www.w3.org/Home/Lassila s:Creator:: s:Person:: @about::http://www.w3.org/staffId/85740 v:Name::Ora Lasilla v:email::lassila@w3.org Cheers, Tom P [1] Ora Lassila lassila@w3.org Message-ID: <002801c1dead$d226a120$0bf13044@tbp> [Uche Ogbuji] > It feels as if you two must have fundamental implementation differences in our > systems, but is there a way to merge them, and put together a standard XML-SIG > proposal for an indented short-hand for XML? > > If so, I suspect we could have another XBEL-grade success on our hands. I > think the people who have to deal with editing XML by hand are profusely > scattered far beyond te Python community. > I'm very willing to look at it if Scott is. I've already sent him my parser to look at. What say, Scott? Cheers, Tom P From Matt Gushee Mon Apr 8 05:49:09 2002 From: Matt Gushee (Matt Gushee) Date: Sun, 7 Apr 2002 22:49:09 -0600 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing In-Reply-To: <200204080157.g381vxk03550@localhost.localdomain> References: <20020407193924.GA386@swordfish.havenrock.com> <200204080157.g381vxk03550@localhost.localdomain> Message-ID: <20020408044909.GB888@swordfish.havenrock.com> On Sun, Apr 07, 2002 at 07:57:59PM -0600, Uche Ogbuji wrote: > > Still too heavy for prose composition, IMNSHO. I've been working on a > > *really* simple alternative intended mainly for writing documentation; > > alpha implementation should be out in a couple of days. > > For writing strictly documentation, there is already structured text NG. Yes, I looked at it and every other structured text format I could easily find on the Web before deciding to create my own ... well, I'm not sure create is the right word: it's a variation on XMLMind's APT format, which is quite similar to Structured Text NG. I removed features that a) encourage people to think of the structured text document as an end product, such as bold and italic tags, or b) tend to impede the writing process, such as the requirement to number every item of an ordered list (makes it hard to delete or insert elements in the middle). I also added a feature or two. For anyone who's interested, there will be a full explanation soon. > These projects are more general. Okay, good point. Though I'm not sure I understand the need for shorthand when creating "documents" that consist mainly of data fields or the like -- they're not very easy to read in any case, and any editor worth its salt either provides shortcuts for typing XML or can be programmed to do so. > For example, can I edit RDF/XML in your format? You could do it as a three-column table, and feed the processor a mapping to the RDF/XML structures. But you've got a good point there: it's really not designed for that sort of thing. -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ From ssweeney@idiosync.net Mon Apr 8 10:11:16 2002 From: ssweeney@idiosync.net (Scott Sweeney) Date: Mon, 8 Apr 2002 02:11:16 -0700 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing In-Reply-To: <002801c1dead$d226a120$0bf13044@tbp> Message-ID: If you two are in, I'd enjoy dedicating some time to it. It sounds like there is enough interest in shorthand XMLs that would be a very worthwhile exercise. Give me a day or two to do a little more research and finish fixing a few of the early bugs in SLIDE and I'll be ready to roll. - Scott -----Original Message----- From: xml-sig-admin@python.org [mailto:xml-sig-admin@python.org]On Behalf Of Thomas B. Passin Sent: Sunday, April 07, 2002 8:31 PM To: XML-SIG@python.org Subject: Re: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing [Uche Ogbuji] > It feels as if you two must have fundamental implementation differences in our > systems, but is there a way to merge them, and put together a standard XML-SIG > proposal for an indented short-hand for XML? > > If so, I suspect we could have another XBEL-grade success on our hands. I > think the people who have to deal with editing XML by hand are profusely > scattered far beyond te Python community. > I'm very willing to look at it if Scott is. I've already sent him my parser to look at. What say, Scott? Cheers, Tom P _______________________________________________ XML-SIG maillist - XML-SIG@python.org http://mail.python.org/mailman/listinfo/xml-sig From ssweeney@idiosync.net Mon Apr 8 10:11:16 2002 From: ssweeney@idiosync.net (Scott Sweeney) Date: Mon, 8 Apr 2002 02:11:16 -0700 Subject: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing In-Reply-To: <20020407193924.GA386@swordfish.havenrock.com> Message-ID: Do you have some samples of the documentation you are building your alternative for? I'd love to have a look at the case you describe. -----Original Message----- From: xml-sig-admin@python.org [mailto:xml-sig-admin@python.org]On Behalf Of Matt Gushee Sent: Sunday, April 07, 2002 12:39 PM To: xml-sig@python.org Subject: Re: [XML-SIG] ANN: SLiP and SLIDE - a quick XML shorthand syntax and tool for editing On Sun, Apr 07, 2002 at 11:00:54AM -0600, Uche Ogbuji wrote: > > [Scott Sweeney] > > > > > Announcing... > > > > > > SLiP 0.1: a "Sorta Like Python" shorthand syntax for XML > > > SLIDE 0.1: a "Sorta Like an IDE" lightweight windows exe for SLiP editing > > > SLiPpy 0.1: a SLiP package for Python, including a SLiP->XML library > > > > Either way, these little indented text formats are wonderful for whipping > > out hand-authored XML. Still too heavy for prose composition, IMNSHO. I've been working on a *really* simple alternative intended mainly for writing documentation; alpha implementation should be out in a couple of days. Oh, I'm doing it in Ruby, though. For the time being. No, Uche, I haven't gone over to the other side. Just broadening my horizons a bit. -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ _______________________________________________ XML-SIG maillist - XML-SIG@python.org http://mail.python.org/mailman/listinfo/xml-sig From reagle@w3.org Mon Apr 8 17:53:44 2002 From: reagle@w3.org (Joseph Reagle) Date: Mon, 8 Apr 2002 12:53:44 -0400 Subject: [XML-SIG] default namespace prefixes in xpath's processorNss In-Reply-To: <200204071705.g37H5DY01752@localhost.localdomain> References: <200204071705.g37H5DY01752@localhost.localdomain> Message-ID: <200204081653.MAA12437@tux.w3.org> --------------Boundary-00=_KLD9NDHW8O7FB4M2IAPG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit On Sunday 07 April 2002 13:05, Uche Ogbuji wrote: > It is not. Unlike some other specs, XPath forbids the application of > default namespace to unqualified names in expressions. Ok, good. > Why do you think you need to apply the default namespace within XPath > expressions? I was trying to create a Canonical form that agreed with Gregor's results in the attachement. However, I was misunderstanding what Gregor was trying to do -- and I didn't think should be done. So now that that is cleared up, I need to return to route out the bug exists in c14n.py instead of being confused (disagreeing) about something that wasn't being done. -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ --------------Boundary-00=_KLD9NDHW8O7FB4M2IAPG Content-Type: text/xml; charset="iso-8859-1"; name="iaikTests.example2.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="iaikTests.example2.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KCjwhLS0gWFBhdGg9InNlbGY6 OlBhcmVudCBvciAocGFyZW50OjpQYXJlbnQgYW5kIG5vdChzZWxmOjpkZWZhdWx0OkNoaWxkKSkg b3Igc2VsZjo6R3JhbmRDaGlsZCBvciBwYXJlbnQ6OkdyYW5kQ2hpbGQiIC0tPgo8IS0tIGFkZGl0 aW9uYWxOU1ByZWZpeGVzPSJkZWZhdWx0IGh0dHA6Ly9mb28uY29tIiAtLT4KCjwhLS0gUmVzdWx0 IEMxNE46CjxQYXJlbnQ+CiAgICA8R3JhbmRDaGlsZD48L0dyYW5kQ2hpbGQ+CiAgPC9QYXJlbnQ+ Ci0tPgoKPCEtLSBBbm5vdGF0aW9uIEMxNE46CjEuIFRoZSB4bWxucz0iIiBvZiBQYXJlbnQgaXMg bm90IHJlbmRlcmVkLCBhbHRob3VnaCBpdCBpcyBleHBsaWNpdGx5IGRlY2xhcmVkLgogICBUaGlz IGlzIGJlY2F1c2UgUGFyZW50IGhhcyBubyBvdXRwdXQgcGFyZW50IHdpdGggYSBkZWZhdWx0IG5h bWVzcGFjZSBkZWNsYS0KICAgcmF0aW9uIHRoYXQgaXMgaW4gdGhlIG5vZGUgc2V0LgoyLiBUaGUg eG1sbnM9IiIgb2YgR3JhbmRDaGlsZCBpcyBub3QgcmVuZGVyZWQsIGFsdGhvdWdoIGl0IGlzIGV4 cGxpY2l0bHkKICAgZGVjbGFyZWQuIFRoaXMgaXMgYmVjYXVzZSBHcmFuZENoaWxkIGhhcyBubyBv dXRwdXQgcGFyZW50IHdpdGggYSBkZWZhdWx0CiAgIG5hbWVzcGFjZSBkZWNsYXJhdGlvbiB0aGF0 IGlzIGluIHRoZSBub2RlIHNldC4KLS0+Cgo8IS0tIFJlc3VsdCBFQzE0TjoKPFBhcmVudD4KICAg IDxHcmFuZENoaWxkPjwvR3JhbmRDaGlsZD4KICA8L1BhcmVudD4KLS0+Cgo8IS0tIEFubm90YXRp b24gRUMxNE46ClNlZSBBbm5vdGF0aW9uIEMxNE4uCi0tPgoKPEdyYW5kUGFyZW50PgogIDxQYXJl bnQgeG1sbnM9IiI+CiAgICA8Q2hpbGQgeG1sbnM9Imh0dHA6Ly9mb28uY29tIj4KICAgICAgPEdy YW5kQ2hpbGQgeG1sbnM9IiIvPgogICAgPC9DaGlsZD4KICA8L1BhcmVudD4KPC9HcmFuZFBhcmVu dD4= --------------Boundary-00=_KLD9NDHW8O7FB4M2IAPG-- From woodm@equire.com Mon Apr 8 19:20:10 2002 From: woodm@equire.com (Matthew D. Wood) Date: 08 Apr 2002 12:20:10 -0600 Subject: [XML-SIG] Hello. Message-ID: <1018290010.1234.24.camel@localhost.localdomain> Hello. I'm new to the list and wanted to say 'Hi.' to everyone here. I also have a question that was semi discussed on the list previously. My problem is demonstrated as following: > python Python 2.2 (#1, Apr 4 2002, 13:37:04)_ [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from xml.xslt.Processor import Processor >>> proc = Processor() >>> proc >>> proc.appendStylesheetUri('Vehicles.xsl') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/_xmlplus/xslt/Processor.py", line 95, in appendStylesheetUri sty = self._styReader.fromUri(styleSheetUri, baseUri) File "/usr/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 297, in fromUri ownerDoc, stripElements) File "/usr/lib/python2.2/site-packages/_xmlplus/xslt/minisupport.py", line 58, in fromUri return self.fromStream(stream, baseUri, ownerDoc, stripElements) File "/usr/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 304, in fromStream self.initParser() File "/usr/lib/python2.2/site-packages/_xmlplus/xslt/StylesheetReader.py", line 344, in initParser if self._force8Bit: AttributeError: StylesheetReader instance has no attribute '_force8Bit' This question was already asked in March on your archive I believe. But I'm using the 0.7 version of PyXML, which I believe to be the newest version available. (It was a package from the Gentoo/Portage tree, if that matters. www.gentoo.org) I don't know what version of 4Suit I'm using, but I can check if someone will tell me how. :-) Anyway, I wanted to thank you for the product that is out there already. I really enjoy using it. -- _________________________ ----------------------------------------------/ / Matthew D. Wood Old Java programmers don't die. They're / Home Phone: 303.415.1550 just dereferenced, and awaiting garbage / E-Mail: woodm@equire.com collection. / _________________________________________/------------------------------ From martin@v.loewis.de Mon Apr 8 21:54:44 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 08 Apr 2002 22:54:44 +0200 Subject: [XML-SIG] Hello. In-Reply-To: <1018290010.1234.24.camel@localhost.localdomain> References: <1018290010.1234.24.camel@localhost.localdomain> Message-ID: "Matthew D. Wood" writes: > AttributeError: StylesheetReader instance has no attribute '_force8Bit' > > > This question was already asked in March on your archive I believe. But > I'm using the 0.7 version of PyXML, which I believe to be the newest > version available. (It was a package from the Gentoo/Portage tree, if > that matters. www.gentoo.org) > > I don't know what version of 4Suit I'm using, but I can check if someone > will tell me how. :-) In that case, you likely ran into a bug in PyXML. If you also have 4Suite, make sure you *only* use the version of xml.xslt that comes with 4Suite. Merely installing it is not enough: you need to delete xml.xslt after installing PyXML, then install 4Suite. HTH, Martin From dwallace@UDel.Edu Mon Apr 8 22:26:35 2002 From: dwallace@UDel.Edu (Dave Wallace) Date: Mon, 08 Apr 2002 17:26:35 -0400 Subject: [XML-SIG] Does this code segfault for you? References: <3CAE6B0F.8020202@comcast.com> <3CAE73A8.5060807@verizon.net> <3CB1D311.9070703@udel.edu> <3CB1F18C.3080107@verizon.net> Message-ID: <3CB20B0B.6080105@udel.edu> [Sorry, I didn't mean to take this private, I'm adding the list back in.] I'm still getting the segfault, even with the latest CVS. Is there a patch that hasn't been applied to the tree yet, or perhaps the bug crept back in? (or better yet: I'm nuts and I screwed something up!) Thanks, Dave. Rich Salz wrote: > The bug has since been resolved. It's a bug purely in the internal > python C implementation. > /r$ From Jean-Francois.Doyon@CCRS.NRCan.gc.ca Mon Apr 8 23:25:25 2002 From: Jean-Francois.Doyon@CCRS.NRCan.gc.ca (Doyon, Jean-Francois) Date: Mon, 8 Apr 2002 18:25:25 -0400 Subject: [XML-SIG] Handling large amouns of character data Message-ID: <7CDD7B94357FD5119E800002A537C46E22FFEF@s5-ccr-r1.ccrs.nrcan.gc.ca> Hello, I've run into a rather weird problem: I'm using the xml.parsers.expat module to parse some GML, and have some character data that contains a LOT of data ... Here is the problem, it seems that the parser inserts some sort of = "newline" when lines are really long, which breaks a whole lot of things. Sounds simple enough to fix, but I can't figure it out!!! Here is my character data handler: def char_data(data): global nextchardata, xynodes if ( nextchardata =3D=3D 'coordinates' ): print data data =3D strip(data) if ( data !=3D '' ): if ( xynodes =3D=3D None ): xynodes =3D data else: xynodes =3D xynodes+' '+data nextchardata =3D None if I do a "print data" RIGHT AFTER the "def" line, I see ALL the data = dumped to screen, with "newlines" appearing after a given size "chunk" it = seems. I've tried to remove those using the "replace" function, but to no = avail. I'm not even sure what they are ... Here's the kicker: If I put that "print data" as the first line within the first "if" statement, boum, my data just got stripped, only the FIRST line of = those now "multiline" data sets is now available!!! I didn't even do anything to = it!=20 What's going on? I'm sure I'm not the first to have come accross this, = but I can't seem to find any documentation on expat, or it's limits, or why = this is happening .... Any help would be greatly appreaciated!!! Thanks, Jean-Fran=E7ois Doyon Internet Service Development and Systems Support GeoAccess Division Canadian Center for Remote Sensing Natural Resources Canada http://atlas.gc.ca Phone: (613) 992-4902 Fax: (613) 947-2410 From martin@v.loewis.de Mon Apr 8 23:22:05 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 09 Apr 2002 00:22:05 +0200 Subject: [XML-SIG] Does this code segfault for you? In-Reply-To: <3CB20B0B.6080105@udel.edu> References: <3CAE6B0F.8020202@comcast.com> <3CAE73A8.5060807@verizon.net> <3CB1D311.9070703@udel.edu> <3CB1F18C.3080107@verizon.net> <3CB20B0B.6080105@udel.edu> Message-ID: Dave Wallace writes: > [Sorry, I didn't mean to take this private, I'm adding the list back in.] > > I'm still getting the segfault, even with the latest CVS. Is there a > patch that hasn't been applied to the tree yet, or perhaps the bug > crept back in? (or better yet: I'm nuts and I screwed something up!) I guess you screwed something. Are you *sure* you both have updated to the latest CVS, and using it? If so, can you report a CVS backtrace? Regards, Martin From fredrik@pythonware.com Mon Apr 8 23:56:29 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 9 Apr 2002 00:56:29 +0200 Subject: [XML-SIG] Handling large amouns of character data References: <7CDD7B94357FD5119E800002A537C46E22FFEF@s5-ccr-r1.ccrs.nrcan.gc.ca> Message-ID: <024e01c1df50$a2c1eb80$ced241d5@hagrid> Jean-Francois wrote: > Here is the problem, it seems that the parser inserts some sort of "newline" > when lines are really long, which breaks a whole lot of things. more likely, the parser calls char_data more than once without calling the start tag or end tag handler. > Here is my character data handler: > > def char_data(data): > global nextchardata, xynodes > if ( nextchardata == 'coordinates' ): > print data > data = strip(data) > if ( data != '' ): > if ( xynodes == None ): > xynodes = data > else: > xynodes = xynodes+' '+data > nextchardata = None > > if I do a "print data" RIGHT AFTER the "def" line, I see ALL the data dumped > to screen, with "newlines" appearing after a given size "chunk" it seems. > > I've tried to remove those using the "replace" function, but to no avail. > I'm not even sure what they are ... the print statement always prints a newline at the end of each line. > Here's the kicker: > > If I put that "print data" as the first line within the first "if" statement, > boum, my data just got stripped, only the FIRST line of those now > "multiline" data sets is now available!!! I didn't even do anything to it! of course you did: the last thing you do in your handler is to set nextchardata to None, which causes the "coordinates" text to fail on the next call. try resetting nextchardata in the end-tag handler instead. (a more robust approach is to use a list or character buffer to collect string fragments in the character handler, reset that list in the start tag handler, and process it in the end tag handler.) From Mike.Olson@fourthought.com Tue Apr 9 05:59:29 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 08 Apr 2002 22:59:29 -0600 Subject: [XML-SIG] Hello. In-Reply-To: <1018290010.1234.24.camel@localhost.localdomain> References: <1018290010.1234.24.camel@localhost.localdomain> Message-ID: <1018328370.4902.2.camel@penny> On Mon, 2002-04-08 at 12:20, Matthew D. Wood wrote: > Hello. I'm new to the list and wanted to say 'Hi.' to everyone here. Welcome. > This question was already asked in March on your archive I believe. But > I'm using the 0.7 version of PyXML, which I believe to be the newest > version available. (It was a package from the Gentoo/Portage tree, if > that matters. www.gentoo.org) > > I don't know what version of 4Suit I'm using, but I can check if someone > will tell me how. :-) I'm pretty sure that you are using 4Suite 0.11.1 which is not compatible with PyXML 0.7 Mike > > > Anyway, I wanted to thank you for the product that is out there > already. I really enjoy using it. > > > > -- > _________________________ > ----------------------------------------------/ > / Matthew D. Wood > Old Java programmers don't die. They're / Home Phone: 303.415.1550 > just dereferenced, and awaiting garbage / E-Mail: woodm@equire.com > collection. / > _________________________________________/------------------------------ > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From woodm@equire.com Tue Apr 9 07:03:29 2002 From: woodm@equire.com (Matthew D. Wood) Date: 09 Apr 2002 00:03:29 -0600 Subject: [XML-SIG] Hello. In-Reply-To: <1018328370.4902.2.camel@penny> References: <1018290010.1234.24.camel@localhost.localdomain> <1018328370.4902.2.camel@penny> Message-ID: <1018332209.1242.35.camel@localhost.localdomain> Thank you all for the help. I tried to install the source for 4suite, but it didn't seem to enjoy itself on my computer. However, I was mostly testing the Gentoo Linux distrobution out anyway. And, as I don't particularly like it, I think I will revert my system back to FreeBSD. Maybe the xml-python suite that's in the ports tree there will be better (or nicer to me at least :-) ) I will keep you guys posted. And thanks again for the responses. On Mon, 2002-04-08 at 22:59, Mike Olson wrote: > On Mon, 2002-04-08 at 12:20, Matthew D. Wood wrote: > > Hello. I'm new to the list and wanted to say 'Hi.' to everyone here. > > Welcome. > > > This question was already asked in March on your archive I believe. But > > I'm using the 0.7 version of PyXML, which I believe to be the newest > > version available. (It was a package from the Gentoo/Portage tree, if > > that matters. www.gentoo.org) > > > > I don't know what version of 4Suit I'm using, but I can check if someone > > will tell me how. :-) > > I'm pretty sure that you are using 4Suite 0.11.1 which is not compatible > with PyXML 0.7 > > Mike > > > > > > > Anyway, I wanted to thank you for the product that is out there > > already. I really enjoy using it. > > > > > > > > -- > > _________________________ > > ----------------------------------------------/ > > / Matthew D. Wood > > Old Java programmers don't die. They're / Home Phone: 303.415.1550 > > just dereferenced, and awaiting garbage / E-Mail: woodm@equire.com > > collection. / > > _________________________________________/------------------------------ > > > > > > _______________________________________________ > > XML-SIG maillist - XML-SIG@python.org > > http://mail.python.org/mailman/listinfo/xml-sig > -- > Mike Olson Principal Consultant > mike.olson@fourthought.com +1 303 583 9900 x 102 > Fourthought, Inc. http://Fourthought.com > 4735 East Walnut St, http://4Suite.org > Boulder, CO 80301-2537, USA > XML strategy, XML tools, knowledge management > -- _________________________ ----------------------------------------------/ / Matthew D. Wood What happens when pasta and antipasta / Home Phone: 303.415.1550 collide? / E-Mail: woodm@equire.com / _________________________________________/------------------------------ From woodm@equire.com Tue Apr 9 07:30:20 2002 From: woodm@equire.com (Matthew D. Wood) Date: 09 Apr 2002 00:30:20 -0600 Subject: [XML-SIG] Hello again. Message-ID: <1018333820.1242.53.camel@localhost.localdomain> While I'm at it, I might as well ask the other question that I've been having trouble with. I am creating an XML document that will contain several web-links. In trying to figure out the best way to represent a web-link I've pretty much convinced myself that the best method will be the standard: Look at the pretty page! style of link. This makes sense to me as it's valid XML and it should be pretty easy to convert it to html when I need to. Now, I would like to use XSLT to transform my XML document into an HTML or XHTML document. I understand the basics of how an XSL document should work in order to accomplish this, but I have no idea how to preserve a portion of the XML tree. I want to totally recreate the entire ... tree, and not change a thing. I can't for the life of me figure out how to do this. I will give a really stupid cut-down example of what I'm talking about here: my XML document:
first section some page
second section a different page
My desired html: a good title some page a different page notice: the ... blocks were not changed at all. I guess I could take out the href portion and the text portion and totally recreate the node, but that seems unnecessary. And for that matter, I haven't figured out how to add an attribute to the target XML. I think I've rambled enough. I will stop now. But thanks for the help guys and gals. I appreciate every little bit. -- _________________________ ----------------------------------------------/ / Matthew D. Wood "There is a diminishing return on / Home Phone: 303.415.1550 caution." / E-Mail: woodm@equire.com / _________________________________________/------------------------------ From Matt Gushee Tue Apr 9 08:12:57 2002 From: Matt Gushee (Matt Gushee) Date: Tue, 9 Apr 2002 01:12:57 -0600 Subject: [XML-SIG] Hello again. In-Reply-To: <1018333820.1242.53.camel@localhost.localdomain> References: <1018333820.1242.53.camel@localhost.localdomain> Message-ID: <20020409071257.GA2400@swordfish.havenrock.com> On Tue, Apr 09, 2002 at 12:30:20AM -0600, Matthew D. Wood wrote: > I am creating an XML document that will contain several web-links. In > trying to figure out the best way to represent a web-link I've pretty > much convinced myself that the best method will be the standard: > Look at the pretty page! > style of link. This makes sense to me as it's valid XML and it should > be pretty easy to convert it to html when I need to. Well, to be exact, it already is HTML, as well as being well-formed* XML. > Now, I would like to use XSLT to transform my XML document into an HTML > or XHTML document. Generally speaking, these sorts of questions are best asked on the xsl-list (http://www.mulberrytech.com/xsl/xsl-list/index.html). Several of the world's leading XSL/XSLT experts are regularly on that list answering questions. But since I know the answer, I'll let it slide this time ;-) > should work in order to accomplish this, but I have no idea how to > preserve a portion of the XML tree. I want to totally recreate the > entire ... tree, and not change a thing. I can't for the > life of me figure out how to do this. It's easy, though maybe not obvious. When you want to copy elements from the source to the output, you can use either an or an instruction. will give you a copy of the context node. Period. So this form is not usually what you want. If you do then you'll get the node, and send its contents back for further processing -- which may consist of more s. will copy the context node (or whatever you specify in the select attribute), and automatically recurse down through its descendants, copying all elements and text nodes. But in this case, you want to copy the attributes, so this one won't work for you. > >
> first section > some page >
> >
> second section > a different page >
> > > > My desired html: > > > > a good title > > > > some page > a different page > > Okay, so you will need something like this: > And for that matter, I haven't figured out how to add an attribute to > the target XML. If the value is a literal string, you just add it: Or you can stick in a variable reference or XPath expression by using an Attribute Value Template (AVT): That should hold you for a bit. If you plan to do any serious XSLT work, I'd suggest: 1) Investing in a good book -- I like the _XSLT Programmer's Reference_, by Michael Kay (Wrox Press). It is a reference, though. If you need a tutorial, there's a recently-published book from O'Reilly ... I forget the exact title; and 2) Subscribing to XSL-LIST. Michael Kay, BTW, is one of the experts who hang out on the list. Best of luck. -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ From Matt Gushee Tue Apr 9 08:23:16 2002 From: Matt Gushee (Matt Gushee) Date: Tue, 9 Apr 2002 01:23:16 -0600 Subject: [XML-SIG] Hello again. In-Reply-To: <20020409071257.GA2400@swordfish.havenrock.com> References: <1018333820.1242.53.camel@localhost.localdomain> <20020409071257.GA2400@swordfish.havenrock.com> Message-ID: <20020409072315.GC2400@swordfish.havenrock.com> On Tue, Apr 09, 2002 at 01:12:57AM -0600, Matt Gushee wrote: > > style of link. This makes sense to me as it's valid XML and it should > > be pretty easy to convert it to html when I need to. > > Well, to be exact, it already is HTML, as well as being well-formed* > XML. Oops. Forgot the footnote. You said "valid XML." Although your meaning is clear enough in context, it's a good habit to keep in mind the distinction between well-formed XML, which is any markup that obeys XML syntax rules, and valid XML, which conforms to a DTD or Schema. -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ From ramya_manian@persistent.com Tue Apr 9 09:02:11 2002 From: ramya_manian@persistent.com (Ramya Manian) Date: Tue, 9 Apr 2002 13:32:11 +0530 Subject: [XML-SIG] XSLT templates in Python Message-ID: <000801c1df9c$daedbbf0$6b02a8c0@intranet.pspl.co.in> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1DFCA.F468EEF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Could you please tell me how can I apply xslt templates on XML documents = in python? Regards Ramya ------=_NextPart_000_0005_01C1DFCA.F468EEF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
Could you please tell me how can I = apply xslt=20 templates on XML documents in python?
 
Regards
Ramya
------=_NextPart_000_0005_01C1DFCA.F468EEF0-- From Matt Gushee Tue Apr 9 09:23:09 2002 From: Matt Gushee (Matt Gushee) Date: Tue, 9 Apr 2002 02:23:09 -0600 Subject: [XML-SIG] XSLT templates in Python In-Reply-To: <000801c1df9c$daedbbf0$6b02a8c0@intranet.pspl.co.in> References: <000801c1df9c$daedbbf0$6b02a8c0@intranet.pspl.co.in> Message-ID: <20020409082309.GD2400@swordfish.havenrock.com> On Tue, Apr 09, 2002 at 01:32:11PM +0530, Ramya Manian wrote: > > Could you please tell me how can I apply xslt templates on XML documents in python? I don't know what you mean by that. Do you need ...to find a Python-based XSLT processor? -- there are at least two: 4xslt, which is part of 4Suite (http://4Suite.org/), and Pyana (don't know the URL) ...instructions on how to write an XSLT stylesheet? -- that has nothing to do with Python. Try the online XSLT tutorial at http://www.zvon.org/. After you understand a little XSLT, you can ask questions on the XSL-LIST (http://www.mulberrytech.com/xsl/xsl-list/index.html) -- but you should try to ask more specific questions. XSL-LIST is very busy, but you will get good answers if you ask good questions. ...instructions on how to use one of the Python XSLT processors? -- whichever one you are using, please read the documentation first. Then, if you have questions about 4Suite, you can ask here, but the best place is the 4Suite mailing list: http://lists.fourthought.com/mailman/listinfo/4suite ...or something else? -- please be more specific. Hope this helps. -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ From tpassin@comcast.net Tue Apr 9 13:44:11 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Tue, 09 Apr 2002 08:44:11 -0400 Subject: [XML-SIG] Hello again. References: <1018333820.1242.53.camel@localhost.localdomain> Message-ID: <000801c1dfc4$3fef3570$0bf13044@tbp> [Matthew D. Wood] > I am creating an XML document that will contain several web-links. In > trying to figure out the best way to represent a web-link I've pretty > much convinced myself that the best method will be the standard: > Look at the pretty page! > style of link. This makes sense to me as it's valid XML and it should > be pretty easy to convert it to html when I need to. > > Now, I would like to use XSLT to transform my XML document into an HTML > or XHTML document. I understand the basics of how an XSL document > should work in order to accomplish this, but I have no idea how to > preserve a portion of the XML tree. I want to totally recreate the > entire ... tree, and not change a thing. I can't for the > life of me figure out how to do this. Use xsl:copy or xsl:copy-of. Join the Mulberrry xslt list - it's very good for xslt questions. Cheers, Tom P From uche.ogbuji@fourthought.com Tue Apr 9 15:08:32 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 09 Apr 2002 08:08:32 -0600 Subject: [XML-SIG] Hello again. In-Reply-To: Message from "Thomas B. Passin" of "Tue, 09 Apr 2002 08:44:11 EDT." <000801c1dfc4$3fef3570$0bf13044@tbp> Message-ID: <200204091408.g39E8WU12663@localhost.localdomain> > Use xsl:copy or xsl:copy-of. Join the Mulberrry xslt list - it's very good > for xslt questions. Not meaning to contradict those rightly asking people to ask basic XSLT questions on the Mulberry XSL list, but I have recently found myself not always making this recommendation. Especially considering I had to dump the list, myself. The volume is huge, and for all we know, some of our correspondents are on dial-up lines, or high-cost connections (still common in parts of the world). Does anyone happen to know of a lower-volume list particularly for XSLT newbies? At the very least, when I recommend someone join the list, these days, I warn them that the volume can be upwards of 50 messages a day. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Latest article: Managing structured Web service metadata - http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/ Latest article: WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id =6004 Next presentation: XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From dwallace@UDel.Edu Tue Apr 9 15:54:08 2002 From: dwallace@UDel.Edu (Dave Wallace) Date: Tue, 09 Apr 2002 10:54:08 -0400 Subject: [XML-SIG] Does this code segfault for you? References: <3CAE6B0F.8020202@comcast.com> <3CAE73A8.5060807@verizon.net> <3CB1D311.9070703@udel.edu> <3CB1F18C.3080107@verizon.net> <3CB20B0B.6080105@udel.edu> Message-ID: <3CB30090.6080509@udel.edu> Martin, I have rebuilt several times, on two separate Linux boxes. I am as sure as I can get that I am using the latest PyXML cvs. I searched around for stray pyexpat.so libraries, I even removed the pyexpat.so that is built by the Python distro. I also modifed my script to import xml.parsers.pyexpat print pyexpat.__version__ which is 2.58. Perhaps there is another native module that comes into play here? I'm not sure what a CVS "backtrace" is? The output of cvs status? Thanks, Dave. Martin v. Loewis wrote: >Dave Wallace writes: > >>[Sorry, I didn't mean to take this private, I'm adding the list back in.] >> >>I'm still getting the segfault, even with the latest CVS. Is there a >>patch that hasn't been applied to the tree yet, or perhaps the bug >>crept back in? (or better yet: I'm nuts and I screwed something up!) >> > >I guess you screwed something. Are you *sure* you both have updated to >the latest CVS, and using it? If so, can you report a CVS backtrace? > >Regards, >Martin > > > >_______________________________________________ >XML-SIG maillist - XML-SIG@python.org >http://mail.python.org/mailman/listinfo/xml-sig > From Alexandre.Fayolle@logilab.fr Tue Apr 9 16:32:17 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Tue, 9 Apr 2002 17:32:17 +0200 Subject: [XML-SIG] What should go in Debian Woody? Message-ID: <20020409153217.GJ20067@orion.logilab.fr> Hi everybody, Debian/Woody is due out Real Soon Now, and there's a problem with the python-xml and python-4suite packages that are currently to ship with Woody. Right now, we have python-xml-0.7-1, which is made of PyXML-0.7 with a few patches to fix some problems with XBEL and without xml.xpath nor xml.xslt, and python-4suite-0.11.1, wich is 4Suite-0.11.1 packages very straightforwardly from the Fourthought release. Problem is that it is impossible to use the xml.xslt package from python-4suite, because of the EMPTY_NAMESPACE changes in PyXML from the end of last year. And on the other hand, it is not possible to use xml.xslt from PyXML-0.7 because of some problems in the port from 4suite (for instance bug #510080). My understanding of the status of the xml.xslt problems in PyXML is that we are waiting for a new release of 4Suite's Xslt to integrate it with PyXML, so there is less incitation to fix the current release (please correct me if I'm wrong). Right now, the only two solution I can think of are: * replacing python-xml-0.7 in Woody with python-xml-0.6.8, which used to work fine with python-4suite-0.11.1 * dropping python-4suite-0.11.1 from Woody and patching python-xml-0.7 to provide a useable xml.xslt module I'd like to know if there are other options that I would have missed, or some suggestions from the people on the lists. There's been a discussion on the debian-python mailing list that you may want to look at: http://lists.debian.org/debian-python/2002/debian-python-200204/msg00018.html 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 Tue Apr 9 16:37:08 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 09 Apr 2002 09:37:08 -0600 Subject: [XML-SIG] Re: [4suite] What should go in Debian Woody? In-Reply-To: <20020409153217.GJ20067@orion.logilab.fr> References: <20020409153217.GJ20067@orion.logilab.fr> Message-ID: <1018366629.12786.95.camel@borgia.local> On Tue, 2002-04-09 at 09:32, Alexandre wrote: > Right now, the only two solution I can think of are: > * replacing python-xml-0.7 in Woody with python-xml-0.6.8, which used > to work fine with python-4suite-0.11.1 > * dropping python-4suite-0.11.1 from Woody and patching python-xml-0.7 > to provide a useable xml.xslt module Since Woody is coming out really soon now, and it is to become the new Debian stable, I think option 1 is the certain best choice. Option 2 would take a good deal of work and time, and would involve adding immature code. PyXML 0.6.8/4Suite 0.11.1 may be old, but they're stable. As long as Sid tracks PyXML 0.7 and 4Suite 0.12.0, people who want the latest and greatest always have an option, and I, as a new Debian convert (for which I can thank/blame Edd Dumbill :-) ), will try to help this process where I can. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Latest article: Managing structured Web service metadata - http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/ Latest article: WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 Next presentation: XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From Jean-Francois.Doyon@CCRS.NRCan.gc.ca Tue Apr 9 18:34:02 2002 From: Jean-Francois.Doyon@CCRS.NRCan.gc.ca (Doyon, Jean-Francois) Date: Tue, 9 Apr 2002 13:34:02 -0400 Subject: [XML-SIG] Handling large amouns of character data Message-ID: <7CDD7B94357FD5119E800002A537C46E22FFF2@s5-ccr-r1.ccrs.nrcan.gc.ca> Frederik, Ahhhh, indeed, it never occured to me that the parser might be calling the CharacterDataHandler more than once for a given set of character data ... Once you helped me realize that, everything fell into place :) Thanks for the help, much appreciated! J.F. -----Original Message----- From: Fredrik Lundh [mailto:fredrik@pythonware.com] Sent: Monday, April 08, 2002 6:56 PM To: Doyon, Jean-Francois; xml-sig@python.org Subject: Re: [XML-SIG] Handling large amouns of character data Jean-Francois wrote: > Here is the problem, it seems that the parser inserts some sort of "newline" > when lines are really long, which breaks a whole lot of things. more likely, the parser calls char_data more than once without calling the start tag or end tag handler. > Here is my character data handler: > > def char_data(data): > global nextchardata, xynodes > if ( nextchardata == 'coordinates' ): > print data > data = strip(data) > if ( data != '' ): > if ( xynodes == None ): > xynodes = data > else: > xynodes = xynodes+' '+data > nextchardata = None > > if I do a "print data" RIGHT AFTER the "def" line, I see ALL the data dumped > to screen, with "newlines" appearing after a given size "chunk" it seems. > > I've tried to remove those using the "replace" function, but to no avail. > I'm not even sure what they are ... the print statement always prints a newline at the end of each line. > Here's the kicker: > > If I put that "print data" as the first line within the first "if" statement, > boum, my data just got stripped, only the FIRST line of those now > "multiline" data sets is now available!!! I didn't even do anything to it! of course you did: the last thing you do in your handler is to set nextchardata to None, which causes the "coordinates" text to fail on the next call. try resetting nextchardata in the end-tag handler instead. (a more robust approach is to use a list or character buffer to collect string fragments in the character handler, reset that list in the start tag handler, and process it in the end tag handler.) From Mike.Olson@fourthought.com Tue Apr 9 20:45:50 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 09 Apr 2002 13:45:50 -0600 Subject: [XML-SIG] What should go in Debian Woody? In-Reply-To: <20020409153217.GJ20067@orion.logilab.fr> References: <20020409153217.GJ20067@orion.logilab.fr> Message-ID: <1018381552.4969.16.camel@penny> On Tue, 2002-04-09 at 09:32, Alexandre wrote: > > Right now, the only two solution I can think of are: > * replacing python-xml-0.7 in Woody with python-xml-0.6.8, which used > to work fine with python-4suite-0.11.1 > * dropping python-4suite-0.11.1 from Woody and patching python-xml-0.7 > to provide a useable xml.xslt module I think another option is to use 0.12.0 w/ PyXML 0.7.1. The only reason it is still Alpha is because we (FT) have not had time to complete packaging and update our web site for the final release. Mike > > I'd like to know if there are other options that I would have missed, or > some suggestions from the people on the lists. > > There's been a discussion on the debian-python mailing list that you may > want to look at: > http://lists.debian.org/debian-python/2002/debian-python-200204/msg00018.html > > 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). > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From martin@v.loewis.de Tue Apr 9 20:43:40 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 09 Apr 2002 21:43:40 +0200 Subject: [XML-SIG] What should go in Debian Woody? In-Reply-To: <20020409153217.GJ20067@orion.logilab.fr> References: <20020409153217.GJ20067@orion.logilab.fr> Message-ID: Alexandre writes: > Right now, the only two solution I can think of are: > * replacing python-xml-0.7 in Woody with python-xml-0.6.8, which used > to work fine with python-4suite-0.11.1 This is what I recommend to do. Regards, Martin From martin@v.loewis.de Tue Apr 9 20:42:18 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 09 Apr 2002 21:42:18 +0200 Subject: [XML-SIG] Does this code segfault for you? In-Reply-To: <3CB30090.6080509@udel.edu> References: <3CAE6B0F.8020202@comcast.com> <3CAE73A8.5060807@verizon.net> <3CB1D311.9070703@udel.edu> <3CB1F18C.3080107@verizon.net> <3CB20B0B.6080105@udel.edu> <3CB30090.6080509@udel.edu> Message-ID: Dave Wallace writes: > I have rebuilt several times, on two separate Linux boxes. I am as > sure as I can get that I am using the latest PyXML cvs. That may be the problem: We were talking about the latest Python CVS... > I'm not sure what a CVS "backtrace" is? The output of cvs status? No: If it still crashes (after rebuilding *Python*), please run it in gdb, let it crash, then invoke "bt". Regards, Martin From uche.ogbuji@fourthought.com Tue Apr 9 21:01:12 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 09 Apr 2002 14:01:12 -0600 Subject: [4suite] Re: [XML-SIG] What should go in Debian Woody? In-Reply-To: <1018381552.4969.16.camel@penny> References: <20020409153217.GJ20067@orion.logilab.fr> <1018381552.4969.16.camel@penny> Message-ID: <1018382473.12787.680.camel@borgia.local> On Tue, 2002-04-09 at 13:45, Mike Olson wrote: > On Tue, 2002-04-09 at 09:32, Alexandre wrote: > > > > Right now, the only two solution I can think of are: > > * replacing python-xml-0.7 in Woody with python-xml-0.6.8, which used > > to work fine with python-4suite-0.11.1 > > * dropping python-4suite-0.11.1 from Woody and patching python-xml-0.7 > > to provide a useable xml.xslt module > > I think another option is to use 0.12.0 w/ PyXML 0.7.1. The only reason > it is still Alpha is because we (FT) have not had time to complete > packaging and update our web site for the final release. Well, since beta release is bug-fix only, I agree with your implication that the next 4Suite release should be beta. But I don't think beta is good enough for Woody (at least not when it becomes Debian Stable). Debian Stable is precisely for mature packages. 4Suite 0.12.0 still needs work in this department, not least in the documentation. -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Latest article: Managing structured Web service metadata - http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/ Latest article: WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 Next presentation: XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From jmarant@free.fr Tue Apr 9 21:17:36 2002 From: jmarant@free.fr (=?iso-8859-1?q?J=E9r=F4me?= Marant) Date: Tue, 09 Apr 2002 22:17:36 +0200 Subject: [XML-SIG] Re: [4suite] What should go in Debian Woody? In-Reply-To: <1018366629.12786.95.camel@borgia.local> (Uche Ogbuji's message of "09 Apr 2002 09:37:08 -0600") References: <20020409153217.GJ20067@orion.logilab.fr> <1018366629.12786.95.camel@borgia.local> Message-ID: <87vgb0pqxr.fsf@marant.org> Uche Ogbuji writes: > On Tue, 2002-04-09 at 09:32, Alexandre wrote: > >> Right now, the only two solution I can think of are: >> * replacing python-xml-0.7 in Woody with python-xml-0.6.8, which used >> to work fine with python-4suite-0.11.1 >> * dropping python-4suite-0.11.1 from Woody and patching python-xml-0.7 >> to provide a useable xml.xslt module > > Since Woody is coming out really soon now, and it is to become the new > Debian stable, I think option 1 is the certain best choice. Option 2 > would take a good deal of work and time, and would involve adding > immature code. PyXML 0.6.8/4Suite 0.11.1 may be old, but they're > stable. Unfortunately, Option 2 is likely to happen: Debian boot floppies use python-xml to render documentation; I already broke them once when I switched from 0.6.7 to 0.7 (it happened last December). I'm not going to do the same mistake this time. Here are my two options: 1/ 4Suite 0.11.1 stay in Debian even broken (except from xslt and xpath, is it still usable indenpendtly?) 2/ 4Suite 0.11.1 be removed > As long as Sid tracks PyXML 0.7 and 4Suite 0.12.0, people who want the > latest and greatest always have an option, and I, as a new Debian > convert (for which I can thank/blame Edd Dumbill :-) ), will try to help > this process where I can. Be careful, pro-Debian rants are not allowed in there ;-) -- Jérôme Marant http://marant.org From uche.ogbuji@fourthought.com Tue Apr 9 21:24:05 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 09 Apr 2002 14:24:05 -0600 Subject: [XML-SIG] Re: [4suite] What should go in Debian Woody? In-Reply-To: <87vgb0pqxr.fsf@marant.org> References: <20020409153217.GJ20067@orion.logilab.fr> <1018366629.12786.95.camel@borgia.local> <87vgb0pqxr.fsf@marant.org> Message-ID: <1018383854.12933.731.camel@borgia.local> On Tue, 2002-04-09 at 14:17, J=E9r=F4me Marant wrote: > Uche Ogbuji writes: >=20 > > On Tue, 2002-04-09 at 09:32, Alexandre wrote: > > > >> Right now, the only two solution I can think of are: > >> * replacing python-xml-0.7 in Woody with python-xml-0.6.8, which used > >> to work fine with python-4suite-0.11.1 > >> * dropping python-4suite-0.11.1 from Woody and patching python-xml-0.= 7 > >> to provide a useable xml.xslt module > > > > Since Woody is coming out really soon now, and it is to become the new > > Debian stable, I think option 1 is the certain best choice. Option 2 > > would take a good deal of work and time, and would involve adding > > immature code. PyXML 0.6.8/4Suite 0.11.1 may be old, but they're > > stable. >=20 > Unfortunately, Option 2 is likely to happen: Debian boot floppies use > python-xml to render documentation; I already broke them once when > I switched from 0.6.7 to 0.7 (it happened last December). I'm not > going to do the same mistake this time. >=20 > Here are my two options: > 1/ 4Suite 0.11.1 stay in Debian even broken (except from xslt and xpath= , > is it still usable indenpendtly?) Yes. 4RDF, in particular, is still usable. But would this not just cause more confusion? What is the upgrade path for packages in stable? If Woody initially goes out with back-dated 4Suite or none, can the sources later update with stable versions of 4Suite 0.12.0? Or would these only appear in testing from now (which I assume is what Sid will become)? --=20 Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 720 320 2046 Fourthought, Inc. http://Fourthought.com=20 4735 East Walnut St, Boulder, CO 80301-2537, USA XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Latest article: Managing structured Web service metadata - http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/ Latest article: WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=3D6004 Next presentation: XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From martin@v.loewis.de Tue Apr 9 21:20:39 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 09 Apr 2002 22:20:39 +0200 Subject: [XML-SIG] What should go in Debian Woody? In-Reply-To: <1018381552.4969.16.camel@penny> References: <20020409153217.GJ20067@orion.logilab.fr> <1018381552.4969.16.camel@penny> Message-ID: Mike Olson writes: > I think another option is to use 0.12.0 w/ PyXML 0.7.1. I don't think this is an option: 4Suote 0.12 is not available today; Debian does need a solution today. Regards, Martin From dwallace@udel.edu Wed Apr 10 02:58:09 2002 From: dwallace@udel.edu (Dave Wallace) Date: Tue, 09 Apr 2002 21:58:09 -0400 Subject: [XML-SIG] Does this code segfault for you? References: <3CAE6B0F.8020202@comcast.com> <3CAE73A8.5060807@verizon.net> <3CB1D311.9070703@udel.edu> <3CB1F18C.3080107@verizon.net> <3CB20B0B.6080105@udel.edu> <3CB30090.6080509@udel.edu> Message-ID: <3CB39C31.8010204@udel.edu> My problem got fixed by a check-in on Python's release22-maint branch yesterday. Sorry, I think I was being a bit thick about the latest CVS stuff, but I thought the problem was in PyXML and I didn't want to add more confusion by having a possibly unstable version of Python. I also hadn't gone back to check up on the associated python bug link that Rich Salz had sent me since it looked like lemburg was saying that couldn't be the problem and I had written it off. Anyhow, thanks for your help ! Dave. Martin v. Loewis wrote: >Dave Wallace writes: > >>I have rebuilt several times, on two separate Linux boxes. I am as >>sure as I can get that I am using the latest PyXML cvs. >> > >That may be the problem: We were talking about the latest Python CVS... > >>I'm not sure what a CVS "backtrace" is? The output of cvs status? >> > >No: If it still crashes (after rebuilding *Python*), please run it in >gdb, let it crash, then invoke "bt". > >Regards, >Martin > > > >_______________________________________________ >XML-SIG maillist - XML-SIG@python.org >http://mail.python.org/mailman/listinfo/xml-sig > From Alexandre.Fayolle@logilab.fr Wed Apr 10 10:21:39 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Wed, 10 Apr 2002 11:21:39 +0200 Subject: [XML-SIG] Re: [4suite] What should go in Debian Woody? In-Reply-To: <1018383854.12933.731.camel@borgia.local> References: <20020409153217.GJ20067@orion.logilab.fr> <1018366629.12786.95.camel@borgia.local> <87vgb0pqxr.fsf@marant.org> <1018383854.12933.731.camel@borgia.local> Message-ID: <20020410092138.GD25413@orion.logilab.fr> On Tue, Apr 09, 2002 at 02:24:05PM -0600, Uche Ogbuji wrote: > Yes. 4RDF, in particular, is still usable. But would this not just > cause more confusion? 4ODS seems OK too. > What is the upgrade path for packages in stable? If Woody initially > goes out with back-dated 4Suite or none, can the sources later update > with stable versions of 4Suite 0.12.0? Or would these only appear in > testing from now (which I assume is what Sid will become)? 4suite is not in potato. PyXML-0.5.1 is. My understanding of the releases in Debian is that it is quite hard to get anything apart form security updates in Stable after it is released. And since lots of API have changed between 4Suite 0.11.1 and 0.12.0, I'd guess that 0.12.0 would have to go in testing at best. 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 fpierfed@eso.org Wed Apr 10 10:42:59 2002 From: fpierfed@eso.org (Francesco Pierfederici) Date: Wed, 10 Apr 2002 11:42:59 +0200 Subject: [XML-SIG] 4Suite build woes (on MacOSX) Message-ID: Hi, I've been trying to build 4Suite (0.11.1, 0.12.0a2 and today's CVS snapshot) on MacOSX without any luck. I'm using python2.3a0 from the CVS and PyXML 0.6.6. The errors I get are about multiple definitions of the following symbols g_errorLocation g_errorOccured g_errorTraceback g_errorType g_errorValue g_prodNum in OqlSwig.o and Oql_wrap.o. Any help would be really appreciated, as I'm hopelessly stuck :-| TIA fra From gherman@darwin.in-berlin.de Wed Apr 10 11:07:07 2002 From: gherman@darwin.in-berlin.de (Dinu Gherman) Date: Wed, 10 Apr 2002 12:07:07 +0200 (CEST) Subject: [XML-SIG] 4Suite build woes (on MacOSX) In-Reply-To: References: Message-ID: <1018433227.3cb40ecb524e2@webmail.in-berlin.de> Francesco Pierfederici : > I've been trying to build 4Suite (0.11.1, 0.12.0a2 and today's CVS > snapshot) > on MacOSX without any luck. > > I'm using python2.3a0 from the CVS and PyXML 0.6.6. > The errors I get are about multiple definitions of the following > symbols > > g_errorLocation > g_errorOccured > g_errorTraceback > g_errorType > g_errorValue > g_prodNum > > in OqlSwig.o and Oql_wrap.o. > > Any help would be really appreciated, as I'm hopelessly stuck :-| I'm running this, which I got compiled and which does most of what I want it to do (except XSLT, I think... The pyRXP stuff was mentioned recently on this list and is totally unrelated to pyXML and 4Suite): Runtime environment: OS name: posix, platform: darwin (Mac OS X 10.1.3 - 400 MHz) Python version: 2.2.0 final 0 PyXML version: 0.7 4Suite version: 0.11.1 RXP version: 1.2.3 I think this combination is not officially recommended, though... Well, there are correlations between pyXML and 4Suite that appear to me at least to be mysterious enough, so I've given up further investigations for now, but I think I know what you mean. Regards, Dinu From bill@rfa.org Wed Apr 10 13:28:34 2002 From: bill@rfa.org (Bill Eldridge) Date: Wed, 10 Apr 2002 14:28:34 +0200 Subject: [XML-SIG] Re: [4suite] What should go in Debian Woody? References: <20020409153217.GJ20067@orion.logilab.fr> <1018366629.12786.95.camel@borgia.local> <87vgb0pqxr.fsf@marant.org> <1018383854.12933.731.camel@borgia.local> <20020410092138.GD25413@orion.logilab.fr> Message-ID: <3CB42FF2.4020001@rfa.org> > > My understanding of the releases in Debian is that it is quite hard to > get anything apart form security updates in Stable after it is released. > And since lots of API have changed between 4Suite 0.11.1 and 0.12.0, I'd > guess that 0.12.0 would have to go in testing at best. The following is Debian's notes on Woody, that it is "close" to being frozen (close as in hand-grenades or ...?) and that the frozen period will last several months where only bug-fixes will be accepted. So my question is do the 4Suite and PyXML folks feel comfortable that the new API's and feature code can be provided by the time Woody is frozen, and that the ensuing months of freeze are sufficient to debug this code. I think this is significantly different from "are the new 4Suite and PyXML releases stable enough now for Woody?". http://www.debian.org/releases/testing/ -- -- Bill Eldridge Radio Free Asia bill@rfa.org From uche.ogbuji@fourthought.com Wed Apr 10 14:47:05 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: 10 Apr 2002 07:47:05 -0600 Subject: [XML-SIG] Re: [4suite] What should go in Debian Woody? In-Reply-To: <3CB42FF2.4020001@rfa.org> References: <20020409153217.GJ20067@orion.logilab.fr> <1018366629.12786.95.camel@borgia.local> <87vgb0pqxr.fsf@marant.org> <1018383854.12933.731.camel@borgia.local> <20020410092138.GD25413@orion.logilab.fr> <3CB42FF2.4020001@rfa.org> Message-ID: <1018446427.12933.3008.camel@borgia.local> On Wed, 2002-04-10 at 06:28, Bill Eldridge wrote: > > > > My understanding of the releases in Debian is that it is quite hard to > > get anything apart form security updates in Stable after it is released. > > And since lots of API have changed between 4Suite 0.11.1 and 0.12.0, I'd > > guess that 0.12.0 would have to go in testing at best. > > The following is Debian's notes on Woody, that > it is "close" to being frozen (close as in hand-grenades > or ...?) and that the frozen period will last several > months where only bug-fixes will be accepted. > > So my question is do the 4Suite and PyXML folks > feel comfortable that the new API's and feature > code can be provided by the time Woody is frozen, > and that the ensuing months of freeze are sufficient > to debug this code. I think > this is significantly different from "are the > new 4Suite and PyXML releases stable enough > now for Woody?". > > http://www.debian.org/releases/testing/ What say you, Debian old heads? If Bill is right, then I would push to continue to include 4Suite in Woody. We are on the verge of beta for 0.12.0, and with a bit more testing and docs, I'm at least as confident in 0.12.0 as I am with 0.11.1 for stability. -- Uche Ogbuji Principal Consultant Fourthought, Inc. uche.ogbuji@fourthought.com http://Fourthought.com +1 720 320 2046 XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Latest article: Managing structured Web service metadata - http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/ Latest article: WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 Next presentation: XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From info@lacaixa.es Wed Apr 10 19:33:41 2002 From: info@lacaixa.es (Servicio Atencion al Cliente) Date: Wed, 10 Apr 2002 20:33:41 +0200 Subject: [XML-SIG] Acuse de Recibo Message-ID: <43ADAD2D71C0D411984F00D0B79D809BCC2FCF@c3app02.lacaixa.es> Apreciado Sr./Sra. Gracias por contactar con nuestro servicio de Buz=F3n de Correo = electr=F3nico "la Caixa". Le informamos que hemos recibido su mensaje y procedemos a tramitarlo a partir de este momento. En breve recibir=E1 una respuesta por correo electr=F3nico donde se le = informar=E1 un n=FAmero de referencia con el que podr=E1 solicitarnos cualquier = informaci=F3n referente a su solicitud. Reciba un cordial saludo, info@lacaixa.es From fdrake@acm.org Thu Apr 11 17:25:41 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Apr 2002 12:25:41 -0400 Subject: [XML-SIG] PyXML 0.7 & 4XSLT Message-ID: <15541.47365.417179.567939@grendel.zope.com> I've trawled through the list archives looking for an answer, and it looks like the answer is "There is no version of 4Suite that works with PyXML 0.7." Is this right? Does the xml.xslt package stand a chance? Just how complicated has the installation dance become? --sigh-- -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Thu Apr 11 17:42:46 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 11 Apr 2002 18:42:46 +0200 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <15541.47365.417179.567939@grendel.zope.com> References: <15541.47365.417179.567939@grendel.zope.com> Message-ID: "Fred L. Drake, Jr." writes: > I've trawled through the list archives looking for an answer, and it > looks like the answer is "There is no version of 4Suite that works > with PyXML 0.7." > > Is this right? Mostly. The precise wording should be "no released version of 4Suite". The 0.12alpha versions reportedly work fine. > Does the xml.xslt package stand a chance? Sorry, I don't understand the phrase "stand a chance". Regards, Martin From pyxml@xhaus.com Thu Apr 11 13:35:48 2002 From: pyxml@xhaus.com (Alan Kennedy) Date: Thu, 11 Apr 2002 12:35:48 EST5EDT Subject: [XML-SIG] XMLFilterbase. Message-ID: <200204111647.MAA213068@spool1.valueweb.net> Greetings All, I had the occasion to use a SAX filter today, and thought I'd inherit from the saxutil.XMLFilterBase class, since I only needed to override a single method. The saxlib.XMLFilter "interface" defines an __init__ method that takes a parent parser, as it should do. So basically the wrapped parser now becomes a "filtering parser", as far as the user of the parser is concerned, in that methods that control the parser should now be given to the filter, which then passes them onto the wrapped parser. However, the XMLFilterBase class, which I would expect to inherit from XMLFilter, instead inherits from XMLReader. And, of course, the __init__ method from XMLReader doesn't take a parent parser as a parameter. So when I subclass XMLFilterBase, override 1 method (startElement in this case), instantiate my subclass, passing a freshly created XMLReader as the parameter to the __init__, the instantiation fails because the XMLReader.__init__ method doesn't expect parameters. Or maybe I'm just misunderstanding SAX2 filters? As an aside, I'm not happy with SAX2 filters, in that they wrap the parser (XMLReader) rather than the handler (ContentHandler). It seems more natural to me to wrap the handler, and that's exactly what I've done in several (java) applications I've written, thus discarding the provided SAX2 filter mechanisms and writing my own. But that's not the only problems I have with the design of SAX2 filters. Anyway, if people think that the current superclass of XMLFilterBase is a bug, I'll report it/submit a patch over @ SourceForge. Regards, Alan Kennedy. --------------------------------------------- This message was sent using WebMail by CyberGate. http://www.gate.net/webmail From fdrake@acm.org Thu Apr 11 18:48:20 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Apr 2002 13:48:20 -0400 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: References: <15541.47365.417179.567939@grendel.zope.com> Message-ID: <15541.52324.820933.827063@grendel.zope.com> Martin v. Loewis writes: > Mostly. The precise wording should be "no released version of > 4Suite". The 0.12alpha versions reportedly work fine. If I use Python 2.2.1, PyXML 0.7, and 4Suite 0.12a2, with this script: ------------------------------------------------------------------------ #! /usr/bin/env python2.2 import sys from xml import xslt from xml.xslt import minisupport from xml.xslt import XsltException from xml.xslt.Processor import Processor ### breaks here p = Processor() reader = minisupport.MinidomReader(0) p.setDocumentReader(reader) p.appendStylesheetUri(sys.argv[1]) ------------------------------------------------------------------------ I get the following traceback: ------------------------------------------------------------------------ grendel(~/tmp); python2.2 tmp.py file:///home/fdrake/projects/python/trunk/Doc/tools/sgmlconv/xslt/module.xsl Traceback (most recent call last): File "tmp.py", line 7, in ? from xml.xslt.Processor 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 66, in ? XML_PARSE_ERROR = Ft.Lib.XML_PARSE_ERROR AttributeError: 'module' object has no attribute 'XML_PARSE_ERROR' ------------------------------------------------------------------------ > Sorry, I don't understand the phrase "stand a chance". Sorry for being obscure. What I mean is that I'm skeptical that the current situation will be maintainable for any length of time. With 4Suite and PyXML having the current strange relationship they have, it's really painful trying to keep up with which versions work together and which don't. The xml.xslt package seems to end up very unstable. My understanding is that 4Thought intends to move 4XSLT entirely into PyXML, where it will be maintained, but in the meanwhile, we don't really seem to have a good XSLT strategy. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From veillard@redhat.com Thu Apr 11 18:58:57 2002 From: veillard@redhat.com (Daniel Veillard) Date: Thu, 11 Apr 2002 13:58:57 -0400 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <15541.52324.820933.827063@grendel.zope.com>; from fdrake@acm.org on Thu, Apr 11, 2002 at 01:48:20PM -0400 References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> Message-ID: <20020411135857.H11960@redhat.com> On Thu, Apr 11, 2002 at 01:48:20PM -0400, Fred L. Drake, Jr. wrote: > PyXML, where it will be maintained, but in the meanwhile, we don't > really seem to have a good XSLT strategy. Have you thought about integrating libxslt + its existing wrappers ? Speed wise and conformance wise, I think your user base would be happy. 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 fdrake@acm.org Thu Apr 11 19:12:02 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Apr 2002 14:12:02 -0400 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <20020411135857.H11960@redhat.com> References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> <20020411135857.H11960@redhat.com> Message-ID: <15541.53746.541390.768478@grendel.zope.com> Daniel Veillard writes: > Have you thought about integrating libxslt + its existing wrappers ? > Speed wise and conformance wise, I think your user base would be happy. I don't have any general objections, I just don't have a lot of time to look into it right now. I have a question from a colleague about what to use, and I need to get an answer for him. I'll take a look at the libxslt package next; I've certainly used xsltproc from the command line and been happy with it. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Thu Apr 11 20:27:41 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 11 Apr 2002 21:27:41 +0200 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <20020411135857.H11960@redhat.com> References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> <20020411135857.H11960@redhat.com> Message-ID: Daniel Veillard writes: > On Thu, Apr 11, 2002 at 01:48:20PM -0400, Fred L. Drake, Jr. wrote: > > PyXML, where it will be maintained, but in the meanwhile, we don't > > really seem to have a good XSLT strategy. > > Have you thought about integrating libxslt + its existing wrappers ? > Speed wise and conformance wise, I think your user base would be happy. I don't think I can find the time to do that in foreseeable future. Contributions are welcome. I'm not sure I'd like to incorporate libxslt as a whole, though - unless it gets flawless distutils support. Regards, Martin From martin@v.loewis.de Thu Apr 11 20:26:15 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 11 Apr 2002 21:26:15 +0200 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <15541.52324.820933.827063@grendel.zope.com> References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> Message-ID: "Fred L. Drake, Jr." writes: > Martin v. Loewis writes: > > Mostly. The precise wording should be "no released version of > > 4Suite". The 0.12alpha versions reportedly work fine. > > If I use Python 2.2.1, PyXML 0.7, and 4Suite 0.12a2, with this script: > ------------------------------------------------------------------------ > #! /usr/bin/env python2.2 > > import sys > from xml import xslt > from xml.xslt import minisupport No surprise it won't work: This is PyXML's xml.xslt _as-is_; 4XSLT is now in Ft.xslt (or some such). > > Sorry, I don't understand the phrase "stand a chance". > > Sorry for being obscure. What I mean is that I'm skeptical that the > current situation will be maintainable for any length of time. With > 4Suite and PyXML having the current strange relationship they have, > it's really painful trying to keep up with which versions work > together and which don't. The xml.xslt package seems to end up very > unstable. It is not unstable it all. It just doesn't work. > My understanding is that 4Thought intends to move 4XSLT entirely into > PyXML, where it will be maintained, but in the meanwhile, we don't > really seem to have a good XSLT strategy. Correct. I initially had considered to leave it out from PyXML 0.7, but included it on user request. Use at your own risk. Regards, Martin From fdrake@acm.org Thu Apr 11 20:53:16 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Apr 2002 15:53:16 -0400 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> Message-ID: <15541.59820.704957.439738@grendel.zope.com> Martin v. Loewis writes: > No surprise it won't work: This is PyXML's xml.xslt _as-is_; 4XSLT is > now in Ft.xslt (or some such). That doesn't help, I suppose! ;-) It looks like its in Ft.Xml.Xslt, but I don't see all the same modules there (minisupport in particular). > Correct. I initially had considered to leave it out from PyXML 0.7, > but included it on user request. Use at your own risk. That sounds vaguely familiar now. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From martin@v.loewis.de Thu Apr 11 22:55:10 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 11 Apr 2002 23:55:10 +0200 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <15541.59820.704957.439738@grendel.zope.com> References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> <15541.59820.704957.439738@grendel.zope.com> Message-ID: "Fred L. Drake, Jr." writes: > Martin v. Loewis writes: > > No surprise it won't work: This is PyXML's xml.xslt _as-is_; 4XSLT is > > now in Ft.xslt (or some such). > > That doesn't help, I suppose! ;-) It looks like its in Ft.Xml.Xslt, > but I don't see all the same modules there (minisupport in > particular). Indeed, minisupport is my attempt to integrate 4XSLT with minidom. It is still incomplete and needs major work. I have delayed this work until somebody (probably me) integrates the current 4XSLT code into PyXML - until then, I can only offer to withdraw the code, or recommend to just not use it. Regards, Martin From uche.ogbuji@fourthought.com Fri Apr 12 06:26:42 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 11 Apr 2002 23:26:42 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: Message from Daniel Veillard of "Thu, 11 Apr 2002 13:58:57 EDT." <20020411135857.H11960@redhat.com> Message-ID: <200204120526.g3C5QgF26404@localhost.localdomain> > On Thu, Apr 11, 2002 at 01:48:20PM -0400, Fred L. Drake, Jr. wrote: > > PyXML, where it will be maintained, but in the meanwhile, we don't > > really seem to have a good XSLT strategy. > > Have you thought about integrating libxslt + its existing wrappers ? > Speed wise and conformance wise, I think your user base would be happy. Ah, good. You have particular performance bugs to report in 4Suite, then, right? So what are they? -- Uche Ogbuji Principal Consultant Fourthought, Inc. uche.ogbuji@fourthought.com http://Fourthought.com +1 720 320 2046 XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Managing structured Web service metadata - http://www-106.ibm.com/developerwork s/webservices/library/ws-wsdlrdf/ WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From uche.ogbuji@fourthought.com Fri Apr 12 06:30:32 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 11 Apr 2002 23:30:32 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: Message from "Fred L. Drake, Jr." of "Thu, 11 Apr 2002 15:53:16 EDT." <15541.59820.704957.439738@grendel.zope.com> Message-ID: <200204120530.g3C5UWI26421@localhost.localdomain> > > Martin v. Loewis writes: > > No surprise it won't work: This is PyXML's xml.xslt _as-is_; 4XSLT is > > now in Ft.xslt (or some such). > > That doesn't help, I suppose! ;-) It looks like its in Ft.Xml.Xslt, > but I don't see all the same modules there (minisupport in > particular). What's minisupport? If you mean minidom, this is there: in fact, minidom is the default DOM that's used for XSLT processing until the next release, when it becomes cDomlette (though we hope to get Alexandre's obscure bug first). -- Uche Ogbuji Principal Consultant Fourthought, Inc. uche.ogbuji@fourthought.com http://Fourthought.com +1 720 320 2046 XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Managing structured Web service metadata - http://www-106.ibm.com/developerwork s/webservices/library/ws-wsdlrdf/ WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From tpassin@comcast.net Fri Apr 12 00:58:18 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Thu, 11 Apr 2002 19:58:18 -0400 Subject: [XML-SIG] PyXML 0.7 & 4XSLT References: <15541.47365.417179.567939@grendel.zope.com> Message-ID: <001401c1e1b4$c0f948d0$0bf13044@tbp> [Fred L. Drake, Jr.] > > I've trawled through the list archives looking for an answer, and it > looks like the answer is "There is no version of 4Suite that works > with PyXML 0.7." > > Is this right? Does the xml.xslt package stand a chance? Just how > complicated has the installation dance become? > > --sigh-- > Whoa, hold on, everyone! I am running pyxml 0.7 with 4Suite 0.11.1 and I can run transformations with 4xslt. I just tried it out to verify my memory. I am using Python 1.5.2 on Windows, but I seem to recall that I got it working with 2.1 also. I remember one or two bugs in xpath and somewhere else that I had to fix - I posted about them months ago. I can't remember if nothing worked until I fixed them or just one particular thing. Probably the latter. The deal is to install pyxml 0.7 first, then delete any ft, xpath, and xslt directories and install 4suite. I can't say about any CVS versions. I'm talking about the distribution I got from SourceForge quite some time ago. Cheers, Tom P From Mike.Olson@fourthought.com Fri Apr 12 06:50:25 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 11 Apr 2002 23:50:25 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> <15541.59820.704957.439738@grendel.zope.com> Message-ID: <1018590631.3180.20.camel@penny> On Thu, 2002-04-11 at 15:55, Martin v. Loewis wrote: > "Fred L. Drake, Jr." writes: > > > Martin v. Loewis writes: > > > No surprise it won't work: This is PyXML's xml.xslt _as-is_; 4XSLT is > > > now in Ft.xslt (or some such). > > > > That doesn't help, I suppose! ;-) It looks like its in Ft.Xml.Xslt, > > but I don't see all the same modules there (minisupport in > > particular). > > Indeed, minisupport is my attempt to integrate 4XSLT with minidom. It > is still incomplete and needs major work. I have delayed this work > until somebody (probably me) integrates the current 4XSLT code into > PyXML - until then, I can only offer to withdraw the code, or > recommend to just not use it. Just to note, 0.12.0 4XSLT supports minidom Mike > > Regards, > Martin > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From Mike.Olson@fourthought.com Fri Apr 12 05:23:49 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 11 Apr 2002 22:23:49 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <15541.47365.417179.567939@grendel.zope.com> References: <15541.47365.417179.567939@grendel.zope.com> Message-ID: <1018585435.3143.0.camel@penny> On Thu, 2002-04-11 at 10:25, Fred L. Drake, Jr. wrote: > > I've trawled through the list archives looking for an answer, and it > looks like the answer is "There is no version of 4Suite that works > with PyXML 0.7." 0.12.0 workd with PyXML 0.7. Also, with 0.12.0, PyXML is not required. > > Is this right? Does the xml.xslt package stand a chance? Just how > complicated has the installation dance become? With 0.12.0, the xml.xslt package is no longer there (unless you install it through PyXML). In 4Suite, it is now in Ft.Xml.Xslt.* Mike > > --sigh-- > > > -Fred > > -- > Fred L. Drake, Jr. > PythonLabs at Zope Corporation > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From Mike.Olson@fourthought.com Fri Apr 12 05:36:17 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 11 Apr 2002 22:36:17 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <15541.52324.820933.827063@grendel.zope.com> References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> Message-ID: <1018586184.3180.10.camel@penny> On Thu, 2002-04-11 at 11:48, Fred L. Drake, Jr. wrote: > > Martin v. Loewis writes: > > Mostly. The precise wording should be "no released version of > > 4Suite". The 0.12alpha versions reportedly work fine. As of 0.12.0 we moved the Xslt processor to Ft.Xml.Xslt to avoid conflicts with PyXML. Mike > > If I use Python 2.2.1, PyXML 0.7, and 4Suite 0.12a2, with this script: > ------------------------------------------------------------------------ > #! /usr/bin/env python2.2 > > import sys > from xml import xslt > from xml.xslt import minisupport > from xml.xslt import XsltException > from xml.xslt.Processor import Processor ### breaks here > > p = Processor() > reader = minisupport.MinidomReader(0) > p.setDocumentReader(reader) > p.appendStylesheetUri(sys.argv[1]) > ------------------------------------------------------------------------ > > I get the following traceback: > > ------------------------------------------------------------------------ > grendel(~/tmp); python2.2 tmp.py file:///home/fdrake/projects/python/trunk/Doc/tools/sgmlconv/xslt/module.xsl > Traceback (most recent call last): > File "tmp.py", line 7, in ? > from xml.xslt.Processor 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 66, in ? > XML_PARSE_ERROR = Ft.Lib.XML_PARSE_ERROR > AttributeError: 'module' object has no attribute 'XML_PARSE_ERROR' > ------------------------------------------------------------------------ > > > Sorry, I don't understand the phrase "stand a chance". > > Sorry for being obscure. What I mean is that I'm skeptical that the > current situation will be maintainable for any length of time. With > 4Suite and PyXML having the current strange relationship they have, > it's really painful trying to keep up with which versions work > together and which don't. The xml.xslt package seems to end up very > unstable. > > My understanding is that 4Thought intends to move 4XSLT entirely into > PyXML, where it will be maintained, but in the meanwhile, we don't > really seem to have a good XSLT strategy. > > > -Fred > > -- > Fred L. Drake, Jr. > PythonLabs at Zope Corporation > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From Mike.Olson@fourthought.com Fri Apr 12 05:41:19 2002 From: Mike.Olson@fourthought.com (Mike Olson) Date: 11 Apr 2002 22:41:19 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <15541.59820.704957.439738@grendel.zope.com> References: <15541.47365.417179.567939@grendel.zope.com> <15541.52324.820933.827063@grendel.zope.com> <15541.59820.704957.439738@grendel.zope.com> Message-ID: <1018586485.3143.14.camel@penny> On Thu, 2002-04-11 at 13:53, Fred L. Drake, Jr. wrote: > > Martin v. Loewis writes: > > No surprise it won't work: This is PyXML's xml.xslt _as-is_; 4XSLT is > > now in Ft.xslt (or some such). > > That doesn't help, I suppose! ;-) It looks like its in Ft.Xml.Xslt, > but I don't see all the same modules there (minisupport in > particular). What is minisupport? Mike > > > Correct. I initially had considered to leave it out from PyXML 0.7, > > but included it on user request. Use at your own risk. > > That sounds vaguely familiar now. > > > -Fred > > -- > Fred L. Drake, Jr. > PythonLabs at Zope Corporation > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://mail.python.org/mailman/listinfo/xml-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com +1 303 583 9900 x 102 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, http://4Suite.org Boulder, CO 80301-2537, USA XML strategy, XML tools, knowledge management From martin@v.loewis.de Fri Apr 12 08:13:17 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 12 Apr 2002 09:13:17 +0200 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <200204120530.g3C5UWI26421@localhost.localdomain> References: <200204120530.g3C5UWI26421@localhost.localdomain> Message-ID: Uche Ogbuji writes: > > That doesn't help, I suppose! ;-) It looks like its in Ft.Xml.Xslt, > > but I don't see all the same modules there (minisupport in > > particular). > > What's minisupport? xml.xslt.minisupport is a module I wrote to integrate 4XSLT 0.10+ with minidom. It is probably obsolete with 4XSLT 0.12. Regards, Martin From martin@v.loewis.de Fri Apr 12 08:23:35 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 12 Apr 2002 09:23:35 +0200 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <200204120526.g3C5QgF26404@localhost.localdomain> References: <200204120526.g3C5QgF26404@localhost.localdomain> Message-ID: Uche Ogbuji writes: > > Have you thought about integrating libxslt + its existing wrappers ? > > Speed wise and conformance wise, I think your user base would be happy. > > Ah, good. You have particular performance bugs to report in 4Suite, then, > right? > > So what are they? I don't think he has (and he didn't claim there are any). In the Python+XML world, it is common that everybody develops his own stuff, and uses and advertises this as a solution to a certain set of problems. Authors of such packages often do not know their competition, let alone comparing their own packages to those of the competition. I'm not even sure there is something wrong with this, as long as users still have a choice. In the specific case, Daniel suggested that libxslt will offer good speed and conformance, and I believe him (without ever having installed the libxslt wrappers). He did not comment at all on the speed and conformance of 4XSLT. I guess he could not have, because he never used it. This is all complicated matter, and it is tricky enough to get on terms with a single toolkit - expecting that many people become experts with different toolkits is probably not realistic. I hope that xml-sig continues to be the place where people can advertise their own software, and where users can get recommendations on various options. For PyXML, I hope that the package continues to receive contributions from various people. Regards, Martin From veillard@redhat.com Fri Apr 12 10:04:07 2002 From: veillard@redhat.com (Daniel Veillard) Date: Fri, 12 Apr 2002 05:04:07 -0400 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: <200204120526.g3C5QgF26404@localhost.localdomain>; from uche.ogbuji@fourthought.com on Thu, Apr 11, 2002 at 11:26:42PM -0600 References: <200204120526.g3C5QgF26404@localhost.localdomain> Message-ID: <20020412050407.N11960@redhat.com> On Thu, Apr 11, 2002 at 11:26:42PM -0600, Uche Ogbuji wrote: > > On Thu, Apr 11, 2002 at 01:48:20PM -0400, Fred L. Drake, Jr. wrote: > > > PyXML, where it will be maintained, but in the meanwhile, we don't > > > really seem to have a good XSLT strategy. > > > > Have you thought about integrating libxslt + its existing wrappers ? > > Speed wise and conformance wise, I think your user base would be happy. > > Ah, good. You have particular performance bugs to report in 4Suite, then, > right? No. Look carefully at my mail I did not specifically say anything about 4XSLT and removed any related context in my reply. The performance race I have run in the last year is with MSXML4 which until recently was considered the faster general purpose XSLT implementation. The goal is to provide free software tools with at least similar performances as those available from our beloved monopolist, yours, 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 noreply@sourceforge.net Fri Apr 12 13:51:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Apr 2002 05:51:23 -0700 Subject: [XML-SIG] [ pyxml-Bugs-542969 ] XMLFilterBase has wrong superclass. Message-ID: Bugs item #542969, was opened at 2002-04-12 05:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=542969&group_id=6473 Category: SAX Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: XMLFilterBase has wrong superclass. Initial Comment: Hi, The XMLFilterBase class in the saxutils module has the wrong superclass. It should subclass XMLFilter, but instead subclasses XMLReader. This means that it's constructor takes the wrong number of arguments. It's constructor should take a parameter of the parser which it wraps and filters the events of. But trying to pass a parameter to the constructor as it is now causes an exception. Changing the superclass from "XMLReader" to "XMLFilter" seems to fix the problem. Cheers, Alan Kennedy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=542969&group_id=6473 From uche.ogbuji@fourthought.com Fri Apr 12 13:37:59 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 12 Apr 2002 06:37:59 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: Message from "Thomas B. Passin" of "Thu, 11 Apr 2002 19:58:18 EDT." <001401c1e1b4$c0f948d0$0bf13044@tbp> Message-ID: <200204121238.g3CCbxc27864@localhost.localdomain> > [Fred L. Drake, Jr.] > > > > > I've trawled through the list archives looking for an answer, and it > > looks like the answer is "There is no version of 4Suite that works > > with PyXML 0.7." > > > > Is this right? Does the xml.xslt package stand a chance? Just how > > complicated has the installation dance become? > > > > --sigh-- > > > > Whoa, hold on, everyone! I am running pyxml 0.7 with 4Suite 0.11.1 and I > can run transformations with 4xslt. I just tried it out to verify my > memory. I am using Python 1.5.2 on Windows, but I seem to recall that I got > it working with 2.1 also. > > I remember one or two bugs in xpath and somewhere else that I had to fix - I > posted about them months ago. I can't remember if nothing worked until I > fixed them or just one particular thing. Probably the latter. The deal is > to install pyxml 0.7 first, then delete any ft, xpath, and xslt directories > and install 4suite. > > I can't say about any CVS versions. I'm talking about the distribution I > got from SourceForge quite some time ago. Or just use python setup.py --without-xslt --without-xpath install I suppose the job of integrating XPath/XSLT just got easier, since fiddling to remove pDomlette is no longer necessary. But it's stil a job. -- Uche Ogbuji Principal Consultant Fourthought, Inc. uche.ogbuji@fourthought.com http://Fourthought.com +1 720 320 2046 XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Managing structured Web service metadata - http://www-106.ibm.com/developerwork s/webservices/library/ws-wsdlrdf/ WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From uche.ogbuji@fourthought.com Fri Apr 12 13:44:24 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 12 Apr 2002 06:44:24 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: Message from martin@v.loewis.de (Martin v. Loewis) of "12 Apr 2002 09:23:35 +0200." Message-ID: <200204121244.g3CCiOY27881@localhost.localdomain> > Uche Ogbuji writes: > In the specific case, Daniel suggested that libxslt will offer good > speed and conformance, and I believe him (without ever having > installed the libxslt wrappers). He did not comment at all on the > speed and conformance of 4XSLT. I guess he could not have, because he > never used it. Sure, and libxslt, being written in C++, with a Python wrapper, is always likely to win on performance, without any extraordinary tricks in play. As I mentioned, my comment was meant to discuss conformance. I know of one conformance bug right now: a pretty obscure corner of namespace nodes which I should really just stop now and fix. There might be others, but I'd like to know what they are. I think conformance is pretty much granted, these days, in XSLT processors, so I wouldn't expect to pick one over the other for conformance reasons. -- Uche Ogbuji Principal Consultant Fourthought, Inc. uche.ogbuji@fourthought.com http://Fourthought.com +1 720 320 2046 XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Managing structured Web service metadata - http://www-106.ibm.com/developerwork s/webservices/library/ws-wsdlrdf/ WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From uche.ogbuji@fourthought.com Fri Apr 12 13:47:13 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 12 Apr 2002 06:47:13 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: Message from Daniel Veillard of "Fri, 12 Apr 2002 05:04:07 EDT." <20020412050407.N11960@redhat.com> Message-ID: <200204121247.g3CClDi27894@localhost.localdomain> > The performance race I have run in the last year is with MSXML4 which > until recently was considered the faster general purpose XSLT implementation. > The goal is to provide free software tools with at least similar performances > as those available from our beloved monopolist, And I'm sure you succeeded. And you've implemented EXSLT, so you get bonus points (now we just have to coax Xalan along...). -- Uche Ogbuji Principal Consultant Fourthought, Inc. uche.ogbuji@fourthought.com http://Fourthought.com +1 720 320 2046 XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Managing structured Web service metadata - http://www-106.ibm.com/developerwork s/webservices/library/ws-wsdlrdf/ WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From uche.ogbuji@fourthought.com Fri Apr 12 13:28:01 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Fri, 12 Apr 2002 06:28:01 -0600 Subject: [XML-SIG] PyXML 0.7 & 4XSLT In-Reply-To: Message from Uche Ogbuji of "Thu, 11 Apr 2002 23:26:42 MDT." <200204120526.g3C5QgF26404@localhost.localdomain> Message-ID: <200204121228.g3CCS2I27765@localhost.localdomain> > > On Thu, Apr 11, 2002 at 01:48:20PM -0400, Fred L. Drake, Jr. wrote: > > > PyXML, where it will be maintained, but in the meanwhile, we don't > > > really seem to have a good XSLT strategy. > > > > Have you thought about integrating libxslt + its existing wrappers ? > > Speed wise and conformance wise, I think your user base would be happy. > > Ah, good. You have particular performance bugs to report in 4Suite, then, > right? I'm sure I'll pay for this typo/freudian slip/whatever. Of course I meant "conformance". I know that 4XSLT's performance will remain on the slower side until we re-write it in the architecture we prototyped. Although it does fluctuate a great deal, and it's not always easy to see why. -- Uche Ogbuji Principal Consultant Fourthought, Inc. uche.ogbuji@fourthought.com http://Fourthought.com +1 720 320 2046 XML strategy, XML tools (http://4Suite.org), knowledge management Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/ Managing structured Web service metadata - http://www-106.ibm.com/developerwork s/webservices/library/ws-wsdlrdf/ WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004 XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel From tpassin@comcast.net Fri Apr 12 14:23:44 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Fri, 12 Apr 2002 09:23:44 -0400 Subject: [XML-SIG] PyXML 0.7 & 4XSLT References: <200204121238.g3CCbxc27864@localhost.localdomain> Message-ID: <003401c1e225$4525ff70$0bf13044@tbp> [Uche Ogbuji] [Tom P] > > I can't say about any CVS versions. I'm talking about the distribution I > > got from SourceForge quite some time ago. > > Or just use > > python setup.py --without-xslt --without-xpath install > Not with the Windows installer :-) you get no options. Cheers, Tom P From noreply@sourceforge.net Fri Apr 12 19:32:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Apr 2002 11:32:11 -0700 Subject: [XML-SIG] [ pyxml-Bugs-543138 ] locator in xmlproc utils.py ErrorPrinter Message-ID: Bugs item #543138, was opened at 2002-04-12 14:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=543138&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Roy (rjroy) Assigned to: Nobody/Anonymous (nobody) Summary: locator in xmlproc utils.py ErrorPrinter Initial Comment: In xmlproc utils.py ver 1.4 The method __get_location of class ErrorPrinter will raise an exception if called. AttributeError: ErrorPrinter instance has no attribute 'locator' I browsed the CVS tree and found that the attribute locator existed until version 1.3. All instantiations of ErrorPrinter in xmlproc pass the parser object as a locator. Here is a context diff with a proposed fix. ####################### *** utils.py Fri Apr 12 14:14:40 2002 --- utils.py.bak Fri Apr 12 14:06:52 2002 *************** *** 23,29 **** """An error handler that prints out warning messages.""" def __init__(self, locator, level = 0, out = sys.stderr): ! xmlapp.ErrorHandler.__init__(self, locator) self.level = level self.out = out --- 23,29 ---- """An error handler that prints out warning messages.""" def __init__(self, locator, level = 0, out = sys.stderr): ! self.locator = locator self.level = level self.out = out ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=543138&group_id=6473 From larsga@garshol.priv.no Sat Apr 13 20:19:42 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 13 Apr 2002 21:19:42 +0200 Subject: [XML-SIG] Spanish translation of xmlproc error messages added Message-ID: Ricardo Javier Cardenes sent me a translation of the xmlproc error messages to Spanish, and I've just checked it into CVS. This means that xmlproc now has error messages in English, Norwegian, Swedish, French, and Spanish. As far as I know it is the only XML parser to have error messages in more than one language. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From jerome.marant@free.fr Sun Apr 14 21:11:15 2002 From: jerome.marant@free.fr (=?iso-8859-1?q?J=E9r=F4me?= Marant) Date: Sun, 14 Apr 2002 22:11:15 +0200 Subject: [XML-SIG] Solution for the Debian 4suite/PyXML problem Message-ID: <87heme82ho.fsf@marant.org> Hi, I've implemented a solution for the current problem with 4Suite 0.11 and PyXML 0.7. It seems to me the most elegant way to work around the problem: - python-xml 0.6.6 is coming back in Debian and shipped as python-xml-0.6 (xbel-utils-0.6 is also provided for those willing to use xbel-utils and having 4suite on their system; the xbel package does not depend on anything python-related so the one from 0.7 is fine). It conflicts with python-xml. - python-4suite now depends on python-xml-0.6 - 4xslt and 4xpath are now back in python-xml 0.7 since the conflicts between python-xml-0.6 and python-xml make it impossible to have both python-4suite and python-xml installed at the same time. All packages are ready for upload. However, python-xml-0.6 will have to enter the archives before I upload the remaining packages, in order to ensure that dependencies are met. You can test them right now: http://people.debian.org/~jerome woody/ in /etc/apt/sources.list (I tested myself that APT resolves dependencies correctly). Alexandre (or anyone else), could you please have a look at http://bugs.debian.org/141549. I have already applied patches for #140148 and #133548. Post-woody plans. ----------------- Once Woody is released as well as 4suite 0.12, we'll be able to remove python-xml-0.6. I'll probably upload python-4suite 0.12 and then it will be the right time for me to give all my Python packages to Alexandre Fayolle since he's the right guy for this job and I don't want to take care of Python packages anymore. I will help him on packaging and will sponsor him though. Regards, -- Jérôme Marant http://marant.org From jyrinx@mindspring.com Mon Apr 15 03:41:44 2002 From: jyrinx@mindspring.com (Luke Maurer) Date: 14 Apr 2002 19:41:44 -0700 Subject: [XML-SIG] Failure when profiling XML processing Message-ID: <1018838504.13088.5.camel@kryptonitespoon.maurers> I'm trying to profile some code that parses an XML file. (I've never used a profiler or done optimizations (this is my first big project) before.) Here's what happens: --- snip --- >>> profile.run("import testCardSet; testCardSet.printAll()") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/profile.py", line 71, in run prof = prof.run(statement) File "/usr/lib/python2.2/profile.py", line 404, in run return self.runctx(cmd, dict, dict) File "/usr/lib/python2.2/profile.py", line 410, in runctx exec cmd in globals, locals File "", line 1, in ? File "testCardSet.py", line 7, in ? set = cardSet.LocalCardSet(filename) File "cardSet.py", line 26, in __init__ self.loadFromFile(filename) File "cardSet.py", line 39, in loadFromFile loadCardSet.loadCardSet(self, filename) File "loadCardSet.py", line 241, in loadCardSet doc = xml.dom.minidom.parse(nrcsFile) File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/xml/dom/minidom.py", line 962, in parse File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/xml/dom/minidom.py", line 954, in _doparse File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/xml/dom/pulldom.py", line 255, in getEvent File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/xml/sax/expatreader.py", line 143, in feed File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/xml/sax/expatreader.py", line 222, in start_element_ns File "/usr/lib/python2.2/profile.py", line 214, in trace_dispatch_i if self.dispatch[event](self, frame,t): File "/usr/lib/python2.2/profile.py", line 260, in trace_dispatch_call assert rframe.f_back is frame.f_back, ("Bad call", rfn, AssertionError: ('Bad call', ('/var/tmp/python2-2.2.1-root/usr/lib/python2.2/xml/sax/expatreader.py', 132, 'feed'), , , , ) --- snip --- (I know that wrapped funny; hope it's understandable) I don't really know, but this looks like a bug to me. The code runs fine outside of the profiler. I'll submit a bug report to SourceForge if it is indeed a bug in the XML tools. Jyrinx jyrinx_list@mindspring.com From Alexandre.Fayolle@logilab.fr Mon Apr 15 08:20:00 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Mon, 15 Apr 2002 09:20:00 +0200 Subject: [XML-SIG] Re: Solution for the Debian 4suite/PyXML problem In-Reply-To: <87heme82ho.fsf@marant.org> References: <87heme82ho.fsf@marant.org> Message-ID: <20020415072000.GD19620@orion.logilab.fr> On Sun, Apr 14, 2002 at 10:11:15PM +0200, Jérôme Marant wrote: > > Hi, > > I've implemented a solution for the current problem with > 4Suite 0.11 and PyXML 0.7. It seems to me the most elegant > way to work around the problem: Sounds fine. > Alexandre (or anyone else), could you please have a look > at http://bugs.debian.org/141549. I'll do that and send you a patch. It looks like a "characters() callback gets called more than once" bug. 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 webmaster@python.org Sun Apr 14 10:58:58 2002 From: webmaster@python.org (webmaster) Date: Sun, 14 Apr 2002 05:58:58 -0400 Subject: [XML-SIG] webmaster , Your first targeted e-mailing is FREE Message-ID: =3Chtml=3E =3Chead=3E =3Ctitle=3ETarget E-mailing & Creative Services=3C=2Ftitle=3E =3Cmeta name=3D=22title=22 content=3D=22Target E-mailing & Creative Services=22=3E =3Cmeta name=3D=22description=22 content=3D=22Our custom marketing databases=2C state-of-the-art merge=2Fpurge data hygiene products=2C marketing automation and customer-centric solutions help companies market more effectively to their prospects and customers=2E=22=3E =3Cmeta name=3D=22keywords=22 content=3D=22data warehouse=2C direct email=2C direct mail marketing=2C direct marketing=2C email marketing=2C list of email addresses=2C target marketing=22=3E =3Cmeta http-equiv=3D=22Content-Type=22 content=3D=22text=2Fhtml=3B charset=3Diso-8859-1=22=3E =3Cstyle=3E =3C!-- td=2Ebodytext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } td=2Enavtext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } a=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A underline=3B hover=3B } =2Enav=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A none=3B hover=3B } font=2Ebodytext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } font=2Enavtext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A none} a=3Ahover=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B font-weight=3A normal=3B color=3A #993366=3B } --=3E =3C=2Fstyle=3E =3C=2Fhead=3E =3Cbody bgcolor=3D=22#FFFFFF=22 leftmargin=3D=220=22 topmargin=3D=220=22 marginwidth=3D=220=22 marginheight=3D=220=22 text=3D=22#000000=22 link=3D=22#000000=22 vlink=3D=22#000000=22 alink=3D=22#000000=22=3E =3Ctable width=3D=22810=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22 height=3D=22874=22 bgcolor=3D=22#CCCC99=22=3E =3Ctr bgcolor=3D=22#cccc99=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctd height=3D=2251=22=3E =3B=3C=2Ftd=3E =3Ctd height=3D=2251=22=3E =3Ctable width=3D=22827=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22 height=3D=2228=22 bgcolor=3D=22#CCCC66=22=3E =3Ctr=3E =3Ctd align=3D=22left=22 valign=3D=22top=22 width=3D=22329=22=3E =3Cdiv align=3D=22center=22=3E =3Chr=3E =3Cfont face=3D=22Geneva=2C Arial=2C Helvetica=2C san-serif=22=3E=3Cfont color=3D=22#993399=22 face=3D=22Times New Roman=2C Times=2C serif=22 size=3D=224=22=3E=3Cb=3ETarget Emailing &=3B Creative Services=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22 size=3D=222=22=3E=3Cfont size=3D=221=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#993399=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E =3Chr=3E =3Cfont color=3D=22#993399=22 size=3D=222=22=3E=3Cfont size=3D=221=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#993399=22=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22 color=3D=22#660099=22=3EHome of 'EMail-IT' True Stealth System=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#660099=22 size=3D=223=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22 size=3D=224=22=3EPh=3A 407-539-0615=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3Ctd align=3D=22center=22 width=3D=22498=22 valign=3D=22top=22=3E =3Cfont size=3D=222=22 color=3D=22#660099=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#0000FF=22 size=3D=223=22=3E=3Ca href=3D=22mailto=3Aremoval=5Flist4864=40email=2Eit=3Fsubject=3DPleaseRemoveAddress-3578786=22=3E=3Cfont size=3D=224=22=3ECLICK HERE TO BE REMOVED=3C=2Ffont=3E=3C=2Fa=3E=3C=2Ffont=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Fb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E FAST! FAST! FAST!=3Cbr=3E Use your CABLE or DSL connection for unbelievable SPEEDS!=3C=2Ffont=3E=3C=2Ffont=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3Cfont size=3D=222=22 color=3D=22#000000=22 face=3D=22Times New Roman=2C Times=2C serif=22=3E"=3BFinally=2E=2E=2EFreedom to e-mail safely and never lose your ISP again!"=3B =3C=2Ffont=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3Cdiv align=3D=22left=22=3E =3Ctable width=3D=2231%=22 border=3D=220=22 bgcolor=3D=22#FFFFCC=22 height=3D=220%=22 cellpadding=3D=2210=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd width=3D=2224%=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctable width=3D=22100%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=220%=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#000000=22 nowrap valign=3D=22top=22 align=3D=22center=22 height=3D=224=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E =3B=3Cfont color=3D=22#FFFFFF=22=3E=3Cb=3ETargeted Opt-In Mailings=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3ETailored for your individual needs=2E Highly targeted E-mail "=3BOpt-In"=3B and Postal Mail campaigns=2E=3Cbr=3E =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3C=2Ffont=3E=3Cfont size=3D=222=22=3EIncluded in every campaign at no extra cost=3A =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22left=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cb=3EDesign of your broadcast message including Graphics=2C=3Cbr=3E =3C=2Fb=3E=3Cbr=3E =3Cb=3EConversion to HTML and Hosting=2E=3C=2Fb=3E=3C=2Ffont=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3Cbr=3E =3Cb=3EOpt-In List Generation=2FManagement=3A =3C=2Fb=3EWe can help you generate your own opt-in lists or manage your current lists for a fraction of what you would pay a broker=2E=3Cbr=3E =3Cb=3E 100% List "=3BOWNERSHIP"=3B !=3C=2Fb=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3EWeb Site Design=3A Let us design your private marketing site=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ENews Letter Promotions=3A Promote your company through monthly newsletters=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ERECEIVE THE GREATEST RETURN ON YOUR MARKETING DOLLAR=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ETargeted Messages Delivered=3Cbr=3E Base Price=3C=2Ffont=3E=3Cfont size=3D=222=22=3E=3Cbr=3E =3Cbr=3E 500=2C000 Messages $1=2C750 =3Cbr=3E 1 Million Messages $3=2C399 =3Cbr=3E 2 Million Messages $4=2C499 =3Cbr=3E 3 Million Messages $7=2C799 =3Cbr=3E 5 Million Messages $12=2C299 =3Cbr=3E 10 Million Messages $16=2C899 =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E=3Cfont color=3D=22#660099=22=3E"=3BCompanies who outsource their e-mail marketing operations actually have a better conversion rate =286%=29 than companies that do not =281=2E4%=29=2E"=3B =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3EMore info=3A 407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctable width=3D=2236%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 align=3D=22center=22 height=3D=22454=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#CCCC66=22 nowrap valign=3D=22top=22=3E=3Cfont face=3D=22Verdana=2C Arial=2C Helvetica=2C sans-serif=22 size=3D=222=22 color=3D=22#FFFFFF=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3EFresh Email Addresses=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 align=3D=22left=22 width=3D=2224%=22 height=3D=22378=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont size=3D=222=22=3EThe key to a good return on your email campaign is NEW addresses=2E Our automated servers harvest new addresses around the clock=2E We offer lists as a direct purchase or as a monthly service=2E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E250=2C000 e-mails $100=2E00=3Cbr=3E 500=2C000 e-mails $125=2E00=3Cbr=3E 1=2C000=2C000 e-mails $200=2E00=3Cbr=3E 5=2C000=2C000 e-mails $400=2E00=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cbr=3E =3C=2Fb=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont size=3D=223=22=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22left=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3EMonthly Service 150=2E00*=3Cbr=3E Includes=3A =3Cbr=3E 4=2C000=2C000 e-mails=2Fmonth=3Cbr=3E 'E-Mail-IT' Cloaking Software Updates=3Cbr=3E FTP Access=3Cbr=3E URL Cloaking Software =3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3Cdiv align=3D=22justify=22=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E*Three months required=2C lists and software download from our FTP server=2E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22center=22 valign=3D=22top=22=3E =3Ctable width=3D=2226%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=22417=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#660099=22 nowrap height=3D=2219=22 valign=3D=22top=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=222=22 color=3D=22#FFFFFF=22=3EEmail-IT CSC Proxy Service=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22 align=3D=22center=22 height=3D=22386=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cb=3ESend your e-mails directly through our servers=2E =3C=2Fb=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3EOur in house =3Cb=3E'Email-IT' True Stealth System=3C=2Fb=3E is based on Unix know-how sending technology=2C providing real anonymous instant delivery=2E =3Cbr=3E =3Cbr=3E Forget problems with ISP 's your IP address will never be shown in our e-mail headers=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3EYou send directly into OUR servers which then send your mail out to the world=2C FAST!=3C=2Ffont=3E =3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22=3EFAST! FAST! FAST!=3Cbr=3E Use your CABLE or DSL connection for mind blowing SPEEDS!=3Cbr=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22=3E'Email-IT' Pricing is based on number of e-mails you can send monthly=2E You only pay for what you send successfully!=3Cbr=3E =3Cbr=3E Priced from $400=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cfont size=3D=223=22=3EInfo=3A=3C=2Ffont=3E=3C=2Fb=3E=3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22center=22 valign=3D=22top=22=3E =3Ctable width=3D=2289%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=22365=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#993399=22 nowrap valign=3D=22top=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E =3B=3Cfont size=3D=222=22 color=3D=22#FFFFFF=22=3E=3Cb=3ESafe Bulk Email Software=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22 height=3D=22390=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3EDon't worry about losing your ISP again=2E Our NEW software system goes beyond open relays and desktop servers=2E This is NEW and it is the ONLY software of it's kind=2E=3Cbr=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E'EMail-IT' Home &=3B Office Kit Includes=3A=3Cbr=3E =3Cfont color=3D=22#333333=22=3E=3Cb=3EStealth System Software=3Cbr=3E Bulk Mailer=3Cbr=3E List Manager=3Cbr=3E Email Extractor=3Cbr=3E =3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EDaisy Chain Connector=3Cbr=3E WWW URL Cloaking Device=3Cbr=3E 1 User License and Key=3C=2Ffont=3E=3C=2Fb=3E=3Cb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3E=3Cbr=3E 2 Instructional Cd's =3Cbr=3E 1 =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E'EMail-IT' =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EOwners=3C=2Ffont=3E =3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EManual=3Cbr=3E 1 Full hour walk through =3C=2Ffont=3E=3Cfont size=3D=222=22 color=3D=22#333333=22=3Eof your installation and set up!=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Fb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cbr=3E Also includes=3A =3Cbr=3E Complete How To Files &=3B=3Cbr=3E Telephone Support*=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E=3Cfont class=3D=22textblack10=22=3EPrice=3A $475=3Cbr=3E =3C=2Ffont=3E Fedex=3Cfont class=3D=22textblack10=22=3E shipping included!=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cbr=3E =3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cbr=3E =3C=2Ffont=3E=3Cfont size=3D=222=22=3E=3Cfont class=3D=22textblack10=22=3E =3C=2Ffont=3E=3Cbr=3E =3Cb=3EO=3C=2Fb=3Erder now and we will start you off with 100=2C000=3C=2Ffont=3E fresh email addresses=2E=3Cbr=3E =3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E*Telephone Support Free for first 30 days only=2E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3Cbr=3E =3C=2Fbody=3E =3C=2Fhtml=3E From webmaster@python.org Sun Apr 14 10:56:50 2002 From: webmaster@python.org (webmaster) Date: Sun, 14 Apr 2002 05:56:50 -0400 Subject: [XML-SIG] webmaster , Your first targeted e-mailing is FREE Message-ID: =3Chtml=3E =3Chead=3E =3Ctitle=3ETarget E-mailing & Creative Services=3C=2Ftitle=3E =3Cmeta name=3D=22title=22 content=3D=22Target E-mailing & Creative Services=22=3E =3Cmeta name=3D=22description=22 content=3D=22Our custom marketing databases=2C state-of-the-art merge=2Fpurge data hygiene products=2C marketing automation and customer-centric solutions help companies market more effectively to their prospects and customers=2E=22=3E =3Cmeta name=3D=22keywords=22 content=3D=22data warehouse=2C direct email=2C direct mail marketing=2C direct marketing=2C email marketing=2C list of email addresses=2C target marketing=22=3E =3Cmeta http-equiv=3D=22Content-Type=22 content=3D=22text=2Fhtml=3B charset=3Diso-8859-1=22=3E =3Cstyle=3E =3C!-- td=2Ebodytext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } td=2Enavtext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } a=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A underline=3B hover=3B } =2Enav=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A none=3B hover=3B } font=2Ebodytext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } font=2Enavtext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A none} a=3Ahover=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B font-weight=3A normal=3B color=3A #993366=3B } --=3E =3C=2Fstyle=3E =3C=2Fhead=3E =3Cbody bgcolor=3D=22#FFFFFF=22 leftmargin=3D=220=22 topmargin=3D=220=22 marginwidth=3D=220=22 marginheight=3D=220=22 text=3D=22#000000=22 link=3D=22#000000=22 vlink=3D=22#000000=22 alink=3D=22#000000=22=3E =3Ctable width=3D=22810=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22 height=3D=22874=22 bgcolor=3D=22#CCCC99=22=3E =3Ctr bgcolor=3D=22#cccc99=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctd height=3D=2251=22=3E =3B=3C=2Ftd=3E =3Ctd height=3D=2251=22=3E =3Ctable width=3D=22827=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22 height=3D=2228=22 bgcolor=3D=22#CCCC66=22=3E =3Ctr=3E =3Ctd align=3D=22left=22 valign=3D=22top=22 width=3D=22329=22=3E =3Cdiv align=3D=22center=22=3E =3Chr=3E =3Cfont face=3D=22Geneva=2C Arial=2C Helvetica=2C san-serif=22=3E=3Cfont color=3D=22#993399=22 face=3D=22Times New Roman=2C Times=2C serif=22 size=3D=224=22=3E=3Cb=3ETarget Emailing &=3B Creative Services=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22 size=3D=222=22=3E=3Cfont size=3D=221=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#993399=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E =3Chr=3E =3Cfont color=3D=22#993399=22 size=3D=222=22=3E=3Cfont size=3D=221=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#993399=22=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22 color=3D=22#660099=22=3EHome of 'EMail-IT' True Stealth System=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#660099=22 size=3D=223=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22 size=3D=224=22=3EPh=3A 407-539-0615=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3Ctd align=3D=22center=22 width=3D=22498=22 valign=3D=22top=22=3E =3Cfont size=3D=222=22 color=3D=22#660099=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#0000FF=22 size=3D=223=22=3E=3Ca href=3D=22mailto=3Aremoval=5Flist4864=40email=2Eit=3Fsubject=3DPleaseRemoveAddress-3578786=22=3E=3Cfont size=3D=224=22=3ECLICK HERE TO BE REMOVED=3C=2Ffont=3E=3C=2Fa=3E=3C=2Ffont=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Fb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E FAST! FAST! FAST!=3Cbr=3E Use your CABLE or DSL connection for unbelievable SPEEDS!=3C=2Ffont=3E=3C=2Ffont=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3Cfont size=3D=222=22 color=3D=22#000000=22 face=3D=22Times New Roman=2C Times=2C serif=22=3E"=3BFinally=2E=2E=2EFreedom to e-mail safely and never lose your ISP again!"=3B =3C=2Ffont=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3Cdiv align=3D=22left=22=3E =3Ctable width=3D=2231%=22 border=3D=220=22 bgcolor=3D=22#FFFFCC=22 height=3D=220%=22 cellpadding=3D=2210=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd width=3D=2224%=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctable width=3D=22100%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=220%=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#000000=22 nowrap valign=3D=22top=22 align=3D=22center=22 height=3D=224=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E =3B=3Cfont color=3D=22#FFFFFF=22=3E=3Cb=3ETargeted Opt-In Mailings=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3ETailored for your individual needs=2E Highly targeted E-mail "=3BOpt-In"=3B and Postal Mail campaigns=2E=3Cbr=3E =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3C=2Ffont=3E=3Cfont size=3D=222=22=3EIncluded in every campaign at no extra cost=3A =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22left=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cb=3EDesign of your broadcast message including Graphics=2C=3Cbr=3E =3C=2Fb=3E=3Cbr=3E =3Cb=3EConversion to HTML and Hosting=2E=3C=2Fb=3E=3C=2Ffont=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3Cbr=3E =3Cb=3EOpt-In List Generation=2FManagement=3A =3C=2Fb=3EWe can help you generate your own opt-in lists or manage your current lists for a fraction of what you would pay a broker=2E=3Cbr=3E =3Cb=3E 100% List "=3BOWNERSHIP"=3B !=3C=2Fb=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3EWeb Site Design=3A Let us design your private marketing site=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ENews Letter Promotions=3A Promote your company through monthly newsletters=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ERECEIVE THE GREATEST RETURN ON YOUR MARKETING DOLLAR=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ETargeted Messages Delivered=3Cbr=3E Base Price=3C=2Ffont=3E=3Cfont size=3D=222=22=3E=3Cbr=3E =3Cbr=3E 500=2C000 Messages $1=2C750 =3Cbr=3E 1 Million Messages $3=2C399 =3Cbr=3E 2 Million Messages $4=2C499 =3Cbr=3E 3 Million Messages $7=2C799 =3Cbr=3E 5 Million Messages $12=2C299 =3Cbr=3E 10 Million Messages $16=2C899 =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E=3Cfont color=3D=22#660099=22=3E"=3BCompanies who outsource their e-mail marketing operations actually have a better conversion rate =286%=29 than companies that do not =281=2E4%=29=2E"=3B =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3EMore info=3A 407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctable width=3D=2236%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 align=3D=22center=22 height=3D=22454=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#CCCC66=22 nowrap valign=3D=22top=22=3E=3Cfont face=3D=22Verdana=2C Arial=2C Helvetica=2C sans-serif=22 size=3D=222=22 color=3D=22#FFFFFF=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3EFresh Email Addresses=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 align=3D=22left=22 width=3D=2224%=22 height=3D=22378=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont size=3D=222=22=3EThe key to a good return on your email campaign is NEW addresses=2E Our automated servers harvest new addresses around the clock=2E We offer lists as a direct purchase or as a monthly service=2E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E250=2C000 e-mails $100=2E00=3Cbr=3E 500=2C000 e-mails $125=2E00=3Cbr=3E 1=2C000=2C000 e-mails $200=2E00=3Cbr=3E 5=2C000=2C000 e-mails $400=2E00=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cbr=3E =3C=2Fb=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont size=3D=223=22=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22left=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3EMonthly Service 150=2E00*=3Cbr=3E Includes=3A =3Cbr=3E 4=2C000=2C000 e-mails=2Fmonth=3Cbr=3E 'E-Mail-IT' Cloaking Software Updates=3Cbr=3E FTP Access=3Cbr=3E URL Cloaking Software =3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3Cdiv align=3D=22justify=22=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E*Three months required=2C lists and software download from our FTP server=2E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22center=22 valign=3D=22top=22=3E =3Ctable width=3D=2226%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=22417=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#660099=22 nowrap height=3D=2219=22 valign=3D=22top=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=222=22 color=3D=22#FFFFFF=22=3EEmail-IT CSC Proxy Service=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22 align=3D=22center=22 height=3D=22386=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cb=3ESend your e-mails directly through our servers=2E =3C=2Fb=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3EOur in house =3Cb=3E'Email-IT' True Stealth System=3C=2Fb=3E is based on Unix know-how sending technology=2C providing real anonymous instant delivery=2E =3Cbr=3E =3Cbr=3E Forget problems with ISP 's your IP address will never be shown in our e-mail headers=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3EYou send directly into OUR servers which then send your mail out to the world=2C FAST!=3C=2Ffont=3E =3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22=3EFAST! FAST! FAST!=3Cbr=3E Use your CABLE or DSL connection for mind blowing SPEEDS!=3Cbr=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22=3E'Email-IT' Pricing is based on number of e-mails you can send monthly=2E You only pay for what you send successfully!=3Cbr=3E =3Cbr=3E Priced from $400=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cfont size=3D=223=22=3EInfo=3A=3C=2Ffont=3E=3C=2Fb=3E=3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22center=22 valign=3D=22top=22=3E =3Ctable width=3D=2289%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=22365=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#993399=22 nowrap valign=3D=22top=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E =3B=3Cfont size=3D=222=22 color=3D=22#FFFFFF=22=3E=3Cb=3ESafe Bulk Email Software=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22 height=3D=22390=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3EDon't worry about losing your ISP again=2E Our NEW software system goes beyond open relays and desktop servers=2E This is NEW and it is the ONLY software of it's kind=2E=3Cbr=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E'EMail-IT' Home &=3B Office Kit Includes=3A=3Cbr=3E =3Cfont color=3D=22#333333=22=3E=3Cb=3EStealth System Software=3Cbr=3E Bulk Mailer=3Cbr=3E List Manager=3Cbr=3E Email Extractor=3Cbr=3E =3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EDaisy Chain Connector=3Cbr=3E WWW URL Cloaking Device=3Cbr=3E 1 User License and Key=3C=2Ffont=3E=3C=2Fb=3E=3Cb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3E=3Cbr=3E 2 Instructional Cd's =3Cbr=3E 1 =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E'EMail-IT' =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EOwners=3C=2Ffont=3E =3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EManual=3Cbr=3E 1 Full hour walk through =3C=2Ffont=3E=3Cfont size=3D=222=22 color=3D=22#333333=22=3Eof your installation and set up!=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Fb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cbr=3E Also includes=3A =3Cbr=3E Complete How To Files &=3B=3Cbr=3E Telephone Support*=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E=3Cfont class=3D=22textblack10=22=3EPrice=3A $475=3Cbr=3E =3C=2Ffont=3E Fedex=3Cfont class=3D=22textblack10=22=3E shipping included!=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cbr=3E =3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cbr=3E =3C=2Ffont=3E=3Cfont size=3D=222=22=3E=3Cfont class=3D=22textblack10=22=3E =3C=2Ffont=3E=3Cbr=3E =3Cb=3EO=3C=2Fb=3Erder now and we will start you off with 100=2C000=3C=2Ffont=3E fresh email addresses=2E=3Cbr=3E =3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E*Telephone Support Free for first 30 days only=2E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3Cbr=3E =3C=2Fbody=3E =3C=2Fhtml=3E From jerome.marant@free.fr Mon Apr 15 18:27:18 2002 From: jerome.marant@free.fr (=?iso-8859-1?q?J=E9r=F4me?= Marant) Date: Mon, 15 Apr 2002 19:27:18 +0200 Subject: [XML-SIG] Re: Solution for the Debian 4suite/PyXML problem In-Reply-To: <20020415072000.GD19620@orion.logilab.fr> (Alexandre's message of "Mon, 15 Apr 2002 09:20:00 +0200") References: <87heme82ho.fsf@marant.org> <20020415072000.GD19620@orion.logilab.fr> Message-ID: <87zo04zxc9.fsf@marant.org> Alexandre writes: > On Sun, Apr 14, 2002 at 10:11:15PM +0200, Jérôme Marant wrote: > >> Alexandre (or anyone else), could you please have a look >> at http://bugs.debian.org/141549. > > I'll do that and send you a patch. It looks like a "characters() callback gets called more than once" bug. Ok. I'm waiting for your patch. Cheers, -- Jérôme Marant http://marant.org From webmaster@python.org Mon Apr 15 05:09:47 2002 From: webmaster@python.org (webmaster) Date: Mon, 15 Apr 2002 00:09:47 -0400 Subject: [XML-SIG] webmaster , Your first targeted e-mailing is FREE Message-ID: =3Chtml=3E =3Chead=3E =3Ctitle=3ETarget E-mailing & Creative Services=3C=2Ftitle=3E =3Cmeta name=3D=22title=22 content=3D=22Target E-mailing & Creative Services=22=3E =3Cmeta name=3D=22description=22 content=3D=22Our custom marketing databases=2C state-of-the-art merge=2Fpurge data hygiene products=2C marketing automation and customer-centric solutions help companies market more effectively to their prospects and customers=2E=22=3E =3Cmeta name=3D=22keywords=22 content=3D=22data warehouse=2C direct email=2C direct mail marketing=2C direct marketing=2C email marketing=2C list of email addresses=2C target marketing=22=3E =3Cmeta http-equiv=3D=22Content-Type=22 content=3D=22text=2Fhtml=3B charset=3Diso-8859-1=22=3E =3Cstyle=3E =3C!-- td=2Ebodytext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } td=2Enavtext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } a=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A underline=3B hover=3B } =2Enav=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A none=3B hover=3B } font=2Ebodytext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3Ablack=3B } font=2Enavtext=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B color=3A#000000=3B text-decoration=3A none} a=3Ahover=09{ font-family=3A Verdana=2C Arial=2C Helvetica=2C sans-serif=3B font-size=3A 10px=3B font-style=3A normal=3B font-weight=3A normal=3B color=3A #993366=3B } --=3E =3C=2Fstyle=3E =3C=2Fhead=3E =3Cbody bgcolor=3D=22#FFFFFF=22 leftmargin=3D=220=22 topmargin=3D=220=22 marginwidth=3D=220=22 marginheight=3D=220=22 text=3D=22#000000=22 link=3D=22#000000=22 vlink=3D=22#000000=22 alink=3D=22#000000=22=3E =3Ctable width=3D=22810=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22 height=3D=22874=22 bgcolor=3D=22#CCCC99=22=3E =3Ctr bgcolor=3D=22#cccc99=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctd height=3D=2251=22=3E =3B=3C=2Ftd=3E =3Ctd height=3D=2251=22=3E =3Ctable width=3D=22827=22 border=3D=220=22 cellspacing=3D=220=22 cellpadding=3D=220=22 height=3D=2228=22 bgcolor=3D=22#CCCC66=22=3E =3Ctr=3E =3Ctd align=3D=22left=22 valign=3D=22top=22 width=3D=22329=22=3E =3Cdiv align=3D=22center=22=3E =3Chr=3E =3Cfont face=3D=22Geneva=2C Arial=2C Helvetica=2C san-serif=22=3E=3Cfont color=3D=22#993399=22 face=3D=22Times New Roman=2C Times=2C serif=22 size=3D=224=22=3E=3Cb=3ETarget Emailing &=3B Creative Services=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22 size=3D=222=22=3E=3Cfont size=3D=221=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#993399=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E =3Chr=3E =3Cfont color=3D=22#993399=22 size=3D=222=22=3E=3Cfont size=3D=221=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#993399=22=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22 color=3D=22#660099=22=3EHome of 'EMail-IT' True Stealth System=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#660099=22 size=3D=223=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22 size=3D=224=22=3EPh=3A 407-539-0615=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3Ctd align=3D=22center=22 width=3D=22498=22 valign=3D=22top=22=3E =3Cfont size=3D=222=22 color=3D=22#660099=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 color=3D=22#0000FF=22 size=3D=223=22=3E=3Ca href=3D=22mailto=3Aremoval=5Flist4864=40email=2Eit=3Fsubject=3DPleaseRemoveAddress-3578786=22=3E=3Cfont size=3D=224=22=3ECLICK HERE TO BE REMOVED=3C=2Ffont=3E=3C=2Fa=3E=3C=2Ffont=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Fb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E FAST! FAST! FAST!=3Cbr=3E Use your CABLE or DSL connection for unbelievable SPEEDS!=3C=2Ffont=3E=3C=2Ffont=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cfont face=3D=22Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3Cfont size=3D=222=22 color=3D=22#000000=22 face=3D=22Times New Roman=2C Times=2C serif=22=3E"=3BFinally=2E=2E=2EFreedom to e-mail safely and never lose your ISP again!"=3B =3C=2Ffont=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3Cdiv align=3D=22left=22=3E =3Ctable width=3D=2231%=22 border=3D=220=22 bgcolor=3D=22#FFFFCC=22 height=3D=220%=22 cellpadding=3D=2210=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd width=3D=2224%=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctable width=3D=22100%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=220%=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#000000=22 nowrap valign=3D=22top=22 align=3D=22center=22 height=3D=224=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E =3B=3Cfont color=3D=22#FFFFFF=22=3E=3Cb=3ETargeted Opt-In Mailings=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3ETailored for your individual needs=2E Highly targeted E-mail "=3BOpt-In"=3B and Postal Mail campaigns=2E=3Cbr=3E =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3C=2Ffont=3E=3Cfont size=3D=222=22=3EIncluded in every campaign at no extra cost=3A =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22left=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cb=3EDesign of your broadcast message including Graphics=2C=3Cbr=3E =3C=2Fb=3E=3Cbr=3E =3Cb=3EConversion to HTML and Hosting=2E=3C=2Fb=3E=3C=2Ffont=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3E=3Cbr=3E =3Cbr=3E =3Cb=3EOpt-In List Generation=2FManagement=3A =3C=2Fb=3EWe can help you generate your own opt-in lists or manage your current lists for a fraction of what you would pay a broker=2E=3Cbr=3E =3Cb=3E 100% List "=3BOWNERSHIP"=3B !=3C=2Fb=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3EWeb Site Design=3A Let us design your private marketing site=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ENews Letter Promotions=3A Promote your company through monthly newsletters=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=221=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ERECEIVE THE GREATEST RETURN ON YOUR MARKETING DOLLAR=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22 face=3D=22Georgia=2C Times New Roman=2C Times=2C serif=22=3ETargeted Messages Delivered=3Cbr=3E Base Price=3C=2Ffont=3E=3Cfont size=3D=222=22=3E=3Cbr=3E =3Cbr=3E 500=2C000 Messages $1=2C750 =3Cbr=3E 1 Million Messages $3=2C399 =3Cbr=3E 2 Million Messages $4=2C499 =3Cbr=3E 3 Million Messages $7=2C799 =3Cbr=3E 5 Million Messages $12=2C299 =3Cbr=3E 10 Million Messages $16=2C899 =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E=3Cfont color=3D=22#660099=22=3E"=3BCompanies who outsource their e-mail marketing operations actually have a better conversion rate =286%=29 than companies that do not =281=2E4%=29=2E"=3B =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3EMore info=3A 407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22left=22 valign=3D=22top=22=3E =3Ctable width=3D=2236%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 align=3D=22center=22 height=3D=22454=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#CCCC66=22 nowrap valign=3D=22top=22=3E=3Cfont face=3D=22Verdana=2C Arial=2C Helvetica=2C sans-serif=22 size=3D=222=22 color=3D=22#FFFFFF=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3EFresh Email Addresses=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 align=3D=22left=22 width=3D=2224%=22 height=3D=22378=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont size=3D=222=22=3EThe key to a good return on your email campaign is NEW addresses=2E Our automated servers harvest new addresses around the clock=2E We offer lists as a direct purchase or as a monthly service=2E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E250=2C000 e-mails $100=2E00=3Cbr=3E 500=2C000 e-mails $125=2E00=3Cbr=3E 1=2C000=2C000 e-mails $200=2E00=3Cbr=3E 5=2C000=2C000 e-mails $400=2E00=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cbr=3E =3C=2Fb=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont size=3D=223=22=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22left=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3EMonthly Service 150=2E00*=3Cbr=3E Includes=3A =3Cbr=3E 4=2C000=2C000 e-mails=2Fmonth=3Cbr=3E 'E-Mail-IT' Cloaking Software Updates=3Cbr=3E FTP Access=3Cbr=3E URL Cloaking Software =3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3Cdiv align=3D=22justify=22=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22 face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E*Three months required=2C lists and software download from our FTP server=2E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22center=22 valign=3D=22top=22=3E =3Ctable width=3D=2226%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=22417=22 align=3D=22center=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#660099=22 nowrap height=3D=2219=22 valign=3D=22top=22=3E=3Cb=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=222=22 color=3D=22#FFFFFF=22=3EEmail-IT CSC Proxy Service=3C=2Ffont=3E=3C=2Fb=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22 align=3D=22center=22 height=3D=22386=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cb=3ESend your e-mails directly through our servers=2E =3C=2Fb=3E=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3EOur in house =3Cb=3E'Email-IT' True Stealth System=3C=2Fb=3E is based on Unix know-how sending technology=2C providing real anonymous instant delivery=2E =3Cbr=3E =3Cbr=3E Forget problems with ISP 's your IP address will never be shown in our e-mail headers=2E =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3EYou send directly into OUR servers which then send your mail out to the world=2C FAST!=3C=2Ffont=3E =3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22=3EFAST! FAST! FAST!=3Cbr=3E Use your CABLE or DSL connection for mind blowing SPEEDS!=3Cbr=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp align=3D=22center=22=3E=3Cfont size=3D=222=22=3E'Email-IT' Pricing is based on number of e-mails you can send monthly=2E You only pay for what you send successfully!=3Cbr=3E =3Cbr=3E Priced from $400=3Cbr=3E =3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cfont size=3D=222=22=3E=3Cb=3E=3Cfont size=3D=223=22=3EInfo=3A=3C=2Ffont=3E=3C=2Fb=3E=3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E =3C=2Ffont=3E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3Ctd width=3D=2224%=22 align=3D=22center=22 valign=3D=22top=22=3E =3Ctable width=3D=2289%=22 border=3D=220=22 cellspacing=3D=223=22 cellpadding=3D=225=22 height=3D=22365=22=3E =3Ctr=3E =3Ctd bgcolor=3D=22#993399=22 nowrap valign=3D=22top=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E =3B=3Cfont size=3D=222=22 color=3D=22#FFFFFF=22=3E=3Cb=3ESafe Bulk Email Software=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ftd=3E =3C=2Ftr=3E =3Ctr=3E =3Ctd valign=3D=22top=22 width=3D=2224%=22 height=3D=22390=22=3E =3Cdiv align=3D=22justify=22=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3EDon't worry about losing your ISP again=2E Our NEW software system goes beyond open relays and desktop servers=2E This is NEW and it is the ONLY software of it's kind=2E=3Cbr=3E =3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E'EMail-IT' Home &=3B Office Kit Includes=3A=3Cbr=3E =3Cfont color=3D=22#333333=22=3E=3Cb=3EStealth System Software=3Cbr=3E Bulk Mailer=3Cbr=3E List Manager=3Cbr=3E Email Extractor=3Cbr=3E =3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EDaisy Chain Connector=3Cbr=3E WWW URL Cloaking Device=3Cbr=3E 1 User License and Key=3C=2Ffont=3E=3C=2Fb=3E=3Cb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3E=3Cbr=3E 2 Instructional Cd's =3Cbr=3E 1 =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E'EMail-IT' =3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EOwners=3C=2Ffont=3E =3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3EManual=3Cbr=3E 1 Full hour walk through =3C=2Ffont=3E=3Cfont size=3D=222=22 color=3D=22#333333=22=3Eof your installation and set up!=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22 color=3D=22#333333=22=3E=3Cbr=3E =3C=2Ffont=3E=3C=2Fb=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cbr=3E Also includes=3A =3Cbr=3E Complete How To Files &=3B=3Cbr=3E Telephone Support*=3C=2Ffont=3E=3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E=3Cfont class=3D=22textblack10=22=3EPrice=3A $475=3Cbr=3E =3C=2Ffont=3E Fedex=3Cfont class=3D=22textblack10=22=3E shipping included!=3Cbr=3E =3C=2Ffont=3E=3C=2Ffont=3E=3Cfont color=3D=22#993399=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22 size=3D=221=22=3E=3Cbr=3E =3Cfont color=3D=22#993399=22 size=3D=223=22=3E=3Cfont face=3D=22Tahoma=2C Verdana=2C Georgia=2C Arial=22=3E=3Cb=3E407-539-0615=3C=2Fb=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E=3C=2Ffont=3E=3Cfont class=3D=22textblack10=22 size=3D=222=22=3E=3Cbr=3E =3C=2Ffont=3E=3Cfont size=3D=222=22=3E=3Cfont class=3D=22textblack10=22=3E =3C=2Ffont=3E=3Cbr=3E =3Cb=3EO=3C=2Fb=3Erder now and we will start you off with 100=2C000=3C=2Ffont=3E fresh email addresses=2E=3Cbr=3E =3C=2Fp=3E =3Cp=3E=3Cfont size=3D=222=22=3E*Telephone Support Free for first 30 days only=2E=3C=2Ffont=3E=3C=2Fp=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3C=2Fdiv=3E =3C=2Ftd=3E =3C=2Ftr=3E =3C=2Ftable=3E =3Cbr=3E =3C=2Fbody=3E =3C=2Fhtml=3E From Alexandre.Fayolle@logilab.fr Tue Apr 16 09:43:23 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Tue, 16 Apr 2002 10:43:23 +0200 Subject: [XML-SIG] adding an "xbel" category to the SF tracker Message-ID: <20020416084323.GL381@orion.logilab.fr> Hello, Could an administrator add an "xbel" category to the SF tracker ? Thanks. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From fdrake@acm.org Tue Apr 16 14:45:16 2002 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 16 Apr 2002 09:45:16 -0400 Subject: [XML-SIG] adding an "xbel" category to the SF tracker In-Reply-To: <20020416084323.GL381@orion.logilab.fr> References: <20020416084323.GL381@orion.logilab.fr> Message-ID: <15548.10988.944108.676097@grendel.zope.com> Alexandre writes: > Could an administrator add an "xbel" category to the SF tracker ? I've just added this for the Bug & Patch trackers. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Alexandre.Fayolle@logilab.fr Tue Apr 16 14:48:48 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Tue, 16 Apr 2002 15:48:48 +0200 Subject: [XML-SIG] adding an "xbel" category to the SF tracker In-Reply-To: <15548.10988.944108.676097@grendel.zope.com> References: <20020416084323.GL381@orion.logilab.fr> <15548.10988.944108.676097@grendel.zope.com> Message-ID: <20020416134848.GB6149@orion.logilab.fr> On Tue, Apr 16, 2002 at 09:45:16AM -0400, Fred L. Drake, Jr. wrote: > > Alexandre writes: > > Could an administrator add an "xbel" category to the SF tracker ? > > I've just added this for the Bug & Patch trackers. Thanks. 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 larsga@garshol.priv.no Tue Apr 16 16:52:29 2002 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 16 Apr 2002 17:52:29 +0200 Subject: [XML-SIG] Problem with entities In-Reply-To: <5.1.0.14.0.20020307100714.00a97ef8@192.168.0.1> References: <5.1.0.14.0.20020307100714.00a97ef8@192.168.0.1> Message-ID: I was off travelling when this was posted, but feel it's worth returning to. * Patrick Gaherty | | I'm using the XMLGenerator class from saxutils (PyXML 0.7) and I'm | having problems with entities. To start off with I'm just trying to | recreate the original XML input file. You can't do that. The XML parser throws away *heaps* of information about the original document that you'd need in order to be able to do this. So if that's what you want you should just stop, because it's not going to work. | This works a treat, except I'm losing any entities I've declared in | my DTD (ie œ). Ideally I'd like them to appear in the output | untouched. As Tom Passin said: the generator expects to get parsed text, where the entities have been replaced by what they represent. So what you should output is the 'oe' character. Of course, that would give you the 'oe' character as output, and you seem to want the entity. The first answer to that is: you shouldn't represent characters using entities. It's just The Wrong Thing. The second answer is that a very strong desire to do The Wrong Thing is very widespread, and so perhaps we should support it. There are two ways to do that: - add a entity(self, name) method - add a literal_text(self, text) method Comments on this? -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From noreply@sourceforge.net Tue Apr 16 18:13:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Apr 2002 10:13:10 -0700 Subject: [XML-SIG] [ pyxml-Bugs-544772 ] iso8601 __extract_time exception Message-ID: Bugs item #544772, was opened at 2002-04-16 17:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=544772&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Steele (daves) Assigned to: Nobody/Anonymous (nobody) Summary: iso8601 __extract_time exception Initial Comment: For the date '2002-04-16T15:51:59.02Z', iso8601.parse returns the following ValueError: Traceback (most recent call last): File "./test", line 111, in setUp backup.closeSession( self.sHdl1 ) File "./backup.py", line 118, in closeSession ( bname, sdate ) = validateSessionHdl( sname ) File "./backup.py", line 107, in validateSessionHdl iso8601.parse( lst[1] ) File "./iso8601.py", line 24, in parse gmt = __extract_date(m) + __extract_time(m) + (0, 0, 0) File "./iso8601.py", line 142, in __extract_time raise ValueError, "illegal seconds number: " + m.group("seconds") ValueError: illegal seconds number: 59.02 ======================================================= =============== Suggest the following patch: 01.py.orig /usr/lib/python1.5/site- packages/xml/utils/iso8601.py --- /usr/lib/python1.5/site- packages/xml/utils/iso8601.py.orig Tue Apr 16 11:58:10 2002 +++ /usr/lib/python1.5/site- packages/xml/utils/iso8601.py Tue Apr 16 12:07:37 2002 @@ -138,7 +138,7 @@ seconds = m.group("seconds") if seconds: seconds = string.atof(seconds) - if not 0 <= seconds <= 59: + if not 0 <= seconds <= 60: raise ValueError, "illegal seconds number: " + m.group("seconds") else: seconds = 0 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=544772&group_id=6473 From tpassin@comcast.net Wed Apr 17 01:00:16 2002 From: tpassin@comcast.net (Thomas B. Passin) Date: Tue, 16 Apr 2002 20:00:16 -0400 Subject: [XML-SIG] Problem with entities References: <5.1.0.14.0.20020307100714.00a97ef8@192.168.0.1> Message-ID: <000c01c1e5a2$db847c00$0bf13044@tbp> [Lars Marius Garshol] > > I was off travelling when this was posted, but feel it's worth > returning to. > > ... > Of course, that would give you the 'oe' character as output, and you > seem to want the entity. > > The first answer to that is: you shouldn't represent characters using > entities. It's just The Wrong Thing. > > The second answer is that a very strong desire to do The Wrong Thing > is very widespread, and so perhaps we should support it. There are two > ways to do that: > > - add a entity(self, name) method > > - add a literal_text(self, text) method > > Comments on this? > This is strictly a matter for a serializer. There are a lot of things people seem to want to do that belong in the serializer domain. Let's not just hack at this. Maybe there is something systematic we add to the basic serializer design to provide a hook for people to modify the output stream. Not to change the way the tree is traversed (or virtually traversed in case there is no actual tree), but just to hook in. This way, one essentially could plug in a post-processor with no modifications to standard code and standard interfaces. The plug-in could enumerate its capabilities, perhaps. If we want an entity replacer, we couldn't easily replace them with the original entity names, but we could supply a translation dictionary form characters to entities. If we want to change element names to upper case, we can do that. And so on... Cheers, Tom P From jpoenninghaus@canopus.lili.uni-bielefeld.de Wed Apr 17 09:02:53 2002 From: jpoenninghaus@canopus.lili.uni-bielefeld.de (jpoenninghaus@canopus.lili.uni-bielefeld.de) Date: Wed, 17 Apr 2002 10:02:53 +0200 Subject: [XML-SIG] 'Strange' behaviour of TreeWalker Message-ID: <20020417100253.A1424@canopus.uni-bielefeld.de> Hi, I'm quite new to Python (and pyxml / 4Suite ) and was quite confused by a 'strange' difference between NodeIterator and TreeWalker. While instances of NodeIterator are "printable" and give reasonable error messages, eg. accessing undefined attributes, instances of TreeWalker give hard times to novice users as __getattr__() effectively prevents any such access without reasonable message. Is that the intended behaviour or just an unwanted side-effect? At least, a note in the docs might be valuable to others. Thanks for your attention Jens Poenninghaus _________________ Transcript of simple session: >>> from xml.dom import NodeIterator,TreeWalker >>> no=NodeIterator.NodeIterator("a","b","c",1) >>> tw=TreeWalker.TreeWalker("a","b","c",1) >>> print no >>> print no.__dict__ {'_nodeStack': [], '_current': 'a', 'expandEntityReferences': 1, '_atStart': 1, 'root': 'a', '_detached': 0, 'whatToShow': 'b', '_atEnd': 0, 'filter': 'c'} >>> print tw.__dict__ {'__root': 'a', '__whatToShow': 'b', '__expandEntityReferences': 1, '__currentNode': 'a', '__filter': 'c'} >>> print tw Traceback (most recent call last): File "", line 1, in ? TypeError: object of type 'None' is not callable >>> print no.stupidMethodCall() Traceback (most recent call last): File "", line 1, in ? AttributeError: NodeIterator instance has no attribute 'stupidMethodCall' >>> print tw.stupidMethodCall() Traceback (most recent call last): File "", line 1, in ? TypeError: object of type 'None' is not callable From noreply@sourceforge.net Wed Apr 17 13:18:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Apr 2002 05:18:06 -0700 Subject: [XML-SIG] [ pyxml-Bugs-545141 ] removeEventListener & captured events Message-ID: Bugs item #545141, was opened at 2002-04-17 05:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=545141&group_id=6473 Category: DOM Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: removeEventListener & captured events Initial Comment: removeEventListener in Event.py does not deal with the removal of captured events correctly. Need to remove the event from the correct listeners map (self.listeners or self.capture_listeners) depending on the value of useCapture. See implementation of addEventListener. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=106473&aid=545141&group_id=6473 From reagle@w3.org Wed Apr 17 20:18:19 2002 From: reagle@w3.org (Joseph Reagle) Date: Wed, 17 Apr 2002 15:18:19 -0400 Subject: [XML-SIG] Re: bug in c14n.py Message-ID: <200204171918.PAA17987@tux.w3.org> --------------Boundary-00=_JA8Q2531E7NEDBEUJMXV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I include a c14n.py that fixes the bug that I speak of below, and a test_c14n.py that has a more consistent treatment of the "withComments" option, and also permits additional prefixes to be passed as a command line parameter under exclusive canonicalization. However, I also discovered a bug from Gregor's example 1 [a]. Presently, c14n.py does the following: 1. takes any xml_attrs (e.g., xml:lang) from previous recursions not rendered and adds them to local xml_attrs. 2. if the element we are processing is in the subset, it renders the accumulated xml_attrs as part of that element and and resets xml_attrs=[] 3. it recurses. This has the effect of rendering all XML attributes that are "in affect" since the last ancestor was rendered. Sounds sensible, but it's not correct according to the the spec [b]. To fix this, I think we'd have to test whether the immediate parent was in the nodeset and keep a dictionary (instead of a list) of *all* ancestors' xml:foo attributes (not just since the nearest rendered one), with the *nearest* value. (Moving from a list to a dictionary is akin to what I did for the namespace bug.) This bug exists on in c14n, not exc-c14n. [a] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0259.html [b] http://www.w3.org/TR/2001/REC-xml-c14n-20010315 "The processing of an element node E MUST be modified slightly when an XPath node-set is given as input and the element's parent is omitted from the node-set. The method for processing the attribute axis of an element E in the node-set is enhanced. All element nodes along E's ancestor axis are examined for nearest occurrences of attributes in the xml namespace, such as xml:lang and xml:space (whether or not they are in the node-set). From this list of attributes, remove any that are in E's attribute axis (whether or not they are in the node-set)." On Monday 08 April 2002 17:44, Joseph Reagle wrote: > I think there's a pretty big bug in c14n.py. I've attached a simple > example [0] that when run with [1] produces [2]. (I started out thinking > this was a problem with default namespaces, but it's something else.) I > don't think e3 should emmit any declaration, but since the ns code only > compares with pvalue (e2's value for the prefix f is different), it > incorrectly emits it. > > However, I've made lots of tweaks. I wonder if I've introduced this > error? I've tried to fix it, but I find the ns code rather hard to > understand. Additionally, I think the solution is to actually keep a > (stack of) dictionary with rendered prefix and value. ns_rendered will > need to be a dictionary of rendered ns prefixes and values, not just the > prefixes. > > > > > [0] > > > > > > > > > [1] test_c14n.py -i egj1.xml -x "(//. | //@* | //namespace::*)[self::e1 > or self::e3]" > > [2] -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ --------------Boundary-00=_JA8Q2531E7NEDBEUJMXV Content-Type: text/html; charset="iso-8859-1"; name="test_c14n.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test_c14n.py" IyEgL3Vzci9iaW4vZW52IHB5dGhvbgoKIyBUaGUgc2V2ZW4gZXhhbXBsZXMgZnJvbSB0aGUgQ2Fu b25pY2FsIFhNTCBzcGVjLgojIGh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRu LTIwMDEwMzE1Cgp0cnk6CiAgICB1ID0gdW5pY29kZQpleGNlcHQgTmFtZUVycm9yOgogICAgZGVm IHUoeCk6cmV0dXJuIHgKCmVnMSA9ICIiIjw/eG1sIHZlcnNpb249IjEuMCI/PgoKPD94bWwtc3R5 bGVzaGVldCAgIGhyZWY9ImRvYy54c2wiCiAgIHR5cGU9InRleHQveHNsIiAgID8+Cgo8IURPQ1RZ UEUgZG9jIFNZU1RFTSAiZG9jLmR0ZCI+Cgo8ZG9jPkhlbGxvLCB3b3JsZCE8IS0tIENvbW1lbnQg MQotLT48L2RvYz4KCjw/cGktd2l0aG91dC1kYXRhICAgICA/PgoKPCEtLSBDb21tZW50IDIgLS0+ Cgo8IS0tIENvbW1lbnQgMyAtLT4KIiIiCgplZzIgPSAiIiI8ZG9jPgogICA8Y2xlYW4+ICAgPC9j bGVhbj4KICAgPGRpcnR5PiAgIEEgICBCICAgPC9kaXJ0eT4KICAgPG1peGVkPgogICAgICBBCiAg ICAgIDxjbGVhbj4gICA8L2NsZWFuPgogICAgICBCCiAgICAgIDxkaXJ0eT4gICBBICAgQiAgIDwv ZGlydHk+CiAgICAgIEMKICAgPC9taXhlZD4KPC9kb2M+CiIiIgoKZWczID0gIiIiPCFET0NUWVBF IGRvYyBbPCFBVFRMSVNUIGU5IGF0dHIgQ0RBVEEgImRlZmF1bHQiPl0+Cjxkb2M+CiAgIDxlMSAg IC8+CiAgIDxlMiAgID48L2UyPgogICA8ZTMgICAgbmFtZSA9ICJlbGVtMyIgICBpZD0iZWxlbTMi ICAgIC8+CiAgIDxlNCAgICBuYW1lPSJlbGVtNCIgICBpZD0iZWxlbTQiICAgID48L2U0PgogICA8 ZTUgYTphdHRyPSJvdXQiIGI6YXR0cj0ic29ydGVkIiBhdHRyMj0iYWxsIiBhdHRyPSJJJ20iCiAg ICAgICB4bWxuczpiPSJodHRwOi8vd3d3LmlldGYub3JnIgogICAgICAgeG1sbnM6YT0iaHR0cDov L3d3dy53My5vcmciCiAgICAgICB4bWxucz0iaHR0cDovL2V4YW1wbGUub3JnIi8+CiAgIDxlNiB4 bWxucz0iIiB4bWxuczphPSJodHRwOi8vd3d3LnczLm9yZyI+CiAgICAgICA8ZTcgeG1sbnM9Imh0 dHA6Ly93d3cuaWV0Zi5vcmciPgogICAgICAgICAgIDxlOCB4bWxucz0iIiB4bWxuczphPSJodHRw Oi8vd3d3LnczLm9yZyI+CiAgICAgICAgICAgICAgIDxlOSB4bWxucz0iIiB4bWxuczphPSJodHRw Oi8vd3d3LmlldGYub3JnIi8+CiAgICAgICAgICAgPC9lOD4KICAgICAgIDwvZTc+CiAgIDwvZTY+ CjwvZG9jPgoiIiIKCmVnMyA9ICIiIjwhRE9DVFlQRSBkb2MgWzwhQVRUTElTVCBlOSBhdHRyIENE QVRBICJkZWZhdWx0Ij5dPgo8ZG9jIHhtbG5zOmZvbz0iaHR0cDovL3d3dy5iYXIub3JnIj4KICAg PGUxICAgLz4KICAgPGUyICAgPjwvZTI+CiAgIDxlMyAgICBuYW1lID0gImVsZW0zIiAgIGlkPSJl bGVtMyIgICAgLz4KICAgPGU0ICAgIG5hbWU9ImVsZW00IiAgIGlkPSJlbGVtNCIgICAgPjwvZTQ+ CiAgIDxlNSBhOmF0dHI9Im91dCIgYjphdHRyPSJzb3J0ZWQiIGF0dHIyPSJhbGwiIGF0dHI9Ikkn bSIKICAgICAgIHhtbG5zOmI9Imh0dHA6Ly93d3cuaWV0Zi5vcmciCiAgICAgICB4bWxuczphPSJo dHRwOi8vd3d3LnczLm9yZyIKICAgICAgIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5vcmciLz4KICAg PGU2IHhtbG5zPSIiIHhtbG5zOmE9Imh0dHA6Ly93d3cudzMub3JnIj4KICAgICAgIDxlNyB4bWxu cz0iaHR0cDovL3d3dy5pZXRmLm9yZyI+CiAgICAgICAgICAgPGU4IHhtbG5zPSIiIHhtbG5zOmE9 Imh0dHA6Ly93d3cudzMub3JnIiBhOmZvbz0iYmFyIj4KICAgICAgICAgICAgICAgPGU5IHhtbG5z PSIiIHhtbG5zOmE9Imh0dHA6Ly93d3cuaWV0Zi5vcmciLz4KICAgICAgICAgICA8L2U4PgogICAg ICAgPC9lNz4KICAgPC9lNj4KPC9kb2M+CiIiIgoKZWc0ID0gIiIiPCFET0NUWVBFIGRvYyBbIDwh QVRUTElTVCBub3JtSWQgaWQgSUQgI0lNUExJRUQ+IDwhQVRUTElTVCBub3JtTmFtZXMgYXR0ciBO TVRPS0VOUyAjSU1QTElFRD4gXT4gPGRvYz4KICAgPHRleHQ+Rmlyc3QgbGluZSYjeDBkOyYjMTA7 U2Vjb25kIGxpbmU8L3RleHQ+CiAgIDx2YWx1ZT4mI3gzMjs8L3ZhbHVlPgogICA8Y29tcHV0ZT48 IVtDREFUQVt2YWx1ZT4iMCIgJiYgdmFsdWU8IjEwIiA/InZhbGlkIjoiZXJyb3IiXV0+PC9jb21w dXRlPgogICA8Y29tcHV0ZSBleHByPSd2YWx1ZT4iMCIgJmFtcDsmYW1wOyB2YWx1ZSZsdDsiMTAi ID8idmFsaWQiOiJlcnJvciInPnZhbGlkPC9jb21wdXRlPgogICA8bm9ybSBhdHRyPScgJmFwb3M7 ICAgJiN4MjA7JiMxMzsmI3hhOyYjOTsgICAmYXBvczsgJy8+CiAgIDxub3JtTmFtZXMgYXR0cj0n ICAgQSAgICYjeDIwOyYjMTM7JiN4YTsmIzk7ICAgQiAgICcvPgogICA8bm9ybUlkIGlkPScgJmFw b3M7ICAgJiN4MjA7JiMxMzsmI3hhOyYjOTsgICAmYXBvczsgJy8+CjwvZG9jPiIiIgoKZWc1ID0g IiIiPCFET0NUWVBFIGRvYyBbCjwhQVRUTElTVCBkb2MgYXR0ckV4dEVudCBFTlRJVFkgI0lNUExJ RUQ+CjwhRU5USVRZIGVudDEgIkhlbGxvIj4KPCFFTlRJVFkgZW50MiBTWVNURU0gIndvcmxkLnR4 dCI+CjwhRU5USVRZIGVudEV4dCBTWVNURU0gImVhcnRoLmdpZiIgTkRBVEEgZ2lmPgo8IU5PVEFU SU9OIGdpZiBTWVNURU0gInZpZXdnaWYuZXhlIj4KXT4KPGRvYyBhdHRyRXh0RW50PSJlbnRFeHQi PgogICAmZW50MTssICZlbnQyOyEKPC9kb2M+Cgo8IS0tIExldCB3b3JsZC50eHQgY29udGFpbiAi d29ybGQiIChleGNsdWRpbmcgdGhlIHF1b3RlcykgLS0+CiIiIgoKZWc2ID0gIiIiPD94bWwgdmVy c2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8ZG9jPiYjMTY5OzwvZG9jPiIiIgoK ZWc3ID0gIiIiPCFET0NUWVBFIGRvYyBbCjwhQVRUTElTVCBlMiB4bWw6c3BhY2UgKGRlZmF1bHR8 cHJlc2VydmUpICdwcmVzZXJ2ZSc+CjwhQVRUTElTVCBlMyBpZCBJRCAjSU1QTElFRD4KXT4KPGRv YyB4bWxucz0iaHR0cDovL3d3dy5pZXRmLm9yZyIgeG1sbnM6dzNjPSJodHRwOi8vd3d3LnczLm9y ZyI+CiAgIDxlMT4KICAgICAgPGUyIHhtbG5zPSIiPgogICAgICAgICA8ZTMgaWQ9IkUzIi8+CiAg ICAgIDwvZTI+CiAgIDwvZTE+CjwvZG9jPiIiIgoKZXhhbXBsZXMgPSBbIGVnMSwgZWcyLCBlZzMs IGVnNCwgZWc1LCBlZzYsIGVnNyBdCnRlc3RfcmVzdWx0cyA9IHsKICAgIGVnMTogJycnUEQ5NGJX d3RjM1I1YkdWemFHVmxkQ0JvY21WbVBTSmtiMk11ZUhOc0lnb2dJQ0IwZVhCbFBTSjBaWGgwTDNo egogICAgYkNJZ0lDQS9QZ284Wkc5alBraGxiR3h2TENCM2IzSnNaQ0U4SVMwdElFTnZiVzFsYm5R Z01Rb3RMVDQ4TDJSdgogICAgWXo0S1BEOXdhUzEzYVhSb2IzVjBMV1JoZEdFL1BnbzhJUzB0SUVO dmJXMWxiblFnTWlBdExUNEtQQ0V0TFNCRAogICAgYjIxdFpXNTBJRE1nTFMwKycnJywKCiAgICBl ZzI6ICcnJ1BHUnZZejRLSUNBZ1BHTnNaV0Z1UGlBZ0lEd3ZZMnhsWVc0K0NpQWdJRHhrYVhKMGVU NGdJQ0JCSUNBZ1FpQWcKICAgIElEd3ZaR2x5ZEhrK0NpQWdJRHh0YVhobFpENEtJQ0FnSUNBZ1FR b2dJQ0FnSUNBOFkyeGxZVzQrSUNBZ1BDOWoKICAgIGJHVmhiajRLSUNBZ0lDQWdRZ29nSUNBZ0lD QThaR2x5ZEhrK0lDQWdRU0FnSUVJZ0lDQThMMlJwY25SNVBnb2cKICAgIElDQWdJQ0JEQ2lBZ0lE d3ZiV2w0WldRK0Nqd3ZaRzlqUGc9PScnJywKCiAgICBlZzM6ICcnJ1BHUnZZeUI0Yld4dWN6cG1i Mjg5SW1oMGRIQTZMeTkzZDNjdVltRnlMbTl5WnlJK0NpQWdJRHhsTVQ0OEwyVXgKICAgIFBnb2dJ Q0E4WlRJK1BDOWxNajRLSUNBZ1BHVXpJR2xrUFNKbGJHVnRNeUlnYm1GdFpUMGlaV3hsYlRNaVBq d3YKICAgIFpUTStDaUFnSUR4bE5DQnBaRDBpWld4bGJUUWlJRzVoYldVOUltVnNaVzAwSWo0OEwy VTBQZ29nSUNBOFpUVWcKICAgIGVHMXNibk05SW1oMGRIQTZMeTlsZUdGdGNHeGxMbTl5WnlJZ2VH MXNibk02WVQwaWFIUjBjRG92TDNkM2R5NTMKICAgIE15NXZjbWNpSUhodGJHNXpPbUk5SW1oMGRI QTZMeTkzZDNjdWFXVjBaaTV2Y21jaUlHRjBkSEk5SWtrbmJTSWcKICAgIFlYUjBjakk5SW1Gc2JD SWdZanBoZEhSeVBTSnpiM0owWldRaUlHRTZZWFIwY2owaWIzVjBJajQ4TDJVMVBnb2cKICAgIElD QThaVFlnZUcxc2JuTTZZVDBpYUhSMGNEb3ZMM2QzZHk1M015NXZjbWNpUGdvZ0lDQWdJQ0FnUEdV M0lIaHQKICAgIGJHNXpQU0pvZEhSd09pOHZkM2QzTG1sbGRHWXViM0puSWo0S0lDQWdJQ0FnSUNB Z0lDQThaVGdnZUcxc2JuTTkKICAgIElpSWdZVHBtYjI4OUltSmhjaUkrQ2lBZ0lDQWdJQ0FnSUNB Z0lDQWdJRHhsT1NCNGJXeHVjenBoUFNKb2RIUncKICAgIE9pOHZkM2QzTG1sbGRHWXViM0puSWlC aGRIUnlQU0prWldaaGRXeDBJajQ4TDJVNVBnb2dJQ0FnSUNBZ0lDQWcKICAgIElEd3ZaVGcrQ2lB Z0lDQWdJQ0E4TDJVM1Bnb2dJQ0E4TDJVMlBnbzhMMlJ2WXo0PScnJywKCiAgICBlZzQ6ICcnJ1BH UnZZejRLSUNBZ1BIUmxlSFErUm1seWMzUWdiR2x1WlNZamVFUTdDbE5sWTI5dVpDQnNhVzVsUEM5 MFpYaDAKICAgIFBnb2dJQ0E4ZG1Gc2RXVStNand2ZG1Gc2RXVStDaUFnSUR4amIyMXdkWFJsUG5a aGJIVmxKbWQwT3lJd0lpQW0KICAgIFlXMXdPeVpoYlhBN0lIWmhiSFZsSm14ME95SXhNQ0lnUHlK MllXeHBaQ0k2SW1WeWNtOXlJand2WTI5dGNIVjAKICAgIFpUNEtJQ0FnUEdOdmJYQjFkR1VnWlho d2NqMGlkbUZzZFdVK0puRjFiM1E3TUNaeGRXOTBPeUFtWVcxd095WmgKICAgIGJYQTdJSFpoYkhW bEpteDBPeVp4ZFc5ME96RXdKbkYxYjNRN0lEOG1jWFZ2ZER0MllXeHBaQ1p4ZFc5ME96b20KICAg IGNYVnZkRHRsY25KdmNpWnhkVzkwT3lJK2RtRnNhV1E4TDJOdmJYQjFkR1UrQ2lBZ0lEeHViM0p0 SUdGMGRISTkKICAgIElpQW5JQ0FnSUNZamVFUW1JM2hCSmlONE9TQWdJQ2NnSWo0OEwyNXZjbTAr Q2lBZ0lEeHViM0p0VG1GdFpYTWcKICAgIFlYUjBjajBpUVNBbUkzaEVKaU40UVNZamVEa2dRaUkr UEM5dWIzSnRUbUZ0WlhNK0NpQWdJRHh1YjNKdFNXUWcKICAgIGFXUTlJaWNnSmlONFJDWWplRUVt STNnNUlDY2lQand2Ym05eWJVbGtQZ284TDJSdll6ND0nJycsCgogICAgZWc1OiAnJydQR1J2WXlC aGRIUnlSWGgwUlc1MFBTSmxiblJGZUhRaVBnb2dJQ0JJWld4c2J5d2dkMjl5YkdRaENqd3ZaRzlq CiAgICBQZz09JycnLAoKICAgIGVnNjogJycnUEdSdll6N0NxVHd2Wkc5alBnPT0nJycsCgogICAg ZWc3OiAnJydQR1J2WXlCNGJXeHVjejBpYUhSMGNEb3ZMM2QzZHk1cFpYUm1MbTl5WnlJZ2VHMXNi bk02ZHpOalBTSm9kSFJ3CiAgICBPaTh2ZDNkM0xuY3pMbTl5WnlJK0NpQWdJRHhsTVQ0S0lDQWdJ Q0FnUEdVeUlIaHRiRzV6UFNJaUlIaHRiRHB6CiAgICBjR0ZqWlQwaWNISmxjMlZ5ZG1VaVBnb2dJ Q0FnSUNBZ0lDQThaVE1nYVdROUlrVXpJajQ4TDJVelBnb2dJQ0FnCiAgICBJQ0E4TDJVeVBnb2dJ Q0E4TDJVeFBnbzhMMlJ2WXo0PScnJywKfQoKIyBMb2FkIFhQYXRoIGFuZCBQYXJzZXIKaW1wb3J0 IHN5cywgdHlwZXMsIHRyYWNlYmFjaywgU3RyaW5nSU8sIGJhc2U2NCwgc3RyaW5nCmZyb20geG1s IGltcG9ydCB4cGF0aApmcm9tIHhtbC54cGF0aC5Db250ZXh0IGltcG9ydCBDb250ZXh0CmZyb20g eG1sLmRvbS5leHQucmVhZGVyIGltcG9ydCBQeUV4cGF0CmZyb20gYzE0biBpbXBvcnQgQ2Fub25p Y2FsaXplCiNmcm9tIHhtbC5kb20uZXh0IGltcG9ydCBDYW5vbmljYWxpemUKCiMgTXkgc3BlY2lh bCByZWFkZXIuClBZRSA9IFB5RXhwYXQuUmVhZGVyCmNsYXNzIFJlYWRlcmZvckMxNE5FeGFtcGxl cyhQWUUpOgogICAgJycnQSBzcGVjaWFsIHJlYWRlciB0byBoYW5kbGUgcmVzb2x1dGlvbiBvZiB0 aGUgQzE0TiBleGFtcGxlcy4KICAgICcnJwogICAgZGVmIGluaXRQYXJzZXIoc2VsZik6CiAgICAg ICAgUFlFLmluaXRQYXJzZXIoc2VsZikKICAgICAgICBzZWxmLnBhcnNlci5FeHRlcm5hbEVudGl0 eVJlZkhhbmRsZXIgPSBzZWxmLmVudGl0eV9yZWYKCiAgICBkZWYgZW50aXR5X3JlZihzZWxmLCAq YXJncyk6CiAgICAgICAgaWYgYXJncyAhPSAodSgnZW50MicpLCBOb25lLCB1KCd3b3JsZC50eHQn KSwgTm9uZSk6IHJldHVybiAwCiAgICAgICAgc2VsZi5wYXJzZXIuQ2hhcmFjdGVyRGF0YUhhbmRs ZXIoJ3dvcmxkJykKICAgICAgICByZXR1cm4gMQoKICAgICMgT3ZlcnJpZGUgc29tZSBtZXRob2Rz IGZyb20gUHlFeHBhdC5SZWFkZXIKICAgIGRlZiB1bnBhcnNlZEVudGl0eURlY2woc2VsZiwgKmFy Z3MpOiBwYXNzCiAgICBkZWYgbm90YXRpb25EZWNsKHNlbGYsICphcmdzKTogcGFzcwoKCnRyeToK ICAgIGltcG9ydCBjb2RlY3MKICAgIHV0Zjhfd3JpdGVyID0gY29kZWNzLmxvb2t1cCgndXRmLTgn KVszXQpleGNlcHQgSW1wb3J0RXJyb3I6CiAgICBkZWYgdXRmOF93cml0ZXIocyk6CiAgICAgICAg cmV0dXJuIHMKCmRlZiBidWlsdGluKCk6CiAgICAnJydSdW4gdGhlIGJ1aWx0aW4gdGVzdHMgZnJv bSB0aGUgQzE0TiBzcGVjLicnJwogICAgZm9yIGkgaW4gcmFuZ2UobGVuKGV4YW1wbGVzKSk6CiAg ICAgICAgbnVtID0gaSsxCiAgICAgICAgZWcgPSBleGFtcGxlc1tpXQoKICAgICAgICBmaWxlbmFt ZSA9ICdvdXQlZC54bWwnICUgbnVtCiAgICAgICAgdHJ5OgogICAgICAgICAgICBvcy51bmxpbmso ZmlsZW5hbWUpCiAgICAgICAgZXhjZXB0OgogICAgICAgICAgICBwYXNzCgogICAgICAgIHByaW50 ICdEb2luZyAlZCwgJXMuLi4nICUgKG51bSwgc3RyaW5nLnJlcGxhY2UoZWdbMDozMF0sICdcbics ICdcXG4nKSksCgogICAgICAgIHIgPSBSZWFkZXJmb3JDMTRORXhhbXBsZXMoKQogICAgICAgIHRy eToKICAgICAgICAgICAgZG9tID0gci5mcm9tU3RyaW5nKGVnKQogICAgICAgIGV4Y2VwdCBFeGNl cHRpb24sIGU6CiAgICAgICAgICAgIHByaW50ICdcbkV4Y2VwdGlvbicsIHJlcHIoZSkKICAgICAg ICAgICAgdHJhY2ViYWNrLnByaW50X2V4YygpCiAgICAgICAgICAgIGNvbnRpbnVlCgogICAgICAg ICMgR2V0IHRoZSBub2Rlc2V0OyB0aGUgdGVzdHMgaGF2ZSBzb21lIHNwZWNpYWwgY2FzZXMuCiAg ICAgICAgaWYgZWcgPT0gZWc1OgogICAgICAgICAgICBwYXR0ZXJuID0gJygvLy4gfCAvL0AqIHwg Ly9uYW1lc3BhY2U6OiopW25vdCAoc2VsZjo6Y29tbWVudCgpKV0nCiAgICAgICAgZWxzZToKICAg ICAgICAgICAgcGF0dGVybiA9ICcoLy8uIHwgLy9AKiB8IC8vbmFtZXNwYWNlOjoqKScKICAgICAg ICBpZiBlZyA9PSBlZzc6CiAgICAgICAgICAgIGNvbiA9IENvbnRleHQoZG9tLCBwcm9jZXNzb3JO c3M9eydpZXRmJzogJ2h0dHA6Ly93d3cuaWV0Zi5vcmcnfSkKICAgICAgICBlbHNlOgogICAgICAg ICAgICBjb24gPSBDb250ZXh0KGRvbSkKICAgICAgICBub2RlbGlzdCA9IHhwYXRoLkV2YWx1YXRl KHBhdHRlcm4sIGNvbnRleHQ9Y29uKQoKICAgICAgICBzID0gU3RyaW5nSU8uU3RyaW5nSU8oKQog ICAgICAgIG91dGYgPSB1dGY4X3dyaXRlcihzKQoKICAgICAgICAjIENhbm9uaWNhbGl6ZSBhIERP TSB3aXRoIGEgZG9jdW1lbnQgc3Vic2V0IGxpc3QgYWNjb3JkaW5nIHRvIFhNTC1DMTROCiAgICAg ICAgaWYgZWcgPT0gZWcxOgogICAgICAgICAgICBDYW5vbmljYWxpemUoZG9tLCBvdXRmLCBzdWJz ZXQ9bm9kZWxpc3QsIGNvbW1lbnRzPTEpCiAgICAgICAgZWxzZToKICAgICAgICAgICAgQ2Fub25p Y2FsaXplKGRvbSwgb3V0Ziwgc3Vic2V0PW5vZGVsaXN0KQoKICAgICAgICBleHBlY3RlZCA9IGJh c2U2NC5kZWNvZGVzdHJpbmcodGVzdF9yZXN1bHRzW2VnXSkKICAgICAgICBpZiBzLmdldHZhbHVl KCkgPT0gZXhwZWN0ZWQ6CiAgICAgICAgICAgIHByaW50ICdPaycKICAgICAgICBlbHNlOgogICAg ICAgICAgICBwcmludCAnRXJyb3IhJwogICAgICAgICAgICBwcmludCAnR290OlxuJywgcy5nZXR2 YWx1ZSgpCiAgICAgICAgICAgIHByaW50ICdFeHBlY3RlZDpcbicsIGV4cGVjdGVkCgpkZWYgdXNh Z2UoKToKICAgIHByaW50ICcnJ09wdGlvbnMgYWNjZXB0ZWQ6CiAgICAtYiwgLS1idWlsdGluICAg ICAgICAgICAgUnVuIHRoZSBDMTROIGJ1aWx0aW4gdGVzdHMKICAgIC1lICAgICAgICAgICAgICAg ICAgICAgICBFeGNsdXNpdmUgQzE0TgogICAgLXAgICAgICAgICAgICAgICAgICAgICAgIEV4Y2x1 c2l2ZSBDMTROIGluY2x1c2l2ZSBwcmVmaXhlcwogICAgLW4gc3RyaW5nLCAgICAgICAgICAgICAg IEFkZGl0aW9uYWwgTlNQcmVmaXhlcyAod2hpdGVzcGFjZSBkZWxpbWl0ZWQpCiAgICAgICAgLS1u YW1lc3BhY2VzPXN0cmluZwogICAgLWkgZmlsZSwgLS1pbj1maWxlICAgICAgIFJlYWQgc3BlY2lm aWVkIGZpbGUqIChkZWZhdWx0IGlzIHN0ZGluKQogICAgLW8gZmlsZSwgLS1vdXQ9ZmlsZSAgICAg IFdyaXRlIHRvIHNwZWNpZmllZCBmaWxlKiAoZGVmYXVsdCBpcyBzdGRvdXQpCiAgICAtaCwgLS1o ZWxwICAgICAgICAgICAgICAgUHJpbnQgdGhpcyB0ZXh0CiAgICAteCBxdWVyeSwgLS14cGF0aD1x dWVyeSAgU3BlY2lmeSBhbiBYUEFUSCBub2RlbGlzdApJZiBmaWxlIChmb3IgaW5wdXQvb3V0cHV0 KSBpcyBsaWtlIHh4eCxuYW1lIHRoZW4geHh4IGlzIHVzZWQgYXMgYW4KZW5jb2RpbmcgKGUuZy4s ICJ1dGYtOCxmb28udHh0IikuCicnJwoKaWYgX19uYW1lX18gIT0gIl9fbWFpbl9fIjoKICAgIGJ1 aWx0aW4oKQplbHNlOgogICAgaWYgbGVuKHN5cy5hcmd2KSA9PSAxOiBzeXMuYXJndi5hcHBlbmQo Jy1iJykKCiAgICBpbXBvcnQgZ2V0b3B0CiAgICB0cnk6CiAgICAgICAgb3B0cywgYXJncyA9IGdl dG9wdC5nZXRvcHQoc3lzLmFyZ3ZbMTpdLCAiY2VoYmk6bzpuOnA6eDoiLAogICAgICAgICAgICBb ICJjb21tZW50cyIsICJleGNsdXNpdmUiLCAiaGVscCIsICJidWlsdGluIiwgCiAgICAgICAgICAg ICJpbj0iLCAib3V0PSIsICJuYW1lc3BhY2VzPSIsICJwcmVmaXhlcz0iLCAieHBhdGg9IiBdKQog ICAgZXhjZXB0IGdldG9wdC5HZXRvcHRFcnJvciwgZToKICAgICAgICBwcmludCBzeXMuYXJndlsw XSArICc6JywgZSwgJ1xuVHJ5IC0taGVscCBmb3IgaGVscC5cbicKICAgICAgICBzeXMuZXhpdCgx KQogICAgaWYgbGVuKGFyZ3MpOgogICAgICAgIHByaW50ICdObyBhcmd1bWVudHMsIG9ubHkgZmxh Z3MuIFRyeSAtLWhlbHAgZm9yIGhlbHAuJwogICAgICAgIHN5cy5leGl0KDEpCgoKICAgIElOLCBP VVQgPSBzeXMuc3RkaW4sIHN5cy5zdGRvdXQKICAgIHF1ZXJ5ID0gJygvLy4gfCAvL0AqIHwgLy9u YW1lc3BhY2U6OiopJwogICAgY29tbWVudHMgPSAwCiAgICBleGNsdXNpdmUsIHBmeGxpc3QgPSBO b25lLCBbXQogICAgbnNkaWN0ID0ge30KICAgIGZvciBvcHQsYXJnIGluIG9wdHM6CiAgICAgICAg aWYgb3B0IGluICgnLWgnLCAnLS1oZWxwJyk6CiAgICAgICAgICAgIHVzYWdlKCkKICAgICAgICAg ICAgc3lzLmV4aXQoMCkKICAgICAgICBpZiBvcHQgaW4gKCctYicsICctLWJ1aWx0aW4nKToKICAg ICAgICAgICAgYnVpbHRpbigpCiAgICAgICAgICAgIHN5cy5leGl0KDApCiAgICAgICAgZWxpZiBv cHQgaW4gKCctYycsICctLWNvbW1lbnRzJyk6CiAgICAgICAgICAgIGNvbW1lbnRzID0gMQogICAg ICAgIGVsaWYgb3B0IGluICgnLW4nLCAnLS1uYW1lc3BhY2VzJyk6CiAgICAgICAgICAgICMgY29u dmVydCBldmVyeSBwYWlyIG9mIHdoaXRlc3BhY2UgZGVsaW1pdGVkICB2YWx1ZXMgdG8gZGljdGlv bmFyeQogICAgICAgICAgICBuc2wgPSBhcmcuc3BsaXQoKQogICAgICAgICAgICBmb3IgaSBpbiBy YW5nZSgwLCBsZW4obnNsKSwgMik6CiAgICAgICAgICAgICAgICBuc2RpY3RbbnNsW2ldXSA9IG5z bFtpKzFdCiAgICAgICAgIyAgICBwcmludCAiTmFtZXNwYWNlIHByZWZpeCBhcmd1bWVudHMgaXMg bm90IHN1cHBvcnRlZCB5ZXQuIgogICAgICAgIGVsaWYgb3B0IGluICgnLWUnLCAnLS1leGNsdXNp dmUnKToKICAgICAgICAgICAgZXhjbHVzaXZlID0gMQogICAgICAgIGVsaWYgb3B0IGluICggJy1w JywgJy0tcHJlZml4ZXMnKToKICAgICAgICAgICAgcGZ4bGlzdCA9IGFyZy5zcGxpdCgnLCcpCiAg ICAgICAgZWxpZiBvcHQgaW4gKCctaScsICctLWluJyk6CiAgICAgICAgICAgIGlmIGFyZy5maW5k KCcsJykgPT0gLTE6CiAgICAgICAgICAgICAgICBJTiA9IG9wZW4oYXJnLCAncicpCiAgICAgICAg ICAgIGVsc2U6CiAgICAgICAgICAgICAgICBpbXBvcnQgY29kZWNzCiAgICAgICAgICAgICAgICBl bmNvZGluZywgZmlsZW5hbWUgPSBhcmcuc3BsaXQoJywnKQogICAgICAgICAgICAgICAgcmVhZGVy ID0gY29kZWNzLmxvb2t1cChlbmNvZGluZylbMl0KICAgICAgICAgICAgICAgIElOID0gcmVhZGVy KG9wZW4oZmlsZW5hbWUsICdyJykpCiAgICAgICAgZWxpZiBvcHQgaW4gKCctbycsICctLW91dCcp OgogICAgICAgICAgICBpZiBhcmcuZmluZCgnLCcpID09IC0xOgogICAgICAgICAgICAgICAgT1VU ID0gb3BlbihhcmcsICd3JykKICAgICAgICAgICAgZWxzZToKICAgICAgICAgICAgICAgIGltcG9y dCBjb2RlY3MKICAgICAgICAgICAgICAgIGVuY29kaW5nLCBmaWxlbmFtZSA9IGFyZy5zcGxpdCgn LCcpCiAgICAgICAgICAgICAgICB3cml0ZXIgPSBjb2RlY3MubG9va3VwKGVuY29kaW5nKVszXQog ICAgICAgICAgICAgICAgT1VUID0gd3JpdGVyKG9wZW4oZmlsZW5hbWUsICd3JykpCiAgICAgICAg ZWxpZiBvcHQgaW4gKCcteCcsICctLXhwYXRoJyk6CiAgICAgICAgICAgIHF1ZXJ5ID0gYXJnCiAg ICAgICAgICAgIAogICAgciA9IFBZRSgpCiAgICBkb20gPSByLmZyb21TdHJlYW0oSU4pCiAgICBj b250ZXh0ID0gQ29udGV4dChkb20sIHByb2Nlc3Nvck5zcz1uc2RpY3QpCiAgICBub2RlbGlzdCA9 IHhwYXRoLkV2YWx1YXRlKHF1ZXJ5LCBjb250ZXh0PWNvbnRleHQpCiAgICBpZiBleGNsdXNpdmU6 CiAgICAgICAgQ2Fub25pY2FsaXplKGRvbSwgT1VULCBzdWJzZXQ9bm9kZWxpc3QsIGNvbW1lbnRz PWNvbW1lbnRzLCB1bnN1cHByZXNzZWRQcmVmaXhlcz1wZnhsaXN0KQogICAgZWxzZToKICAgICAg ICBDYW5vbmljYWxpemUoZG9tLCBPVVQsIHN1YnNldD1ub2RlbGlzdCwgY29tbWVudHM9Y29tbWVu dHMpICMgICAgbnNkaWN0PW5zZGljdAogICAgT1VULmNsb3NlKCkK --------------Boundary-00=_JA8Q2531E7NEDBEUJMXV Content-Type: text/plain; charset="iso-8859-1"; name="c14n.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="c14n.py" IyEgL3Vzci9iaW4vZW52IHB5dGhvbgonJydYTUwgQ2Fub25pY2FsaXphdGlvbgoKVGhpcyBtb2R1 bGUgZ2VuZXJhdGVzIGNhbm9uaWNhbCBYTUwgb2YgYSBkb2N1bWVudCBvciBlbGVtZW50LgogICAg aHR0cDovL3d3dy53My5vcmcvVFIvMjAwMS9SRUMteG1sLWMxNG4tMjAwMTAzMTUKYW5kIGluY2x1 ZGVzIGEgcHJvdG90eXBlIG9mIGV4Y2x1c2l2ZSBjYW5vbmljYWxpemF0aW9uCiAgICBodHRwOi8v d3d3LnczLm9yZy9TaWduYXR1cmUvRHJhZnRzL3htbC1leGMtYzE0bgoKUmVxdWlyZXMgUHlYTUwg MC43LjAgb3IgbGF0ZXIuCgpLbm93biBpc3N1ZXMgaWYgdXNpbmcgRnQuTGliLnBEb21sZXR0ZToK ICAgIDEuIFVuaWNvZGUKICAgIDIuIGRvZXMgbm90IHdoaXRlIHNwYWNlIG5vcm1hbGl6ZSBhdHRy aWJ1dGVzIG9mIHR5cGUgTk1UT0tFTiBhbmQgSUQ/CiAgICAzLiBzZWVtcyB0byBiZSBpbmNsdWRl ICJcbiIgYWZ0ZXIgaW1wb3J0aW5nIGV4dGVybmFsIGVudGl0aWVzPwoKTm90ZSwgdGhpcyB2ZXJz aW9uIHByb2Nlc3NlcyBhIERPTSB0cmVlLCBhbmQgY29uc2VxdWVudGx5IGl0IHByb2Nlc3Nlcwpu YW1lc3BhY2Ugbm9kZXMgYXMgYXR0cmlidXRlcywgbm90IGZyb20gYSBub2RlJ3MgbmFtZXNwYWNl IGF4aXMuIFRoaXMKcGVybWl0cyBzaW1wbGUgZG9jdW1lbnQgYW5kIGVsZW1lbnQgY2Fub25pY2Fs aXphdGlvbiB3aXRob3V0ClhQYXRoLiBXaGVuIFhQYXRoIGlzIHVzZWQsIHRoZSBYUGF0aCByZXN1 bHQgbm9kZSBsaXN0IGlzIHBhc3NlZCBhbmQgdXNlZCB0bwpkZXRlcm1pbmUgaWYgdGhlIG5vZGUg aXMgaW4gdGhlIFhQYXRoIHJlc3VsdCBsaXN0LCBidXQgbGl0dGxlIGVsc2UuCgpBdXRob3JzOgog ICAgIkpvc2VwaCBNLiBSZWFnbGUgSnIuIiA8cmVhZ2xlQHczLm9yZz4KICAgICJSaWNoIFNhbHoi IDxyc2FsekB6b2xlcmEuY29tPgoKJERhdGU6IDIwMDIvMDQvMTcgMTc6NTA6MDcgJCBieSAkQXV0 aG9yOiByZWFnbGUgJAonJycKCl9jb3B5cmlnaHQgPSAnJydDb3B5cmlnaHQgMjAwMSwgWm9sZXJh IFN5c3RlbXMgSW5jLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4KQ29weXJpZ2h0IDIwMDEsIE1JVC4g QWxsIFJpZ2h0cyBSZXNlcnZlZC4KCkRpc3RyaWJ1dGVkIHVuZGVyIHRoZSB0ZXJtcyBvZjoKICBQ eXRob24gMi4wIExpY2Vuc2Ugb3IgbGF0ZXIuCiAgaHR0cDovL3d3dy5weXRob24ub3JnLzIuMC4x L2xpY2Vuc2UuaHRtbApvcgogIFczQyBTb2Z0d2FyZSBMaWNlbnNlCiAgaHR0cDovL3d3dy53My5v cmcvQ29uc29ydGl1bS9MZWdhbC9jb3B5cmlnaHQtc29mdHdhcmUtMTk5ODA3MjAKJycnCgppbXBv cnQgc3RyaW5nCmZyb20geG1sLmRvbSBpbXBvcnQgTm9kZQp0cnk6CiAgICBmcm9tIHhtbC5ucyBp bXBvcnQgWE1MTlMKZXhjZXB0OgogICAgY2xhc3MgWE1MTlM6CiAgICAgICAgQkFTRSA9ICJodHRw Oi8vd3d3LnczLm9yZy8yMDAwL3htbG5zLyIKICAgICAgICBYTUwgPSAiaHR0cDovL3d3dy53My5v cmcvWE1MLzE5OTgvbmFtZXNwYWNlIgp0cnk6CiAgICBpbXBvcnQgY1N0cmluZ0lPCiAgICBTdHJp bmdJTyA9IGNTdHJpbmdJTwpleGNlcHQgSW1wb3J0RXJyb3I6CiAgICBpbXBvcnQgU3RyaW5nSU8K Cl9hdHRycyA9IGxhbWJkYSBFOiAoRS5hdHRyaWJ1dGVzIGFuZCBFLmF0dHJpYnV0ZXMudmFsdWVz KCkpIG9yIFtdCl9jaGlsZHJlbiA9IGxhbWJkYSBFOiBFLmNoaWxkTm9kZXMgb3IgW10KX0lOX1hN TF9OUyA9IGxhbWJkYSBuOiBuLm5hbWVzcGFjZVVSSSA9PSBYTUxOUy5YTUwKCiMgRG9lcyBhIGRv Y3VtZW50L1BJIGhhcyBsZXNzZXIvZ3JlYXRlciBkb2N1bWVudCBvcmRlciB0aGFuIHRoZQojIGZp cnN0IGVsZW1lbnQ/Cl9MZXNzZXJFbGVtZW50LCBfRWxlbWVudCwgX0dyZWF0ZXJFbGVtZW50ID0g cmFuZ2UoMykKCmRlZiBfc29ydGVyKG4xLG4yKToKICAgICcnJ19zb3J0ZXIobjEsbjIpIC0+IGlu dAogICAgU29ydGluZyBwcmVkaWNhdGUgZm9yIG5vbi1OUyBhdHRyaWJ1dGVzLicnJwoKICAgIGkg PSBjbXAobjEubmFtZXNwYWNlVVJJLCBuMi5uYW1lc3BhY2VVUkkpCiAgICBpZiBpOiByZXR1cm4g aQogICAgcmV0dXJuIGNtcChuMS5sb2NhbE5hbWUsIG4yLmxvY2FsTmFtZSkKCgpkZWYgX3NvcnRl cl9ucyhuMSxuMik6CiAgICAnJydfc29ydGVyX25zKChuLHYpLChuLHYpKSAtPiBpbnQKICAgICIo YW4gZW1wdHkgbmFtZXNwYWNlIFVSSSBpcyBsZXhpY29ncmFwaGljYWxseSBsZWFzdCkuIicnJwoK ICAgIGlmIG4xWzBdID09ICd4bWxucyc6IHJldHVybiAtMQogICAgaWYgbjJbMF0gPT0gJ3htbG5z JzogcmV0dXJuIDEKICAgIHJldHVybiBjbXAobjFbMF0sIG4yWzBdKQoKZGVmIF91dGlsaXplZChu LCBub2RlLCBvdGhlcl9hdHRycywgdW5zdXBwcmVzc2VkUHJlZml4ZXMpOgogICAgJycnX3V0aWxp emVkKG4sIG5vZGUsIG90aGVyX2F0dHJzLCB1bnN1cHByZXNzZWRQcmVmaXhlcykgLT4gYm9vbGVh bgogICAgUmV0dXJuIHRydWUgaWYgdGhhdCBub2Rlc3BhY2UgaXMgdXRpbGl6ZWQgd2l0aGluIHRo ZSBub2RlJycnCgogICAgaWYgbi5zdGFydHN3aXRoKCd4bWxuczonKToKICAgICAgICBuID0gbls2 Ol0KICAgIGVsaWYgbi5zdGFydHN3aXRoKCd4bWxucycpOgogICAgICAgIG4gPSBuWzU6XQogICAg aWYgKG49PSIiIGFuZCBub2RlLnByZWZpeCBpbiBbIiNkZWZhdWx0IiwgTm9uZV0pIG9yIFwKICAg ICAgICBuID09IG5vZGUucHJlZml4IG9yIG4gaW4gdW5zdXBwcmVzc2VkUHJlZml4ZXM6IAogICAg ICAgICAgICByZXR1cm4gMQogICAgZm9yIGF0dHIgaW4gb3RoZXJfYXR0cnM6CiAgICAgICAgaWYg biA9PSBhdHRyLnByZWZpeDogcmV0dXJuIDEKICAgIHJldHVybiAwCgojX2luX3N1YnNldCA9IGxh bWJkYSBzdWJzZXQsIG5vZGU6IG5vdCBzdWJzZXQgb3Igbm9kZSBpbiBzdWJzZXQKX2luX3N1YnNl dCA9IGxhbWJkYSBzdWJzZXQsIG5vZGU6IHN1YnNldCBpcyBOb25lIG9yIG5vZGUgaW4gc3Vic2V0 ICMgcmljaCdzIHR3ZWFrCgpjbGFzcyBfaW1wbGVtZW50YXRpb246CiAgICAnJydJbXBsZW1lbnRh dGlvbiBjbGFzcyBmb3IgQzE0Ti4gVGhpcyBhY2NvbXBhbmllcyBhIG5vZGUgZHVyaW5nIGl0J3MK ICAgIHByb2Nlc3NpbmcgYW5kIGluY2x1ZGVzIHRoZSBwYXJhbWV0ZXJzIGFuZCBwcm9jZXNzaW5n IHN0YXRlLicnJwoKICAgICMgSGFuZGxlciBmb3IgZWFjaCBub2RlIHR5cGU7IHBvcHVsYXRlZCBk dXJpbmcgbW9kdWxlIGluc3RhbnRpYXRpb24uCiAgICBoYW5kbGVycyA9IHt9CgogICAgZGVmIF9f aW5pdF9fKHNlbGYsIG5vZGUsIHdyaXRlLCAqKmt3KToKICAgICAgICAnJydDcmVhdGUgYW5kIHJ1 biB0aGUgaW1wbGVtZW50YXRpb24uJycnCiAgICAgICAgc2VsZi53cml0ZSA9IHdyaXRlCiAgICAg ICAgc2VsZi5zdWJzZXQgPSBrdy5nZXQoJ3N1YnNldCcpCiAgICAgICAgc2VsZi5jb21tZW50cyA9 IGt3LmdldCgnY29tbWVudHMnLCAwKQogICAgICAgIHNlbGYudW5zdXBwcmVzc2VkUHJlZml4ZXMg PSBrdy5nZXQoJ3Vuc3VwcHJlc3NlZFByZWZpeGVzJykKICAgICAgICBuc2RpY3QgPSBrdy5nZXQo J25zZGljdCcsIHsgJ3htbCc6IFhNTE5TLlhNTCwgJ3htbG5zJzogWE1MTlMuQkFTRSB9KQogICAg ICAgIAogICAgICAgICMgUHJvY2Vzc2luZyBzdGF0ZS4KICAgICAgICBzZWxmLnN0YXRlID0gKG5z ZGljdCwgeyd4bWwnOicnfSwgW10pICMwNDE3CiAgICAgICAgCiAgICAgICAgaWYgbm9kZS5ub2Rl VHlwZSA9PSBOb2RlLkRPQ1VNRU5UX05PREU6CiAgICAgICAgICAgIHNlbGYuX2RvX2RvY3VtZW50 KG5vZGUpCiAgICAgICAgZWxpZiBub2RlLm5vZGVUeXBlID09IE5vZGUuRUxFTUVOVF9OT0RFOgog ICAgICAgICAgICBzZWxmLmRvY3VtZW50T3JkZXIgPSBfRWxlbWVudCAgICAgICAgIyBBdCBkb2N1 bWVudCBlbGVtZW50CiAgICAgICAgICAgIGlmIHNlbGYudW5zdXBwcmVzc2VkUHJlZml4ZXMgIT0g Tm9uZToKICAgICAgICAgICAgICAgIHNlbGYuX2RvX2VsZW1lbnQobm9kZSkKICAgICAgICAgICAg ZWxzZToKICAgICAgICAgICAgICAgIGluaGVyaXRlZCA9IHNlbGYuX2luaGVyaXRfY29udGV4dChu b2RlKQogICAgICAgICAgICAgICAgc2VsZi5fZG9fZWxlbWVudChub2RlLCBpbmhlcml0ZWQpCiAg ICAgICAgZWxpZiBub2RlLm5vZGVUeXBlID09IE5vZGUuRE9DVU1FTlRfVFlQRV9OT0RFOgogICAg ICAgICAgICBwYXNzCiAgICAgICAgZWxzZToKICAgICAgICAgICAgcmFpc2UgVHlwZUVycm9yLCBz dHIobm9kZSkKCgogICAgZGVmIF9pbmhlcml0X2NvbnRleHQoc2VsZiwgbm9kZSk6CiAgICAgICAg JycnX2luaGVyaXRfY29udGV4dChzZWxmLCBub2RlKSAtPiBsaXN0CiAgICAgICAgU2NhbiBhbmNl c3RvcnMgb2YgYXR0cmlidXRlIGFuZCBuYW1lc3BhY2UgY29udGV4dC4gIFVzZWQgb25seQogICAg ICAgIGZvciBzaW5nbGUgZWxlbWVudCBub2RlIGNhbm9uaWNhbGl6YXRpb24sIG5vdCBmb3Igc3Vi c2V0CiAgICAgICAgY2Fub25pY2FsaXphdGlvbi4nJycKCiAgICAgICAgIyBDb2xsZWN0IHRoZSBp bml0aWFsIGxpc3Qgb2YgeG1sOmZvbyBhdHRyaWJ1dGVzLgogICAgICAgIHhtbGF0dHJzID0gZmls dGVyKF9JTl9YTUxfTlMsIF9hdHRycyhub2RlKSkKCiAgICAgICAgIyBXYWxrIHVwIGFuZCBnZXQg YWxsIHhtbDpYWFggYXR0cmlidXRlcyB3ZSBpbmhlcml0LgogICAgICAgIGluaGVyaXRlZCwgcGFy ZW50ID0gW10sIG5vZGUucGFyZW50Tm9kZQogICAgICAgIHdoaWxlIHBhcmVudCBhbmQgcGFyZW50 Lm5vZGVUeXBlID09IE5vZGUuRUxFTUVOVF9OT0RFOgogICAgICAgICAgICBmb3IgYSBpbiBmaWx0 ZXIoX0lOX1hNTF9OUywgX2F0dHJzKHBhcmVudCkpOgogICAgICAgICAgICAgICAgbiA9IGEubG9j YWxOYW1lCiAgICAgICAgICAgICAgICBpZiBuIG5vdCBpbiB4bWxhdHRyczoKICAgICAgICAgICAg ICAgICAgICB4bWxhdHRycy5hcHBlbmQobikKICAgICAgICAgICAgICAgICAgICBpbmhlcml0ZWQu YXBwZW5kKGEpCiAgICAgICAgICAgIHBhcmVudCA9IHBhcmVudC5wYXJlbnROb2RlCiAgICAgICAg cmV0dXJuIGluaGVyaXRlZAoKCiAgICBkZWYgX2RvX2RvY3VtZW50KHNlbGYsIG5vZGUpOgogICAg ICAgICcnJ19kb19kb2N1bWVudChzZWxmLCBub2RlKSAtPiBOb25lCiAgICAgICAgUHJvY2VzcyBh IGRvY3VtZW50IG5vZGUuIGRvY3VtZW50T3JkZXIgaG9sZHMgd2hldGhlciB0aGUgZG9jdW1lbnQK ICAgICAgICBlbGVtZW50IGhhcyBiZWVuIGVuY291bnRlcmVkIHN1Y2ggdGhhdCBQSXMvY29tbWVu dHMgY2FuIGJlIHdyaXR0ZW4KICAgICAgICBhcyBzcGVjaWZpZWQuJycnCgogICAgICAgIHNlbGYu ZG9jdW1lbnRPcmRlciA9IF9MZXNzZXJFbGVtZW50CiAgICAgICAgZm9yIGNoaWxkIGluIG5vZGUu Y2hpbGROb2RlczoKICAgICAgICAgICAgaWYgY2hpbGQubm9kZVR5cGUgPT0gTm9kZS5FTEVNRU5U X05PREU6CiAgICAgICAgICAgICAgICBzZWxmLmRvY3VtZW50T3JkZXIgPSBfRWxlbWVudCAgICAg ICAgIyBBdCBkb2N1bWVudCBlbGVtZW50CiAgICAgICAgICAgICAgICBzZWxmLl9kb19lbGVtZW50 KGNoaWxkKQogICAgICAgICAgICAgICAgc2VsZi5kb2N1bWVudE9yZGVyID0gX0dyZWF0ZXJFbGVt ZW50ICMgQWZ0ZXIgZG9jdW1lbnQgZWxlbWVudAogICAgICAgICAgICBlbGlmIGNoaWxkLm5vZGVU eXBlID09IE5vZGUuUFJPQ0VTU0lOR19JTlNUUlVDVElPTl9OT0RFOgogICAgICAgICAgICAgICAg c2VsZi5fZG9fcGkoY2hpbGQpCiAgICAgICAgICAgIGVsaWYgY2hpbGQubm9kZVR5cGUgPT0gTm9k ZS5DT01NRU5UX05PREU6CiAgICAgICAgICAgICAgICBzZWxmLl9kb19jb21tZW50KGNoaWxkKQog ICAgICAgICAgICBlbGlmIGNoaWxkLm5vZGVUeXBlID09IE5vZGUuRE9DVU1FTlRfVFlQRV9OT0RF OgogICAgICAgICAgICAgICAgcGFzcwogICAgICAgICAgICBlbHNlOgogICAgICAgICAgICAgICAg cmFpc2UgVHlwZUVycm9yLCBzdHIoY2hpbGQpCiAgICBoYW5kbGVyc1tOb2RlLkRPQ1VNRU5UX05P REVdID0gX2RvX2RvY3VtZW50CgoKICAgIGRlZiBfZG9fdGV4dChzZWxmLCBub2RlKToKICAgICAg ICAnJydfZG9fdGV4dChzZWxmLCBub2RlKSAtPiBOb25lCiAgICAgICAgUHJvY2VzcyBhIHRleHQg b3IgQ0RBVEEgbm9kZS4gIFJlbmRlciB2YXJpb3VzIHNwZWNpYWwgY2hhcmFjdGVycwogICAgICAg IGFzIHRoZWlyIEMxNE4gZW50aXR5IHJlcHJlc2VudGF0aW9ucy4nJycKICAgICAgICBpZiBub3Qg X2luX3N1YnNldChzZWxmLnN1YnNldCwgbm9kZSk6IHJldHVybgogICAgICAgIHMgPSBzdHJpbmcu cmVwbGFjZShub2RlLmRhdGEsICImIiwgIiZhbXA7IikKICAgICAgICBzID0gc3RyaW5nLnJlcGxh Y2UocywgIjwiLCAiJmx0OyIpCiAgICAgICAgcyA9IHN0cmluZy5yZXBsYWNlKHMsICI+IiwgIiZn dDsiKQogICAgICAgIHMgPSBzdHJpbmcucmVwbGFjZShzLCAiXDAxNSIsICImI3hEOyIpCiAgICAg ICAgaWYgczogc2VsZi53cml0ZShzKQogICAgaGFuZGxlcnNbTm9kZS5URVhUX05PREVdID0gX2Rv X3RleHQKICAgIGhhbmRsZXJzW05vZGUuQ0RBVEFfU0VDVElPTl9OT0RFXSA9IF9kb190ZXh0CgoK ICAgIGRlZiBfZG9fcGkoc2VsZiwgbm9kZSk6CiAgICAgICAgJycnX2RvX3BpKHNlbGYsIG5vZGUp IC0+IE5vbmUKICAgICAgICBQcm9jZXNzIGEgUEkgbm9kZS4gUmVuZGVyIGEgbGVhZGluZyBvciB0 cmFpbGluZyAjeEEgaWYgdGhlCiAgICAgICAgZG9jdW1lbnQgb3JkZXIgb2YgdGhlIFBJIGlzIGdy ZWF0ZXIgb3IgbGVzc2VyIChyZXNwZWN0aXZlbHkpCiAgICAgICAgdGhhbiB0aGUgZG9jdW1lbnQg ZWxlbWVudC4KICAgICAgICAnJycKICAgICAgICBpZiBub3QgX2luX3N1YnNldChzZWxmLnN1YnNl dCwgbm9kZSk6IHJldHVybgogICAgICAgIFcgPSBzZWxmLndyaXRlCiAgICAgICAgaWYgc2VsZi5k b2N1bWVudE9yZGVyID09IF9HcmVhdGVyRWxlbWVudDogVygnXG4nKQogICAgICAgIFcoJzw/JykK ICAgICAgICBXKG5vZGUubm9kZU5hbWUpCiAgICAgICAgcyA9IG5vZGUuZGF0YQogICAgICAgIGlm IHM6CiAgICAgICAgICAgIFcoJyAnKQogICAgICAgICAgICBXKHMpCiAgICAgICAgVygnPz4nKQog ICAgICAgIGlmIHNlbGYuZG9jdW1lbnRPcmRlciA9PSBfTGVzc2VyRWxlbWVudDogVygnXG4nKQog ICAgaGFuZGxlcnNbTm9kZS5QUk9DRVNTSU5HX0lOU1RSVUNUSU9OX05PREVdID0gX2RvX3BpCgoK ICAgIGRlZiBfZG9fY29tbWVudChzZWxmLCBub2RlKToKICAgICAgICAnJydfZG9fY29tbWVudChz ZWxmLCBub2RlKSAtPiBOb25lCiAgICAgICAgUHJvY2VzcyBhIGNvbW1lbnQgbm9kZS4gUmVuZGVy IGEgbGVhZGluZyBvciB0cmFpbGluZyAjeEEgaWYgdGhlCiAgICAgICAgZG9jdW1lbnQgb3JkZXIg b2YgdGhlIGNvbW1lbnQgaXMgZ3JlYXRlciBvciBsZXNzZXIgKHJlc3BlY3RpdmVseSkKICAgICAg ICB0aGFuIHRoZSBkb2N1bWVudCBlbGVtZW50LgogICAgICAgICcnJwogICAgICAgIGlmIG5vdCBf aW5fc3Vic2V0KHNlbGYuc3Vic2V0LCBub2RlKTogcmV0dXJuCiAgICAgICAgaWYgc2VsZi5jb21t ZW50czoKICAgICAgICAgICAgVyA9IHNlbGYud3JpdGUKICAgICAgICAgICAgaWYgc2VsZi5kb2N1 bWVudE9yZGVyID09IF9HcmVhdGVyRWxlbWVudDogVygnXG4nKQogICAgICAgICAgICBXKCc8IS0t JykKICAgICAgICAgICAgVyhub2RlLmRhdGEpCiAgICAgICAgICAgIFcoJy0tPicpCiAgICAgICAg ICAgIGlmIHNlbGYuZG9jdW1lbnRPcmRlciA9PSBfTGVzc2VyRWxlbWVudDogVygnXG4nKQogICAg aGFuZGxlcnNbTm9kZS5DT01NRU5UX05PREVdID0gX2RvX2NvbW1lbnQKCgogICAgZGVmIF9kb19h dHRyKHNlbGYsIG4sIHZhbHVlKToKICAgICAgICAnJycnX2RvX2F0dHIoc2VsZiwgbm9kZSkgLT4g Tm9uZQogICAgICAgIFByb2Nlc3MgYW4gYXR0cmlidXRlLicnJwoKICAgICAgICBXID0gc2VsZi53 cml0ZQogICAgICAgIFcoJyAnKQogICAgICAgIFcobikKICAgICAgICBXKCc9IicpCiAgICAgICAg cyA9IHN0cmluZy5yZXBsYWNlKHZhbHVlLCAiJiIsICImYW1wOyIpCiAgICAgICAgcyA9IHN0cmlu Zy5yZXBsYWNlKHMsICI8IiwgIiZsdDsiKQogICAgICAgIHMgPSBzdHJpbmcucmVwbGFjZShzLCAn IicsICcmcXVvdDsnKQogICAgICAgIHMgPSBzdHJpbmcucmVwbGFjZShzLCAnXDAxMScsICcmI3g5 JykKICAgICAgICBzID0gc3RyaW5nLnJlcGxhY2UocywgJ1wwMTInLCAnJiN4QScpCiAgICAgICAg cyA9IHN0cmluZy5yZXBsYWNlKHMsICdcMDE1JywgJyYjeEQnKQogICAgICAgIFcocykKICAgICAg ICBXKCciJykKCgogICAgZGVmIF9kb19lbGVtZW50KHNlbGYsIG5vZGUsIGluaXRpYWxfb3RoZXJf YXR0cnMgPSBbXSk6CiAgICAgICAgJycnX2RvX2VsZW1lbnQoc2VsZiwgbm9kZSwgaW5pdGlhbF9v dGhlcl9hdHRycyA9IFtdKSAtPiBOb25lCiAgICAgICAgUHJvY2VzcyBhbiBlbGVtZW50IChhbmQg aXRzIGNoaWxkcmVuKS4nJycKCiAgICAgICAgIyBHZXQgc3RhdGUgKGZyb20gdGhlIHN0YWNrKSBt YWtlIGxvY2FsIGNvcGllcy4KICAgICAgICAjICAgICAgICBuc19wYXJlbnQgLS0gTlMgZGVjbGFy YXRpb25zIGluIHBhcmVudAogICAgICAgICMgICAgICAgIG5zX3JlbmRlcmVkIC0tIE5TIG5vZGVz IHJlbmRlcmVkIGJ5IGFuY2VzdG9ycwogICAgICAgICMgICAgICAgIHhtbF9hdHRycyAtLSBBdHRy aWJ1dGVzIGluIFhNTCBuYW1lc3BhY2UgZnJvbSBwYXJlbnQKICAgICAgICAjICAgICAgICBuc19s b2NhbCAtLSBOUyBkZWNsYXJhdGlvbnMgcmVsZXZhbnQgdG8gdGhpcyBlbGVtZW50CiAgICAgICAg bnNfcGFyZW50LCBuc19yZW5kZXJlZCwgeG1sX2F0dHJzID0gXAogICAgICAgICAgICAgICAgc2Vs Zi5zdGF0ZVswXSwgc2VsZi5zdGF0ZVsxXS5jb3B5KCksIHNlbGYuc3RhdGVbMl1bOl0gIzA0MTcK ICAgICAgICBuc19sb2NhbCA9IG5zX3BhcmVudC5jb3B5KCkKCiAgICAgICAgIyBEaXZpZGUgYXR0 cmlidXRlcyBpbnRvIE5TLCBYTUwsIGFuZCBvdGhlcnMuCiAgICAgICAgb3RoZXJfYXR0cnMgPSBp bml0aWFsX290aGVyX2F0dHJzWzpdCiAgICAgICAgaW5fc3Vic2V0ID0gX2luX3N1YnNldChzZWxm LnN1YnNldCwgbm9kZSkKICAgICAgICBmb3IgYSBpbiBfYXR0cnMobm9kZSk6CiAgICAgICAgICAg IGlmIGEubmFtZXNwYWNlVVJJID09IFhNTE5TLkJBU0U6CiAgICAgICAgICAgICAgICBuID0gYS5u b2RlTmFtZQogICAgICAgICAgICAgICAgaWYgbiA9PSAieG1sbnM6IjogbiA9ICJ4bWxucyIgICAg ICAgICMgRE9NIGJ1ZyB3b3JrYXJvdW5kCiAgICAgICAgICAgICAgICBuc19sb2NhbFtuXSA9IGEu bm9kZVZhbHVlCiAgICAgICAgICAgIGVsaWYgYS5uYW1lc3BhY2VVUkkgPT0gWE1MTlMuWE1MOgog ICAgICAgICAgICAgICAgaWYgc2VsZi51bnN1cHByZXNzZWRQcmVmaXhlcyA9PSBOb25lIG9yIGlu X3N1YnNldDoKICAgICAgICAgICAgICAgICAgICB4bWxfYXR0cnMuYXBwZW5kKGEpCiAgICAgICAg ICAgIGVsc2U6CiAgICAgICAgICAgICAgICBvdGhlcl9hdHRycy5hcHBlbmQoYSkKCiAgICAgICAg IyBSZW5kZXIgdGhlIG5vZGUKICAgICAgICBXLCBuYW1lID0gc2VsZi53cml0ZSwgTm9uZQogICAg ICAgIGlmIGluX3N1YnNldDoKICAgICAgICAgICAgbmFtZSA9IG5vZGUubm9kZU5hbWUKICAgICAg ICAgICAgVygnPCcpCiAgICAgICAgICAgIFcobmFtZSkKCiAgICAgICAgICAgICMgQ3JlYXRlIGxp c3Qgb2YgTlMgYXR0cmlidXRlcyB0byByZW5kZXIuCiAgICAgICAgICAgIG5zX3RvX3JlbmRlciA9 IFtdCiAgICAgICAgICAgIGZvciBuLHYgaW4gbnNfbG9jYWwuaXRlbXMoKToKICAgICAgICAgICAg ICAgIHB2YWwgPSBuc19wYXJlbnQuZ2V0KG4pCgogICAgICAgICAgICAgICAgIyBJZiBkZWZhdWx0 IG5hbWVzcGFjZSBpcyBYTUxOUy5CQVNFIG9yIGVtcHR5LAogICAgICAgICAgICAgICAgIyBhbmQg aWYgYW4gYW5jZXN0b3Igd2FzIHRoZSBzYW1lCiAgICAgICAgICAgICAgICBpZiBuID09ICJ4bWxu cyIgYW5kIHYgaW4gWyBYTUxOUy5CQVNFLCAnJyBdIFwKICAgICAgICAgICAgICAgIGFuZCBuc19y ZW5kZXJlZC5nZXQoJ3htbG5zJykgaW4gWyBYTUxOUy5CQVNFLCAnJywgTm9uZSBdOgogICAgICAg ICAgICAgICAgICAgIGNvbnRpbnVlCgogICAgICAgICAgICAgICAgIyAib21pdCBuYW1lc3BhY2Ug bm9kZSB3aXRoIGxvY2FsIG5hbWUgeG1sLCB3aGljaCBkZWZpbmVzCiAgICAgICAgICAgICAgICAj IHRoZSB4bWwgcHJlZml4LCBpZiBpdHMgc3RyaW5nIHZhbHVlIGlzCiAgICAgICAgICAgICAgICAj IGh0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25hbWVzcGFjZS4iCiAgICAgICAgICAgICAgICBp ZiBuIGluIFsieG1sbnM6eG1sIiwgInhtbCJdIFwKICAgICAgICAgICAgICAgIGFuZCB2IGluIFsg J2h0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25hbWVzcGFjZScgXToKICAgICAgICAgICAgICAg ICAgICBjb250aW51ZQoKCiAgICAgICAgICAgICAgICAjIElmIG5vdCBwcmV2aW91c2x5IHJlbmRl cmVkCiAgICAgICAgICAgICAgICAjIGFuZCBpdCdzIGluY2x1c2l2ZSAoc2VsZi51bnN1cHByZXNz ZWRQcmVmaXhlcyA9PSBOb25lKSAgb3IgdXRpbGl6ZWQKICAgICAgICAgICAgICAgIGlmIChuLHYp IG5vdCBpbiBuc19yZW5kZXJlZC5pdGVtcygpIFwKICAgICAgICAgICAgICAgICAgYW5kIChzZWxm LnVuc3VwcHJlc3NlZFByZWZpeGVzID09IE5vbmUgb3IgXAogICAgICAgICAgICAgICAgICBfdXRp bGl6ZWQobiwgbm9kZSwgb3RoZXJfYXR0cnMsIHNlbGYudW5zdXBwcmVzc2VkUHJlZml4ZXMpKToK ICAgICAgICAgICAgICAgICAgICBuc190b19yZW5kZXIuYXBwZW5kKChuLCB2KSkKCiAgICAgICAg ICAgICMgU29ydCBhbmQgcmVuZGVyIHRoZSBucywgbWFya2luZyB3aGF0IHdhcyByZW5kZXJlZC4K ICAgICAgICAgICAgbnNfdG9fcmVuZGVyLnNvcnQoX3NvcnRlcl9ucykKICAgICAgICAgICAgZm9y IG4sdiBpbiBuc190b19yZW5kZXI6CiAgICAgICAgICAgICAgICBzZWxmLl9kb19hdHRyKG4sIHYp CiAgICAgICAgICAgICAgICBuc19yZW5kZXJlZFtuXT12ICAgICMwNDE3CgogICAgICAgICAgICAj IEFkZCBpbiB0aGUgWE1MIGF0dHJpYnV0ZXMgKGRvbid0IHBhc3MgdG8gY2hpbGRyZW4sIHNpbmNl CiAgICAgICAgICAgICMgd2UncmUgcmVuZGVyaW5nIHRoZW0pLCBzb3J0LCBhbmQgcmVuZGVyLgog ICAgICAgICAgICBvdGhlcl9hdHRycy5leHRlbmQoeG1sX2F0dHJzKQogICAgICAgICAgICB4bWxf YXR0cnMgPSBbXQogICAgICAgICAgICBvdGhlcl9hdHRycy5zb3J0KF9zb3J0ZXIpCiAgICAgICAg ICAgIGZvciBhIGluIG90aGVyX2F0dHJzOgogICAgICAgICAgICAgICAgc2VsZi5fZG9fYXR0cihh Lm5vZGVOYW1lLCBhLnZhbHVlKQogICAgICAgICAgICBXKCc+JykKCiAgICAgICAgIyBQdXNoIHN0 YXRlLCByZWN1cnNlLCBwb3Agc3RhdGUuCiAgICAgICAgc3RhdGUsIHNlbGYuc3RhdGUgPSBzZWxm LnN0YXRlLCAobnNfbG9jYWwsIG5zX3JlbmRlcmVkLCB4bWxfYXR0cnMpCiAgICAgICAgZm9yIGMg aW4gX2NoaWxkcmVuKG5vZGUpOgogICAgICAgICAgICBfaW1wbGVtZW50YXRpb24uaGFuZGxlcnNb Yy5ub2RlVHlwZV0oc2VsZiwgYykKICAgICAgICBzZWxmLnN0YXRlID0gc3RhdGUKCiAgICAgICAg aWYgbmFtZTogVygnPC8lcz4nICUgbmFtZSkKICAgIGhhbmRsZXJzW05vZGUuRUxFTUVOVF9OT0RF XSA9IF9kb19lbGVtZW50CgoKZGVmIENhbm9uaWNhbGl6ZShub2RlLCBvdXRwdXQ9Tm9uZSwgKipr dyk6CiAgICAnJydDYW5vbmljYWxpemUobm9kZSwgb3V0cHV0PU5vbmUsICoqa3cpIC0+IFVURi04 CgogICAgQ2Fub25pY2FsaXplIGEgRE9NIGRvY3VtZW50L2VsZW1lbnQgbm9kZSBhbmQgYWxsIGRl c2NlbmRlbnRzLgogICAgUmV0dXJuIHRoZSB0ZXh0OyBpZiBvdXRwdXQgaXMgc3BlY2lmaWVkIHRo ZW4gb3V0cHV0LndyaXRlIHdpbGwKICAgIGJlIGNhbGxlZCB0byBvdXRwdXQgdGhlIHRleHQgYW5k IE5vbmUgd2lsbCBiZSByZXR1cm5lZAogICAgS2V5d29yZCBwYXJhbWV0ZXJzOgogICAgICAgIG5z ZGljdDogYSBkaWN0aW9uYXJ5IG9mIHByZWZpeDp1cmkgbmFtZXNwYWNlIGVudHJpZXMKICAgICAg ICAgICAgICAgIGFzc3VtZWQgdG8gZXhpc3QgaW4gdGhlIHN1cnJvdW5kaW5nIGNvbnRleHQKICAg ICAgICBjb21tZW50czoga2VlcCBjb21tZW50cyBpZiBub24temVybyAoZGVmYXVsdCBpcyAwKQog ICAgICAgIHN1YnNldDogQ2Fub25pY2FsIFhNTCBzdWJzZXR0aW5nIHJlc3VsdGluZyBmcm9tIFhQ YXRoCiAgICAgICAgICAgICAgICAoZGVmYXVsdCBpcyBbXSkKICAgICAgICB1bnN1cHByZXNzZWRQ cmVmaXhlczogZG8gZXhjbHVzaXZlIEMxNE4sIGFuZCB0aGlzIHNwZWNpZmllcyB0aGUKICAgICAg ICAgICAgICAgIHByZWZpeGVzIHRoYXQgc2hvdWxkIGJlIGluaGVyaXRlZC4KICAgICcnJwogICAg aWYgb3V0cHV0OgogICAgICAgIGFwcGx5KF9pbXBsZW1lbnRhdGlvbiwgKG5vZGUsIG91dHB1dC53 cml0ZSksIGt3KQogICAgZWxzZToKICAgICAgICBzID0gU3RyaW5nSU8uU3RyaW5nSU8oKQogICAg ICAgIGFwcGx5KF9pbXBsZW1lbnRhdGlvbiwgKG5vZGUsIHMud3JpdGUpLCBrdykKICAgICAgICBy ZXR1cm4gcy5nZXR2YWx1ZSgpCg== --------------Boundary-00=_JA8Q2531E7NEDBEUJMXV-- From teiffel@attglobal.net Wed Apr 17 22:37:32 2002 From: teiffel@attglobal.net (Pietrobon Marcello) Date: Wed, 17 Apr 2002 16:37:32 -0500 Subject: [XML-SIG] Javascript and commands Message-ID: <3CBDEB1C.1EB3EAC9@attglobal.net> Hello ! I urgently need to manage a secure web page by automatically execute actions like reading forms, filling them up and sending requests. Normally the user has to press some buttons but I would like to achieve the same result bu automatically sending something to the web site. Of course I think that Phyton is the best way to do that. The web page uses Javascript. How can I access a secure web page in Phyton ? How can I send requests in Phyton as described before ? Where can I find documentation or examples for this ? Any hints is appreciated. Thank you very much, Marcello P.S. I am really a newby of Javascript and Phyton but this shouldn't be a problem. From Alexandre.Fayolle@logilab.fr Fri Apr 19 07:51:45 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Fri, 19 Apr 2002 08:51:45 +0200 Subject: [XML-SIG] Re: [XML-checkins]CVS: xml/xml/utils iso8601.py,1.6,1.7 In-Reply-To: References: Message-ID: <20020419065145.GC17017@orion.logilab.fr> On Thu, Apr 18, 2002 at 07:31:27PM -0700, Fred L. Drake wrote: if seconds: > seconds = float(seconds) > ! if not 0 <= seconds <= 60: > raise ValueError, "illegal seconds number: " + m.group("seconds") Now, this may be dumb, since I'm not very familiar with the intricacies of real date and time manipulations, but is 60 an allowed value for seconds? In other words, should not this read if not 0 <= seconds < 60: Alexandre "just asking" Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From martin@v.loewis.de Fri Apr 19 08:31:35 2002 From: martin@v.loewis.de (Martin v. Loewis) Date: 19 Apr 2002 09:31:35 +0200 Subject: [XML-SIG] Re: [XML-checkins]CVS: xml/xml/utils iso8601.py,1.6,1.7 In-Reply-To: <20020419065145.GC17017@orion.logilab.fr> References: <20020419065145.GC17017@orion.logilab.fr> Message-ID: Alexandre writes: > Now, this may be dumb, since I'm not very familiar with the intricacies > of real date and time manipulations, but is 60 an allowed value for > seconds? In other words, should not this read > > if not 0 <= seconds < 60: There is: if you have a leap second (see below for a list of past leap seconds); they may be a second numbered 60. Regards, Martin # Leap YEAR MONTH DAY HH:MM:SS CORR R/S Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S Leap 1974 Dec 31 23:59:60 + S Leap 1975 Dec 31 23:59:60 + S Leap 1976 Dec 31 23:59:60 + S Leap 1977 Dec 31 23:59:60 + S Leap 1978 Dec 31 23:59:60 + S Leap 1979 Dec 31 23:59:60 + S Leap 1981 Jun 30 23:59:60 + S Leap 1982 Jun 30 23:59:60 + S Leap 1983 Jun 30 23:59:60 + S Leap 1985 Jun 30 23:59:60 + S Leap 1987 Dec 31 23:59:60 + S Leap 1989 Dec 31 23:59:60 + S Leap 1990 Dec 31 23:59:60 + S Leap 1992 Jun 30 23:59:60 + S Leap 1993 Jun 30 23:59:60 + S Leap 1994 Jun 30 23:59:60 + S Leap 1995 Dec 31 23:59:60 + S Leap 1997 Jun 30 23:59:60 + S Leap 1998 Dec 31 23:59:60 + S From Alexandre.Fayolle@logilab.fr Fri Apr 19 10:46:50 2002 From: Alexandre.Fayolle@logilab.fr (Alexandre) Date: Fri, 19 Apr 2002 11:46:50 +0200 Subject: [XML-SIG] leap seconds In-Reply-To: References: <20020419065145.GC17017@orion.logilab.fr> Message-ID: <20020419094650.GA20774@orion.logilab.fr> On Fri, Apr 19, 2002 at 09:31:35AM +0200, Martin v. Loewis wrote: > Alexandre writes: > > > Now, this may be dumb, since I'm not very familiar with the intricacies > > of real date and time manipulations, but is 60 an allowed value for > > seconds? In other words, should not this read > > > > if not 0 <= seconds < 60: > > There is: if you have a leap second (see below for a list of past leap > seconds); they may be a second numbered 60. And I thought handling DST was a nightmare... Now you tell me there are leap seconds! Who said that to any given problem, there is at least one clear, obvious simple, wrong solution? ;o) 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 mal@lemburg.com Fri Apr 19 11:05:04 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 19 Apr 2002 12:05:04 +0200 Subject: [XML-SIG] leap seconds References: <20020419065145.GC17017@orion.logilab.fr> <20020419094650.GA20774@orion.logilab.fr> Message-ID: <3CBFEBD0.2959E24A@lemburg.com> Alexandre wrote: > > On Fri, Apr 19, 2002 at 09:31:35AM +0200, Martin v. Loewis wrote: > > Alexandre writes: > > > > > Now, this may be dumb, since I'm not very familiar with the intricacies > > > of real date and time manipulations, but is 60 an allowed value for > > > seconds? In other words, should not this read > > > > > > if not 0 <= seconds < 60: > > > > There is: if you have a leap second (see below for a list of past leap > > seconds); they may be a second numbered 60. > > And I thought handling DST was a nightmare... Now you tell me there are leap > seconds! Note that leap seconds are always inserted at 23:59:60 UTC (there have been no deletions so far). See http://tycho.usno.navy.mil/leapsec.html for details. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From teiffel@attglobal.net Sat Apr 20 00:46:03 2002 From: teiffel@attglobal.net (Pietrobon Marcello) Date: Fri, 19 Apr 2002 18:46:03 -0500 Subject: [XML-SIG] Javascript and commands References: <20020417213805.21566.67907.Mailman@mail.python.org> Message-ID: <3CC0AC3B.2AF762BC@attglobal.net> I did it using Perl. But still I would like to do it with Phyton. Does Phyton as a library similar to LWP (libwww-perl) ? Is there some documentation ? If this is not the right mailing list for this kind of questions, please let me know. Thank you very much for any answer. Marcello From noreply@sourceforge.net Mon Apr 22 10:00:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Apr 2002 02:00:18 -0700 Subject: [XML-SIG] [ pyxml-Patches-547001 ] dtd2schema.py sequence/choice tag end Message-ID: Patches item #547001, was opened at 2002-04-22 02:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=547001&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Lars Marius Garshol (larsga) Summary: dtd2schema.py sequence/choice tag end Initial Comment: Instead of sequence or choice ending with or , the slash is left out: or [root@rfa01 EFD]# diff -c dtd2schema.py.old dtd2schema.py.new *** dtd2schema.py.old Mon Apr 22 10:58:37 2002 --- dtd2schema.py.new Mon Apr 22 10:58:14 2002 *************** *** 250,256 **** else: out.write(' \n' % (cp,)) ! out.write(' <%s>\n' % wrapper) out.write(' \n') --- 250,256 ---- else: out.write(' \n' % (cp,)) ! out.write(' \n' % wrapper) out.write(' \n') ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=547001&group_id=6473 From noreply@sourceforge.net Mon Apr 22 10:37:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Apr 2002 02:37:09 -0700 Subject: [XML-SIG] [ pyxml-Patches-547011 ] utils.py/xmldtd.py for ErrorPrinter Message-ID: Patches item #547011, was opened at 2002-04-22 02:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=547011&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: utils.py/xmldtd.py for ErrorPrinter Initial Comment: For some reason ErrorPrinter doesn't have a way to set the locator, and it overrides the ErrorHandler init that would normally set the handler. Here's a possible patch that gives a getter/setter & a locator=None arg, plus gives location and text method for the handler. The default is to leave things as they are. (self.locater=None) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=547011&group_id=6473 From bbirkinbine@earthlink.net Tue Apr 23 17:57:48 2002 From: bbirkinbine@earthlink.net (Brian Birkinbine) Date: Tue, 23 Apr 2002 11:57:48 -0500 Subject: [XML-SIG] parsing xml files delimited with non-xml text Message-ID: <20020423115748.A16467@core-qe1.charter-stl.com> Hello, I'm new to Python and XML, so please be gentle. :) I am using the xml.sax libraries with Python 2.2 on OpenBSD 2.9 I can successfully parse my xml data files without problems, but I am struggling with the following. Lets say I have a large text file with xml data separated with a delimiter line or other non-xml header information (typical when using enterprise management systems for data gathering from many systems (ie. Tivoli task output from many systems)) Should I strip out the non-xml data separately into xml-compliant pieces before calling the parse routine, or can I use exception handling within the xml routines to ignore the non-xml data until I see valid xml data? I would prefer to use exception handling because my functions to strip out non-xml data would have to recognize the start of an xml file, and the xml parser already knows how to detect the start of xml data. Thanks in advance -- Brian Birkinbine GnuPG/PGP Key: 0x37D55FF6 From Matt Gushee Tue Apr 23 18:39:19 2002 From: Matt Gushee (Matt Gushee) Date: Tue, 23 Apr 2002 11:39:19 -0600 Subject: [XML-SIG] parsing xml files delimited with non-xml text In-Reply-To: <20020423115748.A16467@core-qe1.charter-stl.com> References: <20020423115748.A16467@core-qe1.charter-stl.com> Message-ID: <20020423173919.GC1736@swordfish.havenrock.com> On Tue, Apr 23, 2002 at 11:57:48AM -0500, Brian Birkinbine wrote: > > I would prefer to use exception handling because my functions to strip out non-xml data > would have to recognize the start of an xml file, and the xml parser already knows > how to detect the start of xml data. Not really. It *assumes* the input is well-formed XML. No XML parser I know of (except possibly MSXML) is designed to detect XML embedded in non-XML. More to the point, I have two thoughts on your approach. One, I am philosophically opposed to it because I think exception handling is called that for a reason: it is intended for exceptional cases. But that's just me (and some authors of books about good programming practices). In practical terms, I'm not familiar enough w/ the internals of the Python SAX parser to be sure, but the way things normally work, once non-XML is found in the input, you don't get a second chance. So I think you would have to have some logic that iterates over the input lines, repeatedly attempting to start parsing until no exception is raised. -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ From veillard@redhat.com Tue Apr 23 18:49:00 2002 From: veillard@redhat.com (Daniel Veillard) Date: Tue, 23 Apr 2002 13:49:00 -0400 Subject: [XML-SIG] parsing xml files delimited with non-xml text In-Reply-To: <20020423173919.GC1736@swordfish.havenrock.com>; from mgushee@havenrock.com on Tue, Apr 23, 2002 at 11:39:19AM -0600 References: <20020423115748.A16467@core-qe1.charter-stl.com> <20020423173919.GC1736@swordfish.havenrock.com> Message-ID: <20020423134900.H26241@redhat.com> On Tue, Apr 23, 2002 at 11:39:19AM -0600, Matt Gushee wrote: > On Tue, Apr 23, 2002 at 11:57:48AM -0500, Brian Birkinbine wrote: > > > > I would prefer to use exception handling because my functions to strip out non-xml data > > would have to recognize the start of an xml file, and the xml parser already knows > > how to detect the start of xml data. > > Not really. It *assumes* the input is well-formed XML. No XML parser I > know of (except possibly MSXML) is designed to detect XML embedded in > non-XML. Actually, the XML specification is relatively clear, the parser cannot guess the end of the input: http://www.w3.org/TR/REC-xml#NT-document [1] document ::= prolog element Misc* Misc* indicates that the parser cannot find by itself the end of the content, the parser has to be informed of the end of the stream. Anything after the root and till this point must conform to Misc*, and if not it is actaully a fatal error. 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 Matt Gushee Tue Apr 23 19:16:07 2002 From: Matt Gushee (Matt Gushee) Date: Tue, 23 Apr 2002 12:16:07 -0600 Subject: [XML-SIG] parsing xml files delimited with non-xml text In-Reply-To: <20020423134900.H26241@redhat.com> References: <20020423115748.A16467@core-qe1.charter-stl.com> <20020423173919.GC1736@swordfish.havenrock.com> <20020423134900.H26241@redhat.com> Message-ID: <20020423181607.GD1736@swordfish.havenrock.com> On Tue, Apr 23, 2002 at 01:49:00PM -0400, Daniel Veillard wrote: > On Tue, Apr 23, 2002 at 11:39:19AM -0600, Matt Gushee wrote: > > On Tue, Apr 23, 2002 at 11:57:48AM -0500, Brian Birkinbine wrote: > > > > > > I would prefer to use exception handling because my functions to strip out non-xml data > > > would have to recognize the start of an xml file, and the xml parser already knows > > > how to detect the start of xml data. > > > > Not really. It *assumes* the input is well-formed XML. No XML parser I > > know of (except possibly MSXML) is designed to detect XML embedded in > > non-XML. > > Actually, the XML specification is relatively clear, the parser cannot > guess the end of the input: > http://www.w3.org/TR/REC-xml#NT-document > [1] document ::= prolog element Misc* > > Misc* indicates that the parser cannot find by itself the end of the > content, the parser has to be informed of the end of the stream. > Anything after the root and till this point must conform to Misc*, > and if not it is actaully a fatal error. And Misc consists of processing instructions, comments, and white space. Okay ... I'm not sure exactly what your point is, but you seem to be responding to my statement that the parser *assumes* the input is well- formed XML. That was probably a poor choice of words: what I really meant was that XML parsers are designed to accept well-formed XML and reject anything else. Period. As for Brian's idea, well, I don't see why he has to comply with the spec, as long as a) he is aware his application is non-compliant, and b) he isn't distributing it to the public. So it seems to me that assuming he doesn't care about whatever Misc* might be present, if the end tag of the root element is present and he codes the right exception-handling kludges to deal with the stuff at the end, his approach is feasible, is it not? Or should we be trying to save him from himself? -- Matt Gushee Englewood, Colorado, USA mgushee@havenrock.com http://www.havenrock.com/ From bbirkinbine@earthlink.net Tue Apr 23 21:58:21 2002 From: bbirkinbine@earthlink.net (Brian Birkinbine) Date: Tue, 23 Apr 2002 15:58:21 -0500 Subject: [XML-SIG] parsing xml files delimited with non-xml text In-Reply-To: <20020423181607.GD1736@swordfish.havenrock.com>; from mgushee@havenrock.com on Tue, Apr 23, 2002 at 12:16:07PM -0600 References: <20020423115748.A16467@core-qe1.charter-stl.com> <20020423173919.GC1736@swordfish.havenrock.com> <20020423134900.H26241@redhat.com> <20020423181607.GD1736@swordfish.havenrock.com> Message-ID: <20020423155821.A25870@core-qe1.charter-stl.com> I appreciate the feedback on this. I'm sure my newness is showing here, but I am getting my question answered, so I don't mind having others save me from myself. :) Based on the comments I've received from this list. I've decided to pass xml compliant data to the xmlparser and rely on other functions to strip out the non-xml data before xml processing. I guess I started down this road because my xml handler was a subclass of xml.sax.ContentHandler to allow me the ability handle normal xml processing and I was hoping of a way to start/stop the xml checking rather than write another parsing routine to strip out non-xml data (implying that the sanitizing routine knew when xml data started/stopped) This is a non-public program I am writing to help automate a lot of manual processes for me on a large number of UNIX systems. Thanks again, --- Brian Birkinbine GnuPG/PGP Key: 0x37D55FF6 > > > > I would prefer to use exception handling because my functions to strip out non-xml data > > > > would have to recognize the start of an xml file, and the xml parser already knows > > > > how to detect the start of xml data. > > > > > > Not really. It *assumes* the input is well-formed XML. No XML parser I > > > know of (except possibly MSXML) is designed to detect XML embedded in > > > non-XML. > > > > Actually, the XML specification is relatively clear, the parser cannot > > guess the end of the input: > > http://www.w3.org/TR/REC-xml#NT-document > > [1] document ::= prolog element Misc* > > > > Misc* indicates that the parser cannot find by itself the end of the > > content, the parser has to be informed of the end of the stream. > > Anything after the root and till this point must conform to Misc*, > > and if not it is actaully a fatal error. > > And Misc consists of processing instructions, comments, and white space. > Okay ... I'm not sure exactly what your point is, but you seem to be > responding to my statement that the parser *assumes* the input is well- > formed XML. That was probably a poor choice of words: what I really meant > was that XML parsers are designed to accept well-formed XML and reject > anything else. Period. > > As for Brian's idea, well, I don't see why he has to comply with the spec, > as long as a) he is aware his application is non-compliant, and b) he isn't > distributing it to the public. So it seems to me that assuming he doesn't > care about whatever Misc* might be present, if the end tag of the root > element is present and he codes the right exception-handling kludges to > deal with the stuff at the end, his approach is feasible, is it not? Or > should we be trying to save him from himself? From andy@reportlab.com Tue Apr 23 23:18:32 2002 From: andy@reportlab.com (Andy Robinson) Date: Tue, 23 Apr 2002 23:18:32 +0100 Subject: [XML-SIG] parsing xml files delimited with non-xml text In-Reply-To: <20020423115748.A16467@core-qe1.charter-stl.com> Message-ID: > Should I strip out the non-xml data separately into xml-compliant > pieces before > calling the parse routine, or can I use exception handling within > the xml routines > to ignore the non-xml data until I see valid xml data? Does the non-xml data consist of HTML tags (i.e. you have XML chunks embedded in web pages), or totally unrelated stuff like ================xml begins here============= ? If the latter, a pragmatic approach says that string.split, re and friends will do a pretty good job of cutting it up. If the former, I see the temptation to try and get away with a single parser, but you may be better using sgmlop or another non-xml parser to break things into chunks. HTML parsers don't choke on singleton tags, missing quotes and other things. Show us all a snippet and we'll be able to tell you the most pragmatic route! - Andy Robinson From noreply@sourceforge.net Wed Apr 24 21:34:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Apr 2002 13:34:42 -0700 Subject: [XML-SIG] [ pyxml-Patches-548306 ] Improved MSIE parsing for xbel Message-ID: Patches item #548306, was opened at 2002-04-24 22:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=548306&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jérôme Marant (jeromem) Assigned to: Nobody/Anonymous (nobody) Summary: Improved MSIE parsing for xbel Initial Comment: (Please take the diff-only part of the attached file) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=548306&group_id=6473 From noreply@sourceforge.net Wed Apr 24 21:38:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Apr 2002 13:38:13 -0700 Subject: [XML-SIG] [ pyxml-Patches-548307 ] Latin1 compliant parser call for xbel Message-ID: Patches item #548307, was opened at 2002-04-24 22:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=548307&group_id=6473 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jérôme Marant (jeromem) Assigned to: Nobody/Anonymous (nobody) Summary: Latin1 compliant parser call for xbel Initial Comment: (please only consider the diff-only part of the attached file) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=548307&group_id=6473 From noreply@sourceforge.net Thu Apr 25 10:18:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Apr 2002 02:18:28 -0700 Subject: [XML-SIG] [ pyxml-Patches-548503 ] re-submit w/patch - utils.py/xmldtd.py Message-ID: Patches item #548503, was opened at 2002-04-25 11:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=548503&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Eldridge (dcbill) Assigned to: Lars Marius Garshol (larsga) Summary: re-submit w/patch - utils.py/xmldtd.py Initial Comment: Oops, sorry, missed the file upload last time - here's a retry: utils.py/xmldtd.py for ErrorPrinter For some reason ErrorPrinter doesn't have a way to set the locator, and it overrides the ErrorHandler init that would normally set the handler. Here's a possible patch that gives a getter/setter & a locator=None arg, plus gives location and text method for the handler. The default is to leave things as they are. (self.locater=None) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=548503&group_id=6473 From noreply@sourceforge.net Sat Apr 27 14:41:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Apr 2002 06:41:46 -0700 Subject: [XML-SIG] [ pyxml-Patches-549473 ] dtd2schema - sequencee element slash fix Message-ID: Patches item #549473, was opened at 2002-04-27 15:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=549473&group_id=6473 Category: xmlproc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Eldridge (dcbill) Assigned to: Lars Marius Garshol (larsga) Summary: dtd2schema - sequencee element slash fix Initial Comment: Another tough one-line patch. My previous patch fixed lack of end slash for and as well. but I didn't notice: which needs to be: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=306473&aid=549473&group_id=6473 From reagle@w3.org Fri Apr 26 22:28:35 2002 From: reagle@w3.org (Joseph Reagle) Date: Fri, 26 Apr 2002 17:28:35 -0400 Subject: [XML-SIG] Fwd: Re: bug in c14n.py Message-ID: <200204262128.RAA01887@tux.w3.org> --------------Boundary-00=_NB2774YQWHPCTZZJZ5GY Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I've fixed the bug I reported below. I've also attached the test files and expected results in a zip file (in the tests subdirectory) from Gregor that led me to find these recent bugs. I started incorporating them into the test_c14n set (e.g., re_iaik2.xml.b64 is iaik2.xml example using exc-c14n encoded in base64) however I found it awkward, starting writing some code to run the tests from the files and ran out of time.) So no progress on that front. I'd like to finish that (makes fixing future bugs much easier!), but now that I have these bugs out of the way I have a few other python projects I've been meaning to get to... (Also, no guarantees that my tweaks aren't verbose or inefficient! ) ---------- Forwarded Message ---------- Subject: Re: bug in c14n.py Date: Wed, 17 Apr 2002 15:18:19 -0400 From: Joseph Reagle To: Rich Salz Cc: xml-sig@python.org I include a c14n.py that fixes the bug that I speak of below, and a test_c14n.py that has a more consistent treatment of the "withComments" option, and also permits additional prefixes to be passed as a command line parameter under exclusive canonicalization. However, I also discovered a bug from Gregor's example 1 [a]. Presently, c14n.py does the following: 1. takes any xml_attrs (e.g., xml:lang) from previous recursions not rendered and adds them to local xml_attrs. 2. if the element we are processing is in the subset, it renders the accumulated xml_attrs as part of that element and and resets xml_attrs=[] 3. it recurses. This has the effect of rendering all XML attributes that are "in affect" since the last ancestor was rendered. Sounds sensible, but it's not correct according to the the spec [b]. To fix this, I think we'd have to test whether the immediate parent was in the nodeset and keep a dictionary (instead of a list) of *all* ancestors' xml:foo attributes (not just since the nearest rendered one), with the *nearest* value. (Moving from a list to a dictionary is akin to what I did for the namespace bug.) This bug exists on in c14n, not exc-c14n. [a] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0259.html [b] http://www.w3.org/TR/2001/REC-xml-c14n-20010315 "The processing of an element node E MUST be modified slightly when an XPath node-set is given as input and the element's parent is omitted from the node-set. The method for processing the attribute axis of an element E in the node-set is enhanced. All element nodes along E's ancestor axis are examined for nearest occurrences of attributes in the xml namespace, such as xml:lang and xml:space (whether or not they are in the node-set). From this list of attributes, remove any that are in E's attribute axis (whether or not they are in the node-set)." --------------Boundary-00=_NB2774YQWHPCTZZJZ5GY Content-Type: application/x-zip; name="c14n.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="c14n.zip" UEsDBAoAAAAAAKeAmCwAAAAAAAAAAAAAAAAEABUAQ1ZTL1VUCQAD+g/HPIvEyTxVeAQA6APoA1BL AwQKAAAAAACnfWErVh3m2RsAAAAbAAAACAAVAENWUy9Sb290VVQJAANZtOE7d8TJPFV4BADoA+gD ZGV2LnczLm9yZzovc291cmNlcy9wdWJsaWMKUEsDBAoAAAAAAKd9YStP1dfSEwAAABMAAAAOABUA Q1ZTL1JlcG9zaXRvcnlVVAkAA1m04Tt3xMk8VXgEAOgD6AMyMDAxL3htbHNlYy1weXRob24KUEsD BBQAAAAIAKeAmCyhPSkKhgAAANMAAAALABUAQ1ZTL0VudHJpZXNVVAkAA/oPxzx3xMk8VXgEAOgD 6AOFzssKwjAQheF9n2KeoJOZJFpnV3BVcCe4lGICLmpa0hT17U28Ll2fj8OPYa6nO1JNePAOumUA tkBWiERrYKUIscLrGAdXp1v6K6Pv3cW/qcH9eYGuD0BrYBKzEbsqlAtNfk7HE5nwKtC4GwO0UwRo gJp8KsRf/HPMz4AC2eRdVG7QH7itHlBLAwQUAAAACAADeposp7WH39MPAADGMgAABwAVAGMxNG4u cHlVVAkAA3WnyTx3xMk8VXgEAOgD6APNG11z2zbynb8CJ6eV1JEoyUmaVomT+my1pzaWPbZzyZ3j 0dASZHFMkSwJWlY6+e+3uwBIgKQU59qbOT3IIrjYxS72G/De31gvS5PejR/2eHjP4o1YRqHTbDY/ nLxlR14Yhf7MC/xPnvBh3Llc+ilbRfMs4OyWhzzxBE/ZTMMxnBUtmMfm0Sxb8VCwKGE84PjTdRh8 lkLEw15vvV6766dulNz2Ls97+/3+oHc+Ouo+rILubPAs7OJI/+ngueOFc+aHsyCbAyGPxUkkIrGJ OZLhDzCe+ve8WIFeaT2pC/829ESW8N5x4i1E2kN6gIVoOs45/z3zE6BztkFG+u4Lt48MBMBl4jrO b2G0DpmfphnA+AsGtMNb9rNw3/o3bnwcrQIuBB8S8YHL3sGKojmnx30XRAKzwkiw9dIXnKWxN+Pw nKxw1Zx5QiT+TYbyBNaIxcnJ5elvowlDGYyP3xCipy5LOV+lTETshmvRsMbHsMGAJZ4wfxVHicCV 8Qd4DmFbQPq+8Hn6xnEmkeAdJnAf73mSgqxQpjOepiTf49MTJhIOIEh0FoUpyASmBxvmiwLSCb0V 1xzQzqQGAx1ic5FEK8CI75vAeD7Be/BTl6EmOTFPVr5IWQprBo3KlQZpK62pbC1b+6CjmXA+nHli 6bL3Sx4y+g07A1vC58geV0Owm1kgaBEs8FOBMLEHLMyJCIKDJJ05F7iUkOO24myaALB+WEWGeDoM OIVfQsC6eZByUI/DDBaWpHL/G79GKY+X7MRl59y7BahfE7fBXiX08JNUyNcS9NyfLdmFF3zC9yn8 /elTFIBtubNo9dpxnhyD/g0ZmMR+r/+sN3jBBi+Gz/vD/gv2hN1s2BNJeMgkbvYE7ddxprMo3iT+ 7VKwAwYjR/kjGleH/ZtosItNKlCfxuHMZewwCNg5AqWw7JQn93zuOuWZJ+NLtx7SOQbZSC0A4YZz UEcUHwoX1RpFc0YuBgyiz976Mw4KZpiYZbTSGZHhArQ76AUS3l2KVeBECUC/f3rELqKFWHsJ1+ic Oss/Ak1Gq8hWvbf81gt6uXC6qZrfHfz44w/9F/t9KT5pRgzZCW8dUmbwFu4c/qpXEzRukWzkhucQ YaoBwIlMLhzwLzwWEmgWgO7JcTmAn78fXoxgixrVVYO4++ijwrTXyMHRNdVCw4se8tDLba1RLE8t aXZB/IxPaVA/AL7ihVwvG9OEUZKAZpkYcjhnihafwtzAW93MPTYastbINfwYWpg54N57AbjOVruN W351DSq69IN5AgZsIhm5NDwhx6IAx5MpsDedXBSQ4ZCFbs7qu/MxOziQonXh25mSa6ToYE/JwjSL 4wT92Pws4Qv/AcjA1EkUcsdx9thxRK5Qe6Pe2Zgtwb8FOCPp3YKVoZs1IpxUc49cBcxf+Ak4GuW/ 3jjTtzRxJJ87bFr8+kXiUgOwzsQLb3nradsBj7RgU1RZnrTCQSfcb8tdAN20h1n3NXgpIfdTOX7g bg4uE6LMAuQH/rMLgjP2gRSc9hR3fhUDKkuS4MD3rYG2hF4wH70MRFAIgzSkHhSOIAI/PYF5hCB/ AnZMfqZhuoUlfNMKO/ftDn1bvDVaIGC+isXGiCW46z5uzQOE2tvEi5cYKSBYBdxLRdttFJwuWDi4 6l/jTjfJpJo5K91BDrK/BWRQ5RYgO3KC3q5M+BjK57B4CiAdFoFGJNJOOqxO8QwR/DezUUA3EThy T6Y853KBIslUJPNk7JPSwvioiFAUVcGNIrQpJzcVXiJSBGlJQQyb7cJfobWGV98Pr2mEB/VTqjOe qxkA3woPDhoNchBI3Y2JIYy2V409kKUHcbbRIZO8Jmfx0cR1YE1CDceZdQIasnyesX9yM9E0ULY4 15B0sWrkC4nhsCJWrw998BrgbqZpdpNyUbgb+Sx3c0g5kYIgo8QEI1Qjzpenq7ewhyiVKgq2xxLI IyDVEmvu3TmOjDVTSq3QvVD2lKvb2BpWgQlFcjR4NpHpGfNmkIDEXuiTPyRy8wy9P+SCzZQwqYwQ x6xMHfUq9hIwVDBrGQkMUFAWwQsvtMf+AQCQjdACuAfZEBHDJPgli6M4w/Rgromr+sMPAQ0ktsSA Ki4kGoxJf3yWuMkwQbq+mE5bKQ8W2rjWiY+Z8Hff3a0NTcU8iZwyLTnJpIXYMqSF6wmI0iVcQJT+ 2q/yTb1bu7dctJpyoNm2wUDQiD81APVQs8P6Jej6EJbPrHttEAxTCA7mkuQA0PmD/B54vTyMdgpP KMcoWflcIMt/7LGz8gaXJIFjQLUlyQE1SazZ/Ay/P7fZXv/Z/n4VMZohmjt+XWJZRLEaBo5Pj96d jCaX08np8WhoGToRnM6jqY7SLZxdrFo6rVqso7ejXUg1wlOK+gd5NC/EcCiK3EAlARYaoixYkZ+Q WrZtWhYTCkuJB8lHyqsT/RC8mY8Wc6CQqBEoCUIBVWENpq0EOwW6R8kv35XLf52NaqSI1ZeBp7z+ xPOhIkCMlHp2MAFXyzUMusxPYdi2Le8CxNiJpVwOfwGlJpg96LCAMo76GDplkpEqTzsUNqiX3mEB GYXBJseCLgxtgOpCqRrkzMp1rCqSEVqGAI2gDFj4SalfR1EQcLBfckzg13wo8Km0hQWDQQ0XUWTm evlMeKcT9oUfYAJZZNWQi9I7Kem2Se69F9yxLCYJgLdgkF4RmQ8fPpg9izXXelJQzBWng7FAZrhX 1x0VvWlkohsk+FlD2s81KIUM+vk1NkpBHYPidhYl0naNwWGa4hVpa9WuMCHAXQP8WppVLKasXS+O eQgpXdXYLAFpOK9dshUlNSWIGpnpbFxjMq3E9H9bLWQLEFoHVUQaVnl3s7dH+8hsj7iMgjlow5Jj RkU6qt8bRi/NAouqGw7FHw9nUQYWBVULGANEf8pbz8ZpLw+LaJo3nAKs4GGOCjCkMZ/5Cx9kaNlJ vbO2SjHLZKnkxI0lpooC1N5f0AB69TUquX01Xx06clSmk6YFbXHmFZKlihNILqxito4qOfstbJ+d nx6NLi7Gk1/A0i4uz98dXY5PJ7ukgEuP/bpV76JzdHryJfEiYqUvX4v9SzELP1bckgjrYm9t/DKW o1PUq2oKc40bZJhjyZR3B7oagB0mjKBYQhwdH14eKjuG4pEadvde4keZMiyILbMl5PEzTONNswPL 9mWxILvLG/BEmHLqJDm1suQi51FVTstIjjU/ypcVJozpC3WbXMAdQOCl8OTOPeF1WOPbBn55q/hl o71rDtTOjVcEG4hHgL4m0NvHgH7sD54T9N7DsQkO3ELlWVQGrbRu7y9HH+x9x02pgaM9ml6MCsuy JthKApa1S0Xs1zsU5GystEIphYcdlTmm9qA1ApQ8wN97D4eqYZ6jKLXFItlOP6M2jW6dYb+XHDFr gcaAmgnIgoNNIUDdTKv4Jddk6M9p13udHNtFG+5djeesuM4he99qfgyNsgqeX72xnvMEWTbBTG3K FdlWGsudAELWbJeGUovgm9fN9iOWboU9e+W2ru1w51rpYr+kctrn7tK7Gpgdyqeg/1IN1Dj/39RQ b5rOdEoqUK+kf05RtbL+rdutjOZ6WQHvdl+XoP8CfTPDulYwJYmSlmE6rdWnw+ggwVazZhlqt5KF RfFiJ45bRF4yxvdmSg/vDhrNneGCFvw/C1rNRhO+vv09i8TL3etAYAhbA4Lfe/jxUdD7CvrwUdDP FfSxJS7bb6G07P3V2azZolPV7dTozlIFWfUvXzV7l1Lo2qRF3UwsPNQJVbtchv/ChWxzsRYd/aGf gOfZXZutvDvOqIwEtxP7ZhG+x7D/NlWFXbfLJhcgglkAKRZlTViByJflKQm5QaiQ5CR57J4P3myK zoU1kz4wXS6nhmACLN97sBgRyWsB5RIAsUA9qyQIGA6Lqh9Wi8eRRWeERFHDADORFIt5Sz+87QgL yeVS65jS6BhLOzBOCXI1zTuPdFxjPA6uXTwDbrWt0X09WupG5hI8KBaiIM0Gi8Vf0YSWUjj27/05 t7kFoWNrgjqtqHKkrIa+2Mpbo9JX6lAFP+YZws4oZFW+1C4x2z+VktfbcsyKveBtXRSd9tQ3UQBF Qx4sNYY0QT41DGGdnrCb7Jato+TOS6IsnFcJKUFfhdc5yX+in63Wfds4gO+a9umi0pzFXCEX6NaW j7n7V4UIaHWkT98/ooA09nZLV2jPm8+Ve6n2+9CMtSdopjUAFqp80W4WQ9TnrRIXVidQJWL6yLDw 5x2yVytudmwPiyfHufjsMzk11cqVK6lKNU+Rx8qWWJg6udHNUOvMG+UinYZrk0+nIlLuhMJDpZ0Y du6pL6RE4vp4XaYFVlLZuj02XjB1emn4RD81z07whAtPsTs10ynoLJjRhmZrWWuz9Mu2JM9TabFX BkWIxk12XeMbqadduFJ5FqTObuuQyD1l1/X6jz1xPwTjq+GrEa18UyLUEMezYqXGpANAuYMt4NkS ZeiHJVWVmFAUAMjkcWyHFAsvkFEmItNCkHfNxMdcl3Eb9RKmY2npruAbszL8s02kagOaj6HY/LI0 67UMCw2QwT12aoJNngds0ynRTFlxHwZ1UF8EqOOYLl/oRrepIUr1axiXrLfq/GYd8JcuO2w95axr 2+PHNGPtNhH3fbviJfCSjDzdNfwZ0Fx5yR0q0Rqbz2h2OdtbHYaL11ZaxeWV9g7nkU/a0b6k8oVW XRfs9Hog3h3cEy/9Z4MXZfbG5r3YKNEn8ar2VVc+dDaAkQSf82iyLVDssRFEKzkBT4DkBJRi7ql2 zq4Tet0hFX62HJAiM1uymtKBElTZNeEWP2ZwxduxoCWliFfcUfvKWF1GtwWROcXUnqrqeFsvptTr TZFwwDZJ6pUiHkt4I6KfZelSFjEd2JhZluAWx1FcOb+XINYxfvHQwSN9Kb1tubmdcc4o49SVVV3S Wbq14uZdg1nevL9Wxd6sdDciXx/+LZhFpQLRUDPiVe+b9HWTfcPCvC9ntyXMwxzdltBlkbzrZVyN 5+qYPMpEnIkDjJHWtRK8UvIYaCxL313+3P1BLtqcoy5m5zcSrYNlMkIwSagHZyj5UCh70pfB6ALu g3iJMpBk0RPk52YIEKoX6ibL2g8CQnGD59ZBQJek9VyNjwhTRoDgCCpbWyqm/MY3kLvPjVtAxn0w ugEyxLNE+Asb7CUbzNjUJass8Y1kARhK/JpkwEtTkAatjD/Q1W7t2xKqF9CXq4P6fG7eZWN3nMf5 o3Q5YfcTTyLW0hkcCMm8eKOS1yPrnx3kKF26lLfD8RcVwXRlvLJoE/nVdYG9/vLaPDJ8OZ61yCKR ynS9f6nV/NSfWN8KoqPUdBllwVz+v4A+cda66SjrkLtb7BEE0WDTKhkimrqhvlJdoIIG9aWJtpvE klVfF3b1D6Ng3k0irWDHjzrvTjFbJR8H+P4DUEsDBBQAAAAIAFt6mixBad+ZwBYAAIE2AAAIABUA YzE0bi5weWNVVAkAAx6oyTx3xMk8VXgEAOgD6AO0W2tsHNd1Pndn+RouRVJPSq7ksSTLK5ncJSXb smhalkTSNm2RokXJlBk77GhnSI60nFnNzIpLg8ygsX4UCNBX2gD+UdR9Ji0awIDTR5rCKNAkberW Rd0fTeM6KWAUaZO+ASO/ivacc+/Mzi6Xsly0Iji8c++Zc8+c+53HPXd04oc9evWL3xorAf5rx99g WgBEABbAAjbug+ggWAIWBER5sDJwMwMLGYiOg6XBTQ3KWVjIgohOwPpuiB4GKws326DcDgvtIOZd A6JBEEJEQ2C1wRKybYc7AK8BvIQEroBr0TCs74dohHl3wEIHRCfBxkYnzLuHIToFWbsLbujg7SJG InqEKTuJwM2AuBY9BlYHMV3QIToNVie3uyF6HKwubucgOgOWzu0eiM6CvQOsbnhNwMsaLPTCQh8s 9EN0Dqwc0+yEaAqsHm7vgugFsHZwG1/QBKuX23sgKoHVx6/Un7zSXohmhb0PrJ1wB3U2QKLO5XeR Wv9QA7g2fdEYN13PdUpm2XnVDB3P1fUrK05grHpWtWwby7Zr+2ZoB0YppjPoKW/JMA3LK1VXbTc0 PN+wyzY1C7qB/1bCsDJaLK6trRXWThU8f7l45XLx5PDwSPHy5PhQbbU8VBp5xB2inuFTI4/qpmsZ jlsqVy2cyDQqvhd64XrFpmnsGvYHzm27LkEsaeup5pxl1wyrvl2c8M2lMCjSfMiF59T1y/atquPj PLPr9CLDhdOFYXqBMr6lX9D1511vzTWcIKgijbNk4NzusvF0WLjoXC9UJrzVsh2G9ihPPlIwrqJE nmXz7ckCqgSfcr3QWFtxQtsIKmbJxnt/laS2DTMMfed6lfSJr8avODN95dLzkzMG6WBq4ilmdKpg BLa9GhihZ1y3Y9UYh/XDBr6R7RvOasXzQxLMruG9i6uCyndCxw6e0vUZL7QHjZCW8bbtB6gqUmnJ DgJW78SlaSP0bSShOUueG6BK8PHyuuGEdUrdNVft+AV4YYKU/IP8lku+t4ocafwhfO/kAbPmBAWD gKRXbH/VCQMjQJkRUAlmaG4Fmi0ra6w54YpXDfVrs2a4UjDmV2zX4DYuDK6IbdHr2aoLF7NaDlkI o+wEIdFUTHwFiychclSkbtkhieLatKr0ND+AtI67lRnxGTTwTbEVhii3XQ5sRMf5KgrmB3L5Dz/n BXZlxZguGJdtcxmpnvMLh40xn2/OSTyelaSXndKKMWeWX6XxAP+ee9Uro2kVSt7qWV0/OoHwGzXQ Ik4Whx8pjpw2Rk6PPjo8OnzaOGpcXzeOyolHDcnbOKoHJ9AvjnuVdd9ZXgnpyZFBY4F5GnPrQUjw mXJLBcM4Xy4bl4koQDED279tWwW9+cnpqSuF1pT6BOpCrjoq07UQfqQuUiahmFQxu47CuYj/YeOi U7IRUCmLarDRClOynSJ1YaRYlvSFlXC1rHs+Us+fGjfmvKVwzfTtmJ3eytDHEblkBdXV4kV72SwX S/E7DQXq+aGRM2ceHz59clifyQvyelm8zOC6y7s2YB84M1dvcdwRkIFgHzYwTEQFDjfYLpL3xLhz eS6vEZvgIF63ioX6HCaf4wbF4GhLCpyoSIIVE4PJZ2LhLpyfmww0KU2eZKlfgi68FIrkxlCPdZGH 5JOa6BIlAfSjQfAASf8YbAA4ArweELLlZCgwVDBCLgNGAtLCDL9NQM3JQMdr3cgDCsC3zTK6Qqkw JtpWok68Gyubq9ct8+xjEBBFXaB+Eui0EqhJgEyjAKUVp2zRKn3iWU+nZs3QrBTqMPDKWcMMOBrc yCTzZmPubpCja7wcVy9PpbARr0Yii3tPsjzeLEsfyXKmLktKEK0uyG68Vt2gWqn45IatWd9ecmrY lNB17U8qxxkph0NzlEgQ+gmmSZhzEF2AaAJCYKkysCERkoFNTKkmYSMDXjcmU9yaw+xIRE/HxG1M 3EbEc2ggc3IRL+BlkazS9vPuyKB78rgxdBY9bMhecE4FLXw1C909Bsgl9BPo+4dm5lKxpTCT58yP JV6tBMTZHdm6RNx/klXhsALKHsaQGSSRClXPpcm21VhHXfBzwCjUMlpmQOjQLVBrGciS1kzS2hRE z0M0TVrAF99v8Up6OVTONCWh3VJRM6Sf1Hg39+G4HL5ECFAcFCFrMouaJOgFL9UFWnSDfN4dvH18 kK8NKj2cN13DXq2E66nwi8qhwFa2a5icLPtmZYWCK8b3sm0G4fHCYQdi98eOykmhsFFpagnk4jYM batJvUHwKeB1I2XuhpzYTerMQptU53dJnS9ANAfRVWUXqAjMg71+VNGLrJ8M3L+J8z2IHfMxjZbQ XGOarKQhvb7EHW2sckzQCaMaJflhFpZxIdqhcoB9oRxAqoou7zUa5FX6FOXvcpVehtoIYR+TeGz7 R2EzC9ErNMVGVj3Pj7ySPHLrSzAffZoemMNsfy5P2gg+Qyqphg7lgBauIaceg4aHcdRfJNxjOtXK 5nmlr3sY1E2Z7V62MbHFdMWvqizGlHmPXHbKjdQknEGpxIYJ2uO1HnXaG9ee0cbrSF7jiGUvmZgB MSQYJjP5zrp34tcJTT8MaAL2SQn7Ckud+KntPVk3DqTenZ+glgS+nCjh3Ex8V//IXLYDZld6FV6A YEDhcpfoF/Q7nukWOegSu6BXmjx77QOEUZOWPBRwo1PiRdA94qXBf7Neq9cDO6zrIH4NaUBNFDxw Ly7cVAvUS2/AeTSlzZwqc76iUb7yHRK0FO+TbYhWYAV4n3yDrIo2iejU75BFUVuD6HWyJGojqL8M dhZsAXYbIEDGojfJqmgM979/QPtfNdaJY19L3Xfh/dtkcGrD+5dg6/FYN469p3bYtOn9e7Bz8VgP jn0Yb5R3QPQRYD5Ae2VBO+BoWti9MWkfjGHKRdoJMHeBqYb3N0plTPU5joyPPDIjNx2GWcK0umK6 Dm94ONG3qj6FHid8KGBTUvsc6mvYfpLFVEwffSk6sIDHUqSI/dAulDRox59uCMpUnLgB0U2IyuQo EBaL2LNK/oQcD3sz6kQVu3Fnhj2YJG6DyIv7szFxO0SVuLONVjEbdpDqM6jLMW53YbsDxihSI+eA 3BGRWYoG20sas+qGqMrOrgfCHeD0ssvajS7rNjvTPhrDWYX7BvatpSj7mXIBe2sQ7mReuyBah3A3 tfGRHLN5ldnsSdgcw74N7tur+jbxFTfrVBucMgh3GAk/k5pvgOfrwN4IXPTc0U9AuB/CA4rLZzNQ 96eH8TKOOyFMIGh9/Kp0dI2WUUibG1kTQoIGAxn8tvUj7ex/MD8JOfqhk6w7y0A6xPtiD7rm4y6f bTmwy0scGW+u8WPLOOk2828/9Zacs74lSEnVJn1wWPcuzJ4aV9YrdrLHCXqwMXFp/Or05MyVxZlL E5McihctbzHehXPH5MXJOgVxWpyUamQGMeklH3d+MrizrVBJhp0z8VMbeU5xcRi9tRMuljw3tGsh +zXVZ1vBzrRQV16anZTzEhFJP+n7uL9mf4qunDWYqDd53brqlcZT2mmY7a7edRElRTEXbwDv0zSh iZzYIwbwd0g7lNkrdou92NMvdmd2in3Y7shgWOiQqcsH5G3vQPSTEH2OUuKQU3qJVZU//xS5NJkk L2XgZezU2Bh+GmpfoCtagteHwYS9atgFjs4mUEPs/wzUrqe4timu6E5wyH8aNtFD/CxstIOTYwfw c+QA0P3c6ADvKD7/ebpxdlAvWWX08+xNdtATbKWUqISYqPwC8Ub5UKxbYyDmoy8Q4RxXCXkNvtFi QfO0GDKH4QSFaiXsUjnFL2E+arroL0NcR64Txnk922o9SVXcCoZxlSo0nlteT7iQOyd/y4UXWSNi J95cKFJVKKJmO0sYNBMWVCrTG4fhJaccxniemllEW1tEs6ORVFKS2BYav+wleowOKBBbWCO025PB bQxyi7VR9mA2bl1U/kO8zErFdq18R2sjaJCrUZA6CyUOz7OtMbSy2jsy89GymjagDYh2OCjuw9wo J/rwZwCNgreSbWQKPyJTeB2iX4Tol9TucBHh/wbU3mf4Zxm3b4D/DpvFLzM2MSPnkEaIH0SE/gpZ gHryVzla6ETH6P01CLvVmHsH7389xSGXBLTf4Kd64qdcCl1fTFHuSCi/xJS9CSWFot9MUfYloei3 ZCj6bQj7OQhmVCi69QDM143knSav2mwglAkmyJyVyUS6fE6EBaPB0RorXtkKjLUVm1Jfjm7xeMIp towVMzCu2zZuA92SV8XVw9012kNpRe4PZqeCYhx6yC6ookzOM7TdhBVyCCp2yVlybCs2FT4l2EGv dpGilB8HhQSJW6NDgs3GKg77a769V7toiELNQYaz4Gc4/CdCUUSevXxpfHJubmrmGbTouSuXr45f mbo0Ixm2Kx4VhycbvzRdnyzmHyvpE0UobfsIxW+8rdE1h+LXITgkDS6TE71oanuVsck4tDuOP5qM P18mo3sTorcg+kpD/QbDRI73pF8hs5Pb2N+h7a+q2LTH+afG1vi78VCG8k/MNlX/76X62ylPV/2/ n+rvpJRM9X+Vi0VkXV9lWToT68Jfrg9x5vZ59dat4sg2ZkKkVE4enzh/5byyFdwIcyH6tuk7XlWB 1ywbpRXM3Evs2FPQRutx5PZAnpKsG75NqVecKQaFGfaQx3jZjpmrlSf4fozX81g5lLdn5e2yuu2R 1EdqE0/IzYnKjRZTOzwGRYtdn+wLaUfClSeUp4wxkcctMzR5gqCe52wHMya7e5KjlP0mMK41TRP7 oFvchz6cfnQqCWZlSZCrMW9D9McQfb01pL5eh9Q3eDjLa/9NbrPvJMdJdZlvMkDqCIj+hDs06dD/ lLdKglDC99/imy5KkKI/owzEO4S97yhQMsmf8yNaneFf8GibHH03lqA7keDdJgkYg6z2dxNfcI8I nJ1SsFOoM6mOZtF2EGEZ+qZTpvaR2nl1spSwSB2Q0nOePHea5eLcsnRgfFDC/tXIIyQRxyEm1uX1 4wkTdOJuQwBoPGulfxK+OmfDY0/xjcE3T53N5z4pNOvJNfGZb+HmWzng2LFzCtME461BRFbeW+N5 /mNQXXflbyuX2SYxnRO7oF/0oMvMCR3/UntXquT9NcL3exD9DUTfbo3vb9fx/bcK395n8eY7quJN YH+f2x0QdiZQe78Z7H+XBvsHMdi75P1307D+XsxNT7h9r4lbAl7e933QGKzuEcGK+v8UxjHP/ycs EybGHhga4kg7NHQ23/1Jgdyw5/7foToBcgsI38Ulz28L3qZc4z1VhVQI7klhmLGrxZXy7xN2P4To HyD6vqqCk7P8R3KJssgkon+iG1WHiX7AIyqB/mEqaMs6k8bbxn+O+znyY5xX/f+S6u+gOK/6/zXV 30VfsKj+f0v1d9NXK6r/31P9PfTViur/D5ZUmcB/sqQdfGP1Is5pOxI8gZeHSFNc0r0nlLv1rWYh 5QOfPHwvwf0wQ+jYraqnOrrk+JHamRQg8fa8Cv7qdkKVxxMgNAOtvhdrEe+JWJ6vSp/X1sBKPtpI 83HeMY75pIoP1R4uQyllD/8MpH56BOJrJ3QQvo7jpNFHEP0Iov+un8TsV60M7JcHx8n5i7pf0uiT pc0e2OyHzV6IhNjoUWfMm90QZcQKNnZA1CYQeoc2OyBqF+jqiE238rxUEekQtb+iIqAEL+0WO4T/ NmzqEHWKDZ12ZLgBc3ayj3wSMdPFvbu4DqKLjXbCNI314JguEMub7fI4qJsJ98BGN9U+xtwXsS+X YrmXHytib48I96nKJp1OU3GGstkdRLyBovF8Y+yQyUv3iY0OKlpiP6N4p9joBWc/kdL9rc/BfLSH D90PQHhfXADKwWYnRHuZ+8MZEe3jA6pd3DsgNnJsg8RuP91sqPTox+isfLMPooOi9l/0Ks79pGHS 00Hh/4A5t7M/eIB1IU+/HsWX0JTe0Lzk6Zd3P/Zi1wMqdUqGUcZleQSm44xHxK23ZCjLM0fO9BWH HuaLxr8sEvoTCX2R6HEcX5jmYUGpKnUEUvrdizeHaUGoHtzBcDgCr2GwPYAcToqNPtZszCepWL0l 5qNHefQohA9K3TwmamcAu0gZjwl/MKWM06z+Y4oRFZ2jx0l0lIuwcOuPMvPRk3WpchXc6qfB6TxE D7FMZ3m187S6znF6JZZpH46ci0d6UyPRee5FKU/I+wuiNkhvSlJeEP79DO3xWD6GFl0fZilvLWnz 0QSjobueUzyjvuAgJPfTdEtajKosF0eQ9bOidgrCwZQdPSt8Aza7IJoSYQGcImx0gTPMho0tnu2v cbbnxEbC5KJA3Hl7cMqLLAPjcG+SRvegh6ZoGKxAw7Y85aMHDSqs4n5sMXVwZzxpfOqVu3rvuJ6R 5/MYKlbQBtq33eOyJCGPJJODNHmamarNS6+e+EQ5TuX7uIx/r1/jqN0ecR4rPhicncmPbHHx9QI8 fXXEE7rBoiq3dcs7n/Ms24rFUZXFTjnKFT/OOpIh1UeVlxYa3HIU2pQMtcqBZF0wTaGelZXHu3z1 kpw8NGT2MiR1qa4XOSzFZxVNZwP1CiY3qxWLNNZ4asJnpDKsZWNRclI9oaf0x4849D0bU95Ojlca znPvfi5MnyM0fZjQECmb67okMH1ZqWSX4Tf9jUgqKrMYMVRZxFKrg1qeD9Nfq2zHGFB1sPzO1pnk djCQWqiDsHGN5Qq1OmJ34wUsqdVvAKJchUYctwJnI5a3LFYT9D82EVZG/5H0J5iqdI5lekWXpos9 YmdcBYMern/tEwOZvsxubQC3d5zQaF1I05t9NqO3HcPfC9ohDTd/0EvH+W0PiQOZvbQZRC4HRb92 lPkdErmMDnn6Gk2uJxXgFhe3rk58OtT6TGvLQdpdDt3SZRhZRZy8poZo5bmutTg32bpa+XGFzebi 5ZbqZgPMm0upzYXXu39x2PLzg8DA3q6MpnVlcgdye3K7+7Sc3ifw2o+/O/B3Z+81LjJl+cAcqaNZ EX1aRIuU/HgGBpofF+qgC9SBAWUPGdotCPcMjl8XYTuVdyitxMBeSpFrjeSRRRGe6kqQ/iztdbym PnS38+oDnGpYqYZPkhcaNE6cuLnG8enqlaeHHtc5QqWfUV9OxytebDiYopBllssGAqBE0EfdFhq+ 2OEvZmvhE7S3ltPSxjkpuhOBqwYK7B+NNadcZhbX6dyrXOavmONnY348McnP5ETq84S2xY8+b6+v 4aY99UHDaBJ55XnpKB1E4F9cS9Nfp729/IxntOo7qcM6fCHfsetV1Xp1NUBtsGR2jb+9lu8aVH3f q7pcXVA2Uz+bU1AdNW7adiW5Jc3Qp4Cv2r5n5NVnSKSk4Xr9QPq40fq68H9GkL38ZaH8fJta/Gk6 f9O9Reg08/8ZsE0Cl8dWfVgBIxxpDwJoEBmybh68vB4Wf8Uo4yUwUAA1AzIPU5yRX5qTAlnPD52o gyQRP8jwMSjTQ2IXXLYDq84crFkOzzQ4KK8Hg3uZnv7QsTcOSGUJrqoQo27wMWiohVD9+LuW4KIF KUMEMEKW9vExA8tjBWCpLcOoIYleroIrXfjCbPR+MLAi0UvJz0WUntCGnV4e8mIIkDOS4f5C8SSo QPMEb4aATMsgtXBQ62W0iV60tgrIrqLEvPRUbBNeKJNR2EaJkNsFaI0M1DYKWoMNV+SCW0XooQ2Z j0PyHzaXEHI9uqHowYIStqhuh0cRNlejBSdapKOFCUZwIUIENc6QEguOxIAzrYJSsr00Q7EekOZh 4uQGTaWxARsRbIxSzGzgxoMgoyATDyMYskow8XDycPAI8DCJvQUAUEsDBBQAAAAIADpahSx32Bw4 LAEAAKwCAAAHABUAZWczLnhtbFVUCQADMM6tPHfEyTxVeAQA6APoA32STWuEMBCG7/6K2bn0ZrZq 90NMQHZ7WCi0UC+l9BDr2C7oumgWl/76xu9NC+YwZDJP3smbJFjsn3fR28sjJMUnvAeLMIqeDq8R 0BakUiXs9mEUAiaUykumUHwIK2jQa56dKj8tCo7fSp19xuq6tmNZ2kX5hU3Zj2VFRpWuMj9n1BDM WS4dhsICgIDudWT93NFRBIycPnd1hJPMCTggZZS7qBeOCZ+Sca83sF3RuyXbpFX2evoBpN945Fhc FELcJ1VRKkqwte9wlFnWzTke7nJstjaj8x8b/o6k0ta+CUkDqt3/yAjc3BAOplYDg6CoUhxtm8Xy B+fUxSAf0PpPC+OgI9exm6nVjLi+tvbd9WObAp3Idl5k7M3M5ow206kZrTv3jFb6wzH944T1C1BL AwQUAAAACABxWfkqlquor18GAAD8EgAABQAVAG5zLnB5VVQJAAOl4V47d8TJPFV4BADoA+gDtVdt b9pIEP4c/4oV/XBEhwGTpGqq60kUaOEEJMJcW+lURYu9iX2yvT7vAuF+/c3M+o2EkKTV8QWWfeb1 2Z2ZbTQac5fF0l9Hgtk2+zabsjmPhUq5J5gnE6V5opVlLYNQFTj4W/MwUUwHgvniNkxCHQKUyVuW FMKKNXniMyVjoUP4j0lAZ9afi8kv6pStlfDZasc42/AsFHqHsmgc7fk881WbsRH3AuZFXCkWcAVY FchMWzyK7HWaiszjSpDBFtsGIWBhfx357FZGkdwynuxYU8QiuwuTu1P0eiMSdBQAmRUAQgdclxYZ BOjJOJZJtCP/wINPMmPinsdpBDZ8hRAexVJp+NrynbIoDm4yUYbO0gyScg8xgyEWahGDZELhueFd wvU6A3VKsqGLGkHWMlGiBrDK+lpn4WqtQcM21AHIkqcEaoHpiJXxtwwBgqldvJJR6FnkBmsGMhW3 6whiERvpcR1uxCn50yhZbRgaCvVFItpWo9GwrNwn8HruvrfAKwZ/06pVHZEiMIsAtMuazrn9B09s 5/Ly8pRSxr6eDdhCYHYFmEAOIMyJxk2VCi+8DckPUvJbn40Xo08fGoHW6ftOZ7vdtrdnbZnddZaL zmI0sO/jyKYoG78/j7FOPvbdEZ5t5GjFVejVmDLJo6OI27kzHrlonSBjuWAlgjnEDafdtU7Gy6cg uHMOkDxxJkHkSv75wA5E2Ot2ux3wPVGdRpFSdlQCAB3I9LtOad4IkmfHBPNEBTqOzrsV3+5V/7qk GxctCs4N8RKwq9XfwtOs7wH1il1nUktPRiY4BLPmxmk7LfbOnvGdjdHUTkAitfhR3lH5E3TjlnUy mn9BIvZJIM/RLQF3P4IbgbjBUZwnfSgXeKwVRIrV4oLca87Be3NREmmIhCjy89M+3ecZnXmcfOUF IuaqDfwqyVPyH390Cu9yztHFV0kbnzsViUN38rkkERctPEh2WX2Yu4MSfs+wQgOJSCYoML4jHO7w pd1PM2TQqTE4AIEQLrB49jaTKkjiQcYgBF+Fd7YnM9H5mQs6nHweucsbd9x3UMESaRz3bYf54Z2A Kg29J5B+iZsNewUMfz4FuqhAFw9BkJybodvfMwnrzpDMqjLBdfziAX5xBD+e9QcH4sG/SwycjxvM 2dvzAvQROgGsytNbIb+MplfXoyECeVJeA9/02sK6dTJwzuesGAA8nsgEchyF/+Z5xu2bwdVs9iSm xTKBQwFaNycDpoYfqH3dy+J0vDGXoU7xB6PkV9ZQAXf29pHP2n7s9x5sX+xvX5jtOp3Vtq+4XVmo U1hhsj1MRVvdTBBzrwaq8VYDrYi7AlHwVUeUrNklYwZuWDte4ymrgwU1RM85T+hKd8+ci0pFziyo IIVg8c1XGDsGOY213jAYj2b9qjvQsmUGG6pO5RiQr1nzrAud4FEdSTOZSpw9soNlhLTUG8QzzQFL ItmznSd6RA3Bmq7O1h5mEQZRKGgv6D6VeO9ZAz3WHHLN9S4F/e0iETjAroRI2DrxYQxGk74gWjHH 1IQ4XpwUxmGc1WBuiyTcJZydW1SnaX6u5mPQuBGkBzqSmbBpmhM8i0IA+hm/1ThF0+Ru+DPF1Eyr OMXaKNEqc6CEVubQaUmYCCq90u3jFbpJ3MKw5A6h8X9zJ1S6TDLI8TwvIU2decPF2ZBEeiTSe4HI laflCgLDA02iZyR69gJR9JBEbqYTd0m1EIL9Zy0QAA8PDAt2E3iMRGscGUHvUeikhO6VOEzB0fuI YePEZg5FoxDqPV8Xne4BubPn5JwDQiYwEvqLFaQZHkDh9xw2eU0gZbYLI5NXRvRYwWtCeyz9IMaJ OZi9/MB8P9CPMPjqzeNOl9WTBxYoOGXLjCcKzlNMxUoVnE+XMC69tedy8/88ee5VpDtPlR3ce8UE VVnPR6jXtWhDuzvtlKmoPRSv+8txlTVcmdZwzXXApjy5W/M7kScNd382a4cTkoK1/aqHP9ZZBmUW H8Nxqnft/bBTQJVhfHWH0zIKXLTYV7Firsg2Ib53h0J5WZjSy2A/KASz5hd6/zgXh9re/OgD6GA8 W+VHP8PvycfJfHhDbxuQp+9VmNCQiJURfc4x4+WSMPT9ebQ0j4MruEdPCMwmM3KKvh9hXnCwDr1o MN78GVR5Xh+G6MlTA5C7e0MXKK8DyL294Q+aJb6V/gNQSwMEFAAAAAgAS6sxLKa7/+nlAAAAUwEA AAoAFQByZWFkbWUudHh0VVQJAAPNh0c8d8TJPFV4BADoA+gDTZBBSwQxDIXv/RW5qSCtgiB49iKo yKDgTUonM9O1TUqTYWf+ve2uhz2FEN733osx76x4C7qgIEwxoYCvCMRHKL4q8AQf+/fbK9zZR2sA FtXy5JzwWgNOXGe0hOpK5QMGFVf2LSdjPi94kUJaR4QB/ZzwSiB5RVE4M4we0f+KNSbcP5AtezOB Joe+QuZxTWgNyf/lGadIUSOT9GzkM0rxocemsdeIFb6Gl8brHj8XzAHniiJNCSf7Fh5w87n0jFPl DFIwnDCBc+4zRcIube1Cl9IMXM7e15HKqo5X7WMrXpeb/h8wf1BLAwQKAAAAAAAng5osAAAAAAAA AAAAAAAABQAVAHRlc3QvVVQJAAOpt8k8i8TJPFV4BADoA+gDUEsDBBQAAAAIAMeGfSyPBOfKuAEA APEEAAAOABUAdGVzdC9pYWlrMS54bWxVVAkAA4XipDx3xMk8VXgEAOgD6AOlU11L7DAQfc+vGPOk YLvuvSqytCsiXt+8Igq+xnZqA9mkJFHXf++kH2l11UUspW0mM2fOOZ1kp+uVgme0Thqd83l6wAF1 YUqpH3N+d/svOeGnS8aynSSB+2vh65w7VNVicS0sag/Gwm7TfsaQ0CVo43e7vPNaqnJvLyR2gUtL CW00xIbaMcohSYaON+ielIfz+eHVgmU9PjFeVMbk/EFYPqxUu4wRJQJ/1N3KNaLAnJdYCYLjSwZ0 ZRMiU0i6jXPie+RHfIfcWHRon5Evs9kIG/pks471ko2qzjTZIzw53iubp9Brk7pG613s1JoZG4GT mp6S8hztkH9NTS9tSkzZnwhSCwe4bpQspFevUGKhaKME4b2VD08e3aAtwgedKfubwsSUKZeQW1mz ot4Oum1BVJw3NmWHm2VyrFNjYRyQofLo68pW/Zctj98VbhU8Wpiyjem6+NF4fTY8vx6DizgH/zUJ 8LVxOP1dUlOsVQFarLAbBgIEwiyRpO7DSy2LOsQCv8EMnLrRg4ymiDWNkanCJKHCFdEb3GnJT/zY epx+Zt6WQxePWJe+eVQ/2j3rcWef+N3/iWH5BlBLAwQUAAAACACJhHosIc+T93kBAADLAwAADgAV AHRlc3QvaWFpazIueG1sVVQJAAPR6aA8d8TJPFV4BADoA+gDrVLNT4MwFL/zVzw5bYmAMx4MARaz qLdlcTPxWuljbdK1BIrO/96WFjY3E3eQcGjfx+/jvWbz/U7ABzYtVzIPZ/FNCChLRbnc5uHr5im6 D+dFEGRXUQRvK6JZHrYoqjRdkQalBtXApO6PY4hIClLpiaujWJFO6HTBuKDTqW1wiefGFPZRGxsw DtEQoqhwxIRSro1AIpbrVYMV32Obhx4ZmNZ1miSVUnGpdq7N9b1gawsWs7tlGmROXhGA+bIDT5El RxeTzZKh8oD0II0jYjV4tFkMG4ZgpieNlBBUBd4+b617MGeKDdJrIEIz1W0Z8D6J+1rwkmvxBRRL YZpobDVtmEma/x1L0rU4wDFi8UB1uu60HxN8cs2AwDABSXbY1qREhxhZuMap1Yz0rNwe0SBRNPPX cXB7buBoI5ebsFyjjzMTR5AXGLFYJ17+snG27Mf/3baHWyOevoGBu4c7sHnicbBegZuBD568WFfy Q+bYnvj+5BfB3oq/fgNQSwMEFAAAAAgAioR6LPEjrqv6AgAAzw0AAA4AFQB0ZXN0L2lhaWszLnht bFVUCQAD1OmgPHfEyTxVeAQA6APoA81Wy27bMBC86yu2OtlALNVJ2iaC7KAI0qCXwGhToFdaoioC MmWQVB79+i5J2Xr6odQF6pMt7s7sLNezCm9eVhk8USFZzmfu1HvvAuVRHjP+a+b+ePwyuXJv5o4T vptM4OeCqHTmSpolQRDThBSZChZEUK4gFzBam6+dI8Jj4LkaNfNuU5bF47FOtAdcToN7gcHmRD/f 4HVPmlD9Wd1TFyaTuZVC4pgplEyyh+8LQRP2QuXMLVMgVWod+H6S516Ur/zNY6yjfYSPLKqF/Ual DrydXj4ETljqxw5zBO8HdecO4CdsaTQ5WngnTzPOQ78ZP+/N3+YuiWhwHoCHe8pjKmbuimS0j2xI oW/KA8PYqqKGhD0Lfdte/F71/zPHQSP6Yss7mHrwmFLY3iBZUbkmEcWBjCkwCcKQ0BgSHB2LeAaS cQxhCgP07TCeUsGUDhL5CkwdNtRzzi2BHo0D4ArDEiakgkpISWVINFubygR5zsUhFaj6CDJNY6Xp 47xQ60KVfxfIk1okjKy8MaREmmCJlBWvBjLUz0yl1fkTyQp6Bs8pi1IrxpyZSEmxWZeDmiVplKN1 1MsyNFjS+dhzPgy62l7AWkds++nLOmMRU9kr4kYZNgGvSPuX7gOBmCUJNe0yUhGUaIlEt09DbYbi 4yCdKmVip0xEdT696fo7sLrCLfQFdvBq2OzmhcDb3lPn9cA6Dd5xpXYs9u4/8dhTmOi/ckmo26Tu gNPrlHcnskp4YpIts1fd7EKxjP3G2OUr7LVKopRgy0IN8kvkM5a5pWzwVeEnc862TeusNvUOe9sv sGtJQxUetMFehbt490tscRtiO39NmWj8PDdLYlPNAU88ysA6rem/hdO4pQdfN+u/TXEGqLNnK+5c iXZ7ZIKS2Pw5lpTyqgJsVmliI9wme7Zy5dhDx7nt3EfO8/Xf7YfOe1TfOClLEHTGqCF9swBqr15H WH64fUPU7n+U6ZvQzqrwdzw/9Jrd8OYKpA+4Btpx9TIq9HtefkvDL3/+AVBLAwQUAAAACACNhHos S321jqcBAAB9BAAADgAVAHRlc3QvaWFpazQueG1sVVQJAAPZ6aA8d8TJPFV4BADoA+gDzVLBattA EL3rK6Z7SqCSYtFDEZJDCEkoFGPaFHJdS+NqQd4V2pGJ+/Wd0dqNHDs55VCdlpk38968p+L6edPC FntvnC3VLLlSgLZytbG/S/Xr8T7+qq7nUVR8imN4WmpqSuWxXef5UvdoCVwPF934/FfStgbr6CLg bhvT1peXAgwF62f5Q8+gsSP1w/xxR0EczwOxrmtDLFC3i5/LHtfmGX2pGA4NUZen6dq5pHKblEth LMx9s+3gzRYXeoO+0xWG4e/Gk4xnU+wP9ENLcDv7ssijIpwyj4C/4pVidsx6EVuqc/SHdnamnal5 kR6vE44i3fMJXTQRdWPZSC2n74XNEnhsEOzhIDa6Rg9ixSC2+wx4E/CyGnusYc32vnB9Bm9shXIV NbgboStHDRgLvnIdvsKPUXKPweAG6gYa+ThISkTpiXt3/4F9Z927e8e+0T3j3zIteAaGBLM13qza nRw2kGnNH4avdhN0EmVvcGRHHNOlLjgsS9/5Y0MYXqBccxwd9aiJd2kvIcmFsGGuZG/BKOolieNQ PiKLcdNJwOmeIT3NJyrSqai/UEsDBBQAAAAIACp+mizQmWlvIwAAADIAAAARABUAdGVzdC9yaV9p YWlrMi54bWxVVAkAA0CvyTx3xMk8VXgEAOgD6AOzCUgsSs0rseNSAAIb96LEvBTnjMycFDsbfSQO UNZGH6oSAFBLAwQUAAAACAByfposit0o8nsAAABnAQAAEQAVAHRlc3QvcmlfaWFpazMueG1sVVQJ AAPIr8k8d8TJPFV4BADoA+gDswlILErNK1GoyM3JK7ZVyigpKbDS10/Lz9dLzs/VT0lNSyzNKVGy 41IAApu8YkMr96LEvBTnjMycFIgeK6Aghj6gmJKdjT6qejus+uF6kxKLUOwkYLyCe2peSmqRrVJu Yk4qNstIcShZ+hTANqK5AskkYJjZ6EOC1w4AUEsDBBQAAAAIAFx/miz4B4ChSwAAAHgAAAARABUA dGVzdC9yZV9pYWlrNC54bWxVVAkAA4CxyTx3xMk8VXgEAOgD6AOzCUgsSs0rseNSAAKbvGJDK/ei xLwU54zMnBSFitycvGIroKCtUkZJSYGVvn5afr5ecn6uPlBMCS5thEXaSMnORh/VOJAdNvpQ+wBQ SwMEFAAAAAgAY3+aLPgHgKFLAAAAeAAAABEAFQB0ZXN0L3JpX2lhaWs0LnhtbFVUCQADibHJPHfE yTxVeAQA6APoA7MJSCxKzSux41IAApu8YkMr96LEvBTnjMycFIWK3Jy8YiugoK1SRklJgZW+flp+ vl5yfq4+UEwJLm2ERdpIyc5GH9U4kB02+lD7AFBLAwQUAAAACAD7fZosGua6bksAAABnAAAAEQAV AHRlc3QvcmVfaWFpazEueG1sVVQJAAPqrsk8d8TJPFV4BADoA+gDswlILErNK1GoyM2xSsvPt1VK SixSgvFywFyQiB2XAhDYuBcl5qU4Z2TmpICVFBckJqfaKhUUpRanFpWlKtnZ6CNUgLTY6EOMtwMA UEsDBBQAAAAIAEN+mizQmWlvIwAAADIAAAARABUAdGVzdC9yZV9pYWlrMi54bWxVVAkAA22vyTx3 xMk8VXgEAOgD6AOzCUgsSs0rseNSAAIb96LEvBTnjMycFDsbfSQOUNZGH6oSAFBLAwQUAAAACAB6 fposUtBavXMAAAApAQAAEQAVAHRlc3QvcmVfaWFpazMueG1sVVQJAAPYr8k8d8TJPFV4BADoA+gD swlILErNK1GoyM3JK7ZVyigpKbDS10/Lz9dLzs/VT0lNSyzNKVGy41IAApu8YkMr96LEvBTnjMyc FIgeK6Aghj6gmJKdjT6qejvS9Cu4p+alpBbZKuUm5qRiMw2ZrY9dgpAVYCPRrEEyCehrG31IANkB AFBLAwQUAAAACABZgZospsYJ/OsAAACxAQAACwAVAHRlc3QvZW5jLnB5VVQJAANJtMk8d8TJPFV4 BADoA+gDZZDBbsIwDIbveQoPDhlSFgNCHJB4jh5QD2lr2kxtUiWhjLdf0zZsbLlE8Wd//pX1G+DN Oyy0QTID9I/QWMOY7nrrAviHF+CD06YWUChPx4MA6xlb9yo0cAaOje0IHam6JaxUULi/U4FZllU0 4H673eFX13oqP2Y1BvIBOWNX6+CqWwJt4hqpXD1cdqf8xGA82kzsDJd456+1OZD8tLFCbeXfZyRW q83UaW/h97jgsjgeeP6H/dcs7Onpx4aw7BVpciIp0KixPZkUgDv+kyCxZOX3EU50/klJprQVxVkR ezYvZlm21tNTtjzZN1BLAwQUAAAACABagZosmVKUEZcAAACjAAAAFQAVAHRlc3QvcmlfaWFpazQu eG1sLmI2NFVUCQADS7TJPHfEyTxVeAQA6APoAxWMyxJDMABF937Fpk3LyJJoiVIJM1V2jXREiZpR 8fj6sribc85ccnVEKR8jd883jOwKu/NYrhczOQWCycR9ee1QIOfMsp33u4NYigP3bTNcoGTAGnMA fyEwVi1KcfX2jgPrInPbQtLgy/1kimtLFRKqUN4VS+F2gmvymdTWzHHDlzwzGgpEzzyqo9quCIJU y59Byzqqa39QSwMEFAAAAAgAWoGaLLO291ODAAAAjgAAABUAFQB0ZXN0L3JlX2lhaWsxLnhtbC5i NjRVVAkAA0u0yTx3xMk8VXgEAOgD6AMLcHPKSM4NK01xdjJJCi83i8q1LAsI9sqMjPDM9PTIKEly KchNMrIshohBxAPS89M9nR3TA1xTKiPDTbMDjTIKktwD07lS3Q2L/fP8yiPD/XKAGsqBBldFRXgZ RQV7agc4W3ok57qVRrn65SeGV2SDDXEpLwt1d6uMCjc1CEi3teUCAFBLAwQUAAAACABagZos193t EzwAAABFAAAAFQAVAHRlc3QvcmVfaWFpazIueG1sLmI2NFVUCQADS7TJPHfEyTxVeAQA6APoAwtw c8pIzg0rTXEx8fZ0dkz3dKnwSM51K41y9ctPDK/IDsgqLwsy9spIyg1ySXTPKY6CqLPwMYTrs+UC AFBLAwQUAAAACABagZoslktPM+cAAACSAQAAFQAVAHRlc3QvcmVfaWFpazMueG1sLmI2NFVUCQAD S7TJPHfEyTxVeAQA6APoA42QzZKCMBCE73kVL0iJBUfJYhILJaDLT24GtiRgxColBp/esKfV4rDH ma7pr6fp2q9LmfYV9Bc80335tMQRJ1b51anQZooPTsNtSzGUyiJPbxUkMyhWJwJXLr9sddRWQ5E5 bWzXV8BRfPpB85sRlqNI95uuwskjEq5i0lOh3Cm+9wwkELR5qE8Dcz+jyHluD1cMSrnuWbDrjplu Ca7v3AiRHMXphKMZET5mxozlxCNyXnP0/QsCk6TgY4Ye/guljcZTIcA/UowvLhM77U1vg6nhXmT6 TJqFG1rvUDCWachxkW/O/GIWL1BLAwQUAAAACABagZosmVKUEZcAAACjAAAAFQAVAHRlc3QvcmVf aWFpazQueG1sLmI2NFVUCQADS7TJPHfEyTxVeAQA6APoAxWMyxJDMABF937Fpk3LyJJoiVIJM1V2 jXREiZpR8fj6sribc85ccnVEKR8jd883jOwKu/NYrhczOQWCycR9ee1QIOfMsp33u4NYigP3bTNc oGTAGnMAfyEwVi1KcfX2jgPrInPbQtLgy/1kimtLFRKqUN4VS+F2gmvymdTWzHHDlzwzGgpEzzyq o9quCIJUy59Byzqqa39QSwMEFAAAAAgAWoGaLDHrmyCsAAAABAEAABUAFQB0ZXN0L3JpX2lhaWsx LnhtbC5iNjRVVAkAA0u0yTx3xMk8VXgEAOgD6AONj70OgjAYRfe+igsSMHZgkP9igk2IFrpZMAWh YIL8yNNbIUbdHO5yvuQ792LXzFNx6jLL1BgZNlTAHkdBkcSoQH5+Z/ZNMBW2C/vhbUL0WvKKFYhf vHULDnU4JCSsJCwpoXlGRgVdtT2ydhzZo58Kt6NO2JzJWH6ebyESgSzxCpxS1ZkF4A9zTaPF/CUe 5JqJxoEqbytswVkK3lbMG9lk6I+e+6BEVzA3DPAEUEsDBBQAAAAIAFqBmizX3e0TPAAAAEUAAAAV ABUAdGVzdC9yaV9pYWlrMi54bWwuYjY0VVQJAANLtMk8d8TJPFV4BADoA+gDC3BzykjODStNcTHx 9nR2TPd0qfBIznUrjXL1y08Mr8gOyCovCzL2ykjKDXJJdM8pjoKos/AxhOuz5QIAUEsDBBQAAAAI APZ9miwFKdwmaQAAAL4AAAARABUAdGVzdC9yaV9pYWlrMS54bWxVVAkAA+CuyTx3xMk8VXgEAOgD 6AOzCUgsSs0rUajIzbFKy8+3VUpKLFKC8XLAXLhITmJeuq1Sah6EV1yQmJxqq5SSmpZYmlOiZMel AAQ27kWJeSnOGZk5KShGAlF+cXEifpPTU1FMLihKLU4tKktVsrPRRxgLssdGH+JqOwBQSwMEFAAA AAgAWoGaLMOuVhwdAQAA5wEAABUAFQB0ZXN0L3JpX2lhaWszLnhtbC5iNjRVVAkAA0u0yTx3xMk8 VXgEAOgD6AONkc1ygjAUhfd5FTeYggOLLpDfWFSEFiQ7Ax0CmMIMEsGnb2BwRp0uurxzcs+Xc65v r2nKoi4z1jKJ+y69ScXJDaTUrLkHMSeDUhIocexELDlGbWaghVHoOTJ0lfxs+32VDUmsVAdIG0Cc Q/7tLFshrEbRDzd15gbXfaFyzDTusR0noSYgVuGXV/5qIPYXvqPctp+NC1Jmd9ja1ae4r5BLL0QI j4YJs4fZsMIxplncS6i4p2hGiIYYlTJXXwFv0BiBapdA7eJBQQhRHsCoE7EGYXpJ4v6MSlmdNEF/ hPtl/zSD+2/2bHz8d19jtMlQeolnPc05+G9faO4Fi2V8RCLakhLna+oxeNtQwgITnJxzi035Y7yO t5wva8rv4BdQSwMEFAAAAAgAWoqaLMGMpURwEAAARisAAAwAFQB0ZXN0X2MxNG4ucHlVVAkAAzzE yTx3xMk8VXgEAOgD6APtWmlz4kjS/s6vqFbHNDAGcfnExrM2YCyPwRjTxsbrcAipANlCYiRxeXb+ +2bWIQmMe2YnNmLfD68jGlSlzKw8nszKKvrrF5Kb+V5uYDk56szJdBWMXSeR+Eq6Y0p8OqcOoUt9 MrWpT4aeOyEBzFd1x3UsQ7fJQ/Oa+FNqqMAxDoJpOZdbLBbqoqS63ijX7eSK+Xwh16lXs8uJnTUK u04WZ/Klwl4iEXircoLA34xUyAwEuiZN0KVBpwFp6RNa9zzX4xQmHZJZapkuezSYeQ5ZJhJ0VAA2 RVFOfgHZZE4933KdilJQ88ovp4kEm876wQpUH1MagJSxR4cVxXQNdenbCgoOVlNaUQK6DHI4BTOM 9Uvtptp9bNcJ0JK7x7tuvUkYnxmYChLA8+kltW03QxauZ5tfTr5ks6TqTibUCUghkc2enuSQCPWY WtmFBX6dBVlTD3S0RywT4ykS4NmYK7E5MBGtLQprmVSQcGLYVHdO8SnHH9msaXnBCmfP4N85e8un 2NuJtaQme0QK8b1dErJLgh8Khb8qE54T0oXlQu+S0HvNp08nX8663WvtrkvoEdGDwCPV2ln3DLxM h/rMDpTT59NEZCstwGdOPBfhE9xLi2JcQhUcAAyuRG06KWEgLbMSDULeXUnLX+7GKdmASd4V1HtE L6NyFQWCp5CBGPiuF1BTYXoXK4pu2/y5omjJiSJ8QgB+jl8eVJRYYlg0GGJqbBDpa0Q8e9ZJQgKR jYxCGrUvaZQfyZPBAoaDDaFrqoV0nPbwPxMeMR79mDFcL7e+YI4eRprm6AG3MUf3/8vAEkoNXXdN rYHuRQb9P+7+r+MOHMUiCGH7X2BwdysGSQRCx/UmmgmhJlqNfNWa7WutXjvdIMDNzudgbTW7N7/W W3cx2mcgDwshblWnF5bnB8S2HPrt6zJvHn/7Wsgf31HDdUw2e5JjZIxhrtszegp0peLxSY6P+Pbh TqazgJ6efHliGfLE3yl5hXz7RtjgRCnA6BcFBpaplBWKG7Ly/AxQldxxUdApTL1KMiYHIHPMPri8 b3ZwvFVk8pSNN8Siazi+kyBq6vrHMAuWFPNocQk+ljp8HLFp/j6Zi1gjrwI/37o+YcYdLc7JAvaf LcphIVCxtxUViSjoOEbF6sugDvt8vdXVuo9RyIFSTEEXUCAK6zSU9eli2JewBkQNlsEGBQgPaaju BWN1ZA0V0mLlEB6RunXTPetqNy0ch8Rziy5grNIlBZGyXEb6QtVi0nnCfUMdjzPsu3j8JRH2PdjJ XEPfFepHAKCBbjlCZYWkoNmzZ6bljFhb+dvMDaifjjc9+5+2eGAh9IvACsXv7iZ7eLh3lC1g48dy BUK1f3S8FpSDPwsK1HdYpexPdYOSlNgu/jX1qE+9OU2TpHxMnsa5SpvJnVjbYLbXG1GNFiXj04oJ e4+sQSdcNVbHYoXqhK1dUeqlqH5F21MO+eMekG18BQoUNM8Z+CjiRwk/dvFjDz/28ePgOQGhCF7A YnAC8vzOFgC+Mkkmk+3a0e6gtwiMUmdv0Lh/1xv3tlk9d43J/aR9d/U2KDZn9LLlayN3pFXP8/Th 3Ib5fP9hnL8ujd+ZsEFVg5dnufbIPew3jl7bb2N70FjOr6vnpUHpyu9X64faXT7Q6q35oFewB87t qHnrBtfd3cPrYmfOhDy+7/4K2iz0u0JJf+i4g9J9/rrXGZuNOhP8QYB1hgJ+bVfrwfXdeY1rUiwE /d5eXqs1R9d3+R2wMJMQBhe5wY3OHJcCfUftRsvv9y5mbetspNUW88fi0n7s7e5U2Xj5pj9c5Wl3 Fw0/R/pbmGfCkLjfsFfm5ZskDvSHsd2vccGM+NYdiedDKZgtWj165bo27seD1xjDKGKQwtn8HczV mYfRW1PD6eyBQ4QmjOG8VhUmDHr2br93u1N9RQ0hFKNKJe6EUuSE1TlEfjkz3qeTQfHwSJuM8+bl 2f716qhklozZ4+RidT05WvVXmrTRbrKAfV8yYW2u72G/q+2AUXbzVXr1+7vWsN8AJoCC+6C50kaD yUXQ7+atfm9pD7pNqw3qMSH9bjOU3qqeT/s1SXRraY298aD3HTS7hzDl89orWz0fLfydO4E2Cv7A acZNsGnjIjAaS1uYMBI0+4+ghX7ZyRs1d34NhpqrvRIT0lztzY2JYWmX42DQ2Hu/mWgffKL37vN9 S9A1LuAd0Ly9OYM7jWvy+ACSX5HxwseseHydjs3Lzgp88Q6ZkIfQAGN9n9PlLQS5MKsQjynY9vhD laW27Qg06PgSai/QtfcOq7qw+uLGOpwDW+l6Yttm43EGmjhaDHkh6rojuegR18QCE7oSH1djsJpH q7rxD6J3cxfiaSwXZkK2rm6dS7+89Xv9sdlbSj/sxU3Cf1HGdUfx1ZG4JLEAz0WsElhOIL3XML/7 MfEvOza9vN3pTOyVUbodDRr2rH/3+ErrtwdVu2U/Fo9m/eq5r/f2bIA2q3ZrmDchvmbv+04TcCyf BYxfoQYtzIeO3Xb648HlvX01MfM3K22hWWcTDpJeYXGzgpcPZwfapSRaItGyCaBpr66Kj73ltF/V 9gH7KwMgrL1ieToKjMv7vEicsIbNBw/nBbPxfQRqLhBVUqMr56IwKN0eNKv9pdk7ggXOJnJxDpIP GgjC9/pCMmu1w4nxcD83a4HQStK43Bzx0jacq7lhyZW0HdRC791CSEINpY8QA4FMIIG0M4fHlUVh opXG51dWa/cGi1/VGHFwIObza0K6WFgemvHsy1tQMVFAHQXcYlhrb1C7WZWKM60JuuvdciGg8pFm GSNk7jBt6iBstAdasLI1gGgMvkN5+wRte/EKy0DeAfR0YFNiBdHpXADyRN6ea1Dr/MFqMTKLILVx O5Z1W6BtvXjvx4B8UP2tu73EH2wp8R8KyLT/0Jls1kbzvfW6PXUd433LXvBrrPKsZN1s32m8htam vDswGhevWPuNyyvbKN6vzMl3ayPHofI0R8zxb7B38DrwLmnCmgiTq1i+Lz9G4A+88Lx2dZM8tPVg THQ4R7V1D5q9hDWZwqGb+Cs/wy4L8cuDBnGgG28Zchd40IFqNxky0H26D02Uz2YS7KoUe1bBv5yC 3HBWZUO1Cu0wnNMkjRhGVKY7gR48UD2qm9STZO1VHdk5Gd6ohvzyVtZ6p4mvm1K2UoHZzRW7wLV0 m/B11ET7sQ4Nn1hH7bDZhGHrvk/4YOh61cJuqy46yhQwpPk9LfjzbEMeCVwyBo/aFCZ8154F0MMT d8hvkkFMeMGsShHhla/lWAEPRMqn9lAswjD+WFc334YvcaRO2RsVzinUc3Qbzi1WsOrQ4SXTxQML GRll89DoDhPhstEcE5whP+veyI+tDoclnCFfKiQ1SyXx5JNMZ0jLdWiGwER45JGz6TIRN9f5rVpW xzqgCjSt6YEuNBRikpFdQkSBa/qV3MCJyLNMSnx3QsmEBmPXFNf0G9GTls0ctqDJvVGjhr1uIZlC lENqxw10jNZndLErfIEuvMI3uIBZMDx8WXhWwHzNX6i2677NpqkkvMweJtNPpWd54a8xAZtX/pGM VNz/whGgAVINZpYdWE4qwmBn5jB4iTcEzzLx3y8QdexnCwk2QDSxAG7E050RTdnUSUlUpmPrOrMJ 2GLtFMIZOoIJSfpkPSfCN0MLpPDLwaQ7C34yVcjGJPkJhYREof/kn+urM8e2nLeU5I/Czz21Ts/j EI6g+AQkWXPxSP2TmSE/+aqq4qIpWFVWJygoUxtqWIqOnvLlUv45Q5L/dJL4CV/pdCYSiKHbnvPp z22AigNsnor+5hUSVto0g9TZF6ALzpsbNnEr/umEJKAb6OylYs7gK4tKrDKWF5CcWqfAGwfLmdHI oq+kQQOGAgcg6dPgmA04Qsb6XCSTrGEG1HVRmLi7AywnGNNULqeSf5Fc7h8/sy+MFbs7KJd/TicT MQ2AWtT2FLgmHa8iCJ8K2/03ovrXlnmCDCUsM8tlg/9olEqnn6PVqR1b5KC86Zt1zTLgedegvu96 Ld+v/J7E64oktAVbbjCSf6w7OkoR8Kpt+QGI5rtcHa/+9ICmhFEZFhRYsgLf6SgweMkg91NVPsTC CTk0xN8J10pCLK4yrDPHn03xqgbKXBtKuLXEny4hvwEd7BfIjwGPx5pGsR4uhSFPz3H8xHdQopPa TZPgz3vwaLrGjP1w588GgCzC2HXDcD1+x+Xi76VZTKNtGCishye+DI8OeiAjZFekn9GdLPB+pRDL Mdunf0tczKN0CX4JqAkO4N2NCiUcc4andPx+6ImOntdw7asjGrA731SaWSdkbU30m7fkDxQXRGxn +JLc9qrhBmVWv+KrbpUhtWDUUqd1HLNtx9dhExB1X/AmkzesFPkYUKhK0pbsIEOyWbnRxP7kHsQ2 m7WNiPNRsv2vjneivjXnnJx2+pdoYf+Sw6kAPmd3ROHPbLCfmaaFNgH2W3dhrqQWY8gufg2KoJjA yIz8mc2GJciviHaXzVtsy0NvWE4FH6UjYP/gOTa0AE345ufwfpVYPigH6cEXyLqhEIBnTEoPMx4z 6E8EAZeQNEYhY2pv+q7N4hmMgZ6124x4SX6bUW+FLKxqVdiQkDu22gpOBHA0OOtehuUtoQ2ZAiTF WgdnOgtysDZ8pVET23qjZLlcZlgHADBwcIRvZlCWiA4ochLyBpukqDpSM0RhXVFm6LrsNj+tJrA9 SUA6vbygnJcXbDiVl5eJbjkvLwoHYNj9JKLcARZsYeDUokK/NmcpWCgTOVb16ZQ6ZiqZHSRFwov+ DfLHnXKfrG3rMAknH9bzVgSRyr/CRZ4KZWgkFIOOB1bZLTvlaXlZVjJr2fUE70W1UoCWSvjiAEOF 38IeeFxjVQBU+Bphgd8xEOJQAp4NeAgVImqSaDiE2g32xcrJWufB8zy0Jv9MdkiyjHWCtUddgIPA E0YcH1QoI9H2BYx0aQUpUYVFCDYODqKYtFz0JdsrwK2uY6/I0NZHvkq2LbN9ER43rZUhN9+7eJqB dyyTMvIRXMVoOJb/WssiwwPkeek8HqNMbEPkBx3YFpHC8U3LwNnf/wh7afBwBizEjhqhs3Zyggmc B/SNsefk1ibT61VflOC1udD6fHq7vAGXJxC0KTJKlD8TyrqmSKzBxUrXbMqNuazwmQiHi4hAuynk K3ZFcJwLCJ1jtKa65eEheVstJvzXVB/LIboeK7i3WhPn+DaoAxFQ/akNxq3bvHHayWcYVIEHTqvF DcWiCD8BAZxwnkEwe9opPMe6IiLBrbSkkWIXiqCO9Q87VmzQ2H9lICsaqMpnTqPcaSECN30Wvvjc 88A/5VJkgdgUEoE68lYyk/wUDBYX9xFe/E5AHVpYWEEA1txs4aMztRas5U55bQBZXnI9OB87ICb9 w/l6jUfsJJn4qfMTe+SfuJ3ZPJpLUemn4vN23Tljipkgl+N2fOo0lzsNCtLf9RqvcTG3Lf5Hbvvk RiNyW+mj27jy4tCy6bfFD/y25H5j+9mm52RVB30/nsRQwfZjXeT9xoGc6pOU1kqLes/vIH90EOTp z+k/P96JBip2uMPvcDMMkzWy4uORBBz1owOOfMhsPeRVRCqLTX8ND397qTQvbdwFwhMJEVPVsF0f N6l/A1BLAwQKAAAAAABxWfkqqGE43QYAAAAGAAAACQAVAHdvcmxkLnR4dFVUCQADpeFeO3fEyTxV eAQA6APoA3dvcmxkClBLAQIXAwoAAAAAAKeAmCwAAAAAAAAAAAAAAAAEAA0AAAAAAAAAEAD9QQAA AABDVlMvVVQFAAP6D8c8VXgAAFBLAQIXAwoAAAAAAKd9YStWHebZGwAAABsAAAAIAA0AAAAAAAEA AAC0gTcAAABDVlMvUm9vdFVUBQADWbThO1V4AABQSwECFwMKAAAAAACnfWErT9XX0hMAAAATAAAA DgANAAAAAAABAAAAtIGNAAAAQ1ZTL1JlcG9zaXRvcnlVVAUAA1m04TtVeAAAUEsBAhcDFAAAAAgA p4CYLKE9KQqGAAAA0wAAAAsADQAAAAAAAQAAALSB4QAAAENWUy9FbnRyaWVzVVQFAAP6D8c8VXgA AFBLAQIXAxQAAAAIAAN6miyntYff0w8AAMYyAAAHAA0AAAAAAAEAAAD9gaUBAABjMTRuLnB5VVQF AAN1p8k8VXgAAFBLAQIXAxQAAAAIAFt6mixBad+ZwBYAAIE2AAAIAA0AAAAAAAAAAAC0gbIRAABj MTRuLnB5Y1VUBQADHqjJPFV4AABQSwECFwMUAAAACAA6WoUsd9gcOCwBAACsAgAABwANAAAAAAAB AAAAtIGtKAAAZWczLnhtbFVUBQADMM6tPFV4AABQSwECFwMUAAAACABxWfkqlquor18GAAD8EgAA BQANAAAAAAABAAAA/YETKgAAbnMucHlVVAUAA6XhXjtVeAAAUEsBAhcDFAAAAAgAS6sxLKa7/+nl AAAAUwEAAAoADQAAAAAAAQAAAP2BqjAAAHJlYWRtZS50eHRVVAUAA82HRzxVeAAAUEsBAhcDCgAA AAAAJ4OaLAAAAAAAAAAAAAAAAAUADQAAAAAAAAAQAP1BzDEAAHRlc3QvVVQFAAOpt8k8VXgAAFBL AQIXAxQAAAAIAMeGfSyPBOfKuAEAAPEEAAAOAA0AAAAAAAEAAAC0gQQyAAB0ZXN0L2lhaWsxLnht bFVUBQADheKkPFV4AABQSwECFwMUAAAACACJhHosIc+T93kBAADLAwAADgANAAAAAAABAAAAtIH9 MwAAdGVzdC9pYWlrMi54bWxVVAUAA9HpoDxVeAAAUEsBAhcDFAAAAAgAioR6LPEjrqv6AgAAzw0A AA4ADQAAAAAAAQAAALSBtzUAAHRlc3QvaWFpazMueG1sVVQFAAPU6aA8VXgAAFBLAQIXAxQAAAAI AI2EeixLfbWOpwEAAH0EAAAOAA0AAAAAAAEAAAC0gfI4AAB0ZXN0L2lhaWs0LnhtbFVUBQAD2emg PFV4AABQSwECFwMUAAAACAAqfpos0JlpbyMAAAAyAAAAEQANAAAAAAABAAAAtIHaOgAAdGVzdC9y aV9pYWlrMi54bWxVVAUAA0CvyTxVeAAAUEsBAhcDFAAAAAgAcn6aLIrdKPJ7AAAAZwEAABEADQAA AAAAAQAAALSBQTsAAHRlc3QvcmlfaWFpazMueG1sVVQFAAPIr8k8VXgAAFBLAQIXAxQAAAAIAFx/ miz4B4ChSwAAAHgAAAARAA0AAAAAAAEAAAC0gQA8AAB0ZXN0L3JlX2lhaWs0LnhtbFVUBQADgLHJ PFV4AABQSwECFwMUAAAACABjf5os+AeAoUsAAAB4AAAAEQANAAAAAAABAAAAtIGPPAAAdGVzdC9y aV9pYWlrNC54bWxVVAUAA4mxyTxVeAAAUEsBAhcDFAAAAAgA+32aLBrmum5LAAAAZwAAABEADQAA AAAAAQAAALSBHj0AAHRlc3QvcmVfaWFpazEueG1sVVQFAAPqrsk8VXgAAFBLAQIXAxQAAAAIAEN+ mizQmWlvIwAAADIAAAARAA0AAAAAAAEAAAC0ga09AAB0ZXN0L3JlX2lhaWsyLnhtbFVUBQADba/J PFV4AABQSwECFwMUAAAACAB6fposUtBavXMAAAApAQAAEQANAAAAAAABAAAAtIEUPgAAdGVzdC9y ZV9pYWlrMy54bWxVVAUAA9ivyTxVeAAAUEsBAhcDFAAAAAgAWYGaLKbGCfzrAAAAsQEAAAsADQAA AAAAAQAAAO2Byz4AAHRlc3QvZW5jLnB5VVQFAANJtMk8VXgAAFBLAQIXAxQAAAAIAFqBmiyZUpQR lwAAAKMAAAAVAA0AAAAAAAEAAAC0gfQ/AAB0ZXN0L3JpX2lhaWs0LnhtbC5iNjRVVAUAA0u0yTxV eAAAUEsBAhcDFAAAAAgAWoGaLLO291ODAAAAjgAAABUADQAAAAAAAQAAALSB00AAAHRlc3QvcmVf aWFpazEueG1sLmI2NFVUBQADS7TJPFV4AABQSwECFwMUAAAACABagZos193tEzwAAABFAAAAFQAN AAAAAAABAAAAtIGeQQAAdGVzdC9yZV9pYWlrMi54bWwuYjY0VVQFAANLtMk8VXgAAFBLAQIXAxQA AAAIAFqBmiyWS08z5wAAAJIBAAAVAA0AAAAAAAEAAAC0gSJCAAB0ZXN0L3JlX2lhaWszLnhtbC5i NjRVVAUAA0u0yTxVeAAAUEsBAhcDFAAAAAgAWoGaLJlSlBGXAAAAowAAABUADQAAAAAAAQAAALSB UUMAAHRlc3QvcmVfaWFpazQueG1sLmI2NFVUBQADS7TJPFV4AABQSwECFwMUAAAACABagZosMeub IKwAAAAEAQAAFQANAAAAAAABAAAAtIEwRAAAdGVzdC9yaV9pYWlrMS54bWwuYjY0VVQFAANLtMk8 VXgAAFBLAQIXAxQAAAAIAFqBmizX3e0TPAAAAEUAAAAVAA0AAAAAAAEAAAC0gSRFAAB0ZXN0L3Jp X2lhaWsyLnhtbC5iNjRVVAUAA0u0yTxVeAAAUEsBAhcDFAAAAAgA9n2aLAUp3CZpAAAAvgAAABEA DQAAAAAAAQAAALSBqEUAAHRlc3QvcmlfaWFpazEueG1sVVQFAAPgrsk8VXgAAFBLAQIXAxQAAAAI AFqBmizDrlYcHQEAAOcBAAAVAA0AAAAAAAEAAAC0gVVGAAB0ZXN0L3JpX2lhaWszLnhtbC5iNjRV VAUAA0u0yTxVeAAAUEsBAhcDFAAAAAgAWoqaLMGMpURwEAAARisAAAwADQAAAAAAAQAAAO2BukcA AHRlc3RfYzE0bi5weVVUBQADPMTJPFV4AABQSwECFwMKAAAAAABxWfkqqGE43QYAAAAGAAAACQAN AAAAAAABAAAA/YFpWAAAd29ybGQudHh0VVQFAAOl4V47VXgAAFBLBQYAAAAAIQAhAHIJAACrWAAA AAA= --------------Boundary-00=_NB2774YQWHPCTZZJZ5GY Content-Type: text/html; charset="iso-8859-1"; name="test_c14n.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test_c14n.py" IyEgL3Vzci9iaW4vZW52IHB5dGhvbgoKIyBUaGUgc2V2ZW4gZXhhbXBsZXMgZnJvbSB0aGUgQ2Fu b25pY2FsIFhNTCBzcGVjLgojIGh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRu LTIwMDEwMzE1Cgp0cnk6CiAgICB1ID0gdW5pY29kZQpleGNlcHQgTmFtZUVycm9yOgogICAgZGVm IHUoeCk6cmV0dXJuIHgKCmVnMSA9ICIiIjw/eG1sIHZlcnNpb249IjEuMCI/PgoKPD94bWwtc3R5 bGVzaGVldCAgIGhyZWY9ImRvYy54c2wiCiAgIHR5cGU9InRleHQveHNsIiAgID8+Cgo8IURPQ1RZ UEUgZG9jIFNZU1RFTSAiZG9jLmR0ZCI+Cgo8ZG9jPkhlbGxvLCB3b3JsZCE8IS0tIENvbW1lbnQg MQotLT48L2RvYz4KCjw/cGktd2l0aG91dC1kYXRhICAgICA/PgoKPCEtLSBDb21tZW50IDIgLS0+ Cgo8IS0tIENvbW1lbnQgMyAtLT4KIiIiCgplZzIgPSAiIiI8ZG9jPgogICA8Y2xlYW4+ICAgPC9j bGVhbj4KICAgPGRpcnR5PiAgIEEgICBCICAgPC9kaXJ0eT4KICAgPG1peGVkPgogICAgICBBCiAg ICAgIDxjbGVhbj4gICA8L2NsZWFuPgogICAgICBCCiAgICAgIDxkaXJ0eT4gICBBICAgQiAgIDwv ZGlydHk+CiAgICAgIEMKICAgPC9taXhlZD4KPC9kb2M+CiIiIgoKZWczID0gIiIiPCFET0NUWVBF IGRvYyBbPCFBVFRMSVNUIGU5IGF0dHIgQ0RBVEEgImRlZmF1bHQiPl0+Cjxkb2M+CiAgIDxlMSAg IC8+CiAgIDxlMiAgID48L2UyPgogICA8ZTMgICAgbmFtZSA9ICJlbGVtMyIgICBpZD0iZWxlbTMi ICAgIC8+CiAgIDxlNCAgICBuYW1lPSJlbGVtNCIgICBpZD0iZWxlbTQiICAgID48L2U0PgogICA8 ZTUgYTphdHRyPSJvdXQiIGI6YXR0cj0ic29ydGVkIiBhdHRyMj0iYWxsIiBhdHRyPSJJJ20iCiAg ICAgICB4bWxuczpiPSJodHRwOi8vd3d3LmlldGYub3JnIgogICAgICAgeG1sbnM6YT0iaHR0cDov L3d3dy53My5vcmciCiAgICAgICB4bWxucz0iaHR0cDovL2V4YW1wbGUub3JnIi8+CiAgIDxlNiB4 bWxucz0iIiB4bWxuczphPSJodHRwOi8vd3d3LnczLm9yZyI+CiAgICAgICA8ZTcgeG1sbnM9Imh0 dHA6Ly93d3cuaWV0Zi5vcmciPgogICAgICAgICAgIDxlOCB4bWxucz0iIiB4bWxuczphPSJodHRw Oi8vd3d3LnczLm9yZyI+CiAgICAgICAgICAgICAgIDxlOSB4bWxucz0iIiB4bWxuczphPSJodHRw Oi8vd3d3LmlldGYub3JnIi8+CiAgICAgICAgICAgPC9lOD4KICAgICAgIDwvZTc+CiAgIDwvZTY+ CjwvZG9jPgoiIiIKCmVnMyA9ICIiIjwhRE9DVFlQRSBkb2MgWzwhQVRUTElTVCBlOSBhdHRyIENE QVRBICJkZWZhdWx0Ij5dPgo8ZG9jIHhtbG5zOmZvbz0iaHR0cDovL3d3dy5iYXIub3JnIj4KICAg PGUxICAgLz4KICAgPGUyICAgPjwvZTI+CiAgIDxlMyAgICBuYW1lID0gImVsZW0zIiAgIGlkPSJl bGVtMyIgICAgLz4KICAgPGU0ICAgIG5hbWU9ImVsZW00IiAgIGlkPSJlbGVtNCIgICAgPjwvZTQ+ CiAgIDxlNSBhOmF0dHI9Im91dCIgYjphdHRyPSJzb3J0ZWQiIGF0dHIyPSJhbGwiIGF0dHI9Ikkn bSIKICAgICAgIHhtbG5zOmI9Imh0dHA6Ly93d3cuaWV0Zi5vcmciCiAgICAgICB4bWxuczphPSJo dHRwOi8vd3d3LnczLm9yZyIKICAgICAgIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5vcmciLz4KICAg PGU2IHhtbG5zPSIiIHhtbG5zOmE9Imh0dHA6Ly93d3cudzMub3JnIj4KICAgICAgIDxlNyB4bWxu cz0iaHR0cDovL3d3dy5pZXRmLm9yZyI+CiAgICAgICAgICAgPGU4IHhtbG5zPSIiIHhtbG5zOmE9 Imh0dHA6Ly93d3cudzMub3JnIiBhOmZvbz0iYmFyIj4KICAgICAgICAgICAgICAgPGU5IHhtbG5z PSIiIHhtbG5zOmE9Imh0dHA6Ly93d3cuaWV0Zi5vcmciLz4KICAgICAgICAgICA8L2U4PgogICAg ICAgPC9lNz4KICAgPC9lNj4KPC9kb2M+CiIiIgoKZWc0ID0gIiIiPCFET0NUWVBFIGRvYyBbIDwh QVRUTElTVCBub3JtSWQgaWQgSUQgI0lNUExJRUQ+IDwhQVRUTElTVCBub3JtTmFtZXMgYXR0ciBO TVRPS0VOUyAjSU1QTElFRD4gXT4gPGRvYz4KICAgPHRleHQ+Rmlyc3QgbGluZSYjeDBkOyYjMTA7 U2Vjb25kIGxpbmU8L3RleHQ+CiAgIDx2YWx1ZT4mI3gzMjs8L3ZhbHVlPgogICA8Y29tcHV0ZT48 IVtDREFUQVt2YWx1ZT4iMCIgJiYgdmFsdWU8IjEwIiA/InZhbGlkIjoiZXJyb3IiXV0+PC9jb21w dXRlPgogICA8Y29tcHV0ZSBleHByPSd2YWx1ZT4iMCIgJmFtcDsmYW1wOyB2YWx1ZSZsdDsiMTAi ID8idmFsaWQiOiJlcnJvciInPnZhbGlkPC9jb21wdXRlPgogICA8bm9ybSBhdHRyPScgJmFwb3M7 ICAgJiN4MjA7JiMxMzsmI3hhOyYjOTsgICAmYXBvczsgJy8+CiAgIDxub3JtTmFtZXMgYXR0cj0n ICAgQSAgICYjeDIwOyYjMTM7JiN4YTsmIzk7ICAgQiAgICcvPgogICA8bm9ybUlkIGlkPScgJmFw b3M7ICAgJiN4MjA7JiMxMzsmI3hhOyYjOTsgICAmYXBvczsgJy8+CjwvZG9jPiIiIgoKZWc1ID0g IiIiPCFET0NUWVBFIGRvYyBbCjwhQVRUTElTVCBkb2MgYXR0ckV4dEVudCBFTlRJVFkgI0lNUExJ RUQ+CjwhRU5USVRZIGVudDEgIkhlbGxvIj4KPCFFTlRJVFkgZW50MiBTWVNURU0gIndvcmxkLnR4 dCI+CjwhRU5USVRZIGVudEV4dCBTWVNURU0gImVhcnRoLmdpZiIgTkRBVEEgZ2lmPgo8IU5PVEFU SU9OIGdpZiBTWVNURU0gInZpZXdnaWYuZXhlIj4KXT4KPGRvYyBhdHRyRXh0RW50PSJlbnRFeHQi PgogICAmZW50MTssICZlbnQyOyEKPC9kb2M+Cgo8IS0tIExldCB3b3JsZC50eHQgY29udGFpbiAi d29ybGQiIChleGNsdWRpbmcgdGhlIHF1b3RlcykgLS0+CiIiIgoKZWc2ID0gIiIiPD94bWwgdmVy c2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8ZG9jPiYjMTY5OzwvZG9jPiIiIgoK ZWc3ID0gIiIiPCFET0NUWVBFIGRvYyBbCjwhQVRUTElTVCBlMiB4bWw6c3BhY2UgKGRlZmF1bHR8 cHJlc2VydmUpICdwcmVzZXJ2ZSc+CjwhQVRUTElTVCBlMyBpZCBJRCAjSU1QTElFRD4KXT4KPGRv YyB4bWxucz0iaHR0cDovL3d3dy5pZXRmLm9yZyIgeG1sbnM6dzNjPSJodHRwOi8vd3d3LnczLm9y ZyI+CiAgIDxlMT4KICAgICAgPGUyIHhtbG5zPSIiPgogICAgICAgICA8ZTMgaWQ9IkUzIi8+CiAg ICAgIDwvZTI+CiAgIDwvZTE+CjwvZG9jPiIiIgoKZXhhbXBsZXMgPSBbIGVnMSwgZWcyLCBlZzMs IGVnNCwgZWc1LCBlZzYsIGVnN10KdGVzdF9yZXN1bHRzID0gewogICAgZWcxOiAnJydQRDk0Yld3 dGMzUjViR1Z6YUdWbGRDQm9jbVZtUFNKa2IyTXVlSE5zSWdvZ0lDQjBlWEJsUFNKMFpYaDBMM2h6 CiAgICBiQ0lnSUNBL1BnbzhaRzlqUGtobGJHeHZMQ0IzYjNKc1pDRThJUzB0SUVOdmJXMWxiblFn TVFvdExUNDhMMlJ2CiAgICBZejRLUEQ5d2FTMTNhWFJvYjNWMExXUmhkR0UvUGdvOElTMHRJRU52 YlcxbGJuUWdNaUF0TFQ0S1BDRXRMU0JECiAgICBiMjF0Wlc1MElETWdMUzArJycnLAoKICAgIGVn MjogJycnUEdSdll6NEtJQ0FnUEdOc1pXRnVQaUFnSUR3dlkyeGxZVzQrQ2lBZ0lEeGthWEowZVQ0 Z0lDQkJJQ0FnUWlBZwogICAgSUR3dlpHbHlkSGsrQ2lBZ0lEeHRhWGhsWkQ0S0lDQWdJQ0FnUVFv Z0lDQWdJQ0E4WTJ4bFlXNCtJQ0FnUEM5agogICAgYkdWaGJqNEtJQ0FnSUNBZ1Fnb2dJQ0FnSUNB OFpHbHlkSGsrSUNBZ1FTQWdJRUlnSUNBOEwyUnBjblI1UGdvZwogICAgSUNBZ0lDQkRDaUFnSUR3 dmJXbDRaV1ErQ2p3dlpHOWpQZz09JycnLAoKICAgIGVnMzogJycnUEdSdll5QjRiV3h1Y3pwbWIy ODlJbWgwZEhBNkx5OTNkM2N1WW1GeUxtOXlaeUkrQ2lBZ0lEeGxNVDQ4TDJVeAogICAgUGdvZ0lD QThaVEkrUEM5bE1qNEtJQ0FnUEdVeklHbGtQU0psYkdWdE15SWdibUZ0WlQwaVpXeGxiVE1pUGp3 dgogICAgWlRNK0NpQWdJRHhsTkNCcFpEMGlaV3hsYlRRaUlHNWhiV1U5SW1Wc1pXMDBJajQ4TDJV MFBnb2dJQ0E4WlRVZwogICAgZUcxc2JuTTlJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtOXlaeUlnZUcx c2JuTTZZVDBpYUhSMGNEb3ZMM2QzZHk1MwogICAgTXk1dmNtY2lJSGh0Ykc1ek9tSTlJbWgwZEhB Nkx5OTNkM2N1YVdWMFppNXZjbWNpSUdGMGRISTlJa2tuYlNJZwogICAgWVhSMGNqSTlJbUZzYkNJ Z1lqcGhkSFJ5UFNKemIzSjBaV1FpSUdFNllYUjBjajBpYjNWMElqNDhMMlUxUGdvZwogICAgSUNB OFpUWWdlRzFzYm5NNllUMGlhSFIwY0RvdkwzZDNkeTUzTXk1dmNtY2lQZ29nSUNBZ0lDQWdQR1Uz SUhodAogICAgYkc1elBTSm9kSFJ3T2k4dmQzZDNMbWxsZEdZdWIzSm5JajRLSUNBZ0lDQWdJQ0Fn SUNBOFpUZ2dlRzFzYm5NOQogICAgSWlJZ1lUcG1iMjg5SW1KaGNpSStDaUFnSUNBZ0lDQWdJQ0Fn SUNBZ0lEeGxPU0I0Yld4dWN6cGhQU0pvZEhSdwogICAgT2k4dmQzZDNMbWxsZEdZdWIzSm5JaUJo ZEhSeVBTSmtaV1poZFd4MElqNDhMMlU1UGdvZ0lDQWdJQ0FnSUNBZwogICAgSUR3dlpUZytDaUFn SUNBZ0lDQThMMlUzUGdvZ0lDQThMMlUyUGdvOEwyUnZZejQ9JycnLAoKICAgIGVnNDogJycnUEdS dll6NEtJQ0FnUEhSbGVIUStSbWx5YzNRZ2JHbHVaU1lqZUVRN0NsTmxZMjl1WkNCc2FXNWxQQzkw WlhoMAogICAgUGdvZ0lDQThkbUZzZFdVK01qd3ZkbUZzZFdVK0NpQWdJRHhqYjIxd2RYUmxQblpo YkhWbEptZDBPeUl3SWlBbQogICAgWVcxd095WmhiWEE3SUhaaGJIVmxKbXgwT3lJeE1DSWdQeUoy WVd4cFpDSTZJbVZ5Y205eUlqd3ZZMjl0Y0hWMAogICAgWlQ0S0lDQWdQR052YlhCMWRHVWdaWGh3 Y2owaWRtRnNkV1UrSm5GMWIzUTdNQ1p4ZFc5ME95QW1ZVzF3T3laaAogICAgYlhBN0lIWmhiSFZs Sm14ME95WnhkVzkwT3pFd0puRjFiM1E3SUQ4bWNYVnZkRHQyWVd4cFpDWnhkVzkwT3pvbQogICAg Y1hWdmREdGxjbkp2Y2laeGRXOTBPeUkrZG1Gc2FXUThMMk52YlhCMWRHVStDaUFnSUR4dWIzSnRJ R0YwZEhJOQogICAgSWlBbklDQWdJQ1lqZUVRbUkzaEJKaU40T1NBZ0lDY2dJajQ4TDI1dmNtMCtD aUFnSUR4dWIzSnRUbUZ0WlhNZwogICAgWVhSMGNqMGlRU0FtSTNoRUppTjRRU1lqZURrZ1FpSStQ Qzl1YjNKdFRtRnRaWE0rQ2lBZ0lEeHViM0p0U1dRZwogICAgYVdROUlpY2dKaU40UkNZamVFRW1J M2c1SUNjaVBqd3ZibTl5YlVsa1BnbzhMMlJ2WXo0PScnJywKCiAgICBlZzU6ICcnJ1BHUnZZeUJo ZEhSeVJYaDBSVzUwUFNKbGJuUkZlSFFpUGdvZ0lDQklaV3hzYnl3Z2QyOXliR1FoQ2p3dlpHOWoK ICAgIFBnPT0nJycsCgogICAgZWc2OiAnJydQR1J2WXo3Q3FUd3ZaRzlqUGc9PScnJywKCiAgICBl Zzc6ICcnJ1BHUnZZeUI0Yld4dWN6MGlhSFIwY0RvdkwzZDNkeTVwWlhSbUxtOXlaeUlnZUcxc2Ju TTZkek5qUFNKb2RIUncKICAgIE9pOHZkM2QzTG5jekxtOXlaeUkrQ2lBZ0lEeGxNVDRLSUNBZ0lD QWdQR1V5SUhodGJHNXpQU0lpSUhodGJEcHoKICAgIGNHRmpaVDBpY0hKbGMyVnlkbVVpUGdvZ0lD QWdJQ0FnSUNBOFpUTWdhV1E5SWtVeklqNDhMMlV6UGdvZ0lDQWcKICAgIElDQThMMlV5UGdvZ0lD QThMMlV4UGdvOEwyUnZZejQ9JycnLAoKfQoKIyBMb2FkIFhQYXRoIGFuZCBQYXJzZXIKaW1wb3J0 IHN5cywgdHlwZXMsIHRyYWNlYmFjaywgU3RyaW5nSU8sIGJhc2U2NCwgc3RyaW5nCmZyb20geG1s IGltcG9ydCB4cGF0aApmcm9tIHhtbC54cGF0aC5Db250ZXh0IGltcG9ydCBDb250ZXh0CmZyb20g eG1sLmRvbS5leHQucmVhZGVyIGltcG9ydCBQeUV4cGF0CmZyb20gYzE0biBpbXBvcnQgQ2Fub25p Y2FsaXplCiNmcm9tIHhtbC5kb20uZXh0IGltcG9ydCBDYW5vbmljYWxpemUKCiMgTXkgc3BlY2lh bCByZWFkZXIuClBZRSA9IFB5RXhwYXQuUmVhZGVyCmNsYXNzIFJlYWRlcmZvckMxNE5FeGFtcGxl cyhQWUUpOgogICAgJycnQSBzcGVjaWFsIHJlYWRlciB0byBoYW5kbGUgcmVzb2x1dGlvbiBvZiB0 aGUgQzE0TiBleGFtcGxlcy4KICAgICcnJwogICAgZGVmIGluaXRQYXJzZXIoc2VsZik6CiAgICAg ICAgUFlFLmluaXRQYXJzZXIoc2VsZikKICAgICAgICBzZWxmLnBhcnNlci5FeHRlcm5hbEVudGl0 eVJlZkhhbmRsZXIgPSBzZWxmLmVudGl0eV9yZWYKCiAgICBkZWYgZW50aXR5X3JlZihzZWxmLCAq YXJncyk6CiAgICAgICAgaWYgYXJncyAhPSAodSgnZW50MicpLCBOb25lLCB1KCd3b3JsZC50eHQn KSwgTm9uZSk6IHJldHVybiAwCiAgICAgICAgc2VsZi5wYXJzZXIuQ2hhcmFjdGVyRGF0YUhhbmRs ZXIoJ3dvcmxkJykKICAgICAgICByZXR1cm4gMQoKICAgICMgT3ZlcnJpZGUgc29tZSBtZXRob2Rz IGZyb20gUHlFeHBhdC5SZWFkZXIKICAgIGRlZiB1bnBhcnNlZEVudGl0eURlY2woc2VsZiwgKmFy Z3MpOiBwYXNzCiAgICBkZWYgbm90YXRpb25EZWNsKHNlbGYsICphcmdzKTogcGFzcwoKCnRyeToK ICAgIGltcG9ydCBjb2RlY3MKICAgIHV0Zjhfd3JpdGVyID0gY29kZWNzLmxvb2t1cCgndXRmLTgn KVszXQpleGNlcHQgSW1wb3J0RXJyb3I6CiAgICBkZWYgdXRmOF93cml0ZXIocyk6CiAgICAgICAg cmV0dXJuIHMKCmRlZiBidWlsdGluKCk6CiAgICAnJydSdW4gdGhlIGJ1aWx0aW4gdGVzdHMgZnJv bSB0aGUgQzE0TiBzcGVjLicnJwogICAgZm9yIGkgaW4gcmFuZ2UobGVuKGV4YW1wbGVzKSk6CiAg ICAgICAgbnVtID0gaSsxCiAgICAgICAgZWcgPSBleGFtcGxlc1tpXQoKICAgICAgICBmaWxlbmFt ZSA9ICdvdXQlZC54bWwnICUgbnVtCiAgICAgICAgdHJ5OgogICAgICAgICAgICBvcy51bmxpbmso ZmlsZW5hbWUpCiAgICAgICAgZXhjZXB0OgogICAgICAgICAgICBwYXNzCgogICAgICAgIHByaW50 ICdEb2luZyAlZCwgJXMuLi4nICUgKG51bSwgc3RyaW5nLnJlcGxhY2UoZWdbMDozMF0sICdcbics ICdcXG4nKSksCgogICAgICAgIHIgPSBSZWFkZXJmb3JDMTRORXhhbXBsZXMoKQogICAgICAgIHRy eToKICAgICAgICAgICAgZG9tID0gci5mcm9tU3RyaW5nKGVnKQogICAgICAgIGV4Y2VwdCBFeGNl cHRpb24sIGU6CiAgICAgICAgICAgIHByaW50ICdcbkV4Y2VwdGlvbicsIHJlcHIoZSkKICAgICAg ICAgICAgdHJhY2ViYWNrLnByaW50X2V4YygpCiAgICAgICAgICAgIGNvbnRpbnVlCgogICAgICAg ICMgR2V0IHRoZSBub2Rlc2V0OyB0aGUgdGVzdHMgaGF2ZSBzb21lIHNwZWNpYWwgY2FzZXMuCiAg ICAgICAgcGF0dGVybiA9ICcoLy8uIHwgLy9AKiB8IC8vbmFtZXNwYWNlOjoqKScKICAgICAgICBj b24gPSBDb250ZXh0KGRvbSkKICAgICAgICBpZiBlZyA9PSBlZzU6CiAgICAgICAgICAgIHBhdHRl cm4gPSAnKC8vLiB8IC8vQCogfCAvL25hbWVzcGFjZTo6Kilbbm90IChzZWxmOjpjb21tZW50KCkp XScKICAgICAgICBlbGlmIGVnID09IGVnNzoKICAgICAgICAgICAgY29uID0gQ29udGV4dChkb20s IHByb2Nlc3Nvck5zcz17J2lldGYnOiAnaHR0cDovL3d3dy5pZXRmLm9yZyd9KQogICAgICAgICAg ICAKICAgICAgICBub2RlbGlzdCA9IHhwYXRoLkV2YWx1YXRlKHBhdHRlcm4sIGNvbnRleHQ9Y29u KQoKICAgICAgICBzID0gU3RyaW5nSU8uU3RyaW5nSU8oKQogICAgICAgIG91dGYgPSB1dGY4X3dy aXRlcihzKQoKICAgICAgICAjR2V0IHRoZSB1bnN1cHByZXNzZWRQcmVmaXhlcyBmb3IgZXhjLWMx NG47IHRoZSB0ZXN0cyBoYXZlIHNwZWNpYWwgY2FzZXNlCiAgICAgICAgcGZ4bGlzdCA9IFtdCgog ICAgICAgICMgQ2Fub25pY2FsaXplIGEgRE9NIHdpdGggYSBkb2N1bWVudCBzdWJzZXQgbGlzdCBh Y2NvcmRpbmcgdG8gWE1MLUMxNE4KICAgICAgICBpZiBlZyA9PSBlZzE6CiAgICAgICAgICAgIENh bm9uaWNhbGl6ZShkb20sIG91dGYsIHN1YnNldD1ub2RlbGlzdCwgY29tbWVudHM9MSkKICAgICAg ICBlbHNlOgogICAgICAgICAgICBDYW5vbmljYWxpemUoZG9tLCBvdXRmLCBzdWJzZXQ9bm9kZWxp c3QpCgogICAgICAgIGV4cGVjdGVkID0gYmFzZTY0LmRlY29kZXN0cmluZyh0ZXN0X3Jlc3VsdHNb ZWddKQogICAgICAgIGlmIHMuZ2V0dmFsdWUoKSA9PSBleHBlY3RlZDoKICAgICAgICAgICAgcHJp bnQgJ09rJwogICAgICAgIGVsc2U6CiAgICAgICAgICAgIHByaW50ICdFcnJvciEnCiAgICAgICAg ICAgIHByaW50ICdHb3Q6XG4nLCBzLmdldHZhbHVlKCkKICAgICAgICAgICAgcHJpbnQgJ0V4cGVj dGVkOlxuJywgZXhwZWN0ZWQKICAgICAgICAgICAgCmRlZiB1c2FnZSgpOgogICAgcHJpbnQgJycn T3B0aW9ucyBhY2NlcHRlZDoKICAgIC1iLCAtLWJ1aWx0aW4gICAgICAgICAgICBSdW4gdGhlIEMx NE4gYnVpbHRpbiB0ZXN0cwogICAgLWUgICAgICAgICAgICAgICAgICAgICAgIEV4Y2x1c2l2ZSBD MTROCiAgICAtcCAgICAgICAgICAgICAgICAgICAgICAgRXhjbHVzaXZlIEMxNE4gaW5jbHVzaXZl IHByZWZpeGVzCiAgICAtbiBzdHJpbmcsICAgICAgICAgICAgICAgQWRkaXRpb25hbCBOU1ByZWZp eGVzICh3aGl0ZXNwYWNlIGRlbGltaXRlZCkKICAgICAgICAtLW5hbWVzcGFjZXM9c3RyaW5nCiAg ICAtaSBmaWxlLCAtLWluPWZpbGUgICAgICAgUmVhZCBzcGVjaWZpZWQgZmlsZSogKGRlZmF1bHQg aXMgc3RkaW4pCiAgICAtbyBmaWxlLCAtLW91dD1maWxlICAgICAgV3JpdGUgdG8gc3BlY2lmaWVk IGZpbGUqIChkZWZhdWx0IGlzIHN0ZG91dCkKICAgIC1oLCAtLWhlbHAgICAgICAgICAgICAgICBQ cmludCB0aGlzIHRleHQKICAgIC14IHF1ZXJ5LCAtLXhwYXRoPXF1ZXJ5ICBTcGVjaWZ5IGFuIFhQ QVRIIG5vZGVsaXN0CklmIGZpbGUgKGZvciBpbnB1dC9vdXRwdXQpIGlzIGxpa2UgeHh4LG5hbWUg dGhlbiB4eHggaXMgdXNlZCBhcyBhbgplbmNvZGluZyAoZS5nLiwgInV0Zi04LGZvby50eHQiKS4K JycnCgppZiBfX25hbWVfXyAhPSAiX19tYWluX18iOgogICAgYnVpbHRpbigpCmVsc2U6CiAgICBp ZiBsZW4oc3lzLmFyZ3YpID09IDE6IHN5cy5hcmd2LmFwcGVuZCgnLWInKQoKICAgIGltcG9ydCBn ZXRvcHQKICAgIHRyeToKICAgICAgICBvcHRzLCBhcmdzID0gZ2V0b3B0LmdldG9wdChzeXMuYXJn dlsxOl0sICJjZWhiaTpvOm46cDp4OiIsCiAgICAgICAgICAgIFsgImNvbW1lbnRzIiwgImV4Y2x1 c2l2ZSIsICJoZWxwIiwgImJ1aWx0aW4iLCAKICAgICAgICAgICAgImluPSIsICJvdXQ9IiwgIm5h bWVzcGFjZXM9IiwgInByZWZpeGVzPSIsICJ4cGF0aD0iIF0pCiAgICBleGNlcHQgZ2V0b3B0Lkdl dG9wdEVycm9yLCBlOgogICAgICAgIHByaW50IHN5cy5hcmd2WzBdICsgJzonLCBlLCAnXG5Ucnkg LS1oZWxwIGZvciBoZWxwLlxuJwogICAgICAgIHN5cy5leGl0KDEpCiAgICBpZiBsZW4oYXJncyk6 CiAgICAgICAgcHJpbnQgJ05vIGFyZ3VtZW50cywgb25seSBmbGFncy4gVHJ5IC0taGVscCBmb3Ig aGVscC4nCiAgICAgICAgc3lzLmV4aXQoMSkKCgogICAgSU4sIE9VVCA9IHN5cy5zdGRpbiwgc3lz LnN0ZG91dAogICAgcXVlcnkgPSAnKC8vLiB8IC8vQCogfCAvL25hbWVzcGFjZTo6KiknCiAgICBj b21tZW50cyA9IDAKICAgIGV4Y2x1c2l2ZSwgcGZ4bGlzdCA9IE5vbmUsIFtdCiAgICBuc2RpY3Qg PSB7fQogICAgZm9yIG9wdCxhcmcgaW4gb3B0czoKICAgICAgICBpZiBvcHQgaW4gKCctaCcsICct LWhlbHAnKToKICAgICAgICAgICAgdXNhZ2UoKQogICAgICAgICAgICBzeXMuZXhpdCgwKQogICAg ICAgIGlmIG9wdCBpbiAoJy1iJywgJy0tYnVpbHRpbicpOgogICAgICAgICAgICBidWlsdGluKCkK ICAgICAgICAgICAgc3lzLmV4aXQoMCkKICAgICAgICBlbGlmIG9wdCBpbiAoJy1jJywgJy0tY29t bWVudHMnKToKICAgICAgICAgICAgY29tbWVudHMgPSAxCiAgICAgICAgZWxpZiBvcHQgaW4gKCct bicsICctLW5hbWVzcGFjZXMnKToKICAgICAgICAgICAgIyBjb252ZXJ0IGV2ZXJ5IHBhaXIgb2Yg d2hpdGVzcGFjZSBkZWxpbWl0ZWQgIHZhbHVlcyB0byBkaWN0aW9uYXJ5CiAgICAgICAgICAgIG5z bCA9IGFyZy5zcGxpdCgpCiAgICAgICAgICAgIGZvciBpIGluIHJhbmdlKDAsIGxlbihuc2wpLCAy KToKICAgICAgICAgICAgICAgIG5zZGljdFtuc2xbaV1dID0gbnNsW2krMV0KICAgICAgICAjICAg IHByaW50ICJOYW1lc3BhY2UgcHJlZml4IGFyZ3VtZW50cyBpcyBub3Qgc3VwcG9ydGVkIHlldC4i CiAgICAgICAgZWxpZiBvcHQgaW4gKCctZScsICctLWV4Y2x1c2l2ZScpOgogICAgICAgICAgICBl eGNsdXNpdmUgPSAxCiAgICAgICAgZWxpZiBvcHQgaW4gKCAnLXAnLCAnLS1wcmVmaXhlcycpOgog ICAgICAgICAgICBwZnhsaXN0ID0gYXJnLnNwbGl0KCcsJykKICAgICAgICBlbGlmIG9wdCBpbiAo Jy1pJywgJy0taW4nKToKICAgICAgICAgICAgaWYgYXJnLmZpbmQoJywnKSA9PSAtMToKICAgICAg ICAgICAgICAgIElOID0gb3BlbihhcmcsICdyJykKICAgICAgICAgICAgZWxzZToKICAgICAgICAg ICAgICAgIGltcG9ydCBjb2RlY3MKICAgICAgICAgICAgICAgIGVuY29kaW5nLCBmaWxlbmFtZSA9 IGFyZy5zcGxpdCgnLCcpCiAgICAgICAgICAgICAgICByZWFkZXIgPSBjb2RlY3MubG9va3VwKGVu Y29kaW5nKVsyXQogICAgICAgICAgICAgICAgSU4gPSByZWFkZXIob3BlbihmaWxlbmFtZSwgJ3In KSkKICAgICAgICBlbGlmIG9wdCBpbiAoJy1vJywgJy0tb3V0Jyk6CiAgICAgICAgICAgIGlmIGFy Zy5maW5kKCcsJykgPT0gLTE6CiAgICAgICAgICAgICAgICBPVVQgPSBvcGVuKGFyZywgJ3cnKQog ICAgICAgICAgICBlbHNlOgogICAgICAgICAgICAgICAgaW1wb3J0IGNvZGVjcwogICAgICAgICAg ICAgICAgZW5jb2RpbmcsIGZpbGVuYW1lID0gYXJnLnNwbGl0KCcsJykKICAgICAgICAgICAgICAg IHdyaXRlciA9IGNvZGVjcy5sb29rdXAoZW5jb2RpbmcpWzNdCiAgICAgICAgICAgICAgICBPVVQg PSB3cml0ZXIob3BlbihmaWxlbmFtZSwgJ3cnKSkKICAgICAgICBlbGlmIG9wdCBpbiAoJy14Jywg Jy0teHBhdGgnKToKICAgICAgICAgICAgcXVlcnkgPSBhcmcKICAgICAgICAgICAgCiAgICByID0g UFlFKCkKICAgIGRvbSA9IHIuZnJvbVN0cmVhbShJTikKICAgIGNvbnRleHQgPSBDb250ZXh0KGRv bSwgcHJvY2Vzc29yTnNzPW5zZGljdCkKICAgIG5vZGVsaXN0ID0geHBhdGguRXZhbHVhdGUocXVl cnksIGNvbnRleHQ9Y29udGV4dCkKICAgIGlmIGV4Y2x1c2l2ZToKICAgICAgICBDYW5vbmljYWxp emUoZG9tLCBPVVQsIHN1YnNldD1ub2RlbGlzdCwgY29tbWVudHM9Y29tbWVudHMsIHVuc3VwcHJl c3NlZFByZWZpeGVzPXBmeGxpc3QpCiAgICBlbHNlOgogICAgICAgIENhbm9uaWNhbGl6ZShkb20s IE9VVCwgc3Vic2V0PW5vZGVsaXN0LCBjb21tZW50cz1jb21tZW50cykgIyAgICBuc2RpY3Q9bnNk aWN0CiAgICBPVVQuY2xvc2UoKQo= --------------Boundary-00=_NB2774YQWHPCTZZJZ5GY Content-Type: text/plain; charset="iso-8859-1"; name="c14n.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="c14n.py" IyEgL3Vzci9iaW4vZW52IHB5dGhvbgonJydYTUwgQ2Fub25pY2FsaXphdGlvbgoKVGhpcyBtb2R1 bGUgZ2VuZXJhdGVzIGNhbm9uaWNhbCBYTUwgb2YgYSBkb2N1bWVudCBvciBlbGVtZW50LgogICAg aHR0cDovL3d3dy53My5vcmcvVFIvMjAwMS9SRUMteG1sLWMxNG4tMjAwMTAzMTUKYW5kIGluY2x1 ZGVzIGEgcHJvdG90eXBlIG9mIGV4Y2x1c2l2ZSBjYW5vbmljYWxpemF0aW9uCiAgICBodHRwOi8v d3d3LnczLm9yZy9TaWduYXR1cmUvRHJhZnRzL3htbC1leGMtYzE0bgoKUmVxdWlyZXMgUHlYTUwg MC43LjAgb3IgbGF0ZXIuCgpLbm93biBpc3N1ZXMgaWYgdXNpbmcgRnQuTGliLnBEb21sZXR0ZToK ICAgIDEuIFVuaWNvZGUKICAgIDIuIGRvZXMgbm90IHdoaXRlIHNwYWNlIG5vcm1hbGl6ZSBhdHRy aWJ1dGVzIG9mIHR5cGUgTk1UT0tFTiBhbmQgSUQ/CiAgICAzLiBzZWVtcyB0byBiZSBpbmNsdWRl ICJcbiIgYWZ0ZXIgaW1wb3J0aW5nIGV4dGVybmFsIGVudGl0aWVzPwoKTm90ZSwgdGhpcyB2ZXJz aW9uIHByb2Nlc3NlcyBhIERPTSB0cmVlLCBhbmQgY29uc2VxdWVudGx5IGl0IHByb2Nlc3Nlcwpu YW1lc3BhY2Ugbm9kZXMgYXMgYXR0cmlidXRlcywgbm90IGZyb20gYSBub2RlJ3MgbmFtZXNwYWNl IGF4aXMuIFRoaXMKcGVybWl0cyBzaW1wbGUgZG9jdW1lbnQgYW5kIGVsZW1lbnQgY2Fub25pY2Fs aXphdGlvbiB3aXRob3V0ClhQYXRoLiBXaGVuIFhQYXRoIGlzIHVzZWQsIHRoZSBYUGF0aCByZXN1 bHQgbm9kZSBsaXN0IGlzIHBhc3NlZCBhbmQgdXNlZCB0bwpkZXRlcm1pbmUgaWYgdGhlIG5vZGUg aXMgaW4gdGhlIFhQYXRoIHJlc3VsdCBsaXN0LCBidXQgbGl0dGxlIGVsc2UuCgpBdXRob3JzOgog ICAgIkpvc2VwaCBNLiBSZWFnbGUgSnIuIiA8cmVhZ2xlQHczLm9yZz4KICAgICJSaWNoIFNhbHoi IDxyc2FsekB6b2xlcmEuY29tPgoKJERhdGU6IDIwMDIvMDQvMjYgMjE6MjI6MDAgJCBieSAkQXV0 aG9yOiByZWFnbGUgJAonJycKCl9jb3B5cmlnaHQgPSAnJydDb3B5cmlnaHQgMjAwMSwgWm9sZXJh IFN5c3RlbXMgSW5jLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4KQ29weXJpZ2h0IDIwMDEsIE1JVC4g QWxsIFJpZ2h0cyBSZXNlcnZlZC4KCkRpc3RyaWJ1dGVkIHVuZGVyIHRoZSB0ZXJtcyBvZjoKICBQ eXRob24gMi4wIExpY2Vuc2Ugb3IgbGF0ZXIuCiAgaHR0cDovL3d3dy5weXRob24ub3JnLzIuMC4x L2xpY2Vuc2UuaHRtbApvcgogIFczQyBTb2Z0d2FyZSBMaWNlbnNlCiAgaHR0cDovL3d3dy53My5v cmcvQ29uc29ydGl1bS9MZWdhbC9jb3B5cmlnaHQtc29mdHdhcmUtMTk5ODA3MjAKJycnCgppbXBv cnQgc3RyaW5nCmZyb20geG1sLmRvbSBpbXBvcnQgTm9kZQp0cnk6CiAgICBmcm9tIHhtbC5ucyBp bXBvcnQgWE1MTlMKZXhjZXB0OgogICAgY2xhc3MgWE1MTlM6CiAgICAgICAgQkFTRSA9ICJodHRw Oi8vd3d3LnczLm9yZy8yMDAwL3htbG5zLyIKICAgICAgICBYTUwgPSAiaHR0cDovL3d3dy53My5v cmcvWE1MLzE5OTgvbmFtZXNwYWNlIgp0cnk6CiAgICBpbXBvcnQgY1N0cmluZ0lPCiAgICBTdHJp bmdJTyA9IGNTdHJpbmdJTwpleGNlcHQgSW1wb3J0RXJyb3I6CiAgICBpbXBvcnQgU3RyaW5nSU8K Cl9hdHRycyA9IGxhbWJkYSBFOiAoRS5hdHRyaWJ1dGVzIGFuZCBFLmF0dHJpYnV0ZXMudmFsdWVz KCkpIG9yIFtdCl9jaGlsZHJlbiA9IGxhbWJkYSBFOiBFLmNoaWxkTm9kZXMgb3IgW10KX0lOX1hN TF9OUyA9IGxhbWJkYSBuOiBuLm5hbWVzcGFjZVVSSSA9PSBYTUxOUy5YTUwKX2luY2x1c2l2ZSA9 IGxhbWJkYSBuOiBuLnVuc3VwcHJlc3NlZFByZWZpeGVzID09IE5vbmUKCgojIERvZXMgYSBkb2N1 bWVudC9QSSBoYXMgbGVzc2VyL2dyZWF0ZXIgZG9jdW1lbnQgb3JkZXIgdGhhbiB0aGUKIyBmaXJz dCBlbGVtZW50PwpfTGVzc2VyRWxlbWVudCwgX0VsZW1lbnQsIF9HcmVhdGVyRWxlbWVudCA9IHJh bmdlKDMpCgpkZWYgX3NvcnRlcihuMSxuMik6CiAgICAnJydfc29ydGVyKG4xLG4yKSAtPiBpbnQK ICAgIFNvcnRpbmcgcHJlZGljYXRlIGZvciBub24tTlMgYXR0cmlidXRlcy4nJycKCiAgICBpID0g Y21wKG4xLm5hbWVzcGFjZVVSSSwgbjIubmFtZXNwYWNlVVJJKQogICAgaWYgaTogcmV0dXJuIGkK ICAgIHJldHVybiBjbXAobjEubG9jYWxOYW1lLCBuMi5sb2NhbE5hbWUpCgoKZGVmIF9zb3J0ZXJf bnMobjEsbjIpOgogICAgJycnX3NvcnRlcl9ucygobix2KSwobix2KSkgLT4gaW50CiAgICAiKGFu IGVtcHR5IG5hbWVzcGFjZSBVUkkgaXMgbGV4aWNvZ3JhcGhpY2FsbHkgbGVhc3QpLiInJycKCiAg ICBpZiBuMVswXSA9PSAneG1sbnMnOiByZXR1cm4gLTEKICAgIGlmIG4yWzBdID09ICd4bWxucyc6 IHJldHVybiAxCiAgICByZXR1cm4gY21wKG4xWzBdLCBuMlswXSkKCmRlZiBfdXRpbGl6ZWQobiwg bm9kZSwgb3RoZXJfYXR0cnMsIHVuc3VwcHJlc3NlZFByZWZpeGVzKToKICAgICcnJ191dGlsaXpl ZChuLCBub2RlLCBvdGhlcl9hdHRycywgdW5zdXBwcmVzc2VkUHJlZml4ZXMpIC0+IGJvb2xlYW4K ICAgIFJldHVybiB0cnVlIGlmIHRoYXQgbm9kZXNwYWNlIGlzIHV0aWxpemVkIHdpdGhpbiB0aGUg bm9kZScnJwoKICAgIGlmIG4uc3RhcnRzd2l0aCgneG1sbnM6Jyk6CiAgICAgICAgbiA9IG5bNjpd CiAgICBlbGlmIG4uc3RhcnRzd2l0aCgneG1sbnMnKToKICAgICAgICBuID0gbls1Ol0KICAgIGlm IChuPT0iIiBhbmQgbm9kZS5wcmVmaXggaW4gWyIjZGVmYXVsdCIsIE5vbmVdKSBvciBcCiAgICAg ICAgbiA9PSBub2RlLnByZWZpeCBvciBuIGluIHVuc3VwcHJlc3NlZFByZWZpeGVzOiAKICAgICAg ICAgICAgcmV0dXJuIDEKICAgIGZvciBhdHRyIGluIG90aGVyX2F0dHJzOgogICAgICAgIGlmIG4g PT0gYXR0ci5wcmVmaXg6IHJldHVybiAxCiAgICByZXR1cm4gMAoKI19pbl9zdWJzZXQgPSBsYW1i ZGEgc3Vic2V0LCBub2RlOiBub3Qgc3Vic2V0IG9yIG5vZGUgaW4gc3Vic2V0Cl9pbl9zdWJzZXQg PSBsYW1iZGEgc3Vic2V0LCBub2RlOiBzdWJzZXQgaXMgTm9uZSBvciBub2RlIGluIHN1YnNldCAj IHJpY2gncyB0d2VhawoKY2xhc3MgX2ltcGxlbWVudGF0aW9uOgogICAgJycnSW1wbGVtZW50YXRp b24gY2xhc3MgZm9yIEMxNE4uIFRoaXMgYWNjb21wYW5pZXMgYSBub2RlIGR1cmluZyBpdCdzCiAg ICBwcm9jZXNzaW5nIGFuZCBpbmNsdWRlcyB0aGUgcGFyYW1ldGVycyBhbmQgcHJvY2Vzc2luZyBz dGF0ZS4nJycKCiAgICAjIEhhbmRsZXIgZm9yIGVhY2ggbm9kZSB0eXBlOyBwb3B1bGF0ZWQgZHVy aW5nIG1vZHVsZSBpbnN0YW50aWF0aW9uLgogICAgaGFuZGxlcnMgPSB7fQoKICAgIGRlZiBfX2lu aXRfXyhzZWxmLCBub2RlLCB3cml0ZSwgKiprdyk6CiAgICAgICAgJycnQ3JlYXRlIGFuZCBydW4g dGhlIGltcGxlbWVudGF0aW9uLicnJwogICAgICAgIHNlbGYud3JpdGUgPSB3cml0ZQogICAgICAg IHNlbGYuc3Vic2V0ID0ga3cuZ2V0KCdzdWJzZXQnKQogICAgICAgIHNlbGYuY29tbWVudHMgPSBr dy5nZXQoJ2NvbW1lbnRzJywgMCkKICAgICAgICBzZWxmLnVuc3VwcHJlc3NlZFByZWZpeGVzID0g a3cuZ2V0KCd1bnN1cHByZXNzZWRQcmVmaXhlcycpCiAgICAgICAgbnNkaWN0ID0ga3cuZ2V0KCdu c2RpY3QnLCB7ICd4bWwnOiBYTUxOUy5YTUwsICd4bWxucyc6IFhNTE5TLkJBU0UgfSkKICAgICAg ICAKICAgICAgICAjIFByb2Nlc3Npbmcgc3RhdGUuCiAgICAgICAgc2VsZi5zdGF0ZSA9IChuc2Rp Y3QsIHsneG1sJzonJ30sIHt9KSAjMDQyMgogICAgICAgIAogICAgICAgIGlmIG5vZGUubm9kZVR5 cGUgPT0gTm9kZS5ET0NVTUVOVF9OT0RFOgogICAgICAgICAgICBzZWxmLl9kb19kb2N1bWVudChu b2RlKQogICAgICAgIGVsaWYgbm9kZS5ub2RlVHlwZSA9PSBOb2RlLkVMRU1FTlRfTk9ERToKICAg ICAgICAgICAgc2VsZi5kb2N1bWVudE9yZGVyID0gX0VsZW1lbnQgICAgICAgICMgQXQgZG9jdW1l bnQgZWxlbWVudAogICAgICAgICAgICBpZiBub3QgX2luY2x1c2l2ZShzZWxmKToKICAgICAgICAg ICAgICAgIHNlbGYuX2RvX2VsZW1lbnQobm9kZSkKICAgICAgICAgICAgZWxzZToKICAgICAgICAg ICAgICAgIGluaGVyaXRlZCA9IHNlbGYuX2luaGVyaXRfY29udGV4dChub2RlKQogICAgICAgICAg ICAgICAgc2VsZi5fZG9fZWxlbWVudChub2RlLCBpbmhlcml0ZWQpCiAgICAgICAgZWxpZiBub2Rl Lm5vZGVUeXBlID09IE5vZGUuRE9DVU1FTlRfVFlQRV9OT0RFOgogICAgICAgICAgICBwYXNzCiAg ICAgICAgZWxzZToKICAgICAgICAgICAgcmFpc2UgVHlwZUVycm9yLCBzdHIobm9kZSkKCgogICAg ZGVmIF9pbmhlcml0X2NvbnRleHQoc2VsZiwgbm9kZSk6CiAgICAgICAgJycnX2luaGVyaXRfY29u dGV4dChzZWxmLCBub2RlKSAtPiBsaXN0CiAgICAgICAgU2NhbiBhbmNlc3RvcnMgb2YgYXR0cmli dXRlIGFuZCBuYW1lc3BhY2UgY29udGV4dC4gIFVzZWQgb25seQogICAgICAgIGZvciBzaW5nbGUg ZWxlbWVudCBub2RlIGNhbm9uaWNhbGl6YXRpb24sIG5vdCBmb3Igc3Vic2V0CiAgICAgICAgY2Fu b25pY2FsaXphdGlvbi4nJycKCiAgICAgICAgIyBDb2xsZWN0IHRoZSBpbml0aWFsIGxpc3Qgb2Yg eG1sOmZvbyBhdHRyaWJ1dGVzLgogICAgICAgIHhtbGF0dHJzID0gZmlsdGVyKF9JTl9YTUxfTlMs IF9hdHRycyhub2RlKSkKCiAgICAgICAgIyBXYWxrIHVwIGFuZCBnZXQgYWxsIHhtbDpYWFggYXR0 cmlidXRlcyB3ZSBpbmhlcml0LgogICAgICAgIGluaGVyaXRlZCwgcGFyZW50ID0gW10sIG5vZGUu cGFyZW50Tm9kZQogICAgICAgIHdoaWxlIHBhcmVudCBhbmQgcGFyZW50Lm5vZGVUeXBlID09IE5v ZGUuRUxFTUVOVF9OT0RFOgogICAgICAgICAgICBmb3IgYSBpbiBmaWx0ZXIoX0lOX1hNTF9OUywg X2F0dHJzKHBhcmVudCkpOgogICAgICAgICAgICAgICAgbiA9IGEubG9jYWxOYW1lCiAgICAgICAg ICAgICAgICBpZiBuIG5vdCBpbiB4bWxhdHRyczoKICAgICAgICAgICAgICAgICAgICB4bWxhdHRy cy5hcHBlbmQobikKICAgICAgICAgICAgICAgICAgICBpbmhlcml0ZWQuYXBwZW5kKGEpCiAgICAg ICAgICAgIHBhcmVudCA9IHBhcmVudC5wYXJlbnROb2RlCiAgICAgICAgcmV0dXJuIGluaGVyaXRl ZAoKCiAgICBkZWYgX2RvX2RvY3VtZW50KHNlbGYsIG5vZGUpOgogICAgICAgICcnJ19kb19kb2N1 bWVudChzZWxmLCBub2RlKSAtPiBOb25lCiAgICAgICAgUHJvY2VzcyBhIGRvY3VtZW50IG5vZGUu IGRvY3VtZW50T3JkZXIgaG9sZHMgd2hldGhlciB0aGUgZG9jdW1lbnQKICAgICAgICBlbGVtZW50 IGhhcyBiZWVuIGVuY291bnRlcmVkIHN1Y2ggdGhhdCBQSXMvY29tbWVudHMgY2FuIGJlIHdyaXR0 ZW4KICAgICAgICBhcyBzcGVjaWZpZWQuJycnCgogICAgICAgIHNlbGYuZG9jdW1lbnRPcmRlciA9 IF9MZXNzZXJFbGVtZW50CiAgICAgICAgZm9yIGNoaWxkIGluIG5vZGUuY2hpbGROb2RlczoKICAg ICAgICAgICAgaWYgY2hpbGQubm9kZVR5cGUgPT0gTm9kZS5FTEVNRU5UX05PREU6CiAgICAgICAg ICAgICAgICBzZWxmLmRvY3VtZW50T3JkZXIgPSBfRWxlbWVudCAgICAgICAgIyBBdCBkb2N1bWVu dCBlbGVtZW50CiAgICAgICAgICAgICAgICBzZWxmLl9kb19lbGVtZW50KGNoaWxkKQogICAgICAg ICAgICAgICAgc2VsZi5kb2N1bWVudE9yZGVyID0gX0dyZWF0ZXJFbGVtZW50ICMgQWZ0ZXIgZG9j dW1lbnQgZWxlbWVudAogICAgICAgICAgICBlbGlmIGNoaWxkLm5vZGVUeXBlID09IE5vZGUuUFJP Q0VTU0lOR19JTlNUUlVDVElPTl9OT0RFOgogICAgICAgICAgICAgICAgc2VsZi5fZG9fcGkoY2hp bGQpCiAgICAgICAgICAgIGVsaWYgY2hpbGQubm9kZVR5cGUgPT0gTm9kZS5DT01NRU5UX05PREU6 CiAgICAgICAgICAgICAgICBzZWxmLl9kb19jb21tZW50KGNoaWxkKQogICAgICAgICAgICBlbGlm IGNoaWxkLm5vZGVUeXBlID09IE5vZGUuRE9DVU1FTlRfVFlQRV9OT0RFOgogICAgICAgICAgICAg ICAgcGFzcwogICAgICAgICAgICBlbHNlOgogICAgICAgICAgICAgICAgcmFpc2UgVHlwZUVycm9y LCBzdHIoY2hpbGQpCiAgICBoYW5kbGVyc1tOb2RlLkRPQ1VNRU5UX05PREVdID0gX2RvX2RvY3Vt ZW50CgoKICAgIGRlZiBfZG9fdGV4dChzZWxmLCBub2RlKToKICAgICAgICAnJydfZG9fdGV4dChz ZWxmLCBub2RlKSAtPiBOb25lCiAgICAgICAgUHJvY2VzcyBhIHRleHQgb3IgQ0RBVEEgbm9kZS4g IFJlbmRlciB2YXJpb3VzIHNwZWNpYWwgY2hhcmFjdGVycwogICAgICAgIGFzIHRoZWlyIEMxNE4g ZW50aXR5IHJlcHJlc2VudGF0aW9ucy4nJycKICAgICAgICBpZiBub3QgX2luX3N1YnNldChzZWxm LnN1YnNldCwgbm9kZSk6IHJldHVybgogICAgICAgIHMgPSBzdHJpbmcucmVwbGFjZShub2RlLmRh dGEsICImIiwgIiZhbXA7IikKICAgICAgICBzID0gc3RyaW5nLnJlcGxhY2UocywgIjwiLCAiJmx0 OyIpCiAgICAgICAgcyA9IHN0cmluZy5yZXBsYWNlKHMsICI+IiwgIiZndDsiKQogICAgICAgIHMg PSBzdHJpbmcucmVwbGFjZShzLCAiXDAxNSIsICImI3hEOyIpCiAgICAgICAgaWYgczogc2VsZi53 cml0ZShzKQogICAgaGFuZGxlcnNbTm9kZS5URVhUX05PREVdID0gX2RvX3RleHQKICAgIGhhbmRs ZXJzW05vZGUuQ0RBVEFfU0VDVElPTl9OT0RFXSA9IF9kb190ZXh0CgoKICAgIGRlZiBfZG9fcGko c2VsZiwgbm9kZSk6CiAgICAgICAgJycnX2RvX3BpKHNlbGYsIG5vZGUpIC0+IE5vbmUKICAgICAg ICBQcm9jZXNzIGEgUEkgbm9kZS4gUmVuZGVyIGEgbGVhZGluZyBvciB0cmFpbGluZyAjeEEgaWYg dGhlCiAgICAgICAgZG9jdW1lbnQgb3JkZXIgb2YgdGhlIFBJIGlzIGdyZWF0ZXIgb3IgbGVzc2Vy IChyZXNwZWN0aXZlbHkpCiAgICAgICAgdGhhbiB0aGUgZG9jdW1lbnQgZWxlbWVudC4KICAgICAg ICAnJycKICAgICAgICBpZiBub3QgX2luX3N1YnNldChzZWxmLnN1YnNldCwgbm9kZSk6IHJldHVy bgogICAgICAgIFcgPSBzZWxmLndyaXRlCiAgICAgICAgaWYgc2VsZi5kb2N1bWVudE9yZGVyID09 IF9HcmVhdGVyRWxlbWVudDogVygnXG4nKQogICAgICAgIFcoJzw/JykKICAgICAgICBXKG5vZGUu bm9kZU5hbWUpCiAgICAgICAgcyA9IG5vZGUuZGF0YQogICAgICAgIGlmIHM6CiAgICAgICAgICAg IFcoJyAnKQogICAgICAgICAgICBXKHMpCiAgICAgICAgVygnPz4nKQogICAgICAgIGlmIHNlbGYu ZG9jdW1lbnRPcmRlciA9PSBfTGVzc2VyRWxlbWVudDogVygnXG4nKQogICAgaGFuZGxlcnNbTm9k ZS5QUk9DRVNTSU5HX0lOU1RSVUNUSU9OX05PREVdID0gX2RvX3BpCgoKICAgIGRlZiBfZG9fY29t bWVudChzZWxmLCBub2RlKToKICAgICAgICAnJydfZG9fY29tbWVudChzZWxmLCBub2RlKSAtPiBO b25lCiAgICAgICAgUHJvY2VzcyBhIGNvbW1lbnQgbm9kZS4gUmVuZGVyIGEgbGVhZGluZyBvciB0 cmFpbGluZyAjeEEgaWYgdGhlCiAgICAgICAgZG9jdW1lbnQgb3JkZXIgb2YgdGhlIGNvbW1lbnQg aXMgZ3JlYXRlciBvciBsZXNzZXIgKHJlc3BlY3RpdmVseSkKICAgICAgICB0aGFuIHRoZSBkb2N1 bWVudCBlbGVtZW50LgogICAgICAgICcnJwogICAgICAgIGlmIG5vdCBfaW5fc3Vic2V0KHNlbGYu c3Vic2V0LCBub2RlKTogcmV0dXJuCiAgICAgICAgaWYgc2VsZi5jb21tZW50czoKICAgICAgICAg ICAgVyA9IHNlbGYud3JpdGUKICAgICAgICAgICAgaWYgc2VsZi5kb2N1bWVudE9yZGVyID09IF9H cmVhdGVyRWxlbWVudDogVygnXG4nKQogICAgICAgICAgICBXKCc8IS0tJykKICAgICAgICAgICAg Vyhub2RlLmRhdGEpCiAgICAgICAgICAgIFcoJy0tPicpCiAgICAgICAgICAgIGlmIHNlbGYuZG9j dW1lbnRPcmRlciA9PSBfTGVzc2VyRWxlbWVudDogVygnXG4nKQogICAgaGFuZGxlcnNbTm9kZS5D T01NRU5UX05PREVdID0gX2RvX2NvbW1lbnQKCgogICAgZGVmIF9kb19hdHRyKHNlbGYsIG4sIHZh bHVlKToKICAgICAgICAnJycnX2RvX2F0dHIoc2VsZiwgbm9kZSkgLT4gTm9uZQogICAgICAgIFBy b2Nlc3MgYW4gYXR0cmlidXRlLicnJwoKICAgICAgICBXID0gc2VsZi53cml0ZQogICAgICAgIFco JyAnKQogICAgICAgIFcobikKICAgICAgICBXKCc9IicpCiAgICAgICAgcyA9IHN0cmluZy5yZXBs YWNlKHZhbHVlLCAiJiIsICImYW1wOyIpCiAgICAgICAgcyA9IHN0cmluZy5yZXBsYWNlKHMsICI8 IiwgIiZsdDsiKQogICAgICAgIHMgPSBzdHJpbmcucmVwbGFjZShzLCAnIicsICcmcXVvdDsnKQog ICAgICAgIHMgPSBzdHJpbmcucmVwbGFjZShzLCAnXDAxMScsICcmI3g5JykKICAgICAgICBzID0g c3RyaW5nLnJlcGxhY2UocywgJ1wwMTInLCAnJiN4QScpCiAgICAgICAgcyA9IHN0cmluZy5yZXBs YWNlKHMsICdcMDE1JywgJyYjeEQnKQogICAgICAgIFcocykKICAgICAgICBXKCciJykKCgogICAg ZGVmIF9kb19lbGVtZW50KHNlbGYsIG5vZGUsIGluaXRpYWxfb3RoZXJfYXR0cnMgPSBbXSk6CiAg ICAgICAgJycnX2RvX2VsZW1lbnQoc2VsZiwgbm9kZSwgaW5pdGlhbF9vdGhlcl9hdHRycyA9IFtd KSAtPiBOb25lCiAgICAgICAgUHJvY2VzcyBhbiBlbGVtZW50IChhbmQgaXRzIGNoaWxkcmVuKS4n JycKCiAgICAgICAgIyBHZXQgc3RhdGUgKGZyb20gdGhlIHN0YWNrKSBtYWtlIGxvY2FsIGNvcGll cy4KICAgICAgICAjICAgbnNfcGFyZW50IC0tIE5TIGRlY2xhcmF0aW9ucyBpbiBwYXJlbnQKICAg ICAgICAjICAgbnNfcmVuZGVyZWQgLS0gTlMgbm9kZXMgcmVuZGVyZWQgYnkgYW5jZXN0b3JzCiAg ICAgICAgIyAgICAgICAgbnNfbG9jYWwgLS0gTlMgZGVjbGFyYXRpb25zIHJlbGV2YW50IHRvIHRo aXMgZWxlbWVudAogICAgICAgICMgICB4bWxfYXR0cnMgLS0gQXR0cmlidXRlcyBpbiBYTUwgbmFt ZXNwYWNlIGZyb20gcGFyZW50CiAgICAgICAgIyAgICAgICB4bWxfYXR0cnNfbG9jYWwgLS0gTG9j YWwgYXR0cmlidXRlcyBpbiBYTUwgbmFtZXNwYWNlLgogICAgICAgIG5zX3BhcmVudCwgbnNfcmVu ZGVyZWQsIHhtbF9hdHRycyA9IFwKICAgICAgICAgICAgICAgIHNlbGYuc3RhdGVbMF0sIHNlbGYu c3RhdGVbMV0uY29weSgpLCBzZWxmLnN0YXRlWzJdLmNvcHkoKSAjMDQyMgogICAgICAgIG5zX2xv Y2FsID0gbnNfcGFyZW50LmNvcHkoKQogICAgICAgIHhtbF9hdHRyc19sb2NhbCA9IHt9CgogICAg ICAgICMgRGl2aWRlIGF0dHJpYnV0ZXMgaW50byBOUywgWE1MLCBhbmQgb3RoZXJzLgogICAgICAg IG90aGVyX2F0dHJzID0gaW5pdGlhbF9vdGhlcl9hdHRyc1s6XQogICAgICAgIGluX3N1YnNldCA9 IF9pbl9zdWJzZXQoc2VsZi5zdWJzZXQsIG5vZGUpCiAgICAgICAgZm9yIGEgaW4gX2F0dHJzKG5v ZGUpOgogICAgICAgICAgICBpZiBhLm5hbWVzcGFjZVVSSSA9PSBYTUxOUy5CQVNFOgogICAgICAg ICAgICAgICAgbiA9IGEubm9kZU5hbWUKICAgICAgICAgICAgICAgIGlmIG4gPT0gInhtbG5zOiI6 IG4gPSAieG1sbnMiICAgICAgICAjIERPTSBidWcgd29ya2Fyb3VuZAogICAgICAgICAgICAgICAg bnNfbG9jYWxbbl0gPSBhLm5vZGVWYWx1ZQogICAgICAgICAgICBlbGlmIGEubmFtZXNwYWNlVVJJ ID09IFhNTE5TLlhNTDoKICAgICAgICAgICAgICAgIGlmIF9pbmNsdXNpdmUoc2VsZikgb3IgaW5f c3Vic2V0OgogICAgICAgICAgICAgICAgICAgIHhtbF9hdHRyc19sb2NhbFthLm5vZGVOYW1lXSA9 IGEgIzA0MjYKICAgICAgICAgICAgZWxzZToKICAgICAgICAgICAgICAgIG90aGVyX2F0dHJzLmFw cGVuZChhKQogICAgICAgICAgICAjYWRkIGxvY2FsIHhtbDpmb28gYXR0cmlidXRlcyB0byBhbmNl c3RvcidzIHhtbDpmb28gYXR0cmlidXRlcwogICAgICAgICAgICB4bWxfYXR0cnMudXBkYXRlKHht bF9hdHRyc19sb2NhbCkKCiAgICAgICAgIyBSZW5kZXIgdGhlIG5vZGUKICAgICAgICBXLCBuYW1l ID0gc2VsZi53cml0ZSwgTm9uZQogICAgICAgIGlmIGluX3N1YnNldDogCiAgICAgICAgICAgIG5h bWUgPSBub2RlLm5vZGVOYW1lCiAgICAgICAgICAgIFcoJzwnKQogICAgICAgICAgICBXKG5hbWUp CgogICAgICAgICAgICAjIENyZWF0ZSBsaXN0IG9mIE5TIGF0dHJpYnV0ZXMgdG8gcmVuZGVyLgog ICAgICAgICAgICBuc190b19yZW5kZXIgPSBbXQogICAgICAgICAgICBmb3Igbix2IGluIG5zX2xv Y2FsLml0ZW1zKCk6CgogICAgICAgICAgICAgICAgIyBJZiBkZWZhdWx0IG5hbWVzcGFjZSBpcyBY TUxOUy5CQVNFIG9yIGVtcHR5LAogICAgICAgICAgICAgICAgIyBhbmQgaWYgYW4gYW5jZXN0b3Ig d2FzIHRoZSBzYW1lCiAgICAgICAgICAgICAgICBpZiBuID09ICJ4bWxucyIgYW5kIHYgaW4gWyBY TUxOUy5CQVNFLCAnJyBdIFwKICAgICAgICAgICAgICAgIGFuZCBuc19yZW5kZXJlZC5nZXQoJ3ht bG5zJykgaW4gWyBYTUxOUy5CQVNFLCAnJywgTm9uZSBdOgogICAgICAgICAgICAgICAgICAgIGNv bnRpbnVlCgogICAgICAgICAgICAgICAgIyAib21pdCBuYW1lc3BhY2Ugbm9kZSB3aXRoIGxvY2Fs IG5hbWUgeG1sLCB3aGljaCBkZWZpbmVzCiAgICAgICAgICAgICAgICAjIHRoZSB4bWwgcHJlZml4 LCBpZiBpdHMgc3RyaW5nIHZhbHVlIGlzCiAgICAgICAgICAgICAgICAjIGh0dHA6Ly93d3cudzMu b3JnL1hNTC8xOTk4L25hbWVzcGFjZS4iCiAgICAgICAgICAgICAgICBpZiBuIGluIFsieG1sbnM6 eG1sIiwgInhtbCJdIFwKICAgICAgICAgICAgICAgIGFuZCB2IGluIFsgJ2h0dHA6Ly93d3cudzMu b3JnL1hNTC8xOTk4L25hbWVzcGFjZScgXToKICAgICAgICAgICAgICAgICAgICBjb250aW51ZQoK CiAgICAgICAgICAgICAgICAjIElmIG5vdCBwcmV2aW91c2x5IHJlbmRlcmVkCiAgICAgICAgICAg ICAgICAjIGFuZCBpdCdzIGluY2x1c2l2ZSAgb3IgdXRpbGl6ZWQKICAgICAgICAgICAgICAgIGlm IChuLHYpIG5vdCBpbiBuc19yZW5kZXJlZC5pdGVtcygpIFwKICAgICAgICAgICAgICAgICAgYW5k IChfaW5jbHVzaXZlKHNlbGYpIG9yIFwKICAgICAgICAgICAgICAgICAgX3V0aWxpemVkKG4sIG5v ZGUsIG90aGVyX2F0dHJzLCBzZWxmLnVuc3VwcHJlc3NlZFByZWZpeGVzKSk6CiAgICAgICAgICAg ICAgICAgICAgbnNfdG9fcmVuZGVyLmFwcGVuZCgobiwgdikpCgogICAgICAgICAgICAjIFNvcnQg YW5kIHJlbmRlciB0aGUgbnMsIG1hcmtpbmcgd2hhdCB3YXMgcmVuZGVyZWQuCiAgICAgICAgICAg IG5zX3RvX3JlbmRlci5zb3J0KF9zb3J0ZXJfbnMpCiAgICAgICAgICAgIGZvciBuLHYgaW4gbnNf dG9fcmVuZGVyOgogICAgICAgICAgICAgICAgc2VsZi5fZG9fYXR0cihuLCB2KQogICAgICAgICAg ICAgICAgbnNfcmVuZGVyZWRbbl09diAgICAjMDQxNwoKICAgICAgICAgICAgIyBJZiBleGNsdXNp dmUgb3IgdGhlIHBhcmVudCBpcyBpbiB0aGUgc3Vic2V0LCBhZGQgdGhlIGxvY2FsIHhtbCBhdHRy aWJ1dGVzCiAgICAgICAgICAgICMgRWxzZSwgYWRkIGFsbCBsb2NhbCBhbmQgYW5jZXN0b3IgeG1s IGF0dHJpYnV0ZXMKICAgICAgICAgICAgIyBTb3J0IGFuZCByZW5kZXIgdGhlIGF0dHJpYnV0ZXMu CiAgICAgICAgICAgIGlmIG5vdCBfaW5jbHVzaXZlKHNlbGYpIG9yIF9pbl9zdWJzZXQoc2VsZi5z dWJzZXQsbm9kZS5wYXJlbnROb2RlKTogICMwNDI2CiAgICAgICAgICAgICAgICBvdGhlcl9hdHRy cy5leHRlbmQoeG1sX2F0dHJzX2xvY2FsLnZhbHVlcygpKQogICAgICAgICAgICBlbHNlOgogICAg ICAgICAgICAgICAgb3RoZXJfYXR0cnMuZXh0ZW5kKHhtbF9hdHRycy52YWx1ZXMoKSkKICAgICAg ICAgICAgb3RoZXJfYXR0cnMuc29ydChfc29ydGVyKQogICAgICAgICAgICBmb3IgYSBpbiBvdGhl cl9hdHRyczoKICAgICAgICAgICAgICAgIHNlbGYuX2RvX2F0dHIoYS5ub2RlTmFtZSwgYS52YWx1 ZSkKICAgICAgICAgICAgVygnPicpCgogICAgICAgICMgUHVzaCBzdGF0ZSwgcmVjdXJzZSwgcG9w IHN0YXRlLgogICAgICAgIHN0YXRlLCBzZWxmLnN0YXRlID0gc2VsZi5zdGF0ZSwgKG5zX2xvY2Fs LCBuc19yZW5kZXJlZCwgeG1sX2F0dHJzKQogICAgICAgIGZvciBjIGluIF9jaGlsZHJlbihub2Rl KToKICAgICAgICAgICAgX2ltcGxlbWVudGF0aW9uLmhhbmRsZXJzW2Mubm9kZVR5cGVdKHNlbGYs IGMpCiAgICAgICAgc2VsZi5zdGF0ZSA9IHN0YXRlCgogICAgICAgIGlmIG5hbWU6IFcoJzwvJXM+ JyAlIG5hbWUpCiAgICBoYW5kbGVyc1tOb2RlLkVMRU1FTlRfTk9ERV0gPSBfZG9fZWxlbWVudAoK CmRlZiBDYW5vbmljYWxpemUobm9kZSwgb3V0cHV0PU5vbmUsICoqa3cpOgogICAgJycnQ2Fub25p Y2FsaXplKG5vZGUsIG91dHB1dD1Ob25lLCAqKmt3KSAtPiBVVEYtOAoKICAgIENhbm9uaWNhbGl6 ZSBhIERPTSBkb2N1bWVudC9lbGVtZW50IG5vZGUgYW5kIGFsbCBkZXNjZW5kZW50cy4KICAgIFJl dHVybiB0aGUgdGV4dDsgaWYgb3V0cHV0IGlzIHNwZWNpZmllZCB0aGVuIG91dHB1dC53cml0ZSB3 aWxsCiAgICBiZSBjYWxsZWQgdG8gb3V0cHV0IHRoZSB0ZXh0IGFuZCBOb25lIHdpbGwgYmUgcmV0 dXJuZWQKICAgIEtleXdvcmQgcGFyYW1ldGVyczoKICAgICAgICBuc2RpY3Q6IGEgZGljdGlvbmFy eSBvZiBwcmVmaXg6dXJpIG5hbWVzcGFjZSBlbnRyaWVzCiAgICAgICAgICAgICAgICBhc3N1bWVk IHRvIGV4aXN0IGluIHRoZSBzdXJyb3VuZGluZyBjb250ZXh0CiAgICAgICAgY29tbWVudHM6IGtl ZXAgY29tbWVudHMgaWYgbm9uLXplcm8gKGRlZmF1bHQgaXMgMCkKICAgICAgICBzdWJzZXQ6IENh bm9uaWNhbCBYTUwgc3Vic2V0dGluZyByZXN1bHRpbmcgZnJvbSBYUGF0aAogICAgICAgICAgICAg ICAgKGRlZmF1bHQgaXMgW10pCiAgICAgICAgdW5zdXBwcmVzc2VkUHJlZml4ZXM6IGRvIGV4Y2x1 c2l2ZSBDMTROLCBhbmQgdGhpcyBzcGVjaWZpZXMgdGhlCiAgICAgICAgICAgICAgICBwcmVmaXhl cyB0aGF0IHNob3VsZCBiZSBpbmhlcml0ZWQuCiAgICAnJycKICAgIGlmIG91dHB1dDoKICAgICAg ICBhcHBseShfaW1wbGVtZW50YXRpb24sIChub2RlLCBvdXRwdXQud3JpdGUpLCBrdykKICAgIGVs c2U6CiAgICAgICAgcyA9IFN0cmluZ0lPLlN0cmluZ0lPKCkKICAgICAgICBhcHBseShfaW1wbGVt ZW50YXRpb24sIChub2RlLCBzLndyaXRlKSwga3cpCiAgICAgICAgcmV0dXJuIHMuZ2V0dmFsdWUo KQo= --------------Boundary-00=_NB2774YQWHPCTZZJZ5GY--