From chris@rpgarchive.com Mon Apr 3 05:16:24 2000 From: chris@rpgarchive.com (chris davis) Date: Sun, 2 Apr 2000 23:16:24 -0500 Subject: [XML-SIG] merging two separate DOM trees. Message-ID: I'm hoping someone can help me on this. I'm using DOM in my application and I want to insert a xml document into another xml document at a specific node. I'm using DOM and I tired the following. reader = utils.FileReader(f.GetPath()) new_doc = reader.document utils.strip_whitespace(doc) new_xml_node = doc.get_firstChild() old_xml_node.insertBefore(xml_node,None) .... At this point I get the "Node created from a different document" error. I understand what's causing the error, but how can I merge two DOM trees together. I Use DOM extensively in my app, so I'd really like to accomplish this without having to move the XML data to a different abstraction, but I'll take any solution at this point. Thanks. chris davis chris@rpgarchive.com http://www.rpgarchive.com adventure database and open news forum http://www.openrpg.com check out OpenRPG! open source online rpg! From jsydik@virtualparadigm.com Mon Apr 3 06:53:10 2000 From: jsydik@virtualparadigm.com (Jeremy J. Sydik) Date: Mon, 03 Apr 2000 00:53:10 -0500 Subject: [XML-SIG] merging two separate DOM trees. References: Message-ID: <38E831C6.76140909@virtualparadigm.com> I ran into the same issue ~a month ago. The options you have is best solved with the DOM Level 2 method Document.importNode (not implemented in PyDOM), so your options are: 1: Reassign node._document for the nodes that you want to insert (But this is not fun and, as I understand the specs a Bad Thing to do) 2: Use 4DOM. It implements the importNode method you need and has actually been officially brought in as the new XML-Sig tool of choice (correct?). In this solution you would do something like this (I apologize for the quality of this code, just a remnant of a proof of concept for work): # Load the file into a tree, and strip the whitespace. subdoc=Sax.FromXmlUrl('Content/'+node.getAttribute('obj')+'.xml') Ext.StripXml(subdoc) # Copy the new tree to the location of the include, changing # the node ownership to the main document. for all in subdoc.documentElement.childNodes: importedNode=node.ownerDocument.importNode(all,deep=1) includeParent.insertBefore(importedNode,node) # Delete the original include from the tree. includeParent.removeChild(node) 3: If you're tied to PyDOM, use this, courtesy of Sebastian Schneckener: -------------------- #!/usr/bin/env python # GPL type license # www.science-factory.com # 2000/14/03 # import re import sys import xml.dom.core import xml.dom.utils class CopyClass: def __init__(self, document): self.dom=document def copyElement (self, node): """ Returns a copy of the node without a reference to its document to a new document dom. It is not recursive. It copies the name of the node and the attributes incl. values """ if isinstance(node,xml.dom.core.Text): e=self.dom.createTextNode(node.nodeValue) e.nodeValue=node.nodeValue return e e = self.dom.createElement(node.get_tagName()) for i in node.get_attributes().values(): e.setAttribute(i.get_name(), node.getAttribute (i.get_name())) return e def deepCopy (self, node): """copies a given node and all nodes childs. """ copiedNode=self.copyElement(node) self.__recDCE(node,copiedNode) return copiedNode def __recDCE (self, node, copiedNode): for child in node.get_childNodes(): cNode=self.copyElement(child) copiedNode.appendChild(cNode) self.__recDCE(child, cNode) def test(xmlFile ): # reading an existing xml file d = xml.dom.utils.FileReader() dom = d.readFile(xmlFile ) # creating a new DOM tree newDom = xml.dom.core.createDocument() # instantiating a 'CopyClass' myCopyClass = CopyClass(newDom) # copying the old to the new tree newDom.appendChild (myCopyClass.deepCopy(dom.firstChild) ) # printing print newDom.toxml() if __name__ == '__main__': if len (sys.argv) == 2: test(sys.argv[1]) else: print "usage:\n ",sys.argv[0]," file.xml" sys.exit(255) -------------------- Jeremy J. Sydik jsydik@virtualparadigm.com chris davis wrote: > > I'm hoping someone can help me on this. I'm using DOM in my application and > I want to insert a xml document into another xml document at a specific > node. I'm using DOM and I tired the following. > > reader = utils.FileReader(f.GetPath()) > new_doc = reader.document > utils.strip_whitespace(doc) > new_xml_node = doc.get_firstChild() > old_xml_node.insertBefore(xml_node,None) > .... > > At this point I get the "Node created from a different document" error. > I understand what's causing the error, but how can I merge two DOM trees > together. I Use DOM extensively in my app, so I'd really like to accomplish > this without having to move the XML data to a different abstraction, but > I'll take any solution at this point. Thanks. > > chris davis > chris@rpgarchive.com > > http://www.rpgarchive.com > adventure database and open news forum > > http://www.openrpg.com > check out OpenRPG! open source online rpg! > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig From andy@reportlab.com Mon Apr 3 13:48:49 2000 From: andy@reportlab.com (Andy Robinson) Date: Mon, 3 Apr 2000 13:48:49 +0100 Subject: [XML-SIG] xmllib compatibility Message-ID: Hi everyone, I'm new to the group so my apologies if I am dredging up an old problem. The ReportLab package (http://www.reportlab.com/ )contains a demo called PythonPoint, which has an xml language for doing presentation slides and can convert them to PDF documents, along with fancy presentation effects. I'm beefing this up, as I want people to use it at the Open Source conference this summer. This currently uses the xmllib in the standard (1.5.2) distribution, so everyone can get it running. I have two problems: (1) One of our users complained that this broke when the Python XML package was installed. He uses Debian, and says that the installer overwrites the standard Python library xmllib with the one in xml.parsers. Is this correct? If so, how can it be justified? It seems guaranteed to cause problems and is not necessary, as the user can choose which xml parser to import anyway. (2) Anyway, he would like to use it, and if I can make things compatible I will do. I tried to change "import xmllib" to "from xml.parsers import xmllib" and ran the script anyway, and discover that default keywords are no longer supported. For example, I had a tag like this... ...and the defaults for the old parser specified an 'stroke' attribute of 'None', so I did not have to define the stroke for every shape in my XML file. As far as I can see, xml.parsers.xmllib.Fast/SlowXMLParser no longer supports default attributes. Is ths correct, or is there just another way of doing it I have missed? Many thanks, Andy Robinson From fdrake@acm.org Mon Apr 3 15:51:25 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 3 Apr 2000 10:51:25 -0400 (EDT) Subject: [XML-SIG] xmllib compatibility In-Reply-To: References: Message-ID: <14568.45037.269155.923256@seahag.cnri.reston.va.us> Andy Robinson writes: > (1) One of our users complained that this broke when the Python XML package > was installed. He uses Debian, and says that the installer overwrites the > standard Python library xmllib with the one in xml.parsers. Is this > correct? If so, how can it be justified? It seems guaranteed to cause This is a clear problem with the Debian packaging; the stock xmllib should not be overwritten, especially since xml.parsers.xmllib is out of date (and likely to remain that way, and disappear). The Debian package maintainer should be told to fix this. (Is he listening? Does anyone know who does this?) > (2) Anyway, he would like to use it, and if I can make things compatible I > will do. I tried to change "import xmllib" to "from xml.parsers import > xmllib" and ran the script anyway, and discover that default keywords are no > longer supported. For example, I had a tag like this... > > > > ...and the defaults for the old parser specified an 'stroke' attribute of > 'None', so I did not have to define the stroke for every shape in my XML > file. As far as I can see, xml.parsers.xmllib.Fast/SlowXMLParser no longer > supports default attributes. Is ths correct, or is there just another way > of doing it I have missed? This is an incompatibility between the two. Convert to using SAX with pyexpat, since that'll be standard in Python 1.6. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From robt@debian.org Mon Apr 3 23:34:53 2000 From: robt@debian.org (Rob Tillotson) Date: 03 Apr 2000 17:34:53 -0500 Subject: [XML-SIG] xmllib compatibility In-Reply-To: "Fred L. Drake, Jr."'s message of "Mon, 3 Apr 2000 10:51:25 -0400 (EDT)" References: <14568.45037.269155.923256@seahag.cnri.reston.va.us> Message-ID: <87snx26cfm.fsf@selene.pyrite.org> "Fred L. Drake, Jr." writes: > This is a clear problem with the Debian packaging; the stock xmllib > should not be overwritten, especially since xml.parsers.xmllib is out > of date (and likely to remain that way, and disappear). The Debian > package maintainer should be told to fix this. (Is he listening? > Does anyone know who does this?) For the record, this bug is fixed. When I initially made the Debian packages of the XML stuff, replacing the standard xmllib and sgmllib package worked just fine, and to my knowledge it continued to work. I was not even aware that there was a problem with it in later releases (the replacement xmllib falls back to the old code silently), until someone filed a Debian bug report about it a couple of weeks ago. As a result of that, I removed the override of the standard xmllib and sgmllib, and uploaded a fixed package to "woody", which is the Debian "unstable" release. I could not put it in "potato" because we were already deep in the final stages release cycle, and this bug was not of a high enough severity to be allowed in. At any rate, anyone who has problems with this should install the package from "unstable". (Don't worry about the name, the python-xml package doesn't depend on anything but python, and installing it will not bring in other packages from "unstable".) In the meantime, I am deeply sorry for the problems this has caused and for any public shame it has brought to Debian. I have taken steps to make sure it cannot happen again (at least not by me), since I no longer maintain any Debian packages for which I am not the sole upstream author. Deepest apologies, --Rob -- Rob Tillotson N9MTB From andy@reportlab.com Tue Apr 4 13:55:53 2000 From: andy@reportlab.com (Andy Robinson) Date: Tue, 4 Apr 2000 13:55:53 +0100 Subject: [XML-SIG] xmllib compatibility In-Reply-To: <14568.45037.269155.923256@seahag.cnri.reston.va.us> Message-ID: > -----Original Message----- > From: Fred L. Drake, Jr. [mailto:fdrake@acm.org] > This is an incompatibility between the two. Convert to using SAX > with pyexpat, since that'll be standard in Python 1.6. > Does this mean sax and pyexpat are going into the standad Python distribution? Is there anything written down yet about how XML stuff will be packaged in 1.6, without having to read the entire SIG archive? There is nothing listed on the main web site under 'proposed changes', nor on the SIG page. I have a recent Python CVS tree, but cannot find any xml-related modules apart from the old ones. It is somewhat critical for our business to know about this! Thanks very much, Andy From fdrake@acm.org Tue Apr 4 14:51:00 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 4 Apr 2000 09:51:00 -0400 (EDT) Subject: [XML-SIG] xmllib compatibility In-Reply-To: References: <14568.45037.269155.923256@seahag.cnri.reston.va.us> Message-ID: <14569.62276.855467.168875@seahag.cnri.reston.va.us> Andy Robinson writes: > Does this mean sax and pyexpat are going into the standad Python > distribution? pyexpat has already been checked into the CVS tree (but not expat iteself). I think the specific "shape" of things to come hasn't yet been completely hashed out, but essentially we're going to "do the right thing." > Is there anything written down yet about how XML stuff will be packaged in > 1.6, without having to read the entire SIG archive? There is nothing listed > on the main web site under 'proposed changes', nor on the SIG page. I have > a recent Python CVS tree, but cannot find any xml-related modules apart from Andrew K., can you write up a summary on the XML-SIG page so that Guido can link to it from the 1.6 summary? -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From matheusrodrigues@hotmail.com Tue Apr 4 14:52:07 2000 From: matheusrodrigues@hotmail.com (Matheus Rodrigues) Date: Tue, 04 Apr 2000 13:52:07 GMT Subject: [XML-SIG] Examples of Python/XML application Message-ID: <20000404135207.30409.qmail@hotmail.com> Hello guys, Is it possible to someone list to me some URLs where I could find some real-world examples about using Python and XML together. Thanks Matheus ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From guido@python.org Tue Apr 4 15:50:54 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 04 Apr 2000 10:50:54 -0400 Subject: [XML-SIG] xmllib compatibility In-Reply-To: Your message of "Tue, 04 Apr 2000 09:51:00 EDT." <14569.62276.855467.168875@seahag.cnri.reston.va.us> References: <14568.45037.269155.923256@seahag.cnri.reston.va.us> <14569.62276.855467.168875@seahag.cnri.reston.va.us> Message-ID: <200004041450.KAA12431@eric.cnri.reston.va.us> > pyexpat has already been checked into the CVS tree (but not expat > iteself). I think the specific "shape" of things to come hasn't yet > been completely hashed out, but essentially we're going to "do the > right thing." Note that expat itself won't be incorporated into the tree -- it's not a good idea to include by value large bodies of 3rd party code that is being maintained separately. Inclusion by reference (in source distributions anyway) is the only way to go. > Andrew K., can you write up a summary on the XML-SIG page so that > Guido can link to it from the 1.6 summary? That would be a great idea! (I could also use a pointer to a sample Unicode session; I remember seeing one long ago but I can't find it...) --Guido van Rossum (home page: http://www.python.org/~guido/) From fwang2@yahoo.com Tue Apr 4 17:33:53 2000 From: fwang2@yahoo.com (oliver) Date: Tue, 4 Apr 2000 12:33:53 -0400 (EDT) Subject: [XML-SIG] Examples of Python/XML application In-Reply-To: <20000404135207.30409.qmail@hotmail.com> Message-ID: If you downloaded the the python xml package, there is a python xml-howto in "doc" directory, the examples given there works. oliver On Tue, 4 Apr 2000, Matheus Rodrigues wrote: > Hello guys, > > Is it possible to someone list to me some URLs where I could find some > real-world examples about using Python and XML together. > > Thanks > > Matheus > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig > > From fdrake@acm.org Tue Apr 4 17:49:16 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 4 Apr 2000 12:49:16 -0400 (EDT) Subject: [XML-SIG] xmllib compatibility In-Reply-To: <87snx26cfm.fsf@selene.pyrite.org> References: <14568.45037.269155.923256@seahag.cnri.reston.va.us> <87snx26cfm.fsf@selene.pyrite.org> Message-ID: <14570.7436.818146.373382@seahag.cnri.reston.va.us> Rob Tillotson writes: > For the record, this bug is fixed. Thanks! > When I initially made the Debian packages of the XML stuff, replacing > the standard xmllib and sgmllib package worked just fine, and to my > knowledge it continued to work. I was not even aware that there was a I'd have probably considered this "safe" at the time myself, since the basic intention was for it to serve as a replacement. For some applications, it's still acceptable. > In the meantime, I am deeply sorry for the problems this has caused > and for any public shame it has brought to Debian. I have taken > steps to make sure it cannot happen again (at least not by me), since Well, I hope this wasn't the cause for that decision! Thanks for clarifying the situation; I certainly appreciate the information. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From andy@reportlab.com Wed Apr 5 15:28:10 2000 From: andy@reportlab.com (Andy Robinson) Date: Wed, 5 Apr 2000 15:28:10 +0100 Subject: [XML-SIG] The Zen of DOM Message-ID: Looking for spirtual guidance about the right way to do things... I've been slogging my way through the current XML package looking at many different ways of parsing XML documents into my own Python object models. The target is currently "pythonPoint Markup Language", a markup for creating PDF presentation slides in ReportLab; but I'll need to do many similar parsers in future. At the moment, I have a Python class hierarchy with things like Presentation, Slide, Frame, Paragraph, and various primitive shapes to decorate pages. I use a parser derived from xmllib which walks through a document, and I wrote start_slide/end_slide, start_para/end_para handlers which construct instances of my own objects and build a tree. It seems to me that one could use Python's extreme flexibility to take a generic approach to tree-building, and see if there was a class available corresponding to a particular tag before creating some generic node; if so, create it, pass it the available attributes, then pass child nodes to an add() method so it could organize them itself. Then I could magically end up with a notation like... presentation.slides[3].frames[1].paragraphs[0].text ...without having to write lots of new stuff in the parser as well as the application class hierarchy every time. Or at least to navigate the tree using generic node/child notation, but get my own class instances attached at each point. To turn this on its head, there must be a generic way to turn a Python class instance into XML, and unserialize it again later. Has anyone actually worked on this? Is there a solution lurking in the package somewhere? Or is the preferred approach to get a DOM tree, then walk through it building my own objects? Thanks very much, Andy Robinson From ken@bitsko.slc.ut.us Wed Apr 5 16:27:16 2000 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 05 Apr 2000 10:27:16 -0500 Subject: [XML-SIG] The Zen of DOM In-Reply-To: "Andy Robinson"'s message of "Wed, 5 Apr 2000 15:28:10 +0100" References: Message-ID: "Andy Robinson" writes: > To turn this on its head, there must be a generic way to turn a > Python class instance into XML, and unserialize it again later. Yes, you are probably looking for a generic de/serializer, I listed the ones I know of, with some notes, at: The Scarab implementation of SOAP is now available in a snapshot at: -- Ken From uogbuji@fourthought.com Thu Apr 6 07:33:01 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 06 Apr 2000 00:33:01 -0600 Subject: [XML-SIG] The Zen of DOM In-Reply-To: Message from "Andy Robinson" of "Wed, 05 Apr 2000 15:28:10 BST." Message-ID: <200004060633.AAA02315@localhost.localdomain> > Looking for spirtual guidance about the right way to do things... You're really looking for two "right ways" to do two very different things. > It seems to me that one could use Python's extreme flexibility to take a > generic approach to tree-building, and see if there was a class available > corresponding to a particular tag before creating some generic node; if so, > create it, pass it the available attributes, then pass child nodes to an > add() method so it could organize them itself. Then I could magically end > up with a notation like... > presentation.slides[3].frames[1].paragraphs[0].text > ...without having to write lots of new stuff in the parser as well as the > application class hierarchy every time. Or at least to navigate the tree > using generic node/child notation, but get my own class instances attached > at each point. To my moderately trained eye, this has less to do with DOM or even XML than it does abstract models. Grove advocates would tell you that what you want is a grove model for your hierarchical data. But then again you could also do it with a very simple translation layer on top of the DOM. A SAX handler or simple NodeIterator that converts nodes or events from your serialization into application objects representing your direct semantics would zip the trick nicely. We use this model at Fourthought for conversion between XML forms (such as XBEL) and persistent object stubs (such as in our demo bookmark manager app for 4ODS). > To turn this on its head, there must be a generic way to turn a Python class > instance into XML, and unserialize it again later. This is a different and simpler question. Ken MacLeod has your answer. > Has anyone actually worked on this? Is there a solution lurking in the > package somewhere? Or is the preferred approach to get a DOM tree, then > walk through it building my own objects? There are simple trade-offs to consider between speed, code-simplicity and system environment. -- Uche Ogbuji uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From robin@jessikat.demon.co.uk Thu Apr 6 08:01:16 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Thu, 6 Apr 2000 08:01:16 +0100 Subject: [XML-SIG] The Zen of DOM In-Reply-To: <200004060633.AAA02315@localhost.localdomain> References: <200004060633.AAA02315@localhost.localdomain> Message-ID: Completely off topic, why is the term 'event' used to denote 'recognition' in this XML parser world? It doesn't seem to ring the right bells to my jaded ear. I guess what I used to call 'semantic actions' are now known as 'event handlers'. -- Robin Becker From l.szyster@ibm.net Thu Apr 6 10:49:30 2000 From: l.szyster@ibm.net (Laurent Szyster) Date: Thu, 06 Apr 2000 11:49:30 +0200 Subject: [XML-SIG] The Zen of DOM References: Message-ID: <38EC5DAA.C046ABB4@ibm.net> This is a multi-part message in MIME format. --------------6CDEB2A441690ACFA4000AE5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy Robinson wrote: > > It seems to me that one could use Python's extreme flexibility to > take a generic approach to tree-building, and see if there was a > class available corresponding to a particular tag before creating > some generic node; if so, create it, pass it the available > attributes, then pass child nodes to an add() method so it could > organize them itself. Then I could magically end up with a > notation like... > > presentation.slides[3].frames[1].paragraphs[0].text > ...without having to write lots of new stuff in the parser as well > as the application class hierarchy every time. Or at least to > navigate the tree using generic node/child notation, but get my own > class instances attached at each point. > > Has anyone actually worked on this? Is there a solution lurking in > the package somewhere? Or is the preferred approach to get a DOM > tree, then walk through it building my own objects? Yes, I did. Here is attached the latest version of myXML. Store it into your python library /site-packages directory and do: from myXML import base, xmlns class Presentation(base.element) pass # ... class Paragraph(base.element) pass NS = {'myNamespace': {'presentation': Presentation, 'slide': Slide, 'frame': Frame, 'paragraph': Paragraph,}} dom = xmlns.DOM(NS) parser = xmlns.Parser() parser.parse(open('myFile'), dom) # or abreviated as: # # xmlns.Parser().parse(open('myFile'), xmlns.DOM(NS)) # presentation = dom.root() print presentation.slide[3].frame[1].paragraph[0].textof() As you will see from the code I reused much of Greg Stein qp_xml.py. If you want to play with it there is also some support for XPATH, XSLT and XLINK in this package. Laurent Szyster --------------6CDEB2A441690ACFA4000AE5 Content-Type: application/x-compressed; name="myXML-0.2.8.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="myXML-0.2.8.tgz" H4sIAFuY1zgAA+w9/3fbtvH91for8FGWUYplSvLXVbOcuIm7dk3Trs76+iarehQFWYwpUiUp O1rb//1zd/hCgKRkJ3HS7c18jSUBh8Ph7nB3AI7ofPXTty/bn33Uh+13jg4O2GeMdY8OOuan ejqMHXUOD466+93OEfw+2ts7+IwdfFyyxLNMMy9h7LMw3Qx3W/1/6TMn+Y9GQRRko5G7WH2E PrqdzuH+/gb5Hx6S/Dv73f2jbheq4fPwM9b5CLSUnv9x+Y9GXhiORqzPBs7YS7nTYs7beRil 9CUMoiv6svCyGX1Jw8wZ1v5oqh+e+3rE/EfJf5y5j8/m+b/b2evsCft/eNDZ3d2F6s7RXvdh /n+Kp16v1ywdqNVezzhLg/ki5GnGoIa9+O5bNl4G4YQnrOGxNAwuZxnj0cyLfD7nUcbiKftl MQK7AQhY7+dmzY/n4yDiE3YTZDOWmRi/X2WzOGKT2F+KtuM33M/YPJ7w0K3VvoCOoDBiixVH s9NiMw7dsL97c56y56GX+FdOys6wDsCR/hqgjpOMpVkSRJe1WpasejVULVkuMdX4W58vMvY1 lZ4lSZwIsGkSzxkR7yUpT9Jiu1qNIzDYyNEoAjLAXG4zx6VCB2r90EtTxkPihUBJfyZ8ypRn baQ8nLbYkydXN00Bgg8WuqPRJPDR+S4XEy/jDYDQABpPxt9m8ZSwmO2BJoFjGiRppsunQK3P gkhW+jMQXsKjvKFuDCPxXYm8ST9G0zgM4xvkpIJMeLZMAFmZrAhaFokKprJbYKdmiHoUKZpw AZTTqKF5mHK7rSTjVRzxvDNApJq6QTThbwU5RWrY8YmGG+x0h5WYNUCw3R3ekZAaSdkPuRed CQ1ocMkMrkYHNGqi596iYYG3EE713FTaI9Dy1PcWHCdWwwfd8AA2yoIs4Gn/199lL1SB7CTt dxO+CD2fK/j6n+v4x5sv/lpv3gX+mODD7I7gJwR+qcFJ82YwjySpK9RCRbQbZHyeNgxd2Yzd QtS0lE9JDAGlDCbL+aLBWzDlbhLoaDSS/YyX0yl04Rw7oN/Aa5zCmlb80WLXXrjkRKk78rIs qaBUYqEPmP3scdqvP07r8IU1BBJTWoSwKVgCGmhImEGnXM7XHLumuaE6OEFqTZSqUbNZnuZ8 3RwXTPFNptj1ul9L1wwjYHSXAzvH7cfpCY5d8lMA2TOlPKb2iWOYNi20EUmxSnQ5Cj36XMvW DtxEWj30HK811Jw2YdLB8fVqVBjxGxC+NPG1ddadpnW/UzLwSRxbNiCvoRZowvCzbF7BNfBQ ojewotNT3xM+j6/BM6KP9YPEX4KHhMIpT8htkm/DOnTiWcKByaCPXrRirutWIoTqCMg16fOi ifiNAykomGX58uHaamYPtlseKDaRTOR95JPtTwr21+Iqt6p4yZ2qKZ1TtNag53jLFHqLBY8m kkZh1oHWNUK5ma2IiTPvmtsteRPUNs24N3nKxtz3limERvGcMxV7zDG40oiEJDKSYO5OKuTs ZQwWcmuFehe26LBJPco1y5YDOdeHrhwRN1gqQqtv+MqIq27Dg4tOPrRANbvJbgmWTRfNwtw2 9AyrXZrMzXxaGsFSVXNpGqqRWNRIO/A9ycaI7EZfvPzu+TfnX//rDNX5cO8v+3kdTLSRaNbH 73Y4mHCQpiRsEs9tLYeCCj2HUsAEfzforwFIXzUNjXxAVKEC2SpTtExKNQsokFGwK5jwPOGo PTnahXsOC6hMWoCvwFSEPNHR3fnr0x9elyJDoFRag4KiuGfRZA2ms1cvRraVLLPhlvYGzc8h svD8jCcvQBOKoM9fnL4+tbnzljhRtgo0a6U8g2ixzEisRQsmbCeJHoVu8iNbLXiDWjZZvy9+ Ok6zYJ6uFW1vF0IODdlZd5NVuwHPyFnXLiR6AB0hAKK8iZwIWqWbJXjlEsqY1lDnOBZp5jOG Lq9KNRU4IPDrVJKCsH3WwUAq1+lq0uzO8rblhZDScjJf5xSNNhQ9VPYc1qc2OYkXgPGm3lvM oeakD9BUlPYYxnBpSf0rCLZw5UClFZicPRWRAs00qYmZd9liwrqXl2VVvRN2XfSIXBQs7gOY 6sL1yMBHQXAlLZzJGBtdWPga0lHRPIAADK19n4gSPgcWLy1bXiK466Pe5PGY+Kniu/5gaARo W4/YNAhDEfcIrAzdSxBHXrKyIuQAA8XEiy55o9NiIY8agjUttluYZ8onDsTfYIguSn43V4QG p4QrNJnEsph+YrBVXhOjlS11qleJOUxV+ATFebhb4YQtO26HRbmegB3MteQ91WP9oJXDw6di VGqoZq9VuwSWr9KKJkesgq8c7SYjWI1Kx5tFBI8YhtNsuajmaoF8i63CPT0wdxNzb1mt4EKj yH9YAW0a5N3EQy5drdIw+nsv4fDqKWov8G0MEITRIiWvx92nEoixCgXoYsm23OdYLwi1PBZd ia+qVc6ORzs7OxAcp7hViktyZpgy+iHi1mtQtAb8axb2Mm9dAi2gdd6bwiYCx4b4KOK8T79l I/5wQ3f/s/u+FLImVjkpxpN+U+5RLCBoyVj9IvoxDia0cS/WlHXdMwaxShxyd68DRVkw5y7+ kYULsRGOuFtodBpiX6PbrG7DdqDIoMBh7PGEjVdAn6BgAg74ImOPcVh+Sjtm6IWRdBi8DPL8 bgUlOPcXOuApgmDHXbtj3OWARjyr6LQI+zrOvJDwXWQF8vzOtt9t5pqqWfsiSLLVWt7arN29 C2ub1cA4tN278xS+DR5Ph0XW7uK/tubw3u0c3iuTsXc3Dpsk+HvQ8V5bsfAWjpstG/7utr8H tMsvbSmKKlk8p+0kQxZr5LD/Hiq+X+bD/geLYx//5eI4uF0cB2UyDt5DHAfQ8cH7iMPf38bG 4vOdhNFi49CLrpC+95bLtTlBHiRyN4lo1/BlY+r5WZz0ux3T6eJi13Gc4zlPU++Sn0DhMW0S exOITtK0Xw/d9N+rNOPJs2CMq7usfvLSW1K4eS4qjtvYgppCaKob8iS4ojZjXj85gx/AB/Y8 9q+O21lM0ON4sjohMo4XJ18FDIFax+2FLpvFNwwCC7aKlxD1TrzV07x2fNLbaR63xwqYzYLJ BNaF9RVP6yfHgaLyuB2csOM0uIw8cJacBZN+vdPZ3T94+c3fXxx19rpnp387eHH0j/1OvX2S o28r4o7bmjfAKKEEsQ9sqx/7EJJxWmSeXERCr8srTMF2w5+L1vhX7QaYJTB5jtsGYoFWO3dD ssE0P4DugxRHo7kXRKORY512p6u0xS55Fi8wjKedjBapFAGNoBjqveQSFUGAueKjAS1dqLge dHvDlpP05GENtgDYX3/X472CuYlDJmT5OPHX4ArXzNeCoCn1kwPQoOIFrsChfNAZNsUGVLPq +EjosDwY9LI4aCB+pLXh7CSYjNTtOE1o+kenUPxXPyL3gzK+PloC0K35P7uU/9ntYgZQt4P5 f92D/Yf8n0/x4CERSb86lYY8A+mIMi+YJnRbRkx+HL+AtX3wluMhfvl0V1Tisl1C0eTG0yGA py10ZUYEQOkwXhzpSzRAQK94wm9blI2JAA3slI6y75QOgFvihf3wcoZAz0wSUIMcROmwJfMO KOdqXd5AeQDVvRTzEDYifd9khKqz81JHH5CikCvKXZIVSj2vyVioUB0bESUy9GQugySipZMa NsnhnpMhdMKBGJvYfcm3C+w8A+wkXXg+pQGtTTvIoUBf8h82kOJ77uB1ldxVr6iwsxY0lRG/ qU5ze8QWgX/FPCZGSUYlSlnmjUPoGTf9zAOHv+5sOJPWW3D5gAZXNwMHbIYzHMqvUAU/jEPK jcfTiJKYLrdbzXYbk/NQBUWTApfkaQ3PWXNv+Q1UJTfixOkK36Sl95HY8B7WUQhdBrXWVvZ4 BWF7Spt8wXgJMZ7DpsswXLFfll4YTANYNJFkLVQlLciZJE5ncvKqkhOINZs0YAO6ihwFzb18 pCpFIx+WSHyN4nziMQ9WpglEvwmmwmHKLLQo4JFcclI1IWwAeQ5bdDw0vjy9QuVWkJxqpppV nQaooYqdY/xlesacNDLeKS3OpFxpfQuTeualMxxOGKTZHeSmskHU1LkP4W3CWSFBORopA5bi 8A05wRBLggqS4uGCEkiKazFFQJVoKrlgUm0Jbg0L7sSGtUglDwyDbM5NcVygPYFOGcNDDpyz OWtSH9hiGQblMqNUWoQoHRFUtVEwk8t01AcKNLriK5BZc828NGMnHS/m1nVdslB+XmOZPnMJ a1OyjmbKGnCcymknTYaTvzlDOmfnOJQt87rWFMNeF1AYWU9WRF1OW7rHseHO15rx3WFs61qr 8VkNxJLhy3+8kiGsUqIWW6Z8BHXeMswk6cHkbZ4wPA1gqog2jtqvgDERTJ/tdC0va+Cq9JJa dWmPwZFrEGFHir5d+F6s2XpkmfmaokFSCDEpT4jEQW9vSEk+yAiD35UY0SSBn8SkoeSa484m bq66bBJHTibyWli8zMD8vjp31fmPXE6JzoAHQ0WLHpmaagK2WSJCAQ4EgFyoDADXdrc3rIhr S8Qbx41m8pwIa8tngBuz5e7jcBAzRUTsRjataMu2NmRmaFtWOGbX3IQ/q8bGRYKBAeLDrdFN nFzpuHowtKbt3fNUpL9WWSolC0vVfTVdy3NTkzVwnEKKy5YYiMQy6B0Oc0y9jagI/rC3Lmem mkGEImeKcn5ySudommVvaDizS24FmRA+EQtwYZHLW7s1UCTd1oh+0PqIHKXc+pjpde+Y8pT2 EbfG1Tewinwo+dLAuoQoI+2ptTY9qlkrzYRPmWFUWCLkr1I0aXc4l+uaNKvc4Bvc6TQLwes9 nebfJWPmrtk3/3GZNcUkGcVODbClcm9oLOAJYeWdsjJcZTqNJYZ7SYT4nxRGa9NobxEQGbPq rKk7yA6fYvZPMT9njYN+SNK5ryQdjfshUedTJuq8On/I1fkPytXJxbFGFA/pOp80XUfLA0I3 NEcbEnYOb5MMuZDrCvkclhlz+MHyOcR/uXyObpfPUZmMo/eQzxF0fPRe8jncxsbi8x6Sdxgt y/r1H758/pfd3br42aNbW/r1n15+/eqb+sfK72HUS28GUUi/PsuyRa/dvrm5cUV1e0P+jyL6 q9ffvqw/JAM9JAM9JAP9gY/M/8HJ/Afl/7C9o4Ndyv+BWXmwvy/yf/Z2H/J/PsWT3/+jdMBO BELTHgbjFlsmofokF92CZU5VfpBMJtqcIPSIyX14Iy+BtUV6AHybwyod049GVgoD2BxoSBcR MU/0g3kS+qhU7PB5uGeexssECvQSmfbPPfbPH17iiQK+UuPVxKltPN1IgkseGcwMNG1Q81fn 0pin/ozTWQXPQgx+8Io0OkAHdOBDwa7+suTJClxA4l3OxW6HYp6rviBOYe+sU8JHLI7CFUuX C+Rpyr56/fp72gGAniDGmAYhT9FTz1tkgnFfYB5TH+YFALhEJSKrTnimGN+R+UXCzd0Puxn2 5YitVBroZlxCS9xl9MsyzjihHuz2hs31+FHBCuhmgE3qnYsjb4ie7S3gmbtYZgkHHoMbcf52 9toRIqiAmoFbgSjWOfXx/BSdBV4QgEmPzt2hFyG41xI8jyYC3nzTnoaZJH48wfSMJJmnl3iL FYHh0NBt4U03q0IbTAQRzZAzu51Oea+cOE0IUC7FPiu31+3XlJ97ER7AejC4NMUJAdFpOryI GGuQkolp+zhtUsBKGi9GsDHLxOrin5HUW5h22IEUNvaDSMVP4ePlhVzfnYmm0I1xsmQh/fo7 SRoMPcMJrEhHlPC9ImYQ9yFoO9GAmWvWuYihr9vis9Dw1sIHn/LlGHLhM12Imxx05TSIvDBc FWeI64dxqiQmT81wYYI2LYw9TK1gN3wsEimiK+Ad2DFhxrSBg4VGjFlUnj8TG4ICTwoo0ARQ wpBpEWs1MuojjNJhaA3HCNRv9tw4uWx3P//887a+5xEB8VCBdr+oacL9JQ5TXJPx6rwlepc2 EI0PpQJhtcoGwqAs77c1GBrRr+C5aQbfxEFE2F2hbOpsIMdgvPYNM4S61+eYaD5tTgupE9QA ajdd45UDUfw9FzGwaektcJshAG/yI+/GldxWq05iJkhWIZUtjAu8TDJk0lcVHZsFYuoVZTsY +73wpbYmMpa+Hy3nHxT/7XWPuvL+x73u4ZGM/w4e7n/9JI8R/0kdqNVOReSyM00C8G8Qh7xQ dzV+J+5q/BbvaqRIjG5qRNtz9Wa89K843eO4DHmrRvlvnrz2UW4xoQHjCSyJuSuumeRvFxit wUqXhbBiXuKexhK3f8DOEQ0syDANIoqjHTRpEy+BUG6JyUrxdTDhaW0ep5nK45pyWuMDOOcT FfNNOIR0iZcFeLICy/IUbNbcy8wua2FwxdlP5y9fU+5p7Syn6nwVZd5bYwfmtZEX5ccRhgas QUlkXObEyZMqY62+5ba3tsCLbQ3wcFhYpC36exqGRPmxjlRPmE4plaMq9Gah1c0QPZXZp0Jb mmaR41XRzzt1A6v0ck9QaHS29QSCi2yJLpA2bnwvQpHS7VTy6s80DMCZYYIdyQEi5bl3pe6b 3GKWVqBk6kgfvhNfx3z1ep6yloGp5XW2iAF4HHLVHj0j99LV/xV4cCxiMIPFnsgbUHeROinT iWKibVs0KSAiI634F2R4DmS2KQi4Urg3Myi65hS7r2D8KzYmR2qSY+JsVwmWsGO8aCCexstI JmZWdNyyOyYs79J5G3srUhBE09igoIAIfnjqJjSIpVcLXE6oPFmrF8QzeIYQxTny4bifVCO+ jXbiFhVVYueYtZyy+iWPQJnDOqmegzxy0GzVTzvzL36qrxlkP2/2Z/YMG/Vlg8J8WkbaQLWQ lkTkqEZoI2PcM/cSEjolt6C/F8kTFWYGzOZk6Wd3GrBQLBlXC1WHqIvhdYCKB8wJJo5Ifo5Z vdM5qtfUMGVPA0TyTGy6HlnjUgtVa7ch4WJHQWz06U1MWAlmZCQ4WfCWMOShl9EuBF0ZKtop L6Sv8L16c86h6dWbF4FPn39LvMVs/XtNd7not/CShhbu2gshu+Y1orKhWwVZSLRRbC+/gYES sIvpC0V82k+a1zZrx5t+rHcSJLHm5X4Nwf7GgA+bSgaNgX5tYdhkdoD9TvexlvgxqO72V8LV M8p+ZxvXsvfwxsQjDLxj0FuIQ1g6o7ukPQyHxKobjYQMYMCbeZeD3k53WGcpxRrGHhBjJ2yS eDdjz79iPXCb8U0KM/UmItH6eBMf+kgIc/Y6jwvtvMm1B+guYeSTgEKlCkLwIACb75skpRYm 6/FYhJ5bunGtU9amk/EugZk2e+vlkvdys2TVtZIgDP39TOXvSG2ltapQufx9Q3xA/8/srs4g zHG9CdLGChVdUZFrwgb1subKLRMlR2hNlXeeJqdq1Aizdshy2KflKXaaD71U9yPgPkUOIFqR +1eCAaw/Vr+s8OM6tNVbWYKY7nBAHVGKvObbHXbCPsxUqEebARHxazOQwWyIqk0p7rgVL2yq fjVBWh9aizUkzqZr9OTqQE6PxtI4TR2scfyZTVw53bvQT96mopumdoDUav3bieXeCAchl/jE gOQP2j0X7yrQFroxsIvy3CE0I7EzZmGTZei8/Xi+wO1RRYlNiCylHDn6VpN7JV8uIzp1TdF4 Sxxg8xQ82kjMNF7IVYzoDks9WJ3MxxM8U2BifhKV6t5kXDLr1Q6sfEfP6f+OABEOXkOKZ8n1 2ujsbQaWj6ufLzl2ij9Od/7l7fwbil4ElwE633pn53P4+Qp0WLZX0NtMAuFB8s6o59axyO4N ClRXtdE5ohuwi+QiusiGEimVUUuNtj4UBbpPLHoC8D+SBeozZ/BzfbjtAN3icLzxtOe67eb2 b277tzb8ByHe6HvBxx/QCCeYPC+EVP8ZgBv1bWy6XW8+bbhPnjbh42nvGZZil1DcfPqnepNw zEoIcrDfBk+GTWh5cTFouNtPmxcXQ8LU/u1PTWyOK/tic6fhyOYOQuofzSfNp8+grqCE+lFg 0AjanG87T/rys44YiTNQDSPCHdWrN2gWcosFBovLkoaoQ8NPpgNnsVes+/X3Zg1fsJPl+asD 8v8/QLslDfqrzqfUdJBpC7BKhh8i/690MyzufUruwHTyEjAD8vQKmllusXhFsepFftlWAblo P4DmvbmbcDrhh/+GLeb8f3tf3t22leT7d/Qp0MxJSDoUKcl2kpElJbKtJOpxHD9b6aRH0fEB SZCCBRIMQVpS3H6f/dWvqu6CjaSd5fXMmOfEEUGgcJe6tS//gqn5s2aJ9Uy6Y1JkZq3dCjGP xZZDUQVa7kYC1GuWaXR5VE1Z99YJMypkzBPZ5OUmfgIfAruqdsqZnuxfC8fgsnzL7v5FNWOq eGdwJ6h9n5+FsBpEs26d7laJwyUQ1ejbPPYGFpqBedcUGZs1z38S2F3Yo11wQ9qIEZfnWTGc HV4n95Z3QZeKN7S7V9EtyUbt/HrKsXAourLxxybYXovhrhix0TEYiOkgomymJUxwlISsrxLS Zja1nyadGIctXITeAeaobDGZHpZwmZ4DvFLqH/CawDTuNFasYLP5LjvarED4nUqEp/fzeMvA 4CBmeJsftE+51HKeDL6DUOmJDrUQVI6TLVm1Ai2u+uzhHYuVhHnNFZi1cjVW7dOK4evKCOXz m8w032dpqneWV152t5bW2M97D2/N2ufHucH610/Z1xbttZVrQFSTDvbgEsUsWlF7LW1vekUl LDDD2msfrxoXrcpmKyJLXFiW5lZ5Ff57UZHKU7TZaNYh3brxVckRfBjKgEtbWn3UVxC9WtSu JHve5m44mxqip5KPQYhaAWjNoufiOBo/TtkhCN0yGgY/Pzs++w4vmgRvxNrRu3POr7t4+7fG u8zh/YSueqpbBtwC5Np9V+jt1URw5U7VHOcc0z+qbOdQQOtaAriSA21MQEt0wJS7odtaTdGE g5NOcLxPMpCAIQlRhZ3yu+uepvWtA6ASU0HLF5CsyVhVU00aOUNAXonxYvfUqq5ypR/RpdqH qp9cdSBMkkLkHOchwjDir6paPXyrBZ+4vLS3WxI1TKRdr1eRdO2ZT3KGj4qXbWYWq4RWHGSh G4fumzPrMJDCcuYHU3jHCmTMlRWQf0uQ3Y9VWJWLHounhF3x0Jpy9rdb2WW6TIbapQlW5wCe L0Xxcq6keok4dN4vk17nCPpDnCvv4p3Ivf39KrXP/u08W3/schZf7/uq3gDoPhwHb3P3/0E+ KWNazsH/c5xPlT4Onel6NwdCIIXHGdiVXoJZhYWmrnhTJdE5ORf4RW/NGo+Jv2Oa9J1f07/c OYLGRcfO+1H1oD78ulpMf72q4tMKN4j1gRSrW23q/MjhpOOrlRnLgZbIK8XF8h+VKcHlUt6F pMDaJOH12bizCnC1Wbny8zqQFRDLAPl6aM2ojGya/jST8gJAIiMuuU3AIyHJUhDklBZGOSjI 0nJQzMktA2LXqgLKSomdXh5lB3+ZKA/+4pfcyyVSotBKIZXxmUvCLKRm5+8LXPZ65d27xdvh uE5fR3OEVZWTuRkF2sVnAhKL1zy05y2F0lCX9plHbZtZuVfKrDQNE216pUTpmOzKbBEultlh Y4oAwqQRoKbQYQMB1Du7O7uN4Oaw8UUjuD1s3NO0RpN5OZgeNp8c//j85OlZ8OK//vni7OR5 M0iXh42H82VG5zJrBOlh46fTFyeNYEBX6X+zK0TM7N69f+/zL3fu3bvP0HcZ+p6FTvDDQDIw J2GcLNL9RJIebYLn3jVJQZziyc/vCICdioTP8MglfTJkuMCmh43jH7/98cXZ6dPgycnjHx81 Nh32/S937t/b4bfu6LC/XDHucDleZot42k2i4XJQHLas6h4t67d0V/AE98iIJa3UH+/3x88f BcePf3j6Yt1YAVmGtusv6ffhfBAcDzksMbwKOd7vYZpluZcRxi+CCZGFbUERlyHSCKLpIB2i PE/ji368yPwX7d31XnSGOpgohRlgEQKNl7Urc0mA54j4bgSSzyuRtHlEsHF5WA4Tg3HQw/BM IqtX59+1BBWU3xWcX4Puy/mYMKWM7iaoqwozLd43Coj2/pi9QdLyOhz+9v2Q+D3Q9o9E1PdB TdnJbBYNYlCqDTF1Y9wEHS2g5e9DRaX2P0O/Ds4I+i/TpqcAsE+5efDVzSQJiA8gMphwprvT +OroAAM8alpGWpV9ve2rKavzr7Pd0qUmDdy9wx9u5YB+mcqQaAaAxzABBYndRTiSc+KyuwW4 6KgZJ+zokjUL1cHoY346/7pwUC9W3EyI0gurfncBstW/mpdhO7/OY9eaJ3Age+HXaw7zqkH7 IFa/rCd3nr/X29yQW1/nKeGnwdfxsB38K6icfRGSJ4pwgVQ1OYj5lHfWU8MFkY6aNmrG/oRC jvnwHPtTlSyLD+kYN91aw1ECgGoP84RMzl7TAB9za1mDkIc1Dqnyafmr0Pu7ToT25h5oxLon ruYrb0ytuJqg6oeekvevf8A//0+qfLAnlQ/er/SB5v5kyeJPS/9ak/91f+fe519I/48v7t7d u/c58r929j7kf/0lHy//S3BAErPiYRQG/egyRkNO/2dIBZx0gQOA/J7rOElglEK6OvJKwoTO 2W0SZZdRtMi2SNpBxBJ3m3ZZBpp3w4W3mT5sbT0Sa76nku10g4dLLjqOezk9Cz11XSFP6J64 0iV5JeQ8MbVIz6+WsyAdmTOUImfCT/PnPFou7tZBdZvgAJPbZ207l0kzRzYUHb3lwBU251QM KwlpmkPWe4O/vsY73jYQD60iEP+z2w2eS5iIzaQQiWoahP0sTTiTQmhrU1wN/Vv6fzzPvEkc ZCTJREcdZPUMwiRxA+1KcpP8jlVAFcGhqZTIm2GA8KZI+lKWyj7aEcAnFUdS4Z1UDzjlCArX IUinyNhTGOb/x0mW2vSLwsTociIpd/l5tRrdbq/RpvkZKGaaFfO7voymnKlk8rvuFGdqgMiE ac81m4XnrJMNaSPpgIc2K9AUTBCv5iI1QPo10+bf97rBt5yso2WEFxFJvfgyMjGj+fW52w2+ wdmZpQtaFRIUgEmjBA2qp2PSAfTxIw4RHZIoMYwQlDe4tJANOD5fNDYcsTgaElxIuSYjvGEk H9QrIo2BfRqwlSThzO8vYKSQBu47R0IOqW4XDTvoly/NX3dM1h48I1yPEmWmaYNCN2lGIN5Q r1cH//8rGt9yzueN2FQ8iX+THAVkAWISg8s4wl4BzBxoDlcalmSQTiaplX5EEXCHD5l+6XJ8 WUj+SgnPkFtYjLY1YOZRtkzo6SySTCcB6xIPu6Lo8BLHUyRUZBYJ/OYLQgmg59wIbm0LdesG J7TUtwsik+NmpqlZljxpEpPDMEac9Coi2R4ZE3bhni+n+zlq8a3WM7YLzhMEMJ6JfYOk7PoZ /x7V2VPyKWsmrdHRGx17+Sbat8BfGhR+qyUFiB68tlM3aJths7hAKc/JVWT1hpOkKddWMZB1 inQWjsEfQOOHWtP32GMSTLhNZi7bEbnKgVZn0WQTe85EcgdP4eIDoXdksn1XkRjmvlErY6m0 svmU+cDVLNn6ZZk2d6O/ZaTXyecjS254Kp6WOZHfw2nFLnnmXAVjsm91CPYGO+qP6BSChU4i Wo6hG8hJ4NLzoJkEV68YR7CVtsvT1Svsv3P4HdN/LomPM3a8x8RxYp7J5ecNXjBOn/4Awt/J dwnbNPeuOvWuI4U3OrJaXry0rJ58tSHTcpG/2VBpucbfbKS0uWq+r0nws0ehHKN+/jLc/u14 +78uzB872//Rvbjzyy+tLv3T5uB05iil8PI33TtfvUUIuNevyrhTvEsaBioXWn61Wf47sC0P TMQpX+7AsAAl4JdfTHGaNbc35O5GM1cxIt9fXOMrcK0V5Uvfcv+wKZ1jT5/RC2hs3pXq5JwA VrrotzHPKzlR13UvLzQv56HM5stp9BK2K+ME9ofzUnqwVFQ3OXvee37yaBvinacNe01I8FyV v5HHXpWNJr/kIvBzo5dK7f5PbkFc6Xb7+wbt0by5R6z/lpdvk6ZuDEu2VJfQNGvL3bJ+QMVB qZe/7LzMvS3XoG2r8paodIu/+ejypvd1bK+af08sqO+LV4UXlXeXl2pjTGEQ3EbPrlIFypR6 L7JrPctFe1a1ztu082L5jaWni7e/b5+x/LdAA3vYKckw3zAPeGv6zEXEcV4KbN7FFcAqmjx6 s3iXRo8VmZHVbvr17R0LoN7r7Lu+jvTvJm0czf5sTBrccS0hYv2oNuzqqNOuQs8SzE0bPNbv SBlcuddj9dOVSx7k+j6unn9Unn8u9NEkLBZCID+2WjmKrhj0J/ld+pg98/MXOyIparKjUefe PXdMZR+TPGbTYd85fUyfLCeO5Z6z1vGu2MhNLtBO+3wX2fQlZLnJZ4luEvBbeKSAKgwTZGmj oOTIL44m0cONBkeG35Q1jXdKScrlEhXWz+v4Zj4a6icEsOW3vTT9RjVh9dBFVvI/wDsj0wq6 JqTJJ51AFBPgqx+TNx1KfF8z4IhsvtfHAy9xtxAwC2xycrifkyy3l/PAVoa2F06KQ5TKGC03 mTU5FTrBz+B4MJ1d/aP7SdZui+uiAnuqd3KjdxDcWrDVIItHpXYpdQnqsBof0T6xrbX4bDSY m4JPaf28PeAQLNNRMWPHDrAKb1asHhsKPuGiSMQLrEOJsbdwyNfE7/MILNxcE+A1U6L347X8 VnpW1fjNF2clUqx9ebP+le+C9I6eVaP6+8/KQtZBI+3AxABUg/DzqarRZc3M/pijvCYt5V2O cCEr1FBqwt6XMHMViTUe+V9MsP98YpdPXPIdGcahf0B7s429OTIGc91DF2vZqHor7lxNxd7p 3RMEG2kRNMy6/E67vKtkmgqknX8C+hEJuhraVUMfN6O3Sma3Kp48zJHWZvXYLKFw93JM7CdD b5BFhGMsqNCJ1kF2ZxYsTk+tYXAOaEUVK9t+tWAqq3/r1FoMeQqf7eYOaiUWqQ1hU9K64bwM 2PZGG3C+v713YXZhXr0LawpGNyZxxn4Di+bONp1D9EYNqTRXLcmMRx+I5b8fsYxH/99opX31 n0cqaaiW2FU8sQGN+0Cofi+h+rMJjXojdLoc9KI28Ho/o5tC3gq82ppWKpeXCak4H1zYlw38 l7k1WFUvb8XQq6G50Vcb8M2nYmHYAli/LrWmYBvFW2/2XWEkjbcU6cxqq0W0vMRuaoDzWTNn lqtUBCrsouttoqWdfKfdXLuj5V31170eaPUMawyunqZZbf/MH7ziyuYsnhZjlFcbVBQX/jvw bRsc8Tt5uVJdAy6/vDI6w7CBr1n3pYucGCzOgXgXJXJrbllFmypha18cgPYqA3yQN4qfDZg+ r++2C7X668WO4gj+POnjXVWuVUw3IBCOcn8y9GmIQM5jbmetuF8xYP8V616wRuzHx4r+awmJ xIqtpxl1xML4jOUobSRt8J1FYcNihUOC0onWsdK5v1MI5peGL6aJVjFmUBbdVcv0aIydtvlc R/H4ErRld8UGVp5chl3haKk+tPm18SIghymvqYQQI/Kr5mAy7HKBjfqparJDgTDlkyQqimt4 vXQq1/Ud1pZvu9HiITd5Z4zJf7LrI618dF/HCHRORwGnmYziQby4NY0aLN8zlAYNM/IiR2qi +PzwvWhxHUVTFyzXMSHA5SUoXdDaPCzhfMQRxvPIjg1Aputh8MNa3OcjdiJu+MxHH8WZtjgj 8qk184maZ2sAhMEVQnDNKnoxuJzbpks0FMcokt2ScUpU6LKCA65cEDOn910YgaVQBOSaiSWL SxsNKzGuJlpSlonGYJYJsXESFdwvKqSDZDnkcEt+ioPkO9xcRXquMBhEu+NYXkrE/m2edCBu VoONu6uHfAdnPBI4DYm8Roh1w2W7cVw9D4RG3I8S6f1agApC4dePoq2zbWuK769Yabtvutgd KAf697rni+f1GjURdh4E179az7j5lAtn1REuBkL/fOZRX/Opr03FT+K19E/xSUvOCeodAX39 a57yVBA4HSC2na4sbpk2xOiHYuHteMGv1vXCWp+hgDXaHnrLfSxsl7U0NZE4/laG6xXzWhmf 63uIVlhPKuG+s8lkrblklalkhZFkpYHk3YdeYRW5iQbWgmEBs+ydh57/saSelOUx8xE5ipFB nuIMDRWkPKwYzWyECt8h510Cm5l4Ef5xno+JaJZ+I/TX/FafU2rV5OebJq5dw9oLuR/WzsCF tG3sctf8YcqAmFpIWZehnvP04+GFmhgiLgsjARPt0lQlW2XlXHm3dHAEfygT6nBi4FQmNpp1 +a6WjoH96joONNFrNj0NS8ZgbN1Cx6vkXZ6Yuc8FqdeKxroTNqpRQbsLnsqtV/ifl9bT3CDs FjL5cjZPk3QccDVzvqBHYbiB7F0I79RTIlWRDJiqKJi8SmD+sE0KGYBMsiLY080i6tY4ssuj Mc8QLUQ70SqwnkaPQ1S01VQ8YZeuLsN8pV987Utte6/StD62gWC+oOkiJAW2NX/g8AXlEl45 +0j+d+aMdiuqTS6brS0+XqghMYVFXZxhTVifF8KMp/PPLLo+RpbGUqLgC+VlLKBMgxYpbFKa vEZZyS/iuT4OirOo2M2cwcm/t1ujKBd2NdN8IqMvcp5PpYJThT3lMUjUz51Gp3x/odAb54Ov gdNbDSc3F2scFtooBKpwAFxi0WEQczfOLpePa9fcZre67B656ii6upvzO1dfA843FRSeMc1L ryoeq8OQK8ENf1MlzhlVONTSdCTZl03zpG9y0GzQ8pnOLa8v5NpbBaoV1FmGj6ZDvW7zeP0s JAvEaFyVb+B5Op1sBaUoLGC5LhYPGEVo6UyoRoBatdu7F8Wa/tX2+NxIzgmSbUW0eEdjfAUo sMtFWcHw95JrS15GuSxRtwESuouiX2PkL440kBdTZDXegyQaVk4NbXiQCNVN80QQgYavKza4 x2LlTtFmcNPALBrirKqCVnmr1y8hvxRafr+CWxUWHovR0kKwi2M6gQ/36f9d1US26bv+3S5i khUwdqvRe8sf7LEYnArpwpx6ePUK2XpYIBHdVDDi30bGcJEDppUZk1uVYFgKrEo59LZqrFTZ T+7E5pqDZPMbnbHMPs3PoFbw7z41FtL5QlhK3qy1rlRIbk4+HnxsbVAmfbvCGMU5h8XEUt+K 9jFPqR6fbe5pAZMJRvaeKJkYVpVHy9w9y+DQW7ikFJ5eqES02wmkfkkFwffBxBcXBcC4sh0s q7hLHBwo1GougjEuEVGZB1eFiSjnvIimnj2J06XZEhOPPSXLPvPSmNHfUbizsriPdhXCmbhH o7xA5NvE9Rb7m1STcXeUpwm7s61OILRM6G6325X2wcbzaQ1mwShE3SBabccVOZl6pLWuXC45 +iAzNi/CK8LLJKV9n7MBEGnRMz/nz+Syh35jUyTY03eAyB2ntSuO1NYKzK4+7HaL8FR52Tfc ndIO1YmhVRvmoR3KBMdhEv8WBfk06mCcpP0wyWWtc2NS72G2E7wO5zH6LkjVCtGui7JsSUnx gExhZbR8oCwcOUuLr5nVybg+7QelFKmz0gXvjaH5f73L0ols62NUeUCXakLGH4T5QGkPWJff +tiLDa7X+xXQs2WfMCI4Nc0at2yK29ZTtP96s2HC5Jum25/mvm9PsLW0nOC57xxx7ldeaPyU d/m7Gwj98LMJeHY/xCNcj0fuCqM3LrpWt0Hw9q1ZmBfO2MFp5RsUtFYvqcN2+2CxoPXTF+3C TaYqrtaT9Yqdj6pwJa9blpXWeonCGpUKAOVGvUUsSW3FAFfTt7LuqV/X3F7MOPOreeAV7JOK juFwiM7ch41NyjGaUoyoeGgfjObxFT/TjxpHJ/SFJho8SgdXpojhASqUaMXA2dF3cYCbOge9 mb12Ka4BrlOySIfh7Vfu1/7R/nb7oNc3NweX8XAYTQ8bt1HWODqIzSgPevFRcJDF4ym3jNdi lnv37j/5z78//mLn7u7J8bf3H3/xf+7tNHpHDnzPDM4rZtjUHDmpGdg4GBAbiZhuHf0yFXmo rjDhxmUJG6ge6AH2SifSIdXd8ugno+VhY+XJbshd+/PR4Mu9PVftTq7eSHXHn5+cPv1PLgx5 kCtAcciWvt4RD8LKp8bK38NSmwaZ9BXFBWUjLugXyb01P2aLORd3e2Pr771ttzE/Aq4XWlmb NnqfsRC1ki3YRVoC97ViGo2Nt4keoP2LR0eiIvNVOhaEbZ5MXZoAULdx9A39u087ym/oHTWC T5PFg/r3fTqmX1fDxYDP0hzMenhrYEnFH9mtPvGl3GbJpu7nK7tG26iI2Ahw977Ur+piq3Rl Dnr5p9YMoDkzmyqn66KpS+7w8MicDaEqvmHGp9BZUqpk3fgxM+qAE8scgH1zsjQSsNa27xlu hsvJjAPS2t65wfeidV9GQL/74/llDIlPODL7KTSLFv3N9/1zXrIXMYEuS8MCd9EtxrB77+Ti RKiTkk3jWeeXKb3Gow4I7crVZFfu08xToOZn2WfNAvlodlxRGlN1UN9ZVYuH54tmG2ae3vQ8 zoO6idliSHRCWRn/W1Wssn7wXIq9NLa6MpL5GuonWPnNy6ejobOAzxd0PzZgNqjlfmxhGDSZ blKAvbGmAPuRq3Fla6uXq7BvdACqlr96+9zRqFtuOzrvJGtZMm+A4o70hvjfqFQny0l/Wq3N f8ePFHechaTHbmfLPsespdPuzeVikvxR79jd2fmivv7nvfv37t1H/c/P7+998fnuzh79fG/n 3t0P9T//ik+lh3Hr4G+Pf3h09s9nJwHwIHj248Mnp4+Cxnav99PdR73e47PHwc/fnRFnovuD M/CLmC1ESa938lR4RLXwyXi1CwD65/bCe7o7XAxJftk64LfWCrGoQS+Pi7CDvhAqoJN0GnLJ lcOG2AJJykZZxCnKMB42eMxn8fBWrNgOZiPo+RDwzu3o12X8+rDxSB7ePiMZSqZmwXExdYzj QTC4BKFeHMZZuv3ll/f/Y3u3AFIG9e3J05Pnx2c/PC9A+j79LU6SsHevu/NFcE5yctD6eXf3 QXD6IHgST5c3wV53p3v38yD+/MvP28H502jB0R4X/BJ5yyJeJCyz8f+3RB0IvKrvg4xLvGez cNod3AvejOjl21n8W7Qf0An9hIjlrDu4a67j6f0gXoRJPKCfhvHr7mAveANI23RtPN0PBgjC mtOPl7vdwW4O4N7OF588CPiC2Or3g36aDN9uqXgokqJsXEHpozeJneOwMfA6Clzu2qu7jSMm WwRg1yhm9JRZiGoARfW0Pzf7Q4+QXhjTbAZxFETT4AX9H8a9E9qedBL/SuL5dnBM+HmbRcGn 4WT2IDhZLIcRlMginB+nMR8mEpOfxP05fK7Bw/nyJiLhK2Ot01jASJMl1IKxNZzCrXEWDS6n 8SBMgscRCo2z5JAD/1M6T4bXKBV6Ss/NuQBotI3KmRHCeFroGtBmZdW94o6nvHpr1E9I5f51 mTqfAqnOx31ifaSYQn8uzotlUWYT8LJnbLM0NXhn4eAKWkafTlzIBtYJ6QVJdO0C+BAjQ1LC ySSUGq7mkdk8fR2jlFa2nLEUAGYdGuGaRMAO3qBAnroKviEi01B4mJ5kl1bEejzbUX+mE0P8 Xop9wokDU2EXa69w3PJYPLnbOHqGxgkaRETjxNBeIeUk7eN/qGUL2Tg1QzZ7QmsetFhanie3 wfPTpydnbWNnHiXRDXs+FmmaiGsOhVC5Fx0UKRqcgrEyN5s00yVqlhLeSelYuJy4SWaIkqPH GeHU6yhJZ55VOTbmPW3bAMltG/VTlxNoLK/Sfic4JRgDBAvDVq2FizEtt8BJOB0vaVuygAjn pbFfRzeziEg03TlGAUdGUQIz917a9U0kHmqtOpB3NsTKR/NoGC+yElKepWYdsF0dgzPXoSAm 1C1eUNrSwWVKx1tK505MyBWChsKMq8Aeh3N68if2cJOAffXqIVeyDCa0RjAu02umiyWh8C3h +ICLVtvSuhyULCIszjGpSai7KoWQUTkXY7lO51cYx7fzaEyabxRPO8Hf6QQoiL/T3kd06Rua KSxiT5bToWAuB+UaXTOiP7GL117jQluodQhnTZYGk+Xgkj0ajIJ0YRRds5La/f3bc7l3dDpd MOIAqWjVvQ05AF+xcO41jtA7hFGUSOo4nhK1xB3EoAgMP4FDZiK7c3fKSeHo4ll6TYhGgE8e nwY9sWJPNbJvTEfoOrztBqdYCTgViXYTLSHeJOWvzTnreMdLQl8QESF1KBNSH6Jgupz0UbKY NJgJ3DCIgjYFf9Ua4pyWwCDrA5KheCeByP5VxMPliyQXTMfQBh+9+Ada6IRsx6cjRfiSBYyP 8yt1WixnAdirUEiuysq4xpbXBp2EE5yBx6efTvvZ7AF9/z7EhRnR5EZXiRpR/G8iIbSGCH1/ +v0JLaxQjEiq4JnV5b2UkGsMJVV6PSWc4cYv1gXNQMCVuvJ2FD42R4IJsFFYMy31zHDMBpDu Ow5R/FYDF4bRiH0/fPh+QPTfco4SsFJAmXBimsKVGy8zXd0MTI9DIIj77rPlF9W8OaoFbADT hVkY5FnKN9McM5rDOB4I4tPRXyynNJaEZD88PwlvkXpCJ0TXSb3vYGiWDnYdN6WVxbZYTBKv 37ZsoWDvtn0QcxhGdBjmUgXdEHpUSEY8PZCAyTBY0756v+imcI7NgWE/UMThIxxmCxz8V0sN z2D/ZJNDBLiI5IPtNp8Cy02ZKCkvEz6Y3U4X4Q3v/ihWqoHGMWKf2CfxcXEE86YxVKkxc4GC 7PqTmCjdDyp2yo9sSKh4iO0n9jq/Hz/xs/K+GweyG/xTao8H2SUs/IUQpNyDGvvlPUsMQWKg xWDlr7/dF61tLtajG5K9vaMiVLYbfEcrOo9GJE0gKqPDhCCcexX1B/N4tjC814LG1B4FCQl9 IdfRP352yrxHxDPi49vEPodC64iS/y2HWscLGfQkZauPyh+ymXqKgG5s5np8+s3xozPdyhul HRobVJAa6Hi9iCEm0swyLAOxNTqMwThNh7Dkh9tm+IRfglrEFBeMm67A9n7wM7FguCxEnKKX BC0eLuBsk1zP9I475Zqq/KkX0i1iYzZIZ1E7f6JOQghNmC2OHdgU8297PEgFpAXtzoTI4ycd u6uyq2w/usEiZ5GpYU5itVilQua+OJ60oIsU+pAwaAImUw6HryFKE1CtXI9K8d8/wdIg2imF xwPPW5LPA9FuArHgUjofQlxKNWCIG0kK2w2ORYwI54obnORGWNEHp2Pz3lyLmlujn4iceC5K Mh85hb9GUqfbtR7QXgynSrx5YG7cxLcWRpZblEmY8lxANMjAcE4tLqDbB9Y7v3envLD0M4/v THSB7Ren31rZUhE21JKRXJ9/2cfx6SvW6okCr8FIEZVAOw0yeWWMzzmhqEn0cDwhRsY8Upae eSRIw6+ELYQqjtCQ0k1iH71zIpv6MErG8XIi7UKQ20IgdNFgBFrIEWcsZP2y64k3ynTdApAU I0roShEoiRekjZudL4lAP8xNGCcdn5A40+TW7PQYXiGSS5dGDCTOlpJAQvKp4BW0oeTWEuET WM1l7q2/Q1EKHhHOXbWFFM9uo9zvgyuVOvV3BpNbwJYTVtuWbNsa73pPTnBuC6dVTVH0Oxg4 wPmZ6Rh5WriNoL55nzeMaVb1EzskC5c09auCtWi3GuUMpX000tLl3aPjQDrYzaFt0s7clfuO RXK/jKxWGGf2ALOKJY9xR9N+Op+ToDoUUQ0LxzB48YifMDOCWBqECXNmg23QEIG9pCibxBY9 Q4beiVw4JeHlMh2mNyyYElZxaw5ikKSGjZZQg6fsaxhDA+Fzfg0JGjglQZr9aISkkuBFShcv hQsQqqXXU2P64xYshUPkCZW6qbotupEix0WZMAuTKISxLC6Rv6rEyqCFCTzlfkAi9xOhjwc0 qTjhJiCsmxi5hZV/r9GEHHaA9OmQr84czOb0r0SA6ENa07Qi3uPOnavrUjAFRwu9fNldziC2 tugO97wWGeSgDu85znCBW44B5Ku/2+ogEpyFzM5C+CtiDVHr3pYwdJBYtPOHT8wgsrFI3hBI oGi9ZI5zYuI0TTWStlas8X9tmSAXuknSIf2MHHqJ+2FrLXjaiXlUpfnzGcpY3oKl1ZPsF6Kj Mr7HmVOd9m3gK12FqKsaWp+40pVhibbxjQrtg3g+YN5q208K7wU22foEwuVNaUki8bTWc5Zm 0PeF9IRn3AuqC7MaQ88MDpoRSdwVg5lHRm0amrhsORcuHN55rCcR9EoleOLNWoRjj4TpQvtX eGX9C/AbFmmkIFqe8CnKGGn4MroNGrwYDYxqQljzWkPbwuUiBfcfsP7W4sMYZ8ZIR/SF1eFX 4BLor/VVO0cJ7IRVUxFqmMDKmzBpiEfwCHqExY/qlW5/XAGhSG0IX7AbpvE8aalLyDpF/mUk B6PpMSFZJpZwQCwhqguEw24xSAmCc2q64ATvGLjpBgRFHNX19GSYTh4x52e6JZ3Ed9re/Rob xjdzOzT6ceXxYUMCmEnTkN6O0V+CKGaRAM2PJCQ9YEFLWw6FmbxBKC/pM4h37ehhyZ0WCZwc RmGirbsUpe1R5C2W1cLRdeguVgoxoQEFhB3uE+e55QjX6yC8Dm89MfTa2BZEzLoOaceWM5VI CcmC0xGm10Qg51LDu4bptAk+KM2ehlKvQFAYAnAEoToKrzLPdMA8dcyCHAvhNsI2FGrEo+fB MxxpE6CkwdRgCINcT6Uc8utbpiKTuVDgfREn8Qp9MGYTrzks9IOKq1ONZL8F/WLcwmBZ1s73 t/LVANJZbg0qIUeqY6MyMBxYdfc3QGKalkW6A4t6JWyuDDI0XMI+wuGtgs/RIX7Kp2tW5iUq oEIN3RLjNaW/VpZ202IwFq4bmabuaDKpkhN/eJu8kag8svPlcXc/ggHoZs7v50n7c8Yz+VHi SlUHkdJ0Cu85l3dw7lB0sZpQsF3qOnV1JwSdmYtxIstcFCTeMN2qCplZR+nWy+ckgKH8Ic/1 CHc1vZCB8Abb9G0WBelUoMki87XMJqJx38YcVzHZif3oMnwdp0vWjSBVh/3UeV+U6Id09Oam 1ZsxwCkD8BvE4btqVLYBJMvBpqSFMiXDsU241Wz1cfIsUKYl+K1ExXQ5thJmqa0t36BmEugO G5b4yl14A27s49sZnLf71jLmHmKvbqOHe/Bjry9vMA9reTR7+8zBNrdIlF/pcn9evtZzpj6R NrQ9IH6Djp4bt8TP2zePCAFQ6yPLz65Xeq7nmxpXI7h2DyTFZggE1FIhMclVtRukR5djy7Yk 3mymMWaj9pYN1HNh+oUQPROe57dlNteMrL560OwqjHGSSo3qjLJnERVD6Kjw497nsjf5IIXj MVgnewic/gqEtY5Rp79aqzob+00+i5qC4pEIEnzZMCNOP1TzkvYsXGbiNDOWc5/LqvoLHi+s GRaoZaZniB9/6g7cP02nWPR7xJC2oYimM3jWdTE8tV/1y2799pabyMnDJgHAnvXVQf8/Pn/S 8YL0XIQeBDeFlGmIoo5OvrXrBUHXZ/bw/MKTC/V5yURYiTk/MckUCdm8Xug160tWuBg6edBJ FDhnYpIceUOBGdJ+E+8EVHcm5qEsg/PXYXFFQzQpveFYhBTP+pi/vdBO0GKQZ6M8K+pTcG5c GswcRvP4tbGgWJaka6aPqdEJb+dKemohdynITr5vOwnPDoF5mLII8JAV1EO6R66V0DkniUe7 sPsTBoslDsYEtn59m1scdod0LN9xGq9otcowc+InC8vcGjZeFKCprd22hi3LqU78NjWw1PKC c+vQw8sUz2zZJUNuCUUEE2cOE2U73Ujyi6wDUiLGfXQ7cOWHI04M6R/lqZ913kqwq/osRFuo HuI80iAUF/ghzYwhpXAnWYOAzmifc+xpgSNjaU77rznookVrPcG8oFYQhpl+SLb+lcFYjY9w fXl5kvlpwWI2T2nomJMYRGR7bw0mKoU2IFRc8YrfmBgXxQnPwCrmOFLhYf0gygxlxxJ27PgV xKalVy7LxNMb6owoGU8mytn2OYAhEorNKeMmCpz79naDJxHs5+M06LONIA0grdGW8CoKZt+E zB+YVJD05zZytWAl9rQGi07FvqqamULy1aFJNJZLo9RecIIX9/SulNG6HDrYK9zqamHh2zpp bZTuFwU2hbJKajNPOcGNH9pAeuP7akQ4QK2S4jzYlaIcPVeSytx71ot0Vc/3cmvpltjLCuGL 2OOVtPV0BAwUJ25UzM9lzgzUsmjVqSfmqmObwqB5nlLMCvRT88Dkuesv5oTukk5Gse9t8ZPV OZQ/PZYUSjGfvPHTI82fEqH+5u0aWfJpeo3VYE6PA43QhTXCrxlq61xGf1EUg7NNxGC/OMrK ET6L5hkydWFQPLVS3q9LeEONl8IaSIwNSI0eYudgMLG1wEJBFGnARMQZoQE+kLxhaB6J2zX0 TDocs6U8bO5EcKcbsiM4L0eDJBJ+eV6goNUPh1+1LTnzhaocIzbCiFWPnSvKd1xZyfZ0Yb0n IcfbgOXzDCGJSf5zngNCzWYpjaTNSchp3wOaUdRRl5bHLkJ+OywVy3ki2AeXuir9hlevQCBr LWrlpNbcSamzGOkTXEMjnzpbyIWlsQW2w6C9iphgxLwVyqluOQYi1cd47pLkweKama3MVIaD w7uJh2K8ZCZt9w2wCotFiIOtShLPxHy68OQkjTpEjMEgTdRDHylQ3yLhy1IGLXxh10Z/6Ww5 YpMN2VPPEepusJYclVQK0qOYyeBNZ3uQ7KyDw07Poq9PVsFUliuuhLpnVvNxbIkBYIgsb0/U 0fQvWTxniTtvgkk3LyTJR/YSdIn+WEN7XK6gEUHMee1gwZM0lF24jvpYAsyb1sPsiWq6AFHy MxuiizoBKyluWR9lOHpk/homIuu3rwRHF584SxFhjDlSBmTYgtyFlSdtcM2Cs5qScgEbUThN +QpbVNZHwVVmmkQOs02Q9hhRrrhXYgYtBb3WjO95JI43VQpWaylciNaJ79eXqRb4yQnyqpn8 xIrYJAqnQjmumQ8xhiFrl3M5nS4iFlEjQIqyjRKiHNElocISucOckXU7d8zmyyn7wEy4Gnw9 UiIKmL1QBzmcMuwsvZaYFtoFYqpDVJ3VaDroK4Y0zDkOICDKSWK75wTiAXMlMesu8YIuM9Oa w6yIRyweSojzlMMvhykOjHPF4jgYgF/5sTPCbhGY6HitITv5qA6NNLDBcKFVZE1xZw7ACE0N 7HSqgSoP/UAVrswCrOUIdj/oFCvsJzQwkLwxwShgjhUaRj1LluyC8fy70mCB5+Ds5wjsK3qY zLGxJgBzWpzCKZVTXAynCuTe6h/DouanPkjOwzxivGjdRou2yawA9krIEJsftHi2BGqYB0yl ptWknUe5SOe9Hm3IgA4lSWF5pxJkq/Ovce4Oe36lbL6Uc2YgzGwYSzT7LbsRgIQpF0YVu4Vk TUhL77kIdayP6uNWvdUQR/hBkPewmC9RBgeRfhIzj3OaXbOSzLFfUG1tSexohBrrEefhQFJ8 DWOEKVu17Tz7g+WcbQnAAQRz6+PyNt6EB9vtQFeh1+N1uFuY8MNoEJqzbHDdoLn4u+MjRPyQ FBQNOWMI2Os8nApmmnqjVissCHJDZJR4PhQvAg0BCpc9hw1BSIViKx0h/lnEbDpqNOuJ0CR4 htl5ixWwBFHsXi4HgpYqXqiv37lciXLN57cEd0IIwt53G3TYVVOIhvkrmL4SOETI8ws50r4c 0uqlN1nftjJqrMA8HhrDm5lLHyvMBcZi4xVSGHZOLiY9YMKnEF6lfZbI5jZ2WOIYLy1ZRaPV KT9nrES6/OlgsNQqUSMJkrd4wiYv9SFbIBK1YsM0JViK8LkuuQZXfpgiY+0SR1LJtqeJtADr ii236gJjmka4iOAzqXyiolmZ8I5TTnm4TdUkqfZ+KWmu0eSO4qj0GUJDz6QOAqYArS9Jx7T5 8oSk4BhSt0JnVwpy2LhpaMZdSyhI/7Bx2wj+FXw9aK/xirItVjhtdAMSz9EoLYkPVipcqMCF twZN/NtkBFRhx5MgmmFTtpmQMiQpv3nTlOA7iccAvno3D5oclsFgePj2aDT5q8ISZPAf7Bfe ctt0ITiX944eccgK/WEZpy2ZQHMzeqXQds8XHDMTFOLthyQZHa3tRRnV+4rzbmIR4tt5HWKt Qqn65Fpdshx9kPvFrGa5BjHWUi5v5DnnhBeJ1dJKYpagW4eBMT6BiK0SaUlED8ckhreuXr2A xn716lsIHe23eR75pgmJ3LvvDfsG9gP++ra9ZuTHQ46YtB6a1Gp+bDiBh4fL992u8XKsDJU4 MaUQTUWN6uCHeBScuD1DXY1uOPQDCbzfduW3yr5h/qu8+IeWLEnrPLpo2+VsnXvwL9qBa6rX wrp2xNPSXt1H7tjMj0t9YHLybCmu4zgfq3FspljoqvQPgneMKQKUunrysBTeP8pF9f5RBbC6 dDVecc7gsTxucbbqH7OzPMcMy6uaQz6+9jZYo2SZGArlvJxVkJgYppzAuoLO93LyIVP8W0Px v+6vofBs6VLOZnOZZFAbyNkI91QZmGMfacnqx3mSb0HxwPakwJputQixmzKRJgoOB3dwQUj8 BW0WfW/RrhHzwLdzIucXOke62JdHCIVtsZk1lnHIr06Zs3IqAltDTi/T0gcs1RGVSKLC8sjZ w9skC1m3y7FJJ5812ZYyQGTntRFvHOcY6A4XAlEHLCWUDGi+2jiPYSDKSCr3PU/E0p5JgA9v keNxoiWwEJXEk5hTNSKOJec4duKsz3bv3lXHtEY5fPcsOLl3H3r01CRruVoKbijfm/K7M+/N zAU40wjWZi7kjUTDUM1zSK8mdirowwU/4Thkdc05HCFHMP/g1ipsPwSgMWIjERZGShlXvZC4 PqtjuFxUTxfPWRG7FgW0J3c6Uk46s+WhbXeo0Mpvv1mh1usZZBRNJHCIApsiB+ep7daTH5Ln g7UTyiKSsGn+JCCGNiCrvKZ5D2NV1mdIpxA91TRfCJICJ+CJUpAkNqoAlmVlXO1Asty17RFL z5/vfGKbZaUL0hu4mJGYyfl5ml3YhyJM6kQW3HW36yt1fzONMYO7ZWlLqEN30wW3ieKy1SAt UcjKB1IaFtu0b0qe+AZP6zFPis2CNBiYvSUvJGMMYUlDqs9K+Nu97s7OjhfNaiRuuyHF7CzW +zMTes8GL04codGlM5pg/FsotrDrMIZzWDOXZ0tOe1R7zzV3vHkEjXiuCnlfk9oNkRm6FDwr Zes+GRIjYj9neqWSQXDaRLHb0HWWqj59AmUq5XLN2p1CsZTsRFVKOGWLZ9cNvrdoQDeINQdu pknxhHfAPlCml2tIEHqF/ThBm7VYiWt+PZ+kKScRhqZO+1BVIu7NhglNpI1ddhmicFqLrQwI 4tGyE9FydvlpFA5oqx5M4mzC1UMCrlaZs4u9eHK2KqUMLp6O1C1ORy6fTG1oiF/oS9YVUbpo 2PYcXC+WkwnnoJmbxYmf8WUQB6XvWnOuWKFj38Z8Ka3hhHJmKRygjOPBiTz8tFePQhQunBqN zJgxkmtukx+i5OuGlsxzNQ9n5NL8C1FwFc1ouq+jKQwhdFLZFquWfowEVcjFKmtrhT+NFsbw mjOqONsi5Gi1m3EaR006NbvxNKDGduHrc0JrUzsZDQkcJ64YO5UkXRYC3GZH/4QKkHLtAzZT ZJysa8Or7LZoCtp+gBpMLjO4q1ySm4vCGYpy3swu5Wz0pRRFnJkGb5Z6IwJGOJ2JrKeT2ZpH Y06rcWc609YHtOwoLzEJb/tRGxTt9joUk6KrASDKwyRkR2/ml2KwhQBC3+CCTUVJOOQCS3az cBFTeYEtLgUzkDmJQlHyh/WbmB3RiEdccqvA11GoHSb3xajUX44zLgEwInxZaJ6lMbSYMq8H XNvp6H9QtbcPnw+fD58Pnw+fD58Pnw+fD58Pnw+fD58Pnw+fD5//jZ//B4xYgzwAQAEA --------------6CDEB2A441690ACFA4000AE5-- From scongdon@lucent.com Thu Apr 6 13:51:51 2000 From: scongdon@lucent.com (stu) Date: Thu, 06 Apr 2000 13:51:51 +0100 Subject: [XML-SIG] XML, python & CGI. References: <20000405160031.73AFA1CE2C@dinsdale.python.org> Message-ID: <38EC8867.F69D88E6@lucent.com> I am trying to write a cgi script in python that processes an XML doc against a XSL sheet to produce HTML. However I am having some problems. I have written most of the script and its fine, however to do the translation I use a command line (UNIX) command to invoke XT. From within an interactive session it works fine. I use: x = os.popen(process_cmd + " /path/XML/" + real_button1 + ".xml /home/scongdon/XML/" + real_button2 + ".xsl", 'w') which places the correct arguments on the command line, and I receive the correct HTML response. However I cannot figure out how to put this command into a cgi script so the output from my command line command, produces the final webpage. All I get is a server error. or no output at all Stu From larsga@garshol.priv.no Thu Apr 6 14:03:15 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 06 Apr 2000 15:03:15 +0200 Subject: [XML-SIG] XML, python & CGI. In-Reply-To: <38EC8867.F69D88E6@lucent.com> References: <20000405160031.73AFA1CE2C@dinsdale.python.org> <38EC8867.F69D88E6@lucent.com> Message-ID: * scongdon@lucent.com | | However I cannot figure out how to put this command into a cgi | script so the output from my command line command, produces the | final webpage. All I get is a server error. or no output at all The problem is almost certainly that your CGI script is running in a different environment with different environment variable settings (PATH and CLASSPATH). One way to work around that would be to have your Python script exec a shell script that first sets these to the correct values and then runs XT. --Lars M. From tpassin@idsonline.com Thu Apr 6 14:39:13 2000 From: tpassin@idsonline.com (THOMAS PASSIN) Date: Thu, 6 Apr 2000 09:39:13 -0400 Subject: [XML-SIG] XML, python & CGI. References: <20000405160031.73AFA1CE2C@dinsdale.python.org> <38EC8867.F69D88E6@lucent.com> Message-ID: <001301bf9fcd$87e35d40$8e2a08d1@idsonline.com> stu asked for help with cgi scripts: > I am trying to write a cgi script in python that processes an XML doc > against a XSL sheet to produce HTML. However I am having some problems. > > I have written most of the script and its fine, however to do the > translation I use a command line (UNIX) command to invoke XT. From > within an interactive session it works fine. I use: > > x = os.popen(process_cmd + " /path/XML/" + real_button1 + ".xml > /home/scongdon/XML/" + real_button2 + ".xsl", 'w') > > which places the correct arguments on the command line, and I receive > the correct HTML response. > > However I cannot figure out how to put this command into a cgi script so > the output from my command line command, produces the final webpage. All > I get is a server error. or no output at all > Is your difficulty mainly: 1) You don't know how to get your web server to launch Python against the script, or 2) You can run the Python script as a cgi page OK, but the server complains about the output contents, or 3) You can run Python but don't know how to get the form variables from a form in the calling html page to the script, or 4) something else? 1) is different for different web browsers, and I have only done it on WiIndows, so I can't help there. 2) probably indicates that you haven't provided a legal header for the returned data. There needs to be a header containing at least one item:value pair, then there MUST be at least one blank line, then comes your HTML. The header can be as simple as: print "content-type: text/plain\n" Normally, simply printing the output works fine since cgi expects to send/get data on stdin/stdout. For 3), use the standard python cgi library module. It is easy to use and there is enough info in the documentation to show how to use it. Basically, all you need is this: import cgi form=cgi.FieldStorage() T=form["trip"].value T now contains the value for the "trip" variable from the html form that called the script. BTW, I have run XT from a python script (under Windows) as you want to do and it worked fine. I used execv (I think it was that flavor of exec) instead of popen. Tom Passin From Mike.Olson@fourthought.com Thu Apr 6 16:04:54 2000 From: Mike.Olson@fourthought.com (Mike Olson) Date: Thu, 06 Apr 2000 09:04:54 -0600 Subject: [XML-SIG] XML, python & CGI. References: <20000405160031.73AFA1CE2C@dinsdale.python.org> <38EC8867.F69D88E6@lucent.com> Message-ID: <38ECA796.3672011A@Fourthought.com> --------------B544978B713C3CE0ACACEEBE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit stu wrote: Stu, We have done this many times, but using the python XSLT processor 4Xslt. Is there any reason you are using the Java processor? Mike > I am trying to write a cgi script in python that processes an XML doc > against a XSL sheet to produce HTML. However I am having some problems. > > I have written most of the script and its fine, however to do the > translation I use a command line (UNIX) command to invoke XT. From > within an interactive session it works fine. I use: > > x = os.popen(process_cmd + " /path/XML/" + real_button1 + ".xml > /home/scongdon/XML/" + real_button2 + ".xsl", 'w') > > which places the correct arguments on the command line, and I receive > the correct HTML response. > > However I cannot figure out how to put this command into a cgi script so > the output from my command line command, produces the final webpage. All > I get is a server error. or no output at all > > Stu > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig -- Mike Olson Senior Consultant Fourthought, Inc. http://www.fourthought.com http://www.opentechnology.com 720-304-0152 --------------B544978B713C3CE0ACACEEBE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit stu wrote:

Stu,

    We have done this many times, but using the python XSLT processor 4Xslt.  Is there any reason you are using the Java processor?

Mike

I am trying to write a cgi script in python that processes an XML doc
against a XSL sheet to produce HTML. However I am having some problems.

I have written most of the script and its fine, however to do the
translation I use a command line (UNIX) command to invoke XT. From
within an interactive session it works fine. I use:

x = os.popen(process_cmd + " /path/XML/" + real_button1 + ".xml
/home/scongdon/XML/" + real_button2 + ".xsl", 'w')

which places the correct arguments on the command line, and I receive
the correct HTML response.

However I cannot figure out how to put this command into a cgi script so
the output from my command line command, produces the final webpage. All
I get is a server error. or no output at all

Stu

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

-- 
Mike Olson
Senior Consultant Fourthought, Inc.
http://www.fourthought.com http://www.opentechnology.com
720-304-0152
  --------------B544978B713C3CE0ACACEEBE-- From uogbuji@fourthought.com Thu Apr 6 17:10:16 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 06 Apr 2000 10:10:16 -0600 Subject: [XML-SIG] The Zen of DOM In-Reply-To: Message from Robin Becker of "Thu, 06 Apr 2000 08:01:16 BST." Message-ID: <200004061610.KAA04403@localhost.localdomain> > Completely off topic, why is the term 'event' used to denote > 'recognition' in this XML parser world? It doesn't seem to ring the > right bells to my jaded ear. I guess what I used to call 'semantic > actions' are now known as 'event handlers'. It depends on your point of view. The reason "events" are used in the context of SAX semantics is because SAX uses asynchronous events (in the classical sense) to signal semantic units. To SAX's view, the parser is highly-decoupled from the handler, and so it looks as if it is just firing an event and going on about its business. Now you as the programmer, the omniscient observer, sees that most practical SAX applications do actually have a high degree of coupling between the parser and event-handler, and so to you it's nothing more than a simple procedure call. But remember that SAX is modeled such that this needn't be the case. -- Uche Ogbuji uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From uogbuji@fourthought.com Thu Apr 6 17:13:48 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 06 Apr 2000 10:13:48 -0600 Subject: [XML-SIG] XML, python & CGI. In-Reply-To: Message from Mike Olson of "Thu, 06 Apr 2000 09:04:54 MDT." <38ECA796.3672011A@Fourthought.com> Message-ID: <200004061613.KAA04429@localhost.localdomain> > Stu, > > We have done this many times, but using the python XSLT processor > 4Xslt. Is there any reason you are using the Java processor? Well, to be fair, right now XT is several times faster. But to be fair to us, we're closing the gap pretty rapidly. 4XSLT 0.9.3 is almost ten times faster than 4XSLT 0.9.2. Now that we are close to 90% XSLT compliance, we can start focusing on optimization. -- Uche Ogbuji uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From Mike.Olson@fourthought.com Thu Apr 6 17:22:15 2000 From: Mike.Olson@fourthought.com (Mike Olson) Date: Thu, 06 Apr 2000 10:22:15 -0600 Subject: [XML-SIG] XML, python & CGI. References: <200004061613.KAA04429@localhost.localdomain> Message-ID: <38ECB9B7.F064F2A1@Fourthought.com> --------------AD0ACBC72646C14749884F67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Uche Ogbuji wrote: > > Stu, > > > > We have done this many times, but using the python XSLT processor > > 4Xslt. Is there any reason you are using the Java processor? > > Well, to be fair, right now XT is several times faster. But to be fair to us, > we're closing the gap pretty rapidly. 4XSLT 0.9.3 is almost ten times faster > than 4XSLT 0.9.2. Now that we are close to 90% XSLT compliance, we can start > focusing on optimization. > How does this compare to the cost of starting up a JVM for every transform? If the XSLT is fairly simple, I would say that overall time to do the transform would be pretty even. Mike > > -- > Uche Ogbuji > uche.ogbuji@fourthought.com (303)583-9900 x 101 > Fourthought, Inc. http://Fourthought.com > 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 > Software-engineering, knowledge-management, XML, CORBA, Linux, Python -- Mike Olson Senior Consultant Fourthought, Inc. http://www.fourthought.com http://www.opentechnology.com 720-304-0152 --------------AD0ACBC72646C14749884F67 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Uche Ogbuji wrote:
> Stu,
>
>     We have done this many times, but using the python XSLT processor
> 4Xslt.  Is there any reason you are using the Java processor?

Well, to be fair, right now XT is several times faster.  But to be fair to us,
we're closing the gap pretty rapidly.  4XSLT 0.9.3 is almost ten times faster
than 4XSLT 0.9.2.  Now that we are close to 90% XSLT compliance, we can start
focusing on optimization.
 

How does this compare to the cost of starting up a JVM for every transform?  If the XSLT is fairly simple, I would say that overall time to do the transform would be pretty even.

Mike

 
--
Uche Ogbuji
uche.ogbuji@fourthought.com               (303)583-9900 x 101
Fourthought, Inc.                        http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-9036
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
-- 
Mike Olson
Senior Consultant Fourthought, Inc.
http://www.fourthought.com http://www.opentechnology.com
720-304-0152
  --------------AD0ACBC72646C14749884F67-- From robin@jessikat.demon.co.uk Thu Apr 6 18:11:08 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Thu, 6 Apr 2000 18:11:08 +0100 Subject: [XML-SIG] The Zen of DOM In-Reply-To: <200004061610.KAA04403@localhost.localdomain> References: <200004061610.KAA04403@localhost.localdomain> Message-ID: In article <200004061610.KAA04403@localhost.localdomain>, Uche Ogbuji writes >> Completely off topic, why is the term 'event' used to denote >> 'recognition' in this XML parser world? It doesn't seem to ring the >> right bells to my jaded ear. I guess what I used to call 'semantic >> actions' are now known as 'event handlers'. > >It depends on your point of view. The reason "events" are used in the context >of SAX semantics is because SAX uses asynchronous events (in the classical >sense) to signal semantic units. To SAX's view, the parser is >highly-decoupled from the handler, and so it looks as if it is just firing an >event and going on about its business. Now you as the programmer, the >omniscient observer, sees that most practical SAX applications do actually >have a high degree of coupling between the parser and event-handler, and so to >you it's nothing more than a simple procedure call. But remember that SAX is >modeled such that this needn't be the case. > > I assume that the events are ordered even though they may be asynchronous; how are errors reported in this model ie as soon as possible or are the error events also randomly delayed? -- Robin Becker From fdrake@acm.org Thu Apr 6 18:27:22 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 6 Apr 2000 13:27:22 -0400 (EDT) Subject: [XML-SIG] The Zen of DOM In-Reply-To: References: <200004061610.KAA04403@localhost.localdomain> Message-ID: <14572.51450.776809.616110@seahag.cnri.reston.va.us> Robin Becker writes: > I assume that the events are ordered even though they may be > asynchronous; how are errors reported in this model ie as soon as > possible or are the error events also randomly delayed? Robin, The events are ordered, including errors. The (potential) asynchrony comes in that the engine doesn't need to know or care that that handling of the event is complete before proceeding. For all it cares, each event could be run in a separate thread, allowing event handling to overlap. This is all an issue for the handler. (Normally, there's just one thread involved in parsing & handling, so there's nothing to worry about.) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From robin@jessikat.demon.co.uk Thu Apr 6 19:13:23 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Thu, 6 Apr 2000 19:13:23 +0100 Subject: [XML-SIG] The Zen of DOM In-Reply-To: <14572.51450.776809.616110@seahag.cnri.reston.va.us> References: <200004061610.KAA04403@localhost.localdomain> <14572.51450.776809.616110@seahag.cnri.reston.va.us> Message-ID: In article <14572.51450.776809.616110@seahag.cnri.reston.va.us>, Fred L. Drake, Jr. writes > >Robin Becker writes: > > I assume that the events are ordered even though they may be > > asynchronous; how are errors reported in this model ie as soon as > > possible or are the error events also randomly delayed? > >Robin, > The events are ordered, including errors. The (potential) >asynchrony comes in that the engine doesn't need to know or care that >that handling of the event is complete before proceeding. For all it >cares, each event could be run in a separate thread, allowing event >handling to overlap. This is all an issue for the handler. >(Normally, there's just one thread involved in parsing & handling, so >there's nothing to worry about.) > > > -Fred > ... Yes I guessed so, I expect these modern parsers are aimed at streamed languages. These are just my old semantic actions with more difficult error context handling. -- Robin Becker From Craig.Curtin@wdr.com Thu Apr 6 21:57:43 2000 From: Craig.Curtin@wdr.com (Craig.Curtin@wdr.com) Date: Thu, 6 Apr 2000 15:57:43 -0500 Subject: [XML-SIG] processing "special characters" efficiently Message-ID: --openmail-part-149a7002-00000002 Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF" Content-Disposition: inline; filename="BDY.RTF" Content-Transfer-Encoding: quoted-printable hi, i'm looking for an efficient mechanism for filtering out XML special characters.... the following code executes in slo-mo, can anyone =20 identify a more efficient way? this is obviously not optimal. any help is appreciated. thanks, craig text2XMLSpecialCharacters=3D{ '&': '&', =20 '<': '<', =20 '>': '>', =20 } for k in text2XMLspecialChars.keys(): data =3D string.replace(data, k, text2XMLspecialChars[k]) This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. --openmail-part-149a7002-00000002 Content-Type: multipart/mixed; boundary="retimiled-emim-detsen-mijooneldraneldeen" --retimiled-emim-detsen-mijooneldraneldeen Content-Type: application/rtf; name="BDY.RTF" Content-Disposition: attachment; filename="BDY.RTF" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZGVmZjBcZGVmbGFuZzEwMzN7XGZvbnR0Ymx7XGYw XGZzd2lzc1xmY2hhcnNldDAgQXJpYWw7fX0NClx2aWV3a2luZDRcdWMxXHBhcmRcZjBcZnMy MCBoaSxccGFyDQppJ20gbG9va2luZyBmb3IgYW4gZWZmaWNpZW50IG1lY2hhbmlzbSBmb3Ig ZmlsdGVyaW5nIG91dFxwYXINClhNTCBzcGVjaWFsIGNoYXJhY3RlcnMuLi4uXHBhcg0KXHBh cg0KdGhlIGZvbGxvd2luZyBjb2RlIGV4ZWN1dGVzIGluIHNsby1tbywgY2FuIGFueW9uZSBc cGFyDQppZGVudGlmeSBhIG1vcmUgZWZmaWNpZW50IHdheT8gdGhpcyBpcyBvYnZpb3VzbHkg bm90XHBhcg0Kb3B0aW1hbC4gYW55IGhlbHAgaXMgYXBwcmVjaWF0ZWQuXHBhcg0KXHBhcg0K dGhhbmtzLFxwYXINClxwYXINCmNyYWlnXHBhcg0KXHBhcg0KdGV4dDJYTUxTcGVjaWFsQ2hh cmFjdGVycz1ce1x0YWIgJyYnOiAnJmFtcDsnLCBccGFyDQpcdGFiXHRhYlx0YWJcdGFiICc8 JzogJyZsdDsnLCBccGFyDQpcdGFiXHRhYlx0YWJcdGFiICc+JzogJyZndDsnLCBccGFyDQpc dGFiXHRhYlx0YWJcfVxwYXINClxwYXINCmZvciBrIGluIHRleHQyWE1Mc3BlY2lhbENoYXJz LmtleXMoKTpccGFyDQpcdGFiIGRhdGEgPSBzdHJpbmcucmVwbGFjZShkYXRhLCBrLCB0ZXh0 MlhNTHNwZWNpYWxDaGFyc1trXSlccGFyDQp9DQoA --retimiled-emim-detsen-mijooneldraneldeen Content-Type: text/plain; charset=us-ascii; name="disclaim.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Description: Legal Disclaimer This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. --retimiled-emim-detsen-mijooneldraneldeen-- --openmail-part-149a7002-00000002-- From btusdin@mulberrytech.com Fri Apr 7 00:51:47 2000 From: btusdin@mulberrytech.com (B. Tommie Usdin) Date: Thu, 6 Apr 2000 19:51:47 -0400 Subject: [XML-SIG] Extreme Markup Languages - Call for Participation Message-ID: --------------------------------------------------------- ************* Call for Participation ************** *********** Extreme Markup Languages 2000 ************ --------------------------------------------------------- Extreme is a new, highly technical conference concentrating on the evolving abstractions that underlie modern information management solutions, how those abstractions enhance human productivity, and how they are being applied. Abstract and concrete information models, systems built on them, software to exploit them, SGML, XML, XSL, XLink, schemas, topic maps, query languages, and other markup related topics are in scope for this conference. Extreme will be a 3.6-day technical conference preceded by two days of tutorials. WHEN: August 13-18, 2000 WHERE: Montreal, Canada SPONSOR: Graphic Communications Association (GCA) Chairs: Steven R. Newcomb, TechnoTeacher, Inc. B. Tommie Usdin, Mulberry Technologies, Inc. Co-Chairs: Deborah A. Lapeyre, Mulberry Technologies, Inc. C. M. Sperberg-McQueen, World Wide Web Consortium/MIT Laboratory for Computer Sciences WHAT: Call for Papers and Peer Reviewers HOW: Guidelines for Submission and the DTDs are available from the conference secretariat at: Extreme@mulberrytech.com or www.mulberrytech.com/Extreme SCHEDULE: Peer Review Applications Due...31 MARCH, 2000 Paper Submission Deadline......19 APRIL, 2000 Speakers Notified............. 28 MAY, 2000 Revised Papers Due... .........30 JUNE, 2000 QUESTIONS: Email to Extreme@mulberrytech.com or call Tommie Usdin +1 301/315-9631 PAPERS: Must be all new material, address some aspect of information management from a theoretical or practical standpoint, and be detailed and rigorous. Will be published in both the print and electronic conference proceedings, and off-prints will be available to authors. One speaker per talk will be given a complimentary conference registration if the full paper is received on schedule. INFORMATION: For updated information on the program and plans for the conference, see http://www.gca.org For participation details, see http://www.mulberrytech.com/Extreme Extreme Markup Languages is the successor conference to all of the following GCA conferences: * Markup Technologies * XML Developers Conference * Metastructures * International Markup * HyTime * SGML'XX Principals of those conferences have now joined forces to offer a single unabashedly hard-core conference as a gathering place for the technically-oriented members of the information interchange community; a place for these people to meet and refresh each other with ideas advice, and camaraderie. The conference is agnostic with respect to commercial and political persuasion. It is passionate about providing a forum where technical ideas can be communicated and explained ====================================================================== Extreme Markup Languages 2000 mailto:extreme@mulberrytech.com August 13-18, 2000 details soon: http:www.gca.org Montreal, Canada author info: http://www.mulberrytech.com/Extreme ====================================================================== From tpassin@idsonline.com Fri Apr 7 02:47:54 2000 From: tpassin@idsonline.com (THOMAS PASSIN) Date: Thu, 6 Apr 2000 21:47:54 -0400 Subject: [XML-SIG] processing "special characters" efficiently References: Message-ID: <003001bfa033$4d6c9080$3b2a08d1@idsonline.com> You might be able to wait and do a replace on an entire string after you have accumulated it, rather than character-by-character like your example. Regular expresssions would work well for this. But if you really want to go char-by-char, try this and see if it's not faster: import string MAGIC_CHARS="<&>'"+'"' ESCAPES=["<","&",">","'","""] def test(char): if char in MAGIC_CHARS: return ESCAPES[string.find(MAGIC_CHARS,char)] if __name__=="__main__": c="&" print test(c) Tom Passin ============================================================================ ========================= asked - i'm looking for an efficient mechanism for filtering out XML special characters.... the following code executes in slo-mo, can anyone identify a more efficient way? this is obviously not optimal. any help is appreciated. thanks, craig text2XMLSpecialCharacters={ '&': '&', '<': '<', '>': '>', } for k in text2XMLspecialChars.keys(): data = string.replace(data, k, text2XMLspecialChars[k]) From dgoodger@atsautomation.com Fri Apr 7 21:08:39 2000 From: dgoodger@atsautomation.com (Goodger, David) Date: Fri, 7 Apr 2000 16:08:39 -0400 Subject: [XML-SIG] processing "special characters" efficiently Message-ID: > From: Craig.Curtin@wdr.com > Date: Thu, 6 Apr 2000 15:57:43 -0500 > > i'm looking for an efficient mechanism for filtering out > XML special characters.... > > the following code executes in slo-mo, can anyone =20 > identify a more efficient way? this is obviously not > optimal. any help is appreciated. > > thanks, > > craig > > text2XMLSpecialCharacters=3D{ '&': '&', =20 > '<': '<', =20 > '>': '>', =20 > } > > for k in text2XMLspecialChars.keys(): > data =3D string.replace(data, k, text2XMLspecialChars[k]) This code has a dangerous logic bug. You cannot depend on the order of dictionary keys; if '&' happened to come up last, then the input data = " & " would produce the following output: &lt;you&gt; & &lt;me&gt; Which is probably not what you want. (I won't mention the variable name problems.) David Goodger Systems Administrator, Advanced Systems Automation Tooling Systems Inc., Automation Systems Division direct: (519) 653-4483 ext. 2126 fax: (519) 653-8948 e-mail: dgoodger@atsautomation.com This message contains NO confidential information and is intended for anybody who is interested. Even if you are not the named addressee you may disseminate, distribute or copy this e-mail. Do whatever you like with it on your system, I don't care. From scongdon@lucent.com Mon Apr 10 09:25:30 2000 From: scongdon@lucent.com (stu) Date: Mon, 10 Apr 2000 09:25:30 +0100 Subject: [XML-SIG] XML, python & CGI. References: <20000406160013.B00B41CE91@dinsdale.python.org> Message-ID: <38F18FFA.1196C085@lucent.com> > Is your difficulty mainly: > 1) You don't know how to get your web server to launch Python against the > script, or > 2) You can run the Python script as a cgi page OK, but the server complains > about the output contents, or > 3) You can run Python but don't know how to get the form variables from a > form in the calling html page to the script, or > 4) something else? Thankk you for the info, my problem is that I can get the cgi script to work with a default "the script has worked" output line however when I place the following line into the script and try to evaluate it: x = os.popen(process_cmd + " /path/XML/" + real_button1 + ".xml /home/scongdon/XML/" + real_button2 + ".xsl", 'w') then I get the server error. I will work through your suggestions and let you know what happens Stu From ludvig.svenonius@excosoft.se Mon Apr 10 09:56:22 2000 From: ludvig.svenonius@excosoft.se (Ludvig Svenonius) Date: Mon, 10 Apr 2000 10:56:22 +0200 Subject: [XML-SIG] The Zen of DOM In-Reply-To: Message-ID: I've written a couple of applications that do what you describe and for me it is the only alternative when it comes to reading in XML data. The 4DOM parser has limited support for this sort of thing, I've found. If you use the 4DOM Sax parser (actually a DOM parser, found in Ft/Dom/Ext/Reader), you can easily specify that you want to use a custom Document instance. Because the Document is also a node factory for the resulting DOM, you can subclass the default Document class and parse the XML file using your own custom document, with overridden methods for things like creating elements. Typically, an overridden element factory method (createElement or createElementNS) checks the namespace URI and tag name and if a match is found, returns some custom object like you describe, otherwise it simply calls the same method of its superclass, Document. The custom object returned by the element factory method should probably inherit from the Element class, but you could of course override its functionality arbitrarily. Unfortunately, this is not so easy to accomplish using 4DOM, I've found, because the Sax parser previously mentioned doesn't seem to include namespace support. There is an alternative parser called Sax2 that includes NS support, but for some reason I've been unable to figure out, the ability to specify a custom Document instance in the Sax2 parser has been removed. I had to hack my way around this problem, resulting in a somewhat unstable solution (it seems like the semantics of the Sax2 parser are a bit different under Unix and Win32). I had to access a 'private' member variable inside the Sax2 parser instance in order to forcibly replace the default Document instance before parsing. Perhaps someone working on 4DOM can provide some insight into a better way, or at least an explanation to why the custom element factory feature has been removed in Sax2. I have example code, although I cannot access it from where I am right now. Get back to me privately if you want me to send it. -- Ludvig Svenonius Excosoft AB lss@excosoft.se / dominio@hem.passagen.se -----Original Message----- From: xml-sig-admin@python.org [mailto:xml-sig-admin@python.org]On Behalf Of Andy Robinson Sent: Wednesday, April 05, 2000 4:28 PM To: Xml-Sig@Python. Org Subject: [XML-SIG] The Zen of DOM Looking for spirtual guidance about the right way to do things... I've been slogging my way through the current XML package looking at many different ways of parsing XML documents into my own Python object models. The target is currently "pythonPoint Markup Language", a markup for creating PDF presentation slides in ReportLab; but I'll need to do many similar parsers in future. At the moment, I have a Python class hierarchy with things like Presentation, Slide, Frame, Paragraph, and various primitive shapes to decorate pages. I use a parser derived from xmllib which walks through a document, and I wrote start_slide/end_slide, start_para/end_para handlers which construct instances of my own objects and build a tree. It seems to me that one could use Python's extreme flexibility to take a generic approach to tree-building, and see if there was a class available corresponding to a particular tag before creating some generic node; if so, create it, pass it the available attributes, then pass child nodes to an add() method so it could organize them itself. Then I could magically end up with a notation like... presentation.slides[3].frames[1].paragraphs[0].text ...without having to write lots of new stuff in the parser as well as the application class hierarchy every time. Or at least to navigate the tree using generic node/child notation, but get my own class instances attached at each point. To turn this on its head, there must be a generic way to turn a Python class instance into XML, and unserialize it again later. Has anyone actually worked on this? Is there a solution lurking in the package somewhere? Or is the preferred approach to get a DOM tree, then walk through it building my own objects? Thanks very much, Andy Robinson _______________________________________________ XML-SIG maillist - XML-SIG@python.org http://www.python.org/mailman/listinfo/xml-sig From andy@reportlab.com Mon Apr 10 12:34:52 2000 From: andy@reportlab.com (Andy Robinson) Date: Mon, 10 Apr 2000 12:34:52 +0100 Subject: [XML-SIG] Re: The Zen of DOM Message-ID: Due to a network screwup, I only got onto the list this morning. Many thanks to everyone who replied in the meantime - this has given me plenty of useful ideas! - Andy Robinson From scongdon@lucent.com Mon Apr 10 15:45:37 2000 From: scongdon@lucent.com (stu) Date: Mon, 10 Apr 2000 15:45:37 +0100 Subject: [XML-SIG] Re: XML, python & CGI. References: <20000408160013.CC2941CDA5@dinsdale.python.org> Message-ID: <38F1E911.1967123B@lucent.com> The answer to my problem was: There needs to be a header containing at least one item:value pair, then there MUST be at least one blank line, then comes your HTML. The header can be as simple as: print "content-type: text/plain\n\n" SImple but important. Thanks everyone for your help. Stu From paul@prescod.net Tue Apr 11 07:38:52 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 11 Apr 2000 01:38:52 -0500 Subject: [XML-SIG] Python 1.6 and XML References: <200003311623.LAA25456@amarok.cnri.reston.va.us> Message-ID: <38F2C87C.A0E10472@prescod.net> Did I miss a discussion of how much of saxlib we want to put into Python 1.6 alpha 2, and under what packaging structure? I think we all agree that "import pyexpat" is only marginally better than "import xmllib" in terms of portability and longevity. I don't think we have the option of waiting for SAX 2 so we either need to use SAX 1 or a SAX 2 pre-release. We're no worse off here than the Java people, or the Apache people, etc. Version control is a bitch... We should be able to support SAX on PyExpat with no runtime cost because SAX "handlers" map basically one-to-one to Expat handlers, I think. If there are any that are slightly different then we can work out the mapping in the pyexpat DLL instead of in Python code. Although I would love to see something like EasySAX or "eventdom" in Python core, right now it depends on PyXPath which depends on PyBison and the whole thing is too large and too slow. We'll have to put that off for Python 1.7. If someone had the bandwidth then it *would* be nice for the PyExpat module to have a mode where it generates DOM-ish Python objects. It's not a lot of code or difficulty, it just needs a C programmer to step up to the plate. If you choose to do so, let's discuss it here first because I've thought about what properties are most vital for my (Python-implemented) "minidom". Opinions? Have I missed some discussion on this during my heads-down phase? -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "I and my companions suffer from a disease of the heart that can only be cured with gold", Hernan Cortes From larsga@garshol.priv.no Tue Apr 11 09:21:49 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 11 Apr 2000 10:21:49 +0200 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <38F2C87C.A0E10472@prescod.net> References: <200003311623.LAA25456@amarok.cnri.reston.va.us> <38F2C87C.A0E10472@prescod.net> Message-ID: * Paul Prescod | | Did I miss a discussion of how much of saxlib we want to put | into Python 1.6 alpha 2, and under what packaging structure? Uh, if you did, then so did I. | I think we all agree that "import pyexpat" is only marginally better | than "import xmllib" in terms of portability and longevity. Yes. | I don't think we have the option of waiting for SAX 2 so we either | need to use SAX 1 or a SAX 2 pre-release. Then I think we should go for a pre-release. I have had one with a couple of demo drivers sitting at home waiting to be released for a while, but have so far been putting it off. I can release this stuff tonight, so that people can look at it. We still have a couple of unresolved issues left, but we should be able to clear those up quickly. | We should be able to support SAX on PyExpat with no runtime cost | because SAX "handlers" map basically one-to-one to Expat handlers, I | think. If there are any that are slightly different then we can work | out the mapping in the pyexpat DLL instead of in Python code. There are some differences, such as the Attributes interface used to represent attributes, but this should be easy to work out from C code. --Lars M. From andy@reportlab.com Tue Apr 11 09:53:56 2000 From: andy@reportlab.com (Andy Robinson) Date: Tue, 11 Apr 2000 09:53:56 +0100 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: Message-ID: > > * Paul Prescod > | > | Did I miss a discussion of how much of saxlib we want to put > | into Python 1.6 alpha 2, and under what packaging structure? Nope, I just joined and asked some newbie questions about what was in 1.6. And you're answering them! Couple of quick thoughts from a newbie: - I'd rather the existing xmllib stayed in 1.6 rather than being updated, otherwise a bunch of people will have to update existing apps. We can then write two parsers for our apps, one for the 'standard library' xmllib and one for the new SAX standard, and be safe on everyone's machines. - a 'miniDOM' sounds very cool. Compliance with W3C API standards excites me a lot less than really convenient, Pythonic ways to turn XML docs into object trees at C-like speeds - especially if one has hooks to use one's own base classes. But that sounds like later than 1.7. - Andy Robinson From Juergen Hermann" On Tue, 11 Apr 2000 01:38:52 -0500, Paul Prescod wrote: >I think we all agree that "import pyexpat" is only marginally better >than "import xmllib" in terms of portability and longevity. Another question on that topic: How does all of this affect the integrat= ion of "foreign" parsers into the default XML library / interface of Python. I'= m constantly confused about xmllib vs. 4DOM vs. pyexpat etc., what's stand= ard, how are they related... The matter at hand for me is that I need to integrate Xerces into Python= sooner or later, preferably in a way that survives the 1.6 release. Or has some= one already done that? Ciao, J=FCrgen -- J=FCrgen Hermann (jhe@webde-ag.de) WEB.DE AG, Amalienbadstr.41, D-76227 Karlsruhe Tel.: 0721/94329-0, Fax: 0721/94329-22 From fdrake@acm.org Tue Apr 11 14:38:08 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 11 Apr 2000 09:38:08 -0400 (EDT) Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: References: Message-ID: <14579.10944.676719.595150@seahag.cnri.reston.va.us> Andy Robinson writes: > - I'd rather the existing xmllib stayed in 1.6 rather than being updated, > otherwise a bunch of people will have to update existing apps. We can then > write two parsers for our apps, one for the 'standard library' xmllib and > one for the new SAX standard, and be safe on everyone's machines. The XML-SIG session decided that xmllib would not be changed, but marked deprecated once the SAX support was added to the standard library. Andrew, were you working on getting this in? > - a 'miniDOM' sounds very cool. Compliance with W3C API standards excites > me a lot less than really convenient, Pythonic ways to turn XML docs into > object trees at C-like speeds - especially if one has hooks to use one's own > base classes. But that sounds like later than 1.7. I don't remember what we said about this; I'd like to see one in the core myself. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From akuchlin@mems-exchange.org Tue Apr 11 17:00:25 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Tue, 11 Apr 2000 12:00:25 -0400 (EDT) Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <14579.10944.676719.595150@seahag.cnri.reston.va.us> References: <14579.10944.676719.595150@seahag.cnri.reston.va.us> Message-ID: <14579.19481.821123.774166@amarok.cnri.reston.va.us> Fred L. Drake, Jr. writes: > The XML-SIG session decided that xmllib would not be changed, but >marked deprecated once the SAX support was added to the standard >library. > Andrew, were you working on getting this in? SAX support? Not yet, no, though we should start. One issue is SAX1 vs. SAX2. (I'd call for SAX2, myself; maybe the additional pressure from a widely distributed Python implementation will wake the SAX2 specification process from its stupor.) The most nasty issue is the unresolved package name question; if the Python code includes a package named 'xml', that package name can't be extended by add-on modules. So what do we do? Does the xml package in the standard library automatically import all the names and modules from some other package ('xml_ext'? 'xml2') in site-packages? Maybe this is a python-dev question... -- A.M. Kuchling http://starship.python.net/crew/amk/ This is good. It means that while Ionesco is dead, his spirit lives on. -- Gordon McMillan on how Windows attaches meaning to 3-character file extensions, 30 Jul 1999 From lzapotoc@haworthpressinc.com Wed Apr 12 20:17:31 2000 From: lzapotoc@haworthpressinc.com (lzapotoc@haworthpressinc.com) Date: Wed, 12 Apr 2000 15:17:31 -0400 Subject: [XML-SIG] Announcing: The Love Drug Message-ID: <20000412191050.242C51CE93@dinsdale.python.org> PRESS RELEASE: The Love Drug: Marching to the Beat of Ecstasy, by Richard Cohen Please note that this is a one-time e-mailing, and we do not have your e-mail address on file for future use. If you wish to receive e-mail announcements from us on a regular basis, visit our website at: http://www.haworthpressinc.com and click on "services" from the menu bar on the left-hand side of the page. WE DO NOT WISH TO COMMUNICATE WITH NON-INTERESTED PEOPLE. IF YOU REGARD NEW BOOK ANNOUNCEMENTS IN THE SCHOLARLY/ACADEMIC FIELD AS JUNK E-MAIL, PLEASE JUST DELETE THIS FILE IMMEDIATELY. We apologize in advance for sending this to un-interested people. ________________________________________________________________ PRESS RELEASE: The Love Drug: Marching to the Beat of Ecstasy, by Richard Cohen To order this book, please go to: http://www.haworthpressinc.com/OrderForm Please visit our website at: http://www.haworthpressinc.com Binghamton, NY (4/12/00) Use of MDMA, more commonly known on the streets as Ecstasy, has grown to epidemic proportions worldwide. As media reports have recently suggested, Ecstasy is an illegal drug associated with the all-night dance parties known as raves. Ecstasy has rapidly become the drug of choice for hundreds of thousands, perhaps even millions of young people worldwide. While users tout the drug promotes sensuality and love, hospital emergency room reports tell a tale of a much different sort with regard to Ecstasy, one involving psychological and organic complications, sometimes even death. So just what is this drug that we have been hearing so much about on the news lately? Well, it's not cocaine, although people claim it makes them feel invincible. It's not alcohol, but some do report that it decreases their inhibitions. It's called Ecstasy, better known in the laboratories as 3,4-methylenedioxymethamphetamine (MDMA), and it's the most popular drug on the party scene today. The Love Drug: Marching to the Beat of Ecstasy, by Richard S. Cohen, takes a sobering look at what has the nightlife in Tokyo, New York, and London raving while medical professionals and civic officials the world over try to raise a warning flag to a generation raving down the road of nonstop dancing, drug ingesting, and music. This book takes a stunning look at this wildly popular mood-altering substance and presents the reader with accurate information concerning the entire history as well as current use of what's called "the love drug", Ecstasy. This book discusses the medical and social implications of Ecstasy from an un-biased viewpoint. Instead of preaching the evils or singing the praises of Ecstasy, Cohen presents raw facts side-by-side with real-life experiences, allowing readers to draw their own conclusions and make informed choices about this drug. As a responsible professional, however, he does recommend that people exercise extreme caution when contemplating whether or not to experiment with the underground drug market, including Ecstasy. Richard S. Cohen, MA, MSW. Mr. Cohen has appeared on various television segments to discuss his book and the drug Ecstasy. His most recent appearances have been on 'Good Day New York' in New York City. He also appeared on 'Sunday Live with Wally Kennedy' on ABC in Philadelphia. Richard Cohen was also interviewed as part of a Fox television special that appeared nationally with regard to both raves and Ecstasy use. The Love Drug: Marching to the Beat of Ecstasy is available in stores now. Richard S. Cohen is available for interviews via telephone or nationwide by arrangement. For a review copy or other media information, please contact Margaret Tatich, Sales Manager, 1-800 HAWORTH Ext. 321, E-mail: mtatich@haworthpressinc.com To order this book, please go to: http://www.haworthpressinc.com/OrderForm Or call 1-800-HAWORTH. $49.95 hardcover. ISBN: 0-7890-0453-4. (Outside US/Canada/Mexico: $60.00) $19.95 softcover. ISBN: 0-7890-0454-2. (Outside US/Canada/Mexico: $24.00) 116 pp. with Index. Features tables, figures, a glossary, and a bibliography. Please visit our website at: http://www.haworthpressinc.com Note: If your Internet service does not support hyperlinks, simply copy the link above and paste it into your browser window. The Haworth Press, Inc. 10 Alice Street Binghamton, NY 13904-1580 607.722.5857 Web: http://www.haworthpressinc.com E-mail: lzapotoc@haworthpressinc.com From akuchlin@mems-exchange.org Wed Apr 12 21:11:46 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 12 Apr 2000 16:11:46 -0400 (EDT) Subject: [XML-SIG] SAX for 1.6 In-Reply-To: <14579.10944.676719.595150@seahag.cnri.reston.va.us> References: <14579.10944.676719.595150@seahag.cnri.reston.va.us> Message-ID: <14580.55426.551636.721368@amarok.cnri.reston.va.us> Fred L. Drake, Jr. writes: > The XML-SIG session decided that xmllib would not be changed, but >marked deprecated once the SAX support was added to the standard >library. OK; the best option seems to be creating a saxlib.py that contains the important classes. Adding a whole xml/ package is fraught with too many problems. Second question, SAX1 or SAX2? Lars, can you please post a pointer to your current SAX2 code? -- A.M. Kuchling http://starship.python.net/crew/amk/ "I... I did not intend to hurt you." "And what if you did not? Intent and outcome are so rarely coincident." -- Dream and Larissa, in SANDMAN #65: "The Kindly Ones:9" From uogbuji@fourthought.com Thu Apr 13 00:44:56 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 12 Apr 2000 17:44:56 -0600 Subject: [XML-SIG] The Zen of DOM In-Reply-To: Message from "Ludvig Svenonius" of "Mon, 10 Apr 2000 10:56:22 +0200." Message-ID: <200004122344.RAA04930@localhost.localdomain> The problem is that the W3C folks throws quite a curve ball with DOM level 2. The level 2 document has to be created with prior knowledge of the document-type and document-element. In Level 1, none of this was needed. Since we didn't imagine that most users would have prior knowledge of this, we decided that it was unlikely that they would be passing in a document to the Sax2 handler, so we took the doc parameter out of the initializer. Now there is no technical reason to omit it. If you are in a situation where you can construct a proper DOM Level 2 document and pass it to the Sax2 handler, there is no reason for us not to let you. I think I'll go ahead and reinstate the "doc" parameter to the Sax2 handler. Look for this in the next version, or I can send you a patch, if you're desparate. Another approach is that we could have the Sax2 handler accept a document factory object which is inkokes to create the document. This might be an unnecessarily heavyweight solution, though. -- Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python > I've written a couple of applications that do what you describe and for me > it is the only alternative when it comes to reading in XML data. The 4DOM > parser has limited support for this sort of thing, I've found. If you use > the 4DOM Sax parser (actually a DOM parser, found in Ft/Dom/Ext/Reader), you > can easily specify that you want to use a custom Document instance. Because > the Document is also a node factory for the resulting DOM, you can subclass > the default Document class and parse the XML file using your own custom > document, with overridden methods for things like creating elements. > Typically, an overridden element factory method (createElement or > createElementNS) checks the namespace URI and tag name and if a match is > found, returns some custom object like you describe, otherwise it simply > calls the same method of its superclass, Document. The custom object > returned by the element factory method should probably inherit from the > Element class, but you could of course override its functionality > arbitrarily. > > Unfortunately, this is not so easy to accomplish using 4DOM, I've found, > because the Sax parser previously mentioned doesn't seem to include > namespace support. There is an alternative parser called Sax2 that includes > NS support, but for some reason I've been unable to figure out, the ability > to specify a custom Document instance in the Sax2 parser has been removed. I > had to hack my way around this problem, resulting in a somewhat unstable > solution (it seems like the semantics of the Sax2 parser are a bit different > under Unix and Win32). I had to access a 'private' member variable inside > the Sax2 parser instance in order to forcibly replace the default Document > instance before parsing. Perhaps someone working on 4DOM can provide some > insight into a better way, or at least an explanation to why the custom > element factory feature has been removed in Sax2. > > I have example code, although I cannot access it from where I am right now. > Get back to me privately if you want me to send it. From uogbuji@fourthought.com Thu Apr 13 00:55:39 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 12 Apr 2000 17:55:39 -0600 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: Message from "Juergen Hermann" of "Tue, 11 Apr 2000 11:37:39 BST." <200004110937.LAA28144@statistik.cinetic.de> Message-ID: <200004122355.RAA04954@localhost.localdomain> > On Tue, 11 Apr 2000 01:38:52 -0500, Paul Prescod wrote: > >I think we all agree that "import pyexpat" is only marginally better > >than "import xmllib" in terms of portability and longevity. = > = > Another question on that topic: How does all of this affect the integra= tion of = > "foreign" parsers into the default XML library / interface of Python. I= 'm = > constantly confused about xmllib vs. 4DOM vs. pyexpat etc., what's stan= dard, how = > are they related... Which of these things is not like the others... Seriously, xmllib and pyexpat are parsers, 4DOM is a DOM library -- big = difference. 4DOM actually uses pyexpat and xmlproc (indirectly, through = pysax) for parsing. We've been too busy modifying 4DOM for PyXML and Zope distribution to do = much = work on the Python 1.6 effort (soory, Paul). BTW, to scatter responses at other posts in this thread, I agree that it = would = be great to have some miniDOM implementation in Python 1.6: I'm the first= to = say that 4DOM/PyDOM is too big. However, I have no qualms about nuking x= mllib = from 1.6. Also, 4DOM (and incidentally 4XPath and 4XSLT) have reached 90+% levels o= f = conformance and we've been working on performance. We have some changes = on = the way that should almost double 4DOM's speed and speed up 4XPath and 4X= SLT = by much larger factors. -- = Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com = 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From gstein@lyra.org Thu Apr 13 02:09:11 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 12 Apr 2000 18:09:11 -0700 (PDT) Subject: [XML-SIG] SAX for 1.6 In-Reply-To: <14580.55426.551636.721368@amarok.cnri.reston.va.us> Message-ID: On Wed, 12 Apr 2000, Andrew M. Kuchling wrote: > Fred L. Drake, Jr. writes: > > The XML-SIG session decided that xmllib would not be changed, but > >marked deprecated once the SAX support was added to the standard > >library. > > OK; the best option seems to be creating a saxlib.py that contains the > important classes. Adding a whole xml/ package is fraught with too > many problems. > > Second question, SAX1 or SAX2? Lars, can you please post a pointer to > your current SAX2 code? Is SAX2 going to be done in the next two months? If not, then we shouldn't pretend to support it. We also don't want to try, and then discover that something isn't quite right when SAX2 arrives. +1 on SAX1 -0 on SAX2 Cheers, -g -- Greg Stein, http://www.lyra.org/ From fdrake@acm.org Thu Apr 13 03:28:15 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 12 Apr 2000 22:28:15 -0400 (EDT) Subject: [XML-SIG] SAX for 1.6 In-Reply-To: References: <14580.55426.551636.721368@amarok.cnri.reston.va.us> Message-ID: <14581.12479.745456.28360@seahag.cnri.reston.va.us> Greg Stein writes: > Is SAX2 going to be done in the next two months? If not, then we shouldn't > pretend to support it. We also don't want to try, and then discover that > something isn't quite right when SAX2 arrives. > > +1 on SAX1 > -0 on SAX2 I actually agree on this one. I'd hate for the API to be too far off from the final SAX2. We can add a sax2lib later for the new API, if appropriate. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From larsga@garshol.priv.no Thu Apr 13 07:21:36 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 13 Apr 2000 08:21:36 +0200 Subject: [XML-SIG] SAX for 1.6 In-Reply-To: <14580.55426.551636.721368@amarok.cnri.reston.va.us> References: <14579.10944.676719.595150@seahag.cnri.reston.va.us> <14580.55426.551636.721368@amarok.cnri.reston.va.us> Message-ID: * Andrew M. Kuchling | | Second question, SAX1 or SAX2? I think SAX2 will be finished within the next 2 months, but I'll email David Megginson to hear what kind of schedule he is thinking of. | Lars, can you please post a pointer to your current SAX2 code? Will do that tonight. Sorry about the delay. --Lars M. From Juergen Hermann" On Wed, 12 Apr 2000 17:55:39 -0600, Uche Ogbuji wrote: >Seriously, xmllib and pyexpat are parsers, 4DOM is a DOM library -- big= >difference. 4DOM actually uses pyexpat and xmlproc (indirectly, throug= h >pysax) for parsing. OK, that clears up the "how are they related" part a lot. Now say I want= to make 4DOM use Xerces-C++ (with appropriate wrappers around it, of course), is= that possible? Ciao, J=FCrgen -- J=FCrgen Hermann (jhe@webde-ag.de) WEB.DE AG, Amalienbadstr.41, D-76227 Karlsruhe Tel.: 0721/94329-0, Fax: 0721/94329-22 From uche.ogbuji@fourthought.com Thu Apr 13 17:05:46 2000 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 13 Apr 2000 10:05:46 -0600 Subject: [XML-SIG] Python 1.6 and XML References: <200004130802.KAA16785@statistik.cinetic.de> Message-ID: <38F5F05A.701CADE9@fourthought.com> Juergen Hermann wrote: > >Seriously, xmllib and pyexpat are parsers, 4DOM is a DOM library -- big > >difference. 4DOM actually uses pyexpat and xmlproc (indirectly, through > >pysax) for parsing. > > OK, that clears up the "how are they related" part a lot. Now say I want to make > 4DOM use Xerces-C++ (with appropriate wrappers around it, of course), is that > possible? Yes. All you need to do is add a Xerces.py or so to Ft.Dom.Reader implementing the methods (FromXml, FromXmlFile, etc.) as in Sax.py and Sax2.py. The hard part, of course, would be wrapping Xerces for Python/SAX. But I'm sure even non-4DOM users would be grateful if you were able to do so and contribute it to the XML-SIG. -- Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From larsga@garshol.priv.no Thu Apr 13 17:16:38 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 13 Apr 2000 18:16:38 +0200 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <200004130802.KAA16786@statistik.cinetic.de> References: <200004130802.KAA16786@statistik.cinetic.de> Message-ID: * Juergen Hermann | | OK, that clears up the "how are they related" part a lot. Now say I | want to make 4DOM use Xerces-C++ (with appropriate wrappers around | it, of course), is that possible? One approach (in addition to the one suggested by Uche) would be to make a SAX2 driver for Xerces. Then it would suddenly be useable with PyDOM, 4DOM, EventDOM and anything else we might cook up, which would probably make a lot of people happy. At some point I would like to make a SAX2 driver for the C++ SAX2 mapping once that happens, and since Xerces would be extremely likely to get a C++ SAX2 driver, that would give us this anyway, but probably a bit into the future. --Lars M. From uogbuji@fourthought.com Thu Apr 13 18:43:54 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Thu, 13 Apr 2000 11:43:54 -0600 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: Message from Lars Marius Garshol of "13 Apr 2000 18:16:38 +0200." Message-ID: <200004131743.LAA01751@localhost.localdomain> > * Juergen Hermann > | > | OK, that clears up the "how are they related" part a lot. Now say I > | want to make 4DOM use Xerces-C++ (with appropriate wrappers around > | it, of course), is that possible? > > One approach (in addition to the one suggested by Uche) would be to > make a SAX2 driver for Xerces. Then it would suddenly be useable with > PyDOM, 4DOM, EventDOM and anything else we might cook up, which would > probably make a lot of people happy. Oh, absolutely. On re-reading I wasn't clear. I definitely think the way to go is to write a SAX or SAX2 driver, which can be dropped in throughout the Python/XML tools. This would trulky kick arse because then we'd have a beta Schema implementation for Python. > At some point I would like to make a SAX2 driver for the C++ SAX2 > mapping once that happens, and since Xerces would be extremely likely > to get a C++ SAX2 driver, that would give us this anyway, but probably > a bit into the future. Great idea. Let us know when you start working on it. If we're done with 4DOM->XML-SIG by then we'll probably be able to help. -- Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From larsga@garshol.priv.no Thu Apr 13 19:40:59 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 13 Apr 2000 20:40:59 +0200 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <200004131743.LAA01751@localhost.localdomain> References: <200004131743.LAA01751@localhost.localdomain> Message-ID: * Uche Ogbuji | | I definitely think the way to go is to write a SAX or SAX2 driver, | which can be dropped in throughout the Python/XML tools. This would | trulky kick arse because then we'd have a beta Schema implementation | for Python. Good point. I didn't think about that. * Lars Marius Garshol | | At some point I would like to make a SAX2 driver for the C++ SAX2 | mapping once that happens, and since Xerces would be extremely likely | to get a C++ SAX2 driver, that would give us this anyway, but probably | a bit into the future. * Uche Ogbuji | | Great idea. Let us know when you start working on it. If we're | done with 4DOM->XML-SIG by then we'll probably be able to help. I will do that. In fact, I'll add to the SAX 2 page[1] a list of drivers I would like to see, so that people who feel like it can pick one and start working on it. --Lars M. [1] See my next posting. :-) From larsga@garshol.priv.no Thu Apr 13 19:42:39 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 13 Apr 2000 20:42:39 +0200 Subject: [XML-SIG] SAX 2.0 alpha 1 Message-ID: I have now put a page listing open issues and remaining work on SAX 2.0 at Please download and have a look at the current state of it. A sample driver for xmlproc is included. I think it works with xmlproc 0.61, but can't verify that right now (extreme time pressure, sorry). --Lars M. From dgoodger@bigfoot.com Thu Apr 13 23:47:45 2000 From: dgoodger@bigfoot.com (David Goodger) Date: Thu, 13 Apr 2000 18:47:45 -0400 Subject: [XML-SIG] processing "special characters" efficiently Message-ID: > From: Craig.Curtin@wdr.com > Date: Thu, 6 Apr 2000 15:57:43 -0500 > > i'm looking for an efficient mechanism for filtering out > XML special characters.... I don't know if you follow comp.lang.python, but Fredrik Lundh just posted the solution to your problem. His book "(the eff-bot guide to) the standard python library" looks to be a treasure trove of such examples. Enjoy! -- David Goodger dgoodger@bigfoot.com Open-source projects: - The Go Tools Project: http://gotools.sourceforge.net (more to come!) ============================================================ Fredrik Lundh posted to comp.lang.python: ============================================================ Randall Hopper wrote: > Is there a Python feature or standard library API that will get me less > Python code spinning inside this loop? re.multisub or equivalent? :-) haven't benchmarked it, but I suspect that this approach is more efficient: ... # based on re-example-5.py import re import string symbol_map = { "foo": "FOO", "bar": "BAR" } def symbol_replace(match, get=symbol_map.get): return get(match.group(1), "") symbol_pattern = re.compile( "(" + string.join(map(re.escape, symbol_map.keys()), "|") + ")" ) print symbol_pattern.sub(symbol_replace, "foobarfiebarfoo") ... ============================================================ Randall Hopper wrote: > Thanks! It's much more efficient. The 140 seconds original running time > was reduced to 11.6 seconds. I can certainly live with that. thought so ;-) while you're at it, try replacing the original readline loop with: while 1: lines = fp.readlines(BUFFERSIZE) if not lines: break lines = string.join(lines, "") lines = re.sub(...) out_fp.write(lines) where BUFFERSIZE is 1000000 or so... From brugman@wt.tno.nl Fri Apr 14 16:11:24 2000 From: brugman@wt.tno.nl (Frank Brugman) Date: Fri, 14 Apr 2000 17:11:24 +0200 Subject: [XML-SIG] python installatie op Windows Message-ID: Dear Reader, I tried to install the xml extention for Python under Windows NT from the file PyXML-0.5.3.tar. ( I have installed python 1.5.2 under progam files and created a path to it. ) I extracted the files and tried to invoke the command: 'python setup.py build' >>>>>>>>>>> Logging from screen >>>>>>>>>>>>>>>>>>>>> D:\Users\Brugman\xml\PyXML-0.5.3>python setup.py build Traceback (innermost last): File "setup.py", line 19, in ? from distutils.command.build import Build ImportError: cannot import name Build D:\Users\Brugman\xml\PyXML-0.5.3>ls ANNOUNCE README Wise mac xml CREDITS README.pyexpat demo setup.py LICENCE README.sgmlop doc test MANIFEST TODO extensions windows <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< So it failed, and I don't have a clue what I did wrong. As I am unfamiliar with python I also can't see which command line will python let parse a XML file. ( or setup a TCL/TK interface for editing such a XML file ) I hope I didn't ask too stupid questions, With kind regards, Frank Brugman ---------------------------------------------------------------- Frank Brugman TNO Automotive Phone: +31 15 2 69 70 35 P.O. Box 6033, 2600 JA, DELFT Fax: +31 15 2 62 43 21 The Netherlands URL: http://www.madymo.com E-Mail: brugman@wt.tno.nl(laparesse@wish.net) ---------------------------------------------------------------- From cknight@ptolemy.arc.nasa.gov Fri Apr 14 17:38:19 2000 From: cknight@ptolemy.arc.nasa.gov (Chris Knight) Date: Fri, 14 Apr 2000 09:38:19 -0700 Subject: [XML-SIG] python installatie op Windows In-Reply-To: Message-ID: I'll second that note, documentation on proper installation on Win32 platforms (esp. without a compiler, since it *looks* like all of the necessary dlls are there) would be highly useful (or is the setup.py supposed to work with the precompiled distribution?) > -----Original Message----- > From: xml-sig-admin@python.org [mailto:xml-sig-admin@python.org]On > Behalf Of Frank Brugman > Sent: Friday, April 14, 2000 8:11 AM > To: xml-sig@python.org > Subject: [XML-SIG] python installatie op Windows > > > > Dear Reader, > > I tried to install the xml extention for Python under Windows NT > from the file PyXML-0.5.3.tar. > ( I have installed python 1.5.2 under progam files and created a > path to it. ) > I extracted the files and tried to invoke the command: > > 'python setup.py build' > > >>>>>>>>>>> Logging from screen >>>>>>>>>>>>>>>>>>>>> > > D:\Users\Brugman\xml\PyXML-0.5.3>python setup.py build > > Traceback (innermost last): > File "setup.py", line 19, in ? > from distutils.command.build import Build > ImportError: cannot import name Build > > D:\Users\Brugman\xml\PyXML-0.5.3>ls > > ANNOUNCE README Wise mac xml > CREDITS README.pyexpat demo setup.py > LICENCE README.sgmlop doc test > MANIFEST TODO extensions windows > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > So it failed, and I don't have a clue what I did wrong. > As I am unfamiliar with python I also can't see which command line will > python let parse a XML file. ( or setup a TCL/TK interface for > editing such a XML file ) > > I hope I didn't ask too stupid questions, > > With kind regards, Frank Brugman > > > > > ---------------------------------------------------------------- > Frank Brugman TNO Automotive > Phone: +31 15 2 69 70 35 P.O. Box 6033, 2600 JA, DELFT > Fax: +31 15 2 62 43 21 The Netherlands > URL: http://www.madymo.com E-Mail: brugman@wt.tno.nl(laparesse@wish.net) > ---------------------------------------------------------------- > > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig From robin@jessikat.demon.co.uk Sat Apr 15 12:08:22 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Sat, 15 Apr 2000 12:08:22 +0100 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <200004122355.RAA04954@localhost.localdomain> References: <200004122355.RAA04954@localhost.localdomain> Message-ID: It may be easy for you guys to nuke xmllib, but what will we be able to use instead. I'm forced to use some version of xmllib as that makes client installation a bit easier. I see differences between xmllib as supplied in xml-sig and python 1.5.2, how am I to proceed when these two versions can't even agree on the significance of ']' or the syntax_error argument list? Do I bite the bullet and go with another parser for simple parsing and if so which? The xml-sig should take a leadership role and at least give some guidance on these issues. I don't need SAX2 (yet), but please give us something. -- Robin Becker From paul@prescod.net Sat Apr 15 19:56:57 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Apr 2000 13:56:57 -0500 Subject: [XML-SIG] Python 1.6 and XML References: <200004122355.RAA04954@localhost.localdomain> Message-ID: <38F8BB79.9CB8F5C2@prescod.net> I don't think we are going to nuke xmllib. That was just an aside. The current plan (AFAIK) is to just deprecate it. You can move over to SAX1/2 at your own pace. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Ivory towers are no longer in order. We need ivory networks. Today, sitting quietly and thinking is the world's greatest generator of wealth and prosperity." - http://www.bespoke.org/viridian/print.asp?t=140 From robin@jessikat.demon.co.uk Sat Apr 15 21:37:38 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Sat, 15 Apr 2000 21:37:38 +0100 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <38F8BB79.9CB8F5C2@prescod.net> References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> Message-ID: In article <38F8BB79.9CB8F5C2@prescod.net>, Paul Prescod writes >I don't think we are going to nuke xmllib. That was just an aside. > >The current plan (AFAIK) is to just deprecate it. You can move over to >SAX1/2 at your own pace. > so will the xmllib.py in lib be the new one or remain as it is in 1.5.2? -- Robin Becker From paul@prescod.net Sat Apr 15 20:17:14 2000 From: paul@prescod.net (Paul Prescod) Date: Sat, 15 Apr 2000 14:17:14 -0500 Subject: [XML-SIG] SAX for 1.6 References: Message-ID: <38F8C03A.874A2A14@prescod.net> My opinion is that a simple SAX 2 API would have a 90% chance of being in-line with the final SAX 2 because AFAIK, it hasn't been changing very much for the last six months. It's just a matter of finishing touches. Officially it is in "beta" so major changes would be surprising. A SAX 1 API would have an 100% chance of being out of date by the end of the year, though. Therefore I think we should go with SAX2. Also, there is no requirement to support all of SAX2 in the core implementation. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "Ivory towers are no longer in order. We need ivory networks. Today, sitting quietly and thinking is the world's greatest generator of wealth and prosperity." - http://www.bespoke.org/viridian/print.asp?t=140 From larsga@garshol.priv.no Sun Apr 16 10:19:17 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 16 Apr 2000 11:19:17 +0200 Subject: [XML-SIG] SAX for 1.6 In-Reply-To: <38F8C03A.874A2A14@prescod.net> References: <38F8C03A.874A2A14@prescod.net> Message-ID: * Paul Prescod | | My opinion is that a simple SAX 2 API would have a 90% chance of being | in-line with the final SAX 2 because AFAIK, it hasn't been changing very | much for the last six months. It's just a matter of finishing touches. | Officially it is in "beta" so major changes would be surprising. This is more or less the same response I got from David Megginson. Also, the most controversial parts (DTD declarations and lexical events) have been moved out into an extension package. So I would say that we should put the core SAX2 stuff in the Python 1.6 distribution, and then put the extension stuff with more drivers in the XML-SIG package. --Lars M. From andy@reportlab.com Mon Apr 17 09:03:26 2000 From: andy@reportlab.com (Andy Robinson) Date: Mon, 17 Apr 2000 09:03:26 +0100 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: Message-ID: Robin > so will the xmllib.py in lib be the new one or remain as it is in 1.5.2? Yes, that's the critical question. Can someone give us an answer on this? - Andy From paul@prescod.net Mon Apr 17 14:39:05 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Apr 2000 08:39:05 -0500 Subject: [XML-SIG] Python 1.6 and XML References: Message-ID: <38FB13F9.70905D03@prescod.net> I think that we agreed at the conference not to touch it. At all. Even a little. xmllib will stay as it is (but deprecated) probably until Py3K. Paul Prescod Andy Robinson wrote: > > Robin > so will the xmllib.py in lib be the new one or remain as it is in > 1.5.2? > > Yes, that's the critical question. Can someone give us an answer on this? > > - Andy > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From fdrake@acm.org Mon Apr 17 15:07:30 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 17 Apr 2000 10:07:30 -0400 (EDT) Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> Message-ID: <14587.6818.355329.861002@seahag.cnri.reston.va.us> Robin Becker writes: > so will the xmllib.py in lib be the new one or remain as it is in 1.5.2? The "standard" xmllib from 1.5.2 will remain; the one in PyXML is known to be out of date (and should be removed from CVS). -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Mon Apr 17 15:14:14 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 17 Apr 2000 10:14:14 -0400 (EDT) Subject: [XML-SIG] SAX for 1.6 In-Reply-To: References: <38F8C03A.874A2A14@prescod.net> Message-ID: <14587.7222.563342.513165@seahag.cnri.reston.va.us> Lars Marius Garshol writes: > This is more or less the same response I got from David Megginson. > Also, the most controversial parts (DTD declarations and lexical > events) have been moved out into an extension package. > > So I would say that we should put the core SAX2 stuff in the Python > 1.6 distribution, and then put the extension stuff with more drivers > in the XML-SIG package. Lars, This is great news, especicially considering Paul's comments regarding the expected lifetimes of the two APIs. +1 on using SAX2's final definition. -0 on using a "convenient" subset of SAX2. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From ken@bitsko.slc.ut.us Mon Apr 17 15:42:09 2000 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 17 Apr 2000 09:42:09 -0500 Subject: [XML-SIG] SAX 2.0 alpha 1 In-Reply-To: Lars Marius Garshol's message of "13 Apr 2000 20:42:39 +0200" References: Message-ID: Lars Marius Garshol writes: > I have now put a page listing open issues and remaining work on SAX > 2.0 at > > In the "Open issues" list in the above URL: > Should the EntityResolver return an InputSource or a string? An InputSource, unless it can return either. The entity to be resolved may be on a stream or be several [MG]B's in size. Another reason for returning an InputSource is so that only a SystemId (or PublicId, I guess) can be returned and the parser (or default resolver?) can resolve the SystemId. -- Ken From larsga@garshol.priv.no Mon Apr 17 15:46:41 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 17 Apr 2000 16:46:41 +0200 Subject: [XML-SIG] SAX 2.0 alpha 1 In-Reply-To: References: Message-ID: * Ken MacLeod | | In the "Open issues" list in the above URL: | > Should the EntityResolver return an InputSource or a string? | | An InputSource, unless it can return either. The entity to be | resolved may be on a stream or be several [MG]B's in size. I guess I should have explained myself better there. In SAX1 it currently returns the sysid as a string, which is not what the Java spec says (and not what makes the most sense either). So the alternatives are an InputSource or the sysid as a string. | Another reason for returning an InputSource is so that only a | SystemId (or PublicId, I guess) can be returned and the parser (or | default resolver?) can resolve the SystemId. Definitely. (It would be the parser, BTW, not the default resolver, though the parser/driver would of course be free to use that to implement the resolution.) --Lars m. From fdrake@acm.org Mon Apr 17 15:54:12 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 17 Apr 2000 10:54:12 -0400 (EDT) Subject: [XML-SIG] SAX 2.0 alpha 1 In-Reply-To: References: Message-ID: <14587.9620.407256.186682@seahag.cnri.reston.va.us> Ken MacLeod wrote: > An InputSource, unless it can return either. The entity to be > resolved may be on a stream or be several [MG]B's in size. Lars Marius Garshol writes: > I guess I should have explained myself better there. In SAX1 it > currently returns the sysid as a string, which is not what the Java > spec says (and not what makes the most sense either). So the > alternatives are an InputSource or the sysid as a string. Sounds like InputSource is the right thing to me as well. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From paul@prescod.net Mon Apr 17 18:37:49 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Apr 2000 12:37:49 -0500 Subject: [XML-SIG] SAX 2.0 alpha 1 References: Message-ID: <38FB4BED.6846EC36@prescod.net> Lars Marius Garshol wrote: > > ... > > I guess I should have explained myself better there. In SAX1 it > currently returns the sysid as a string, which is not what the Java > spec says (and not what makes the most sense either). So the > alternatives are an InputSource or the sysid as a string. I agree it should be an InputSource. For those that want to see what that means... http://www.megginson.com/SAX/javadoc/org.xml.sax.InputSource.html I think that the there would be only stream-getting methods on a Python InputSource. Java has the most confusing IO library of any language I know... Would it break things if the "mini" SAX2 that goes into the core library did not have support for InputSource and entity handler overriding? -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself When George Bush entered office, a Washington Post-ABC News poll found that 62 percent of Americans "would be willing to give up a few of the freedoms we have" for the war effort. They have gotten their wish. - "This is your bill of rights...on drugs", Harpers, Dec. 1999 From larsga@garshol.priv.no Mon Apr 17 19:17:56 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 17 Apr 2000 20:17:56 +0200 Subject: [XML-SIG] SAX 2.0 alpha 1 In-Reply-To: <38FB4BED.6846EC36@prescod.net> References: <38FB4BED.6846EC36@prescod.net> Message-ID: * Paul Prescod | | I think that the there would be only stream-getting methods on a Python | InputSource. Java has the most confusing IO library of any language I | know... I'm not sure I understand what you mean here. My view is this: we should have both current Python file-like objects (byte streams) and the character streams in the new Python 1.6a2 Unicode implementations, so that applications can either do conversion themselves or leave it to the parser. | Would it break things if the "mini" SAX2 that goes into the core library | did not have support for InputSource and entity handler overriding? Not necessarily, but I'm pretty sure the entity resolution stuff in the SAX2 distribution will be tiny, so it would hardly cost anything at all to have it there. --Lars M. From paul@prescod.net Mon Apr 17 20:09:12 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Apr 2000 14:09:12 -0500 Subject: [XML-SIG] SAX 2.0 alpha 1 References: <38FB4BED.6846EC36@prescod.net> Message-ID: <38FB6158.F31DEA39@prescod.net> Lars Marius Garshol wrote: > > * Paul Prescod > | > | I think that the there would be only stream-getting methods on a Python > | InputSource. Java has the most confusing IO library of any language I > | know... > > I'm not sure I understand what you mean here. See attached... > My view is this: we should have both current Python file-like objects > (byte streams) and the character streams in the new Python 1.6a2 > Unicode implementations, so that applications can either do conversion > themselves or leave it to the parser. How often will applications want to do conversion themselves? Surely if they aren't happy with Python's encoding conversion they should "hook in" at a lower level rather than in SAX! > | Would it break things if the "mini" SAX2 that goes into the core library > | did not have support for InputSource and entity handler overriding? > > Not necessarily, but I'm pretty sure the entity resolution stuff in > the SAX2 distribution will be tiny, so it would hardly cost anything > at all to have it there. I'm thinking more about confusion, documentation, etc. SAX is not really so "simple" anymore, when you get into entity handlers, decl handlers, input sources, locators, etc. etc. I would like the documented interface to be something that you could read and understand in fifteen minutes. Or maybe it's the DOM event layer that should be that simple. Here's the attachment I promised: class java.io.InputStream class java.io.ByteArrayInputStream class java.io.FileInputStream class java.io.FilterInputStream class java.io.BufferedInputStream class java.util.zip.CheckedInputStream class java.io.DataInputStream (implements java.io.DataInput) class java.security.DigestInputStream class java.util.zip.InflaterInputStream class java.util.zip.GZIPInputStream class java.util.zip.ZipInputStream (implements java.util.zip.ZipConstants) class java.io.LineNumberInputStream class java.io.PushbackInputStream class java.io.ObjectInputStream (implements java.io.ObjectInput, java.io.ObjectStreamConstants) class java.io.PipedInputStream class java.io.SequenceInputStream class java.io.StringBufferInputStream class java.io.Reader class java.io.BufferedReader class java.io.LineNumberReader class java.io.CharArrayReader class java.io.FilterReader class java.io.PushbackReader class java.io.InputStreamReader class java.io.FileReader class java.io.PipedReader class java.io.StringReader -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself [In retrospect] the story of a Cold War that was the scene of history's only nuclear arms race will be very different from the story of a Cold War that turned out to be only the first of many interlocking nuclear arms races in many parts of the world. The nuclear, question, in sum, hangs like a giant question mark over our waning century. - The Unfinished Twentieth Century by Jonathan Schell Harper's Magazine, January 2000 From robin@jessikat.demon.co.uk Mon Apr 17 20:10:50 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Mon, 17 Apr 2000 20:10:50 +0100 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <14587.6818.355329.861002@seahag.cnri.reston.va.us> References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> <14587.6818.355329.861002@seahag.cnri.reston.va.us> Message-ID: In article <14587.6818.355329.861002@seahag.cnri.reston.va.us>, Fred L. Drake, Jr. writes > >Robin Becker writes: > > so will the xmllib.py in lib be the new one or remain as it is in 1.5.2? > > The "standard" xmllib from 1.5.2 will remain; the one in PyXML is >known to be out of date (and should be removed from CVS). > > > -Fred > >-- >Fred L. Drake, Jr. >Corporation for National Research Initiatives > > ... I'm confused now. PyXML's xmllib doesn't do anything about ']' characters in open text whereas the Python 1.5.2 xmllib does. I'm not clever enough to know which one is correct, but I don't see that text [stuff] more text should pay special attention to [stuff] or am I out of date. -- Robin Becker From fdrake@acm.org Mon Apr 17 20:32:22 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 17 Apr 2000 15:32:22 -0400 (EDT) Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> <14587.6818.355329.861002@seahag.cnri.reston.va.us> Message-ID: <14587.26310.980367.548082@seahag.cnri.reston.va.us> Robin Becker writes: > I'm confused now. PyXML's xmllib doesn't do anything about ']' > characters in open text whereas the Python 1.5.2 xmllib does. I'm not > clever enough to know which one is correct, but I don't see that > > text [stuff] more text > > should pay special attention to [stuff] or am I out of date. Hmm. It shouldn't as far as I can tell. That must be a bug. If someone sends a patch for it, I don't see any reason not to integrate it (we don't want bugs, regardless). The 1.5.2 xmllib understands namespaces, whereas PyXML's xmllib does not. I think the concensus is to drop xml.parsers.xmllib; if enough people agree I can remove it (I've not yet seen anyone respond that this is the right thing). At any rate, it will not become a replacement for the 1.5.2 xmllib. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From ken@bitsko.slc.ut.us Mon Apr 17 21:07:29 2000 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 17 Apr 2000 15:07:29 -0500 Subject: [XML-SIG] SAX 2.0 alpha 1 In-Reply-To: Paul Prescod's message of "Mon, 17 Apr 2000 14:09:12 -0500" References: <38FB4BED.6846EC36@prescod.net> <38FB6158.F31DEA39@prescod.net> Message-ID: Paul Prescod writes: > Lars Marius Garshol wrote: > > > > * Paul Prescod > > | > > | I think that the there would be only stream-getting methods on a Python > > | InputSource. Java has the most confusing IO library of any language I > > | know... > > > > I'm not sure I understand what you mean here. > > See attached... [list of all Java input classes] Not that I'm a huge fan of Java, but the stackable IO classes are a big win, IMO. -- Ken From paul@prescod.net Mon Apr 17 22:34:14 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 17 Apr 2000 16:34:14 -0500 Subject: [XML-SIG] Python 1.6 and XML References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> <14587.6818.355329.861002@seahag.cnri.reston.va.us> <14587.26310.980367.548082@seahag.cnri.reston.va.us> Message-ID: <38FB8356.A452C869@prescod.net> Square brackets should not be flagged in plain old text. I vote to dump xml.parsers.xmllib because I don't think anybody has the interest to maintain and improve it. Arguably, namespaces and xmllib don't play together nicely anyhow because of the function name/":"-character clash. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself [In retrospect] the story of a Cold War that was the scene of history's only nuclear arms race will be very different from the story of a Cold War that turned out to be only the first of many interlocking nuclear arms races in many parts of the world. The nuclear, question, in sum, hangs like a giant question mark over our waning century. - The Unfinished Twentieth Century by Jonathan Schell Harper's Magazine, January 2000 From gstein@lyra.org Tue Apr 18 01:17:11 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Apr 2000 17:17:11 -0700 (PDT) Subject: [XML-SIG] SAX for 1.6 In-Reply-To: <14587.7222.563342.513165@seahag.cnri.reston.va.us> Message-ID: On Mon, 17 Apr 2000, Fred L. Drake, Jr. wrote: > Lars Marius Garshol writes: > > This is more or less the same response I got from David Megginson. > > Also, the most controversial parts (DTD declarations and lexical > > events) have been moved out into an extension package. > > > > So I would say that we should put the core SAX2 stuff in the Python > > 1.6 distribution, and then put the extension stuff with more drivers > > in the XML-SIG package. > > Lars, > This is great news, especicially considering Paul's comments > regarding the expected lifetimes of the two APIs. > > +1 on using SAX2's final definition. > -0 on using a "convenient" subset of SAX2. How do you plan to use the final definition if it isn't complete before Python's ship date?!? This is why I suggested sticking to SAX1 since we know its final form. Using a partial SAX2 could simply be confusing "gee, what parts were left out?" And the argument about SAX1 being dead by the end of the year is bogus. It is useful technology, and there is still the XML-SIG distribution to provide additional XML capabilities. An extra ship vehicle, if you will. +1 on SAX1 -0 on SAX2 "light" -1 on SAX2 "final" (impossible) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Apr 18 01:18:43 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Apr 2000 17:18:43 -0700 (PDT) Subject: [XML-SIG] SAX 2.0 alpha 1 In-Reply-To: <38FB4BED.6846EC36@prescod.net> Message-ID: On Mon, 17 Apr 2000, Paul Prescod wrote: >... > Would it break things if the "mini" SAX2 that goes into the core library > did not have support for InputSource and entity handler overriding? Intuitiveness. "Oh?! It doesn't have that! Crap." -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Apr 18 01:19:58 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Apr 2000 17:19:58 -0700 (PDT) Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <14587.26310.980367.548082@seahag.cnri.reston.va.us> Message-ID: On Mon, 17 Apr 2000, Fred L. Drake, Jr. wrote: > The 1.5.2 xmllib understands namespaces, whereas PyXML's xmllib does > not. I think the concensus is to drop xml.parsers.xmllib; if enough > people agree I can remove it (I've not yet seen anyone respond that > this is the right thing). At any rate, it will not become a > replacement for the 1.5.2 xmllib. +1. Torch it. -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Tue Apr 18 02:40:51 2000 From: gstein@lyra.org (Greg Stein) Date: Mon, 17 Apr 2000 18:40:51 -0700 (PDT) Subject: [XML-SIG] SAX 2.0 alpha 1 In-Reply-To: <14587.9620.407256.186682@seahag.cnri.reston.va.us> Message-ID: On Mon, 17 Apr 2000, Fred L. Drake, Jr. wrote: > Ken MacLeod wrote: > > An InputSource, unless it can return either. The entity to be > > resolved may be on a stream or be several [MG]B's in size. > > Lars Marius Garshol writes: > > I guess I should have explained myself better there. In SAX1 it > > currently returns the sysid as a string, which is not what the Java > > spec says (and not what makes the most sense either). So the > > alternatives are an InputSource or the sysid as a string. > > Sounds like InputSource is the right thing to me as well. Sounds like the Python / SAX2 design isn't quite there. Everybody still feel comfortable that this can be solidified and shipped in *six weeks* ?? Cheers, -g -- Greg Stein, http://www.lyra.org/ From robin@jessikat.demon.co.uk Tue Apr 18 08:06:36 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Tue, 18 Apr 2000 08:06:36 +0100 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <14587.26310.980367.548082@seahag.cnri.reston.va.us> References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> <14587.6818.355329.861002@seahag.cnri.reston.va.us> <14587.26310.980367.548082@seahag.cnri.reston.va.us> Message-ID: <4yw0NIA8lA$4EwFi@jessikat.demon.co.uk> In article <14587.26310.980367.548082@seahag.cnri.reston.va.us>, Fred L. Drake, Jr. writes > >Robin Becker writes: > > I'm confused now. PyXML's xmllib doesn't do anything about ']' > > characters in open text whereas the Python 1.5.2 xmllib does. I'm not > > clever enough to know which one is correct, but I don't see that > > > > text [stuff] more text > > > > should pay special attention to [stuff] or am I out of date. > > Hmm. It shouldn't as far as I can tell. That must be a bug. If >someone sends a patch for it, I don't see any reason not to integrate >it (we don't want bugs, regardless). > The 1.5.2 xmllib understands namespaces, whereas PyXML's xmllib does >not. I think the concensus is to drop xml.parsers.xmllib; if enough >people agree I can remove it (I've not yet seen anyone respond that >this is the right thing). At any rate, it will not become a >replacement for the 1.5.2 xmllib. > > > -Fred ... How current is the testxml.py stuff? If I put '[stuff]' into the first quotation ie We will perhaps eventually be writing only small [stuff] modules and then run python testxml.py I get both test_sax and test_pyexpat to fail I'm concerned that I am missing something very obvious about xml ie that [] has some special significance; I had believed that only and &id; were important. -- Robin Becker From robin@jessikat.demon.co.uk Tue Apr 18 13:01:28 2000 From: robin@jessikat.demon.co.uk (Robin Becker) Date: Tue, 18 Apr 2000 13:01:28 +0100 Subject: [XML-SIG] xmllib problems Message-ID: I was being stupid complaining about the test_pyexpat & test_sax scripts as these check their output. The error in xmllib I see is that cdata gets called at odd points ie the following output is obtained with the sample parser below. start tag: handle_data:'aaa[stuff' handle_data:']' handle_data:'bbb' end tag: the odd handle_data:']' doesn't happen with the xml-sig xmllib. I'm not sure that this is a bug, but it causes me problems as I assumed I wouldn't get this kind of split data. from xmllib import TestXMLParser class myParser(TestXMLParser): def __init__(self): TestXMLParser.__init__(self) def parse(self,text): self.reset() self.feed(text) self.close() def handle_data(self,data): print 'handle_data:\'%s\'' % data _parser = myParser() _parser.parse('aaa[stuff]bbb') -- Robin Becker From ludvig.svenonius@excosoft.se Tue Apr 18 14:56:02 2000 From: ludvig.svenonius@excosoft.se (Ludvig Svenonius) Date: Tue, 18 Apr 2000 15:56:02 +0200 Subject: [XML-SIG] 4XPath under Win32 Message-ID: I'm involved in a project where we need a working XPath python library and due to circumstances beyond our control we are tied to the Win32 platform. I've also been searching for other XPath implementations but 4XPath seems to be the safest bet to me. So, my question is: what's the ETA on a version of 4XPath that works under Win32? ================================================================== Ludvig Svenonius - Researcher Excosoft AB * Electrum 420 * Isafjordsgatan 32c SE-164 40 Kista * Sweden Phones: +46 8 633 29 58 * +46 70 789 16 85 mailto:ludvig.svenonius@excosoft.se ================================================================== From fdrake@acm.org Tue Apr 18 17:15:51 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 18 Apr 2000 12:15:51 -0400 (EDT) Subject: [XML-SIG] xml.parsers.xmllib removed Message-ID: <14588.35383.372633.949307@seahag.cnri.reston.va.us> I've removed xml.parsers.xmllib; do a CVS update to catch the change. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From uogbuji@fourthought.com Tue Apr 18 22:01:55 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 18 Apr 2000 15:01:55 -0600 Subject: [XML-SIG] 4XPath under Win32 In-Reply-To: Message from "Ludvig Svenonius" of "Tue, 18 Apr 2000 15:56:02 +0200." Message-ID: <200004182101.PAA11102@localhost.localdomain> > I'm involved in a project where we need a working XPath python library and > due to circumstances beyond our control we are tied to the Win32 platform. > I've also been searching for other XPath implementations but 4XPath seems to > be the safest bet to me. So, my question is: what's the ETA on a version of > 4XPath that works under Win32? Actually, Oliver Gathmann already contributed a Windows port for 4XPath. I just never put it on the FTP because I assumed most people would want 4XSLT as well. I went ahead and put up Oliver's binary at ftp://ftp.fourthought.com/pub/4Suite/binaries/windows/4XPath-4_8_3-bin-win32.zi p I'd like to stress that we haven't tested this much in-house (we just ran a basic test on it), and that if you have any support questions, please post them to the 4Suite mailing list (4suite@fourthought.com), which Oliver read as well as Fourthought staff, and the appropriate person might be able to help. Note that we are working on a more permanent solution for 4XSLT and 4XPath on Windows (it's not just the platform port: we are moving the packages to use BisonGen, which can already generate Windows binaries). The ETA on this is still in April. -- Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From akuchlin@mems-exchange.org Fri Apr 21 17:12:51 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Fri, 21 Apr 2000 12:12:51 -0400 (EDT) Subject: [XML-SIG] 0.5.4 release candidate Message-ID: <200004211612.MAA21728@amarok.cnri.reston.va.us> I've put a release candidate for version 0.5.4 in http://www.python.org/sigs/xml-sig/files/ (darn, just realized I forgot to GPG-sign it). The major purpose of this release is to make the package compatible with the current state of the Distutils, though there have been other changes along the way. Can people please try it out and let me know the result, even if it installed perfectly? Thanks! -- A.M. Kuchling http://starship.python.net/crew/amk/ It begins to rain fish. Mackerel. Herring. Sea bass. Pike. Sturgeon. Tench. Plaice. Salmon. From a clear sky. Trout. No cod. -- Father McGarry's last sight, in DOOM PATROL #20. From a.k.heath@open.ac.uk Sat Apr 22 10:18:57 2000 From: a.k.heath@open.ac.uk (Andy Heath) Date: Sat, 22 Apr 2000 10:18:57 +0100 Subject: [XML-SIG] XML-SCHEMA Message-ID: <39016E81.C7FA3858@open.ac.uk> Are you guys doing anything about XML Schema? I know the spec is not out there in any final'ish form yet but IMHO the whole world will go that way when it is. For my work I track IMS (amongst other standards) and within IMS many people use a tool called XML-Authority which runs on windows boxes. To the best of my knowledge is the best/only tool available that will work with any XML-Schema. It is notable also that there is XML-Schema (xdr) support in IE5. I know this is chicken-and-egg but I'd really like to work with Python on linux rather than paying for a windows tool. Anything happening on this front? Andy -- ------------------------------------------------------------ Andy Heath Home:+44 (0)114 2885738 a.k.heath@open.ac.uk Center for Educational Technology Interoperability Standards From akuchlin@mems-exchange.org Sat Apr 22 17:27:11 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Sat, 22 Apr 2000 12:27:11 -0400 (EDT) Subject: [XML-SIG] XML-SCHEMA In-Reply-To: <39016E81.C7FA3858@open.ac.uk> References: <39016E81.C7FA3858@open.ac.uk> Message-ID: <14593.53983.551893.612230@amarok.cnri.reston.va.us> Andy Heath writes: >Are you guys doing anything about XML Schema? > >I know the spec is not out there in any final'ish form >yet but IMHO the whole world will go that way when it is. I don't know if anyone is working on XML Schema support, but your message gave me the impetus to go to www.w3.org to take a look at the working drafts. To my horror, the two parts of the XML schema WDs are 520K and 360K of HTML; that's huge! (XML 1.0 is 188K.) Didn't people want schemas because they thought DTD syntax was too complicated? -- A.M. Kuchling http://starship.python.net/crew/amk/ I pity the poor shades confined to the Euclidean prison that is sanity. -- From Amadeus Arkham's journal in ARKHAM ASYLUM From tismer@tismer.com Sat Apr 22 18:06:45 2000 From: tismer@tismer.com (Christian Tismer) Date: Sat, 22 Apr 2000 19:06:45 +0200 Subject: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> Message-ID: <3901DC25.8E598D66@tismer.com> "Andrew M. Kuchling" wrote: ... > To my horror, the two parts of the XML schema WDs are 520K and 360K of > HTML; that's huge! (XML 1.0 is 188K.) Didn't people want schemas > because they thought DTD syntax was too complicated? It looks so, yes. But it's all XML, no DTD needed, and it is much more powerful and easy to read. To get a feeling, I suggest to grab a demo copy of XMLAuthority at http://www.extensiblity.com and play with it. Create a simple document structure, and save it as DTD and as Schema. This is quite impressive and convincing. Writing a schema processor would not involve to write a new XML parser per se, but you would use an existing, probably non-validating parser, maybe one that validates the XSD file. But generating the rules from the XSD files is then already completely Python's task, since what we generate is a set of rules which are used as the validating/processing part for data files which make use of that schema. These rules would be put on top of a fast non-validating parser. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From tismer@tismer.com Sat Apr 22 18:06:55 2000 From: tismer@tismer.com (Christian Tismer) Date: Sat, 22 Apr 2000 19:06:55 +0200 Subject: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> Message-ID: <3901DC2F.3887E159@tismer.com> "Andrew M. Kuchling" wrote: ... > To my horror, the two parts of the XML schema WDs are 520K and 360K of > HTML; that's huge! (XML 1.0 is 188K.) Didn't people want schemas > because they thought DTD syntax was too complicated? It looks so, yes. But it's all XML, no DTD needed, and it is much more powerful and easy to read. To get a feeling, I suggest to grab a demo copy of XMLAuthority at http://www.extensibility.com and play with it. Create a simple document structure, and save it as DTD and as Schema. This is quite impressive and convincing. Writing a schema processor would not involve to write a new XML parser per se, but you would use an existing, probably non-validating parser, maybe one that validates the XSD file. But generating the rules from the XSD files is then already completely Python's task, since what we generate is a set of rules which are used as the validating/processing part for data files which make use of that schema. These rules would be put on top of a fast non-validating parser. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From ken@bitsko.slc.ut.us Sat Apr 22 21:06:06 2000 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 22 Apr 2000 15:06:06 -0500 Subject: [OFFTOPIC] Re: [XML-SIG] XML-SCHEMA In-Reply-To: Christian Tismer's message of "Sat, 22 Apr 2000 19:06:45 +0200" References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> <3901DC25.8E598D66@tismer.com> Message-ID: Christian Tismer writes: > "Andrew M. Kuchling" wrote: > ... > > To my horror, the two parts of the XML schema WDs are 520K and 360K of > > HTML; that's huge! (XML 1.0 is 188K.) Didn't people want schemas > > because they thought DTD syntax was too complicated? > > It looks so, yes. But it's all XML, no DTD needed, and it is much > more powerful and easy to read. To get a feeling, I suggest to grab > a demo copy of XMLAuthority at http://www.extensiblity.com and play > with it. Create a simple document structure, and save it as DTD and > as Schema. This is quite impressive and convincing. > > Writing a schema processor would not involve to write a new XML > parser per se, but you would use an existing, probably > non-validating parser, maybe one that validates the XSD file. > But generating the rules from the XSD files is then already > completely Python's task, since what we generate is a set of rules > which are used as the validating/processing part for data files > which make use of that schema. These rules would be put on top of a > fast non-validating parser. I respect the functionality of XML Schema, but to claim its XML grammar as "more powerful and easy to read" is a big reach. Domain-specific syntaxes almost always beat out generic or interchange syntaxes for expressiveness and readability. That ranks up there with using a DOM interface to your application's data as one of the biggest misuses of XML. -- Ken From a.k.heath@open.ac.uk Sun Apr 23 17:35:12 2000 From: a.k.heath@open.ac.uk (Andy Heath) Date: Sun, 23 Apr 2000 17:35:12 +0100 Subject: [XML-SIG] Re: XML-SCHEMA References: <20000423160010.993C71CDC7@dinsdale.python.org> Message-ID: <39032640.D5E477BC@open.ac.uk> > I respect the functionality of XML Schema, but to claim its XML > grammar as "more powerful and easy to read" is a big reach. For me the major point is the ability to reference other schemas within a schema. This give a tool for abstraction that is otherwise absent. It seems to me that this particular mechanism is sorely needed. Andy -- ------------------------------------------------------------ Andy Heath Home:+44 (0)114 2885738 a.k.heath@open.ac.uk Center for Educational Technology Interoperability Standards From tismer@trixie.triqs.com Sun Apr 23 21:43:14 2000 From: tismer@trixie.triqs.com (Christian Tismer) Date: Sun, 23 Apr 2000 22:43:14 +0200 Subject: [OFFTOPIC] Re: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> <3901DC25.8E598D66@tismer.com> Message-ID: <39036062.60E55B31@trixie.triqs.com> Ken MacLeod wrote: > > Christian Tismer writes: [a little about Schemas] ... > I respect the functionality of XML Schema, but to claim its XML > grammar as "more powerful and easy to read" is a big reach. Sorry, it is more powerful than a DTD and easier to read. Feel free to prove the opposite. I'm prepared well. > Domain-specific syntaxes almost always beat out generic or interchange > syntaxes for expressiveness and readability. The one does not exclude the other. But it makes absolute sense to express primitive and composite types using the schema definitions as far as they fit. You can put on top whatever else you need. > That ranks up there with using a DOM interface to your application's > data as one of the biggest misuses of XML. What do you try to express by this? I have never been arguing pro DOM. If you want to know my opinions about DOM, please read Greg Stein's posts of last year. Mine opinions are exactly the same, incidentally. Instead of raising general claims I suggest to read the specs. I you were in fact working with schemas (as I do since months) you could not arrive at your conclusions. point not taken until you show me your schemas - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From tismer@trixie.triqs.com Sun Apr 23 22:05:21 2000 From: tismer@trixie.triqs.com (Christian Tismer) Date: Sun, 23 Apr 2000 23:05:21 +0200 Subject: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> Message-ID: <39036591.9ADDAE1@trixie.triqs.com> Second reply to this, since I think something more has to be said. "Andrew M. Kuchling" wrote: > > Andy Heath writes: > >Are you guys doing anything about XML Schema? > > > >I know the spec is not out there in any final'ish form > >yet but IMHO the whole world will go that way when it is. > > I don't know if anyone is working on XML Schema support, but your > message gave me the impetus to go to www.w3.org to take a look at the > working drafts. > > To my horror, the two parts of the XML schema WDs are 520K and 360K of > HTML; that's huge! (XML 1.0 is 188K.) Didn't people want schemas > because they thought DTD syntax was too complicated? People want schemas since a DTD has limited expressiveness. Schemas go far beyond DTDs. With schemas, you can express new data types with constraints, you can build new abstract types and assign rules about what they can contain. You can explicitly describe what attributes and elements may contain, by setting ranges, enumerating values and giving regular expressions. New types can be built from given/other types both by restriction and extension. This all cannot be done with DTDs. it-looks-like-I-will-have-to-support-this-ly y'rs -chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From mclay@nist.gov Sun Apr 23 23:46:20 2000 From: mclay@nist.gov (Michael McLay) Date: Sun, 23 Apr 2000 18:46:20 -0400 (EDT) Subject: [XML-SIG] RELAX in lieu of XML Schema? Message-ID: <14595.32060.234197.685900@fermi.eeel.nist.gov> Andrew M. Kuchling writes: > Andy Heath writes: > >Are you guys doing anything about XML Schema? > > > >I know the spec is not out there in any final'ish form > >yet but IMHO the whole world will go that way when it is. > > I don't know if anyone is working on XML Schema support, but your > message gave me the impetus to go to www.w3.org to take a look at the > working drafts. > > To my horror, the two parts of the XML schema WDs are 520K and 360K of > HTML; that's huge! (XML 1.0 is 188K.) Didn't people want schemas > because they thought DTD syntax was too complicated? The Schema committee lost control of the scope of the project. A typical standards committee mistake. Yet another standard that may have become so complex that it will never be consistently implemented. I'd like to see XML Schema available for Python, but I'd be happy with any DTD replacement mechanism be used that allows typing information and namespaces to be managed. Has anyone looked at RELAX, http://www.xml.gr.jp/relax/ ? It is a smaller and easier to implement alternative to XML Schema. Here's a quote from an article about RELAX that sums up why I think it might be a good first step towards adding schema capabilities to Python. Murata had hit the 80/20 mark that they [the XML Schema committee] had missed. RELAX core could provide a much easier on-ramp to schemas for application and schema authors than the W3C draft which is not modular. [...] Our First Take. We share the stunned admiration for Murata's lone samurai charge. On first analysis, RELAX appears to combine greater simplicity in approach, exposition and execution with greater power-a compelling combination under any circumstances. Given the low but omnipresent level of grumbling over the length, complexity and compromises of the W3C spec, RELAX will be given every chance to live up to its claims. Backing up his claim to ease of implementation, Murata's group already has made available a Java converter from DTDs to RELAX and a validator written in C++,with source code to come under an open source license. As Sperberg-McQueen indicated, ultimately adoption rests with the marketplace. One very strong point in favor of RELAX is that it can be implemented without ripping out existing XML processors and APIs. Because the Core module is a direct DTD replacement, no extensions are required to DOM and SAX implementations. RELAX grammar validation, with datatypes, can be added as a subsequent step. - http://www.seyboldreports.com/News/2000/20000307.html The C++ code isn't available in a format I recognize. The file name is regular1.lzh. The strings function located 51 .cpp file names and 120 .h file names. I would assume that the code could be added to the XML package as an optional post DOM processing step. Someone with SWIG or SIP experience could probably have the new module with RELAX capability up and running quickly. I don't see a down side to adding RELAX as a feature of the XML package. An XML Schema processing engine could be added along side of RELAX when and if XML Schema starts to be adopted widely. An article on RELAX at http://www.xml.com/pub/2000/02/xtech/relax.html also includes a review of Paul Prescod's EasySAX. Did I miss this article being referenced on this mailing list? There doesn't seem to be list of articles on Python and XML in the xml-sig pages. EasySAX was also described in http://www.javaworld.com/jw-03-2000/jw-03-xmlshow.html From ken@bitsko.slc.ut.us Mon Apr 24 00:47:53 2000 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 23 Apr 2000 18:47:53 -0500 Subject: [OFFTOPIC] Re: [XML-SIG] XML-SCHEMA In-Reply-To: Christian Tismer's message of "Sun, 23 Apr 2000 22:43:14 +0200" References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> <3901DC25.8E598D66@tismer.com> <39036062.60E55B31@trixie.triqs.com> Message-ID: Christian Tismer writes: > Ken MacLeod wrote: > > > > Christian Tismer writes: > [a little about Schemas] > ... > > I respect the functionality of XML Schema, but to claim its XML > > grammar as "more powerful and easy to read" is a big reach. > > Sorry, it is more powerful than a DTD and easier to read. > Feel free to prove the opposite. I'm prepared well. I think you may have misinterpreted my comment. My comment was specifically in reference to "But it's all XML, no DTD needed". I took this statement to mean "it's better because it's in XML syntax, instead of being in a schema specific syntax". I wasn't trying to say DTDs were better than XML Schema, but that XML Schema itself would likely be "more powerful and easy to read" if it had it's _own_ syntax rather than layering over XML. You later wrote: > Writing a schema processor would not involve to write a new XML > parser per se, but you would use an existing, probably > non-validating parser, maybe one that validates the XSD file. Which, although true, does not make the syntax necessarily more powerful or easier to read for the most important part of the equation: the user who has to write it. In other words, XMLAuthority wouldn't be a required necessity if the syntax of the language (XML Schema) weren't so convoluted because it's _in_ XML. A parallel is the thread here a few months back about expressing programming languages in XML. Sure, it's possible, but would _you_ want to write a program in XML rather than Python? I wouldn't. > > That ranks up there with using a DOM interface to your application's > > data as one of the biggest misuses of XML. > > What do you try to express by this? A common mistake in using XML, similar in spirit to XML Schema being expressed in XML, is for people to access their application data through a layer of XML exposed through DOM. DOM is an interface to XML information. Accessing application data represented via XML information is an unnecessary and burdensome layer; far better to simply convert the XML into application objects and use those directly. -- Ken From ht@cogsci.ed.ac.uk Mon Apr 24 09:43:42 2000 From: ht@cogsci.ed.ac.uk (Henry S. Thompson) Date: 24 Apr 2000 09:43:42 +0100 Subject: [XML-SIG] XML-SCHEMA In-Reply-To: Andy Heath's message of "Sat, 22 Apr 2000 10:18:57 +0100" References: <39016E81.C7FA3858@open.ac.uk> Message-ID: We will shortly be announcing an open-source XML Schema (Last Call draft version) parser, written in Python. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2001, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ From tismer@trixie.triqs.com Mon Apr 24 14:09:17 2000 From: tismer@trixie.triqs.com (Christian Tismer) Date: Mon, 24 Apr 2000 15:09:17 +0200 Subject: [OFFTOPIC] Re: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> <3901DC25.8E598D66@tismer.com> <39036062.60E55B31@trixie.triqs.com> Message-ID: <3904477C.A987B53@trixie.triqs.com> Ken, Ken MacLeod wrote: > > Christian Tismer writes: > > > Ken MacLeod wrote: > > > > > > Christian Tismer writes: > > [a little about Schemas] > > ... > > > I respect the functionality of XML Schema, but to claim its XML > > > grammar as "more powerful and easy to read" is a big reach. > > > > Sorry, it is more powerful than a DTD and easier to read. > > Feel free to prove the opposite. I'm prepared well. > > I think you may have misinterpreted my comment. My comment was > specifically in reference to "But it's all XML, no DTD needed". Yes, here we have different oppinions. My point was: Schema is written in XML. We have good parsers for XML. We don't need write yet another parser and don't need to care about DTDs and possible extensions to them. > I took this statement to mean "it's better because it's in XML syntax, > instead of being in a schema specific syntax". I wasn't trying to say > DTDs were better than XML Schema, but that XML Schema itself would > likely be "more powerful and easy to read" if it had it's _own_ syntax > rather than layering over XML. XML Schema is a language, defined in terms of XML itself, together with rules which define the meaning of certain constructs in the Schema namespace. Schema definitions are quite a bit more verbose that their DTD counterparts (as long as they exist), but they appear to be concise enough to be very readable for me. > You later wrote: > > Writing a schema processor would not involve to write a new XML > > parser per se, but you would use an existing, probably > > non-validating parser, maybe one that validates the XSD file. > > Which, although true, does not make the syntax necessarily more > powerful or easier to read for the most important part of the > equation: the user who has to write it. In other words, XMLAuthority > wouldn't be a required necessity if the syntax of the language (XML > Schema) weren't so convoluted because it's _in_ XML. This is true, but I doubt that the majority of users would still use a text editor to write a schema for a complex problem. They will need to validate it, they will want to create test data, and they want to easily try out different layouts until they are pleased. Theoretically this is possible to be done by hand, as it is still possible to write HTML documents by hand. But I believe you can count those people by the fingers of that hand. In other words: If problems are real problems, I doubt that one would create the structure without a good tool. For simple problems, a schema would be overkill, anyway. > A parallel is the thread here a few months back about expressing > programming languages in XML. Sure, it's possible, but would _you_ > want to write a program in XML rather than Python? I wouldn't. No, this isn't parallel. I would of course not write in XML if I wanted to write Python. A serialization forth and back would be ok, if it's done by a tool. But expressing structure *in* the language which is used to create structured instances is not a particularly new idea of XML. Databases use recursive metainformation for their own structured contents since a long time. Doing so with XML seems to be straight forward to me. My parallel is the types-sig: Python needs a way to describe its own types. This will be done by adding some more structures, but it will still be part of Python, as I understand it. XML does so by using a couple of name spaces with given meaning. > > > That ranks up there with using a DOM interface to your application's > > > data as one of the biggest misuses of XML. > > > > What do you try to express by this? > > A common mistake in using XML, similar in spirit to XML Schema being > expressed in XML, is for people to access their application data > through a layer of XML exposed through DOM. DOM is an interface to > XML information. Accessing application data represented via XML > information is an unnecessary and burdensome layer; far better to > simply convert the XML into application objects and use those > directly. Yes, right, but what's the point? Of course I would create application objects and validate them with the XML schema, which of course would be converted into some suitable application object before processing. It would make sense in the case of Schemas to build some mini-DOMs as an intermediate step, probably. But after the parsing, there is no more XML involved, just rules remain which check for presense, absense and correctness of attributes and elements. This happens in the moment where we create the application structure. What's what I'm missing? thanks for your patience - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From tismer@trixie.triqs.com Mon Apr 24 14:18:09 2000 From: tismer@trixie.triqs.com (Christian Tismer) Date: Mon, 24 Apr 2000 15:18:09 +0200 Subject: [XML-SIG] RELAX in lieu of XML Schema? References: <14595.32060.234197.685900@fermi.eeel.nist.gov> Message-ID: <39044991.E8E4702C@trixie.triqs.com> Michael McLay wrote: > > Andrew M. Kuchling writes: [horror about spec size] > The Schema committee lost control of the scope of the project. A > typical standards committee mistake. Yet another standard that may > have become so complex that it will never be consistently > implemented. I'd like to see XML Schema available for Python, but I'd > be happy with any DTD replacement mechanism be used that allows typing > information and namespaces to be managed. > > Has anyone looked at RELAX, http://www.xml.gr.jp/relax/ ? It is a > smaller and easier to implement alternative to XML Schema. Here's a > quote from an article about RELAX that sums up why I think it might be > a good first step towards adding schema capabilities to Python. Hmm, I had a quick look, but it's quite hard to judge just from reading, since there is no 1-to-1 comparison to Schema provided. [article snipped] > The C++ code isn't available in a format I recognize. The file name > is regular1.lzh. The strings function located 51 .cpp file names and > 120 .h file names. I would assume that the code could be added to the > XML package as an optional post DOM processing step. Someone with > SWIG or SIP experience could probably have the new module with RELAX > capability up and running quickly. I don't see a down side to adding > RELAX as a feature of the XML package. An XML Schema processing > engine could be added along side of RELAX when and if XML Schema > starts to be adopted widely. I don't thik that we would want to add a lot of C++ to the XML package, and then on top of DOM. We have very fast XML parsers, that's enough of C. The schema stuff, whatever flavor, should be at least prototyped with Python. See also Henry S. Thompsons announcement of a Schema parser, done the right way, written in Python. Having the same for RELAX would make it much easier to compare the two concepts. (But why, if it's there, soon.) ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From paul@prescod.net Mon Apr 24 16:22:26 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Apr 2000 10:22:26 -0500 Subject: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> Message-ID: <390466B2.9CE6769E@prescod.net> "Andrew M. Kuchling" wrote: > > ... > > To my horror, the two parts of the XML schema WDs are 520K and 360K of > HTML; that's huge! (XML 1.0 is 188K.) Didn't people want schemas > because they thought DTD syntax was too complicated? "Too complicated?" I don't really think so. Ugly? Yes. Also, DTD syntax was not XML element and attribute syntax. That deeply offended some people. Those were the nonsense reasons that schemas were developed. The serious reasons were: * to introduce a primtive datatype and datatype extension system. * to make extensions to the syntax easier * to add concepts of super/subtyping As you can see, the goal was never to simplify... -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Neo-liberals should try applying the same skepticism to the process of granting and defining the state-conferred monopolies called intellectual property rights that they do to the state-conferred regulatory monopolies that affect certain kinds of banking business or the electromagnetic spectrum. - http://www.salon.com/tech/feature/2000/04/07/greenspan/index2.html From paul@prescod.net Mon Apr 24 16:22:41 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Apr 2000 10:22:41 -0500 Subject: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> <3901DC25.8E598D66@tismer.com> Message-ID: <390466C1.C4310F88@prescod.net> Christian Tismer wrote: > >... > > It looks so, yes. But it's all XML, no DTD needed, > and it is much more powerful and easy to read. Well, those are both arguable. Somewhat more powerful, yes. Easier to read? If you don't know either language, yes, it is easier to read, as COBOL is easier to read than Python. But once you've learned both languages the more compact syntax means that you can read faster. It's a difference between having fifty one-line declarations on a screen at one time versus having ten five-line declarations. Schemas allow a few more types of validation and extension in exchange for complexity and verbosity. Judged entirely on this basis, the debate could go either way but political and historical factors are more likely to be the decision makers. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself From paul@prescod.net Mon Apr 24 16:22:13 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Apr 2000 10:22:13 -0500 Subject: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> Message-ID: <390466A5.F3FD278@prescod.net> Andy Heath wrote: > > Are you guys doing anything about XML Schema? > > I know the spec is not out there in any final'ish form > yet but IMHO the whole world will go that way when it is. > > For my work I track IMS (amongst other standards) and within > IMS many people use a tool called XML-Authority which > runs on windows boxes. To the best of my knowledge is the > best/only tool available that will work with any XML-Schema. > > It is notable also that there is XML-Schema (xdr) support > in IE5. > > > I know this is chicken-and-egg but I'd really like to work > with Python on linux rather than paying for a windows tool. I'm not following you Andy. XML Authority is a graphical DTD/schema authoring tool, not a programming language. I don't think that XML schema support in Python/XML would get you any closer to having a graphical authoring tool that works on Linux. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Neo-liberals should try applying the same skepticism to the process of granting and defining the state-conferred monopolies called intellectual property rights that they do to the state-conferred regulatory monopolies that affect certain kinds of banking business or the electromagnetic spectrum. - http://www.salon.com/tech/feature/2000/04/07/greenspan/index2.html From paul@prescod.net Mon Apr 24 16:22:48 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 24 Apr 2000 10:22:48 -0500 Subject: [XML-SIG] Re: XML-SCHEMA References: <20000423160010.993C71CDC7@dinsdale.python.org> <39032640.D5E477BC@open.ac.uk> Message-ID: <390466C8.CD9D7AA3@prescod.net> Andy Heath wrote: > > ... > > For me the major point is the ability to reference other schemas > within a schema. This give a tool for abstraction that > is otherwise absent. It seems to me that this particular > mechanism is sorely needed. XML DTDs have always been able to refer to and build on other XML DTDs. XML schemas are marginally better than DTDs at abstraction but I think that both have a fatal flaw in that their abstraction mechanisms only work on the tree data structure and do nothing for links. What real application does not rely on links? -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From Mike.Olson@fourthought.com Mon Apr 24 16:31:42 2000 From: Mike.Olson@fourthought.com (Mike Olson) Date: Mon, 24 Apr 2000 09:31:42 -0600 Subject: [XML-SIG] RELAX in lieu of XML Schema? References: <14595.32060.234197.685900@fermi.eeel.nist.gov> Message-ID: <390468DE.CAF8DB7@FourThought.com> --------------052CCFF15A5845F93F47EF92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael McLay wrote: > Andrew M. Kuchling writes: > > Andy Heath writes: > > >Are you guys doing anything about XML Schema? > > > > > >I know the spec is not out there in any final'ish form > > >yet but IMHO the whole world will go that way when it is. > > > > I don't know if anyone is working on XML Schema support, but your > > message gave me the impetus to go to www.w3.org to take a look at the > > working drafts. > > > > To my horror, the two parts of the XML schema WDs are 520K and 360K of > > HTML; that's huge! (XML 1.0 is 188K.) Didn't people want schemas > > because they thought DTD syntax was too complicated? > > The Schema committee lost control of the scope of the project. A > typical standards committee mistake. Yet another standard that may > have become so complex that it will never be consistently > implemented. I'd like to see XML Schema available for Python, but I'd > be happy with any DTD replacement mechanism be used that allows typing > information and namespaces to be managed. > What about Schematron? The nice thing about this is that it can be validated with a XSLT processor. There is a stylesheet with 4XSLT to do this. You run the stylesheet against the Schema file, and it produces a new stylesheet. You then apply this stylesheet to your data and it reports errors and warnings. Mike > > Has anyone looked at RELAX, http://www.xml.gr.jp/relax/ ? It is a > smaller and easier to implement alternative to XML Schema. Here's a > quote from an article about RELAX that sums up why I think it might be > a good first step towards adding schema capabilities to Python. > > Murata had hit the 80/20 mark that they [the XML Schema committee] > had missed. RELAX core could provide a much easier on-ramp to > schemas for application and schema authors than the W3C draft > which is not modular. > > [...] > > Our First Take. We share the stunned admiration for Murata's lone > samurai charge. On first analysis, RELAX appears to combine greater > simplicity in approach, exposition and execution with greater power-a > compelling combination under any circumstances. Given the low but > omnipresent level of grumbling over the length, complexity and > compromises of the W3C spec, RELAX will be given every chance to live > up to its claims. > > Backing up his claim to ease of implementation, Murata's group > already has made available a Java converter from DTDs to RELAX and a > validator written in C++,with source code to come under an open source > license. As Sperberg-McQueen indicated, ultimately adoption rests with > the marketplace. One very strong point in favor of RELAX is that it > can be implemented without ripping out existing XML processors and > APIs. Because the Core module is a direct DTD replacement, no > extensions are required to DOM and SAX implementations. RELAX grammar > validation, with datatypes, can be added as a subsequent step. > > - http://www.seyboldreports.com/News/2000/20000307.html > > The C++ code isn't available in a format I recognize. The file name > is regular1.lzh. The strings function located 51 .cpp file names and > 120 .h file names. I would assume that the code could be added to the > XML package as an optional post DOM processing step. Someone with > SWIG or SIP experience could probably have the new module with RELAX > capability up and running quickly. I don't see a down side to adding > RELAX as a feature of the XML package. An XML Schema processing > engine could be added along side of RELAX when and if XML Schema > starts to be adopted widely. > > An article on RELAX at http://www.xml.com/pub/2000/02/xtech/relax.html > also includes a review of Paul Prescod's EasySAX. Did I miss this > article being referenced on this mailing list? There doesn't seem to > be list of articles on Python and XML in the xml-sig pages. EasySAX > was also described in http://www.javaworld.com/jw-03-2000/jw-03-xmlshow.html > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig -- Mike Olson Senior Consultant mike.olson@fourthought.com (303)583-9900 x 102 Fourthought, Inc. http://Fourthought.com Software-engineering, knowledge-management, XML, CORBA, Linux, Python --------------052CCFF15A5845F93F47EF92 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Michael McLay wrote:
Andrew M. Kuchling writes:
 > Andy Heath writes:
 > >Are you guys doing anything about XML Schema?
 > >
 > >I know the spec is not out there in any final'ish form
 > >yet but IMHO the whole world will go that way when it is.
 >
 > I don't know if anyone is working on XML Schema support, but your
 > message gave me the impetus to go to www.w3.org to take a look at the
 > working drafts.
 >
 > To my horror, the two parts of the XML schema WDs are 520K and 360K of
 > HTML; that's huge!  (XML 1.0 is 188K.)  Didn't people want schemas
 > because they thought DTD syntax was too complicated?

The Schema committee lost control of the scope of the project.  A
typical standards committee mistake.  Yet another standard that may
have become so complex that it will never be consistently
implemented.  I'd like to see XML Schema available for Python, but I'd
be happy with any DTD replacement mechanism be used that allows typing
information and namespaces to be managed.
 

What about Schematron?  The nice thing about this is that it can be validated with a XSLT processor.  There is a stylesheet with  4XSLT to do this.  You run the stylesheet against the Schema file, and it produces a new stylesheet.  You then apply this stylesheet to your data and it reports errors and warnings.

Mike
 

 
Has anyone looked at RELAX, http://www.xml.gr.jp/relax/ ? It is a
smaller and easier to implement alternative to XML Schema.  Here's a
quote from an article about RELAX that sums up why I think it might be
a good first step towards adding schema capabilities to Python.

    Murata had hit the 80/20 mark that they [the XML Schema committee]
    had missed. RELAX core could provide a much easier on-ramp to
    schemas for application and schema authors than the W3C draft
    which is not modular.

    [...]

    Our First Take. We share the stunned admiration for Murata's lone
    samurai charge. On first analysis, RELAX appears to combine greater
    simplicity in approach, exposition and execution with greater power-a
    compelling combination under any circumstances. Given the low but
    omnipresent level of grumbling over the length, complexity and
    compromises of the W3C spec, RELAX will be given every chance to live
    up to its claims.

    Backing up his claim to ease of implementation, Murata's group
    already has made available a Java converter from DTDs to RELAX and a
    validator written in C++,with source code to come under an open source
    license. As Sperberg-McQueen indicated, ultimately adoption rests with
    the marketplace. One very strong point in favor of RELAX is that it
    can be implemented without ripping out existing XML processors and
    APIs. Because the Core module is a direct DTD replacement, no
    extensions are required to DOM and SAX implementations. RELAX grammar
    validation, with datatypes, can be added as a subsequent step.

       - http://www.seyboldreports.com/News/2000/20000307.html

The C++ code isn't available in a format I recognize.  The file name
is regular1.lzh.  The strings function located 51 .cpp file names and
120 .h file names.  I would assume that the code could be added to the
XML package as an optional post DOM processing step.  Someone with
SWIG or SIP experience could probably have the new module with RELAX
capability up and running quickly.  I don't see a down side to adding
RELAX as a feature of the XML package.  An XML Schema processing
engine could be added along side of RELAX when and if XML Schema
starts to be adopted widely.

An article on RELAX at http://www.xml.com/pub/2000/02/xtech/relax.html
also includes a review of Paul Prescod's EasySAX.  Did I miss this
article being referenced on this mailing list?  There doesn't seem to
be list of articles on Python and XML in the xml-sig pages.  EasySAX
was also described in http://www.javaworld.com/jw-03-2000/jw-03-xmlshow.html

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

-- 
Mike Olson                                Senior Consultant
mike.olson@fourthought.com               (303)583-9900 x 102
Fourthought, Inc.                         http://Fourthought.com 
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
  --------------052CCFF15A5845F93F47EF92-- From mclay@nist.gov Mon Apr 24 16:40:39 2000 From: mclay@nist.gov (Michael McLay) Date: Mon, 24 Apr 2000 11:40:39 -0400 (EDT) Subject: [XML-SIG] RELAX in lieu of XML Schema? In-Reply-To: <39044991.E8E4702C@trixie.triqs.com> References: <14595.32060.234197.685900@fermi.eeel.nist.gov> <39044991.E8E4702C@trixie.triqs.com> Message-ID: <14596.27383.365478.509923@fermi.eeel.nist.gov> Christian Tismer writes: > See also Henry S. Thompsons announcement of a Schema parser, > done the right way, written in Python. > Having the same for RELAX would make it much easier to > compare the two concepts. (But why, if it's there, soon.) I missed this announcment. Thanks for the reference. I agree that a side by side comparison would be nice, but I was just looking for a method for validating data types. If a Schema based one exisits I'll use it. From ken@bitsko.slc.ut.us Mon Apr 24 18:36:14 2000 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 24 Apr 2000 12:36:14 -0500 Subject: [OFFTOPIC] Re: [XML-SIG] XML-SCHEMA In-Reply-To: Christian Tismer's message of "Mon, 24 Apr 2000 15:09:17 +0200" References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> <3901DC25.8E598D66@tismer.com> <39036062.60E55B31@trixie.triqs.com> <3904477C.A987B53@trixie.triqs.com> Message-ID: Christian Tismer writes: > Ken MacLeod wrote: > > A common mistake in using XML, similar in spirit to XML Schema > > being expressed in XML, is for people to access their application > > data through a layer of XML exposed through DOM. DOM is an > > interface to XML information. Accessing application data > > represented via XML information is an unnecessary and burdensome > > layer; far better to simply convert the XML into application > > objects and use those directly. > > Yes, right, but what's the point? Of course I would create > application objects and validate them with the XML schema, which of > course would be converted into some suitable application object > before processing. It would make sense in the case of Schemas to > build some mini-DOMs as an intermediate step, probably. But after > the parsing, there is no more XML involved, just rules remain which > check for presense, absense and correctness of attributes and > elements. This happens in the moment where we create the application > structure. Yes, converting into suitable application objects before processing is the right way to do it. There are XML users who don't do that, instead accessing their data through DOM, that's the wrong way to do it. -- Ken From tismer@tismer.com Mon Apr 24 19:56:49 2000 From: tismer@tismer.com (Christian Tismer) Date: Mon, 24 Apr 2000 20:56:49 +0200 Subject: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> <3901DC25.8E598D66@tismer.com> <390466C1.C4310F88@prescod.net> Message-ID: <390498F1.9681D1DA@tismer.com> Paul Prescod wrote: > > Christian Tismer wrote: > > > >... > > > > It looks so, yes. But it's all XML, no DTD needed, > > and it is much more powerful and easy to read. > > Well, those are both arguable. Somewhat more powerful, yes. Sure. > Easier to read? If you don't know either language, yes, it is easier to > read, as COBOL is easier to read than Python. But once you've learned > both languages the more compact syntax means that you can read faster. > It's a difference between having fifty one-line declarations on a screen > at one time versus having ten five-line declarations. Yes, but... I usually avoid as most as possible MS stuff, but in this case I'm guilty: An XML schema looks just great when you browse it with IE5. You can fold nodes, you have a quite readable XML document. Since I don't have such a tool for DTDs, browsing schemas is in fact easier for me than DTD text files. Let's see the schema structure under a different aspect: It is in fact a higher level structure, which is expressed somehow in XML. I agree that there might be better visualizations of the model. Maybe this could be visualized by an application on top of schema. I also agree that links need to be supported, nut just trees. > Schemas allow a few more types of validation and extension in exchange > for complexity and verbosity. Judged entirely on this basis, the debate > could go either way but political and historical factors are more likely > to be the decision makers. Ok, I think of it like of a Python structure which is serialized as an XML pickle. Of course this doesn't show the real structure, it is not perfect and verbose. But what I'm in fact after is the ability to define types, have more control over my XML documents. If the state-of-the-art happens to be schema, well I'll take it, but I'm not excited about it. Give me something more powerful with a good chance to get widely accepted, I'll switch immediately. Schema is just better than nothing. Has somebody looked into XMLAuthority? I'd really like to know what their native data abstraction is. They seem to be very flexible in reading and writing different formats. Perhaps the *right* way to do it hides somewhere in their implementation? ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From tismer@tismer.com Mon Apr 24 20:12:02 2000 From: tismer@tismer.com (Christian Tismer) Date: Mon, 24 Apr 2000 21:12:02 +0200 Subject: [XML-SIG] XML Installer for Windows Message-ID: <39049C82.AD6EB635@tismer.com> Howdy, I got the request to revive my XML installer. I did so with the current CVS from April 19, and would like if somebody can find problems. I'd also like to know how to get the Wise source into the CVS again. Last time nobody seemed to care about my update. http://www.tismer.com/xml/PythonXML.EXE ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From a.k.heath@open.ac.uk Mon Apr 24 21:14:09 2000 From: a.k.heath@open.ac.uk (Andy Heath) Date: Mon, 24 Apr 2000 21:14:09 +0100 Subject: [XML-SIG] XML-SCHEMA Message-ID: <3904AB11.539F120A@open.ac.uk> > XML Authority is a graphical DTD/schema authoring tool, not a > programming language. I don't think that XML schema support in > Python/XML would get you any closer to having a graphical authoring tool > that works on Linux. This is true but it isn't just authoring tools its applications, translations and so on. In my particular area its things like ed. content packagers that rely on collections of externally (i.e. via links) defined schemas over which the application has no control. > XML schemas are marginally better than DTDs at abstraction but I think > that both have a fatal flaw in that their abstraction mechanisms only > work on the tree data structure and do nothing for links. What real > application does not rely on links? Exactly. I guess rather than abstraction I should have talked about different groups of people doing different things (writing different schemas) in different places, but in many circumstances this is not so different from abstraction, which is the way I was thinking about it. For example one may wish to have ed. content whose structure is defined by several referenced (elswhere) schemas in some complicated arrangement where pieces described by different schemas are intermingled in some complicated, probably nested, way. Andy -- ------------------------------------------------------------ Andy Heath Home:+44 (0)114 2885738 a.k.heath@open.ac.uk Center for Educational Technology Interoperability Standards From tpassin@idsonline.com Tue Apr 25 01:15:38 2000 From: tpassin@idsonline.com (THOMAS PASSIN) Date: Mon, 24 Apr 2000 20:15:38 -0400 Subject: [XML-SIG] XML-SCHEMA References: <39016E81.C7FA3858@open.ac.uk> <14593.53983.551893.612230@amarok.cnri.reston.va.us> <3901DC25.8E598D66@tismer.com> <390466C1.C4310F88@prescod.net> <390498F1.9681D1DA@tismer.com> Message-ID: <002701bfae4b$654898e0$0102a8c0@home.com> Christian Tismer asked - > Has somebody looked into XMLAuthority? I'd really like to > know what their native data abstraction is. They seem to > be very flexible in reading and writing different formats. > Perhaps the *right* way to do it hides somewhere in their > implementation? > I've played with it a little, we have it at work. If you haven't tried it out, it has its own data model - don't know exactly what it is. You can design a schema - a data structure - semi-graphically, then you can have the tool save it to a file in a number of formats. Two of the formats are DTDs and (an older version of) XML-schemas. It can read a lot of file formats and deduce a schema. It understands DTDs very well, including external subsets and parameter entities. It really seems to be oriented towards DTD type things, even though you can output XML-schemas. The content models look like DTD-type content models, and you can specify them using pretty nearly the usual DTD syntax. I don't recall seeing a lot of support for much of the XML-schema things that are not possible in DTDs, especially for creating new schemas. This will probably change, though, as the schema spec stabilizes. It's a nice tool, though, especially for longer schemas. It doesn't look so useful, though, for parameterizing schemas. It understands them, and will let you create your own parameter entities. But it expands everything when you import the DTD (or whatever) so you can't find the module and parameters in the main graphical views. They say they will be supporting the newer versions of the XML-Schema draft. Tom Passin From uogbuji@fourthought.com Tue Apr 25 02:21:25 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 24 Apr 2000 19:21:25 -0600 Subject: [XML-SIG] DTD? Schemas? RELAX? Try Schematron In-Reply-To: Message from Michael McLay of "Sun, 23 Apr 2000 18:46:20 EDT." <14595.32060.234197.685900@fermi.eeel.nist.gov> Message-ID: <200004250121.TAA01315@localhost.localdomain> Since everyone is weighing in with their favorite schema technology, I'll mention that I _really_ like Rick Jelliffe's Schematron http://www.ascc.net/xml/resource/schematron/schematron.html Rick is on the W3C Schema group, so he'd never outright say it is out of control, but actions speak louder than words and he's provided a much saner approach to the problem. Schematron simply harnesses the enormous power of XSLT to make assertions about a document, providing a very flexible approach to the rules, output and style of validation. Best of all, since there is a basic implementation in XSLT, it's already here for Python using 4XSLT. We've used it this way in a production project (validation was not required for every XML document access). -- Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From alwagner@tcac.net Tue Apr 25 04:47:35 2000 From: alwagner@tcac.net (Albert Wagner) Date: Mon, 24 Apr 2000 22:47:35 -0500 Subject: [XML-SIG] No confirmation sent Message-ID: <39051557.E09CD347@tcac.net> I have tried on two occasions to subscribe to the xml-sig list but have never received a confirmation email. Is is being sent and not received or is it not being sent? -- Small is Beautiful From jeremy.kloth@fourthought.com Tue Apr 25 04:43:24 2000 From: jeremy.kloth@fourthought.com (Jeremy Kloth) Date: Mon, 24 Apr 2000 21:43:24 -0600 Subject: [XML-SIG] 4DOM update Message-ID: <3905145B.71047F6@fourthought.com> --------------FEDD45106DEEB1D3C2551EC0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The long promised update to 4DOM migration to xml-sig. Also ncludes some bug fixes and speed improvements, up to 40% in some cases. ftp://ftp.fourthought.com/pub/4Suite/4DOM/4DOM-XML-Sig.tgz -- Jeremy Kloth Junior Consultant jeremy.kloth@fourthought.com (303) 583-9900 x105 Fourthought, Inc. http://www.Fourthought.com Software-engineering, knowledge-management, XML, CORBA, Linux, Python --------------FEDD45106DEEB1D3C2551EC0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit     The long promised update to 4DOM migration to xml-sig. Also ncludes some
bug fixes and speed improvements, up to 40% in some cases.

ftp://ftp.fourthought.com/pub/4Suite/4DOM/4DOM-XML-Sig.tgz 

-- 
Jeremy Kloth                              Junior Consultant
jeremy.kloth@fourthought.com              (303) 583-9900 x105
Fourthought, Inc.                         http://www.Fourthought.com
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
  --------------FEDD45106DEEB1D3C2551EC0-- From paul@auctionflow.com Tue Apr 25 04:48:41 2000 From: paul@auctionflow.com (Paul Schreiber) Date: Mon, 24 Apr 2000 20:48:41 -0700 Subject: [XML-SIG] SAX_expat extension -- parseString() Message-ID: <39051599.F9A4E1E7@auctionflow.com> I hacked up my copy of drv_pyexpat.py because I wanted to be able to parse XML that didn't exist in files or URLs. Paul Here's the code: class SAX_expat(saxlib.Parser,saxlib.Locator): "SAX driver for the Pyexpat C module." [snip] def parse(self,sysID): self.sysID=sysID self.parseString(urllib.urlopen(sysID).read()) def parseFile(self,fileobj): self.parseString(fileobj.read()) def parseString(self, str): self.reset() self.doc_handler.startDocument() if not self.parser.Parse( str, 1): self.__report_error() self.doc_handler.endDocument() Here's a context diff: *** /tmp/PyXML-0.5.3/xml/sax/drivers/drv_pyexpat.py Tue Dec 15 18:54:33 1998 --- drv_pyexpat.py Mon Apr 24 20:45:21 2000 *************** *** 53,77 **** def parse(self,sysID): self.sysID=sysID ! self.parseFile(urllib.urlopen(sysID)) ! def parseFile(self,fileobj): self.reset() self.doc_handler.startDocument() ! # while 1: ! # buf=fileobj.read(16384) ! # ! # if buf: ! # if not self.parser.Parse(buf): ! # self.__report_error() ! # return ! # else: ! # break ! ! if not self.parser.Parse(fileobj.read(),1): self.__report_error() ! self.doc_handler.endDocument() # --- Locator methods. Only usable after errors. --- 53,70 ---- def parse(self,sysID): self.sysID=sysID ! self.parseString(urllib.urlopen(sysID).read()) ! def parseFile(self,fileobj): + self.parseString(fileobj.read()) + + def parseString(self, str): self.reset() self.doc_handler.startDocument() ! if not self.parser.Parse( str, 1): self.__report_error() ! self.doc_handler.endDocument() # --- Locator methods. Only usable after errors. From paul@prescod.net Tue Apr 25 08:42:01 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 25 Apr 2000 02:42:01 -0500 Subject: [XML-SIG] XML-SCHEMA References: <3904AB11.539F120A@open.ac.uk> Message-ID: <39054C49.D7D59872@prescod.net> Andy Heath wrote: > > For example one may wish to have ed. content whose structure is defined > by > several referenced (elswhere) schemas in some complicated arrangement > where pieces described by different schemas are intermingled > in some complicated, probably nested, way. I am not yet convinced that schemas make this problem easier to solve than DTDs do but I have not experimented enough to claim otherwise. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From larsga@garshol.priv.no Tue Apr 25 12:09:35 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 25 Apr 2000 13:09:35 +0200 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <38FB8356.A452C869@prescod.net> References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> <14587.6818.355329.861002@seahag.cnri.reston.va.us> <14587.26310.980367.548082@seahag.cnri.reston.va.us> <38FB8356.A452C869@prescod.net> Message-ID: * Paul Prescod | | I vote to dump xml.parsers.xmllib because I don't think anybody has | the interest to maintain and improve it. Should we check that with Sjoerd before we dump it? | Arguably, namespaces and xmllib don't play together nicely anyhow | because of the function name/":"-character clash. The elements dictionary fixes that, and in fact the current xmllib version supports namespaces. --Lars M. From l.szyster@ibm.net Tue Apr 25 12:49:24 2000 From: l.szyster@ibm.net (Laurent Szyster) Date: Tue, 25 Apr 2000 13:49:24 +0200 Subject: [XML-SIG] XML Schema and e-commerce Message-ID: <39058644.F30D193C@ibm.net> XML Schema is a "standard" candidate pushed forward by Microsoft for it's BizTalk e-commerce initiative. Basically, MS proposes to build a web of e-commerce document specifications. XML with Schema could be a substitute for traditional EDI (EDIFACT, X12, etc). This means savings for SME, as Microsoft provides the document browser, validating parser and an XSLT mapper for free. However, I don't think e-commerce will be built on XML Schema. The reason is that XML Schema is conceptually the same thing as EDIFACT or X12. It's the same methodology: you define a standard interface and you add support for it into your application. Unfortunately the process of standard definition takes a long time and the result is a huge and complex data model that tries to fit all existing applications (well, the applications of the companies who paid enough money to get their requirement into the standard ;-) So, developping e-commerce interfaces with XML Schemas and XSLT stylesheets will not be significantly faster or less expensive than doing it with traditional EDI tools. Laurent Szyster ___ Consultant WISE s.c. From tpassin@idsonline.com Tue Apr 25 13:31:47 2000 From: tpassin@idsonline.com (THOMAS PASSIN) Date: Tue, 25 Apr 2000 08:31:47 -0400 Subject: [XML-SIG] Python 1.6 and XML References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> <14587.6818.355329.861002@seahag.cnri.reston.va.us> <14587.26310.980367.548082@seahag.cnri.reston.va.us> <38FB8356.A452C869@prescod.net> Message-ID: <001f01bfaeb2$3bc2d820$0102a8c0@home.com> Lars Marius Garshol wrote, about keeping xmllib or not - > > * Paul Prescod > | > | I vote to dump xml.parsers.xmllib because I don't think anybody has > | the interest to maintain and improve it. > > Should we check that with Sjoerd before we dump it? > > | Arguably, namespaces and xmllib don't play together nicely anyhow > | because of the function name/":"-character clash. > > The elements dictionary fixes that, and in fact the current xmllib > version supports namespaces. xmllib is the easiest, quickest way to get started processing xml in Python. The learning curve is small. This makes it valuable to have in the package. When I first started with Python and xml, sgmlop didn't work because of a version mismatch, and pyexpat wouldn't run because it couldn't find its dynamic modules (this is WIndows95). But xmllib worked like a champ. Its existence also helped me to understand how much you could do easily with Python, because it didn't use a bit of C code, only Python. I think other newcomers would also find it to be a good thing. Let's keep xmllib. BTW, there seem to be at least two versions of urllib floating around, and one of them doesn't handle file: urls correctly when the path to the file includes the drive spec (as in c:\xml\file1.xml). This is because it keeps looking for a ':' after finding the one in "file:". Does anyone know whether this applies to the version currently packaged with the 1.5.2 distribution? Tom Passin From larsga@garshol.priv.no Tue Apr 25 15:04:36 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 25 Apr 2000 16:04:36 +0200 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <001f01bfaeb2$3bc2d820$0102a8c0@home.com> References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> <14587.6818.355329.861002@seahag.cnri.reston.va.us> <14587.26310.980367.548082@seahag.cnri.reston.va.us> <38FB8356.A452C869@prescod.net> <001f01bfaeb2$3bc2d820$0102a8c0@home.com> Message-ID: * THOMAS PASSIN | | I think other newcomers would also find it to be a good thing. | Let's keep xmllib. That requires a maintainer. But I suppose that regardless of what the XML-SIG does, someone can assume responsibility for xmllib and keep maintaining it. | BTW, there seem to be at least two versions of urllib floating | around, and one of them doesn't handle file: urls correctly when the | path to the file includes the drive spec (as in c:\xml\file1.xml). | This is because it keeps looking for a ':' after finding the one in | "file:". Are you sure that your understanding of file URLs is aligned with what's described in the various specs? :) Perhaps you could give an example? --Lars M. From larsga@garshol.priv.no Tue Apr 25 15:07:29 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 25 Apr 2000 16:07:29 +0200 Subject: [XML-SIG] XML Schema and e-commerce In-Reply-To: <39058644.F30D193C@ibm.net> References: <39058644.F30D193C@ibm.net> Message-ID: * Laurent Szyster | | So, developping e-commerce interfaces with XML Schemas and XSLT | stylesheets will not be significantly faster or less expensive | than doing it with traditional EDI tools. I don't know EDI at all, but to me that sounds very reasonable. The question is: what happens when everyone believes that this is so? (Similarly: what happens when everyone believes that Perl is a wonderful programming language and Python is a fringe language with little or nothing to give the world?) --Lars M. From fdrake@acm.org Tue Apr 25 15:36:26 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 25 Apr 2000 10:36:26 -0400 (EDT) Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: References: <200004122355.RAA04954@localhost.localdomain> <38F8BB79.9CB8F5C2@prescod.net> <14587.6818.355329.861002@seahag.cnri.reston.va.us> <14587.26310.980367.548082@seahag.cnri.reston.va.us> <38FB8356.A452C869@prescod.net> Message-ID: <14597.44394.93323.885735@seahag.cnri.reston.va.us> Lars Marius Garshol writes: > Should we check that with Sjoerd before we dump it? That's Fredrk's code, and he didn't get violent at the SIG meeting at IPC8. ;-) Sjeord did the code xmllib, and probably won't submit too many more patches to it once I've got it marked deprecated. :) > The elements dictionary fixes that, and in fact the current xmllib > version supports namespaces. Yes, but that's goes outside the "easy" aspect of the interface, which tolerates tag names that look like Python identifiers, not all possible XML tag names. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From mclay@nist.gov Tue Apr 25 15:51:12 2000 From: mclay@nist.gov (Michael McLay) Date: Tue, 25 Apr 2000 10:51:12 -0400 (EDT) Subject: [XML-SIG] XML Schema and e-commerce In-Reply-To: References: <39058644.F30D193C@ibm.net> Message-ID: <14597.45280.590494.750346@fermi.eeel.nist.gov> Lars Marius Garshol writes: > > * Laurent Szyster > | > | So, developping e-commerce interfaces with XML Schemas and XSLT > | stylesheets will not be significantly faster or less expensive > | than doing it with traditional EDI tools. > > I don't know EDI at all, but to me that sounds very reasonable. The > question is: what happens when everyone believes that this is so? > (Similarly: what happens when everyone believes that Perl is a > wonderful programming language and Python is a fringe language with > little or nothing to give the world?) Perhaps we need to take a Pythonic approach to this problem. Paul's EasyDOM is a good example of blending what the rest of the world is doing to manipulate XML (SAX and DOM) with what makes sense in Python. A module in the XML package could support XML Schema directly, but then there should also be the EasySchema layer on top of it that makes it comprehensible and easy to a Python user. My only need in having XML Schema is so that I can have type checks made on the data contained in an XML file. I could care less that this is done by XML Schema. I just need one mechanism that does this well. The more Pythonic the better. From uogbuji@fourthought.com Tue Apr 25 16:35:34 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 25 Apr 2000 09:35:34 -0600 Subject: [XML-SIG] 4DOM update In-Reply-To: Message from Jeremy Kloth of "Mon, 24 Apr 2000 21:43:24 MDT." <3905145B.71047F6@fourthought.com> Message-ID: <200004251535.JAA02395@localhost.localdomain> > The long promised update to 4DOM migration to xml-sig. Also ncludes > some > bug fixes and speed improvements, up to 40% in some cases. > > ftp://ftp.fourthought.com/pub/4Suite/4DOM/4DOM-XML-Sig.tgz I should note that this is merely a pre-release for XML-SIG members. In fact, there will still be a branched version of 4DOM released (hopefully today) with the old structure, and 4XSLT and 4XPath to go with it. These will be the last versions using the old 4DOM structure. Meanwhile we would appreciate if those using PyDOM and 4DOM took a look so we can iron out bugs before it replaces the core PyDOM package. It's probably a good time to begin discussion of the procedure for replacing old PyDOM (do we go through a deprecation cycle? How do we set up CVS? etc.) Thanks. -- Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From jdnier@execpc.com Tue Apr 25 18:30:26 2000 From: jdnier@execpc.com (David Niergarth) Date: Tue, 25 Apr 2000 12:30:26 -0500 (CDT) Subject: [XML-SIG] XML-SCHEMA In-Reply-To: <39016E81.C7FA3858@open.ac.uk> Message-ID: On Sat, 22 Apr 2000, Andy Heath wrote: > I know this is chicken-and-egg but I'd really like to work > with Python on linux rather than paying for a windows tool. Since I didn't notice anyone mention it, I thought I'd point out that XML Authority is written in Java so it's not just a Windows tool. It comes with a Mac installer; presumably it could run on other platforms with Java. --David From paul@prescod.net Tue Apr 25 20:24:58 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 25 Apr 2000 14:24:58 -0500 Subject: [XML-SIG] XML Schema and e-commerce References: <39058644.F30D193C@ibm.net> Message-ID: <3905F10A.B62E4095@prescod.net> Laurent Szyster wrote: > > XML Schema is a "standard" candidate pushed forward by Microsoft > for it's BizTalk e-commerce initiative. Basically, MS proposes to > build a web of e-commerce document specifications. Actually, this idea is pretty universally embraced. All of Microsoft's competitors in e-business are also working on e-commerce document specifications. > So, developping e-commerce interfaces with XML Schemas and XSLT > stylesheets will not be significantly faster or less expensive > than doing it with traditional EDI tools. There are sociological and technical aspects to the problem. XML does not magically solve the sociological aspects, but they will solve themselves because they *must be solved*. People will get together, and will define reasonable, maintainable document structures because e-commerce cannot afford to fail. The number of players in the EDI world were probably numbered in the hundreds and when standardization failed they could afford point to point solutions. They *already* had to negotiate and pay for point to point VANs so the cost of poor standardization was not so high. Now that the networking costs have evaporated, small companies are not going to allow the lack of standards to get between them and their customers like amazon.com and general motors. OASIS, the UN, Microsoft or *somebody* is going to work out the standards that allow these players into the market. They have too much money to ignore. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From paul@prescod.net Tue Apr 25 20:49:32 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 25 Apr 2000 14:49:32 -0500 Subject: [XML-SIG] XML-SCHEMA References: <3904AB11.539F120A@open.ac.uk> Message-ID: <3905F6CC.D206228@prescod.net> Andy Heath wrote: > > ... > > > XML schemas are marginally better than DTDs at abstraction but I think > > that both have a fatal flaw in that their abstraction mechanisms only > > work on the tree data structure and do nothing for links. What real > > application does not rely on links? > > Exactly. Let me hasten to point out that while I really do think that this is a flaw in XML Schema (for abstractions, not in general) I certainly did not understand the situation when the schema group started its work and so I don't blame anyone else for not recognizing it sooner. Abstraction in XML is H A R D. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From mgushee@havenrock.com Tue Apr 25 21:59:27 2000 From: mgushee@havenrock.com (Matt Gushee) Date: Tue, 25 Apr 2000 16:59:27 -0400 (EDT) Subject: [XML-SIG] [OFF-TOPIC] What's up with swig.org? Message-ID: <14598.1839.774630.235387@lobstah.architag.com> Hi-- Sorry for the OT post ... I don't know what the appropriate forum would be, and I figure someone here might know. I wanted to try out 4Suite on my Windows box, but I see that it requires SWIG. And I've been trying to access www.swig.org for several days, but I keep getting 'unknown host' errors. Is the site down? If so, will it be back up anytime soon? If not, is there somewhere else I can obtain SWIG? Or does my ISP have a DNS problem? Thanks for any info. Matt Gushee From tab@codexsoftware.com Tue Apr 25 21:55:47 2000 From: tab@codexsoftware.com (TR Hockamier) Date: Tue, 25 Apr 2000 13:55:47 -0700 Subject: [XML-SIG] installation of xml toolkit Message-ID: <4.3.1.2.20000425134934.00a767d0@pop.codexsoftware.com> Greetings, I am having some difficulty installing the PyXML-0.5.3 toolkit. Here's what I have done: - installed distutils - added the python/distutils and python/distutils/command to my path - unpacked the .tgz file into my D:\Temp directory - this created the PyXML-0.5.3 toolkit sub-directory with other subdirectories under it. The installation how-to says to run a make on the code but I do not have a C compiler installed. Is this required? It appears that the ../xml folder is there.... So I tried running: python setup.py build - received and error telling me it could not import the Build package Tried running: python setup.py install - same thing, could not import the Install package Any ideas on how to get this to work? Item 4 in the install how-to says that an xml/ package will be created under the site-packages/ directory - can't I copy this over? Thanks for any help you can offer Tab - Codex Software. From tab@codexsoftware.com Tue Apr 25 22:33:54 2000 From: tab@codexsoftware.com (TR Hockamier) Date: Tue, 25 Apr 2000 14:33:54 -0700 Subject: [XML-SIG] almost there? Message-ID: <4.3.1.2.20000425143101.00a76860@pop.codexsoftware.com> Most everything works upto the point of running cl.exe - DO I need a C compiler to use the SAX XML parser? or can I just copy the /xml folder to the python install? Following is tail end of running: python setup.py install . . . copying xml\sax\drivers\drv_xmldc.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\drv_xmllib.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\drv_xmlproc.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\drv_xmlproc_val.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\drv_xmltoolkit.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\pylibs.py -> build\lib.win32\xml\sax\drivers creating build\lib.win32\xml\unicode copying xml\unicode\__init__.py -> build\lib.win32\xml\unicode copying xml\unicode\iso8859.py -> build\lib.win32\xml\unicode copying xml\unicode\wstremul.py -> build\lib.win32\xml\unicode copying xml\unicode\wstring.py -> build\lib.win32\xml\unicode creating build\lib.win32\xml\utils copying xml\utils\__init__.py -> build\lib.win32\xml\utils copying xml\utils\iso8601.py -> build\lib.win32\xml\utils copying xml\utils\qp_xml.py -> build\lib.win32\xml\utils running build_ext building 'sgmlop' extension creating build\temp.win32 creating build\temp.win32\Release creating build\temp.win32\Release\extensions cl.exe /c /nologo /Ox /MD /W3 -ID:\DEVUTILS\PYTHON\Include /Tcextensions/sgmlop.c /Fobuild\temp.win32\Release\extensions/sgmlop.obj error: command 'cl.exe' failed: No such file or directory From tcodex@home.com Tue Apr 25 22:35:41 2000 From: tcodex@home.com (TR Hockamier - Home) Date: Tue, 25 Apr 2000 14:35:41 -0700 Subject: [XML-SIG] almost there? Message-ID: <4.3.1.2.20000425143515.00a7aba0@pop.codexsoftware.com> Most everything works upto the point of running cl.exe - DO I need a C compiler to use the SAX XML parser? or can I just copy the /xml folder to the python install? Following is tail end of running: python setup.py install . . . copying xml\sax\drivers\drv_xmldc.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\drv_xmllib.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\drv_xmlproc.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\drv_xmlproc_val.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\drv_xmltoolkit.py -> build\lib.win32\xml\sax\drivers copying xml\sax\drivers\pylibs.py -> build\lib.win32\xml\sax\drivers creating build\lib.win32\xml\unicode copying xml\unicode\__init__.py -> build\lib.win32\xml\unicode copying xml\unicode\iso8859.py -> build\lib.win32\xml\unicode copying xml\unicode\wstremul.py -> build\lib.win32\xml\unicode copying xml\unicode\wstring.py -> build\lib.win32\xml\unicode creating build\lib.win32\xml\utils copying xml\utils\__init__.py -> build\lib.win32\xml\utils copying xml\utils\iso8601.py -> build\lib.win32\xml\utils copying xml\utils\qp_xml.py -> build\lib.win32\xml\utils running build_ext building 'sgmlop' extension creating build\temp.win32 creating build\temp.win32\Release creating build\temp.win32\Release\extensions cl.exe /c /nologo /Ox /MD /W3 -ID:\DEVUTILS\PYTHON\Include /Tcextensions/sgmlop.c /Fobuild\temp.win32\Release\extensions/sgmlop.obj error: command 'cl.exe' failed: No such file or directory Tab tab@Codexsoftware.com From uogbuji@fourthought.com Tue Apr 25 23:01:24 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Tue, 25 Apr 2000 16:01:24 -0600 Subject: [XML-SIG] [OFF-TOPIC] What's up with swig.org? In-Reply-To: Message from Matt Gushee of "Tue, 25 Apr 2000 16:59:27 EDT." <14598.1839.774630.235387@lobstah.architag.com> Message-ID: <200004252201.QAA01471@localhost.localdomain> > Sorry for the OT post ... I don't know what the appropriate forum > would be, and I figure someone here might know. > > I wanted to try out 4Suite on my Windows box, but I see that it > requires SWIG. And I've been trying to access www.swig.org for several > days, but I keep getting 'unknown host' errors. Is the site down? If > so, will it be back up anytime soon? If not, is there somewhere else I > can obtain SWIG? Oops. Looks as if David Beazley forgot to pay his InterNIC tax or something. I can't resolve it either. Unfortunately I don't have a copy of SWIG source lying about. If anyone out there has this (or Windows binaries), please let us have a copy and we'll put it on our FTP site to help out others in the same predicament. You can already find SWIG RPMs for Linux on our python4linux mirror: http://fourthought.com/Python/python4linux.html -- Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com (303)583-9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036 Software-engineering, knowledge-management, XML, CORBA, Linux, Python From jeremy.kloth@fourthought.com Wed Apr 26 01:16:08 2000 From: jeremy.kloth@fourthought.com (Jeremy Kloth) Date: Tue, 25 Apr 2000 18:16:08 -0600 Subject: [XML-SIG] Re:[XML-SIG][OFF-TOPIC] What's up with swig.org? Message-ID: <39063548.A2C6BA07@fourthought.com> --------------4AC43D9887B6128A41690467 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A copy of the SWIG source, version 1.3a2, is now located at: ftp://ftp.fourthought.com/pub/swig/swig1.3a2-src.tgz A pre-built Windows binary is here also: ftp://ftp.fourthought.com/pub/swig/swig1.3a2-win.zip -- Jeremy Kloth Junior Consultant jeremy.kloth@fourthought.com (303) 583-9900 x105 Fourthought, Inc. http://www.Fourthought.com Software-engineering, knowledge-management, XML, CORBA, Linux, Python --------------4AC43D9887B6128A41690467 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit A copy of the SWIG source, version 1.3a2, is now located at:

ftp://ftp.fourthought.com/pub/swig/swig1.3a2-src.tgz

A pre-built Windows binary is here also:

ftp://ftp.fourthought.com/pub/swig/swig1.3a2-win.zip 

-- 
Jeremy Kloth                              Junior Consultant
jeremy.kloth@fourthought.com              (303) 583-9900 x105
Fourthought, Inc.                         http://www.Fourthought.com
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
  --------------4AC43D9887B6128A41690467-- From gstein@lyra.org Wed Apr 26 02:29:02 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 25 Apr 2000 18:29:02 -0700 (PDT) Subject: [XML-SIG] [OFF-TOPIC] What's up with swig.org? In-Reply-To: <200004252201.QAA01471@localhost.localdomain> Message-ID: On Tue, 25 Apr 2000, Uche Ogbuji wrote: > > Sorry for the OT post ... I don't know what the appropriate forum > > would be, and I figure someone here might know. > > > > I wanted to try out 4Suite on my Windows box, but I see that it > > requires SWIG. And I've been trying to access www.swig.org for several > > days, but I keep getting 'unknown host' errors. Is the site down? If > > so, will it be back up anytime soon? If not, is there somewhere else I > > can obtain SWIG? > > Oops. Looks as if David Beazley forgot to pay his InterNIC tax or something. > I can't resolve it either. Unfortunately I don't have a copy of SWIG source Nah, the InterNIC is resolving it properly. His upstream provider (Christian's skyport.net) is not providing any information for swig.org. I would guess that it is a misconfiguration on ns.skyport.net and ns2.skyport.net. Cheers, -g -- Greg Stein, http://www.lyra.org/ From tismer@tismer.com Wed Apr 26 01:49:07 2000 From: tismer@tismer.com (Christian Tismer) Date: Wed, 26 Apr 2000 02:49:07 +0200 Subject: [XML-SIG] [OFF-TOPIC] What's up with swig.org? References: Message-ID: <39063D03.25C01637@tismer.com> Sigh... Greg Stein, in complete ignorance of the announced deprecation of starship.python.net, wrote: > > On Tue, 25 Apr 2000, Uche Ogbuji wrote: > > > Sorry for the OT post ... I don't know what the appropriate forum > > > would be, and I figure someone here might know. > > > > > > I wanted to try out 4Suite on my Windows box, but I see that it > > > requires SWIG. And I've been trying to access www.swig.org for several > > > days, but I keep getting 'unknown host' errors. Is the site down? If > > > so, will it be back up anytime soon? If not, is there somewhere else I > > > can obtain SWIG? > > > > Oops. Looks as if David Beazley forgot to pay his InterNIC tax or something. > > I can't resolve it either. Unfortunately I don't have a copy of SWIG source > > Nah, the InterNIC is resolving it properly. His upstream provider > (Christian's skyport.net) is not providing any information for swig.org. I > would guess that it is a misconfiguration on ns.skyport.net and > ns2.skyport.net. Wrong guess. The InterNIC is resolving correctly what it fails to configure correctly. It isn't a misconfiguration, but your misconception. My announce of starship.skyport's death is more than a month old. David and I are trying to get the SWIG domain moved, but something seems to be a show stopper. (Not my first experience with Networksolutions.com's Perl scripts). I-have-enough-real-faults-worth-to-attack - ly y'rs - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com From beazley@rustler.cs.uchicago.edu Wed Apr 26 03:08:39 2000 From: beazley@rustler.cs.uchicago.edu (David M. Beazley) Date: Tue, 25 Apr 2000 21:08:39 -0500 (CDT) Subject: [XML-SIG] [OFF-TOPIC] What's up with swig.org? In-Reply-To: <39063D03.25C01637@tismer.com> References: <39063D03.25C01637@tismer.com> Message-ID: <200004260208.VAA11027@rustler.cs.uchicago.edu> Christian Tismer writes: > > Wrong guess. The InterNIC is resolving correctly what it > fails to configure correctly. It isn't a misconfiguration, > but your misconception. My announce of starship.skyport's > death is more than a month old. > David and I are trying to get the SWIG domain moved, but > something seems to be a show stopper. (Not my first > experience with Networksolutions.com's Perl scripts). I have been working on this, but have been having huge problems getting Network Solutions to acknowledge my authority over the domain (nevermind the fact that I own it). At this point, they are refusing to change the configuration because they don't acknowledge the existence of the University of Chicago (or something to that extent). I'm too busy to spend 5 hours a day fighting with them over that right now, so don't plan on seeing swig.org back online for another week or so. In the meantime, go to swig.sourceforge.net. Cheers, Dave From gstein@lyra.org Wed Apr 26 04:10:32 2000 From: gstein@lyra.org (Greg Stein) Date: Tue, 25 Apr 2000 20:10:32 -0700 (PDT) Subject: [XML-SIG] [OFF-TOPIC] What's up with swig.org? In-Reply-To: <39063D03.25C01637@tismer.com> Message-ID: On Wed, 26 Apr 2000, Christian Tismer wrote: > Sigh... > > Greg Stein, in complete ignorance of the announced > deprecation of starship.python.net, wrote: Oh, this is total bunk, Christian. I was reporting on the swig.org domain. That has NOTHING to do with starship.python.net. If you happened to build and deploy it that way, then great. More power to you. But my statements regarding swig.org are completely appropriate. > > On Tue, 25 Apr 2000, Uche Ogbuji wrote: > > > > Sorry for the OT post ... I don't know what the appropriate forum > > > > would be, and I figure someone here might know. > > > > > > > > I wanted to try out 4Suite on my Windows box, but I see that it > > > > requires SWIG. And I've been trying to access www.swig.org for several > > > > days, but I keep getting 'unknown host' errors. Is the site down? If > > > > so, will it be back up anytime soon? If not, is there somewhere else I > > > > can obtain SWIG? > > > > > > Oops. Looks as if David Beazley forgot to pay his InterNIC tax or something. > > > I can't resolve it either. Unfortunately I don't have a copy of SWIG source > > > > Nah, the InterNIC is resolving it properly. His upstream provider > > (Christian's skyport.net) is not providing any information for swig.org. I > > would guess that it is a misconfiguration on ns.skyport.net and > > ns2.skyport.net. > > Wrong guess. The InterNIC is resolving correctly what it > fails to configure correctly. What the hell does that mean? "fails to configure correctly" ?? WHOIS turns up "ns.skyport.net" and "ns2.skyport.net" as the nameservers for the swig.org domain. I point at those servers and ask for any information they may have about swig.org. Nada. That tells me the NS servers are misconfigured. The NIC says they are the authoritative servers, but ns*.skyport.net reports no information about swig.org. > It isn't a misconfiguration, but your misconception. Not at all. swig.org is misconfigured at ns*.skyport.net. If that is the wrong nameservers, then somebody needs to tell the NIC. In the current setup, the NIC points to ns*.skyport.net and those fall down. > My announce of starship.skyport's death is more than a month old. Totally unrelated. We're talking swig.org. > David and I are trying to get the SWIG domain moved, but > something seems to be a show stopper. (Not my first > experience with Networksolutions.com's Perl scripts). What about their Perl scripts? What are you saying they dropped the ball on? I presume that you're trying to say that you've submitted an NS update to them, but it has not carried through to the DNS root servers? > I-have-enough-real-faults-worth-to-attack - ly y'rs - chris I was not attacking any fault of yours. I was stating what is going on with swig.org. You replied that I have misconceptions, and that starship.skyport.net is why. Feh. That's bunk. If you had said "the swig.org domain was hosted on starship.skyport.net, but that machine has been taken down (taking swig.org with it)" then I would be fine. But that's not what you said, and it pisses me off. -g -- Greg Stein, http://www.lyra.org/ From srn@techno.com Wed Apr 26 03:11:37 2000 From: srn@techno.com (Steven R. Newcomb) Date: Tue, 25 Apr 2000 21:11:37 -0500 Subject: [XML-SIG] XML-SCHEMA In-Reply-To: <3905F6CC.D206228@prescod.net> (message from Paul Prescod on Tue, 25 Apr 2000 14:49:32 -0500) References: <3904AB11.539F120A@open.ac.uk> <3905F6CC.D206228@prescod.net> Message-ID: <200004260211.VAA11402@bruno.techno.com> > Andy Heath wrote: > > > > ... > > > > > XML schemas are marginally better than DTDs at abstraction but I think > > > that both have a fatal flaw in that their abstraction mechanisms only > > > work on the tree data structure and do nothing for links. What real > > > application does not rely on links? > > > > Exactly. [Paul Prescod:] > Let me hasten to point out that while I really do think that this is a > flaw in XML Schema (for abstractions, not in general) I certainly did > not understand the situation when the schema group started its work and > so I don't blame anyone else for not recognizing it sooner. Abstraction > in XML is H A R D. There is an ISO HyTime "common attribute" architectural form, "reftype", that can be used to constrain the anchors of hyperlinks. Is this the kind of thing you're looking for? -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 517 7954 fax +1 972 517 4571 Suite 211 7101 Chase Oaks Boulevard Plano, Texas 75025 USA From gstein@lyra.org Wed Apr 26 13:16:40 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 26 Apr 2000 05:16:40 -0700 (PDT) Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: Message-ID: On 25 Apr 2000, Lars Marius Garshol wrote: > * THOMAS PASSIN > | > | I think other newcomers would also find it to be a good thing. > | Let's keep xmllib. > > That requires a maintainer. But I suppose that regardless of what the > XML-SIG does, someone can assume responsibility for xmllib and keep > maintaining it. Who? Are you volunteering? If a maintainer is not present NOW, then it should disappear. And recall, we're talking about the XML-SIG version of xmllib.py. The one in the standard Python distro will remain. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Wed Apr 26 13:17:49 2000 From: gstein@lyra.org (Greg Stein) Date: Wed, 26 Apr 2000 05:17:49 -0700 (PDT) Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: <001f01bfaeb2$3bc2d820$0102a8c0@home.com> Message-ID: On Tue, 25 Apr 2000, THOMAS PASSIN wrote: >... > I think other newcomers would also find it to be a good thing. > Let's keep xmllib. Keep it in the Python distro (Lib/xmllib.py). Nuke it from the XML-SIG release. We've already said before that the duplicate is unmaintained and has no hope of replacing the standard distro version. Apparently, it doesn't really offer anything over the standard distro. (but I dunno on this) Cheers, -g -- Greg Stein, http://www.lyra.org/ From tpassin@idsonline.com Wed Apr 26 13:29:13 2000 From: tpassin@idsonline.com (THOMAS PASSIN) Date: Wed, 26 Apr 2000 08:29:13 -0400 Subject: [XML-SIG] Python 1.6 and XML References: Message-ID: <00c401bfaf7b$088a9000$0102a8c0@home.com> Greg Stein said. about xmllib - > And recall, we're talking about the XML-SIG version of xmllib.py. The one > in the standard Python distro will remain. Yes, I didn't mean to keep two versions, just to make sure that one of them remains in the standard distribution. Tom Passin From larsga@garshol.priv.no Wed Apr 26 13:36:14 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 26 Apr 2000 14:36:14 +0200 Subject: [XML-SIG] Python 1.6 and XML In-Reply-To: References: Message-ID: * THOMAS PASSIN | | I think other newcomers would also find it to be a good thing. | Let's keep xmllib. * Lars Marius Garshol | | That requires a maintainer. But I suppose that regardless of what | the XML-SIG does, someone can assume responsibility for xmllib and | keep maintaining it. * Greg Stein | | Who? Are you volunteering? No, I was just telling Thomas (and anyone else who might volunteer) that we would need a maintainer... | And recall, we're talking about the XML-SIG version of xmllib.py. | The one in the standard Python distro will remain. Ah, I didn't catch that. Then I too think it should go. --Lars M. From l.szyster@ibm.net Wed Apr 26 14:58:27 2000 From: l.szyster@ibm.net (Laurent Szyster) Date: Wed, 26 Apr 2000 15:58:27 +0200 Subject: [XML-SIG] XML Schema and e-commerce References: <39058644.F30D193C@ibm.net> <3905F10A.B62E4095@prescod.net> Message-ID: <3906F603.FCB6543F@ibm.net> Paul Prescod wrote: > > People will get together, and will define reasonable, maintainable > document structures because e-commerce cannot afford to fail. Yet, the fact that e-commerce cannot afford poor standardization does not make the process of standard definition more efficient. Also, "reasonable, maintainable document structures" is a myth. One data model won't fit all applications. Specially on the Internet where _all_ applications can exchange data. IMHO, small companies will continue to implement only subsets of the standard documents. Just enough to do business with their trading partners _today_. And large players will continue to force small ones to use their own "flavour" of the standards. EDI (EDIFACT, X12, ...) standards have been around for a while now. Knowing that there is no such thing as a universal data model, why on earth should people invest in a new unproven standard? People can benefit from XML features (like UNICODE) and the availability of commodity software for it by translating EDI messages into XML. That's a lot faster than waiting for BizTalk (or somebody else) to come up with a working standard. Laurent Szyster ___ Consultant WISE s.c. From ken@bitsko.slc.ut.us Wed Apr 26 18:23:03 2000 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 26 Apr 2000 12:23:03 -0500 Subject: [XML-SIG] XML namespaces and Python attributes Message-ID: This was a random thought that came up during a discussion of RDF and namespace support in languages: since XML uses/supports a model of mixing namespaces at the object attribute level, can/should we look into supporting that with first-class syntax in languages? We used Python as an example: rdf = 'http://www.w3.org/TR/RDF/' my_description = some_item.rdf:description and an unaliased syntax: my_description = some_item.{http://www.w3.org/TR/RDF/}description Internal implementation would use tuples as we've discussed here before. The same syntax could possibly be used as indexes as well, so the following would all be synonomous: namespace = 'someURI' dict[(namespace, 'localname')] dict[namespace:localname] dict[{someURI}localname] (The conflict of syntax with ranges is noted, some other special character would likely need to be used.) -- Ken From ping_ll@yahoo.com Thu Apr 27 03:01:07 2000 From: ping_ll@yahoo.com (Ping Lee) Date: Wed, 26 Apr 2000 20:01:07 -0600 Subject: [XML-SIG] Web Site Translation for Ligand-Protein Docking Message-ID: <20000427010132.NCVZ1339.mtiwmhc21.worldnet.att.net@b> From: Ping Lee To: Ligand-Protein Docking Date: April 26, 2000 Dear Web Manager, I visited your Web site at http://www.scripps.edu/pub/olson-web/people/gmm and would like to let you know that your Web site could also be presented in other languages for broader recognition. If you feel that my suggestion has no value, please kindly ignore this message and accept my apology. According to research done by International Data Corporation, non-English speaking users will make up over 50% of the total online population by 2002, and 70% by 2004. Business Web users are three times more likely to buy when addressed in their own languages (survey by Forrester Research). We specialize in Web Site Translation and Global URL Submission in 11 languages - English, Spanish, French, German, Italian, Portuguese, Dutch, Traditional Chinese, Simplified Chinese, Japanese and Korean. Our customized service package includes: 1. Web page translation and Web programming localization -- We not only convert HTML pages and graphics, but also ensure that the translated Web sites fully function in the target language environment. 2. URL submission and re-submission to leading search engines and business directories in the target languages -- Our Web promotion specialists optimize the keywords and descriptions of the translated Web sites for ideal search engine rankings. 3. Company profile translation and a free listing in GlobalListing, a multi-language business directory. 4. Six-month maintenance program -- Web site updates, email translation, and unlimited technical support. The translation is conducted by our professional translators who are native speakers and have years of Web translation experience. We are not hired for the ability to take a word in one language and convert it into an equivalent word in another language. Instead, we get to the heart of communication and express the true meaning of your message, because we are aware that improper translation may cause unrecoverable damages to your company's image. At GlobalListing, we are in the business of ensuring that you are 100% satisfied with our quality services. Thank you very much for your time. Should you be interested in our services, please contact me for a free estimate or any further information. Best regards, Ping Lee Director, Web Translation GlobalListing Phone: (604) 324-4638 Fax: (413) 431-2597 Office Hour: 9:00AM - 5:00PM (Pacific Time) From alwagner@tcac.net Thu Apr 27 02:45:07 2000 From: alwagner@tcac.net (Albert Wagner) Date: Wed, 26 Apr 2000 20:45:07 -0500 Subject: [XML-SIG] *.tex files in dist Message-ID: <39079BA3.E99CD981@tcac.net> Can someone help a newbie print the *.tex files in the PyXML dist? They don't seem to be standard tex files to pdftex/pdflatex. -- Small is Beautiful From paul@prescod.net Thu Apr 27 03:00:57 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 26 Apr 2000 21:00:57 -0500 Subject: [XML-SIG] XML namespaces and Python attributes References: Message-ID: <39079F59.71EC576F@prescod.net> Ken MacLeod wrote: > > ... > We used > Python as an example: > > rdf = 'http://www.w3.org/TR/RDF/' > my_description = some_item.rdf:description > > and an unaliased syntax: > > my_description = some_item.{http://www.w3.org/TR/RDF/}description I've been thinking about a pseudo-RDF implementation and my thoughts about syntax were: some_item["http://www.w3.org/TR/RDF/prop"]["http://www.w3.org/TR/RDF/prop"][5] and of course: some_item[rdf+"/prop"][rdf+"/prop"] Of course this would only apply to specially-designed objects that support RDF-based getitem. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From akuchlin@mems-exchange.org Thu Apr 27 03:08:22 2000 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 26 Apr 2000 22:08:22 -0400 (EDT) Subject: [XML-SIG] Python 1.6a2 Unicode experiences? Message-ID: <200004270208.WAA01413@newcnri.cnri.reston.va.us> Has anyone here tried to use the new Unicode support in Python 1.6a2? The XML-SIG's readership seems likely to have a use for Unicode, so perhaps people here have tried the new code. I'm asking because there are lengthy debates about the 1.6a2 Unicode support on the python-dev list at the moment, and I thought that hearing from actual users would be helpful in resolving the issues. --amk From paul@prescod.net Thu Apr 27 06:30:00 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 27 Apr 2000 00:30:00 -0500 Subject: [XML-SIG] XML Schema and e-commerce References: <39058644.F30D193C@ibm.net> <3905F10A.B62E4095@prescod.net> <3906F603.FCB6543F@ibm.net> Message-ID: <3907D058.D95BCC38@prescod.net> Laurent Szyster wrote: > > Paul Prescod wrote: > > > > People will get together, and will define reasonable, maintainable > > document structures because e-commerce cannot afford to fail. > > Yet, the fact that e-commerce cannot afford poor standardization > does not make the process of standard definition more efficient. Infinitely efficient, no, but motivation does tend to improve efficiency. > Also, "reasonable, maintainable document structures" is a myth. Do you have any evidence of that? We have applications based on "maintainable document structures" that have been running for almost a decade now. > One data model won't fit all applications. That's right. That's *why* you use schema languages, so you can have different vocabularies based on different data models! > EDI (EDIFACT, X12, ...) standards have been around for a while now. > Knowing that there is no such thing as a universal data model, why > on earth should people invest in a new unproven standard? Because the existing one is considered broken. Your argument seems to be "perfection is impossible therefore it is not worth trying to improve at all." > People can benefit from XML features (like UNICODE) and the > availability of commodity software for it by translating EDI > messages into XML. If you translate EDI messages into XML, how do you express the XML structures? That's what schema languages are for. > That's a lot faster than waiting for BizTalk > (or somebody else) to come up with a working standard. Biztalk isn't a schema language. If you're arguing against Biztalk then be my guest. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From andy@reportlab.com Thu Apr 27 11:28:38 2000 From: andy@reportlab.com (Andy Robinson) Date: Thu, 27 Apr 2000 11:28:38 +0100 Subject: [XML-SIG] Python 1.6a2 Unicode experiences? References: <200004270208.WAA01413@newcnri.cnri.reston.va.us> Message-ID: <001c01bfb033$96bf66d0$01ac2ac0@boulder> ----- Original Message ----- From: Andrew Kuchling To: Sent: 27 April 2000 03:08 Subject: [XML-SIG] Python 1.6a2 Unicode experiences? > Has anyone here tried to use the new Unicode support in Python 1.6a2? > The XML-SIG's readership seems likely to have a use for Unicode, so > perhaps people here have tried the new code. > > I'm asking because there are lengthy debates about the 1.6a2 Unicode > support on the python-dev list at the moment, and I thought that > hearing from actual users would be helpful in resolving the issues. > > --amk I've played with it, but my job took a turn away from dealing with Asian data in February so I have not used it in anger. However, XML is going to matter a lot to ReportLab and I played a part in shaping the spec. I think (it's hard to follow) that the current discussion is about whether literal strings and source files should be treated as UTF-8 or Latin-1. Some people with little practical i18n experience note that Tcl and Perl have only one string type, and it just became UTF-8, so we should do the same thing. I disagree. I think our proposal is BETTER than Java, Tcl, Visual Basic etc for the following reasons: - you can work with old fashioned strings, which are understood by everyone to be arrays of bytes, and there is no magic conversion going on. The bytes in literal strings in your script file are the bytes that end up in the program. - you can work with Unicode strings if you want - you are in explicit control of conversions between them - both types have similar methods so there isn't much to learn or remember These give us all the tools we need. If you are writing an XML parser you would only need one line of code to say "this file is UTF-8, so let's treat it accordingly, and work in Unicode internally". I'm also convinced that the majority of Python scripts won't need to work in Unicode. Even working with exotic languages, there is always a native 8-bit encoding. I have only used Unicode when (a) working with data that is in several languages (b) doing conversions, which requires a 'central point' (b) wanting to do per-character operations safely on multi-byte data I still haven't sorted out in my head whether the default encoding thing is a big red herring or is important; I already have a safe way to construct Unicode literals in my source files if I want to using unicode('rawdata','myencoding'). But if there has to be one I'd say the following: - strict ASCII is an option - Latin-1 is the more generous option that is right for the most people, and has a 'special status' among 8-bit encodings - UTF-8 is not one byte per character and will confuse people Just my 2p worth, Andy > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig > From shecter@darmstadt.gmd.de Thu Apr 27 15:59:56 2000 From: shecter@darmstadt.gmd.de (Robb Shecter) Date: Thu, 27 Apr 2000 16:59:56 +0200 Subject: [XML-SIG] *.tex files in dist References: <39079BA3.E99CD981@tcac.net> Message-ID: <390855EC.6EFE705A@darmstadt.gmd.de> Albert Wagner wrote: > > Can someone help a newbie print the *.tex files in the PyXML dist? Ditto. They apparently need a document class that's not included in the distribution. Anybody know where it is? - Robb From akuchlin@mems-exchange.org Thu Apr 27 15:57:27 2000 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Thu, 27 Apr 2000 10:57:27 -0400 (EDT) Subject: [XML-SIG] *.tex files in dist In-Reply-To: <390855EC.6EFE705A@darmstadt.gmd.de> References: <39079BA3.E99CD981@tcac.net> <390855EC.6EFE705A@darmstadt.gmd.de> Message-ID: <14600.21847.388752.80873@amarok.cnri.reston.va.us> Robb Shecter writes: >Albert Wagner wrote: >> >> Can someone help a newbie print the *.tex files in the PyXML dist? > >Ditto. They apparently need a document class that's not included in the >distribution. Anybody know where it is? It's part of the TeX material that comes with the Python documentation, so you'd have to download the LaTeX source for the Python docs from http://www.python.org/ftp/python/doc/1.5.2p1/. --amk From shecter@darmstadt.gmd.de Thu Apr 27 16:11:46 2000 From: shecter@darmstadt.gmd.de (Robb Shecter) Date: Thu, 27 Apr 2000 17:11:46 +0200 Subject: [XML-SIG] Schema + python examples? Message-ID: <390858B2.C0F1A7CD@darmstadt.gmd.de> Hi, Has anyone done anything with (say, w3c-spec) schemas and python? I'm working on a project, and it's be great to get some pointers to some examples of what others have done. FWIW, I'm working on a system that analyzes a metadata description and builds up a Prolog database with element containment information. I've got this working with DTDs, but I want to make use of namespaces. - Robb From alwagner@tcac.net Thu Apr 27 18:05:39 2000 From: alwagner@tcac.net (Albert Wagner) Date: Thu, 27 Apr 2000 12:05:39 -0500 Subject: [XML-SIG] *.tex files in dist References: <39079BA3.E99CD981@tcac.net> Message-ID: <39087363.695853DC@tcac.net> For those who are seriously Latex impaired like myself. Here is how I got xml-howto.tex and xml-ref.tex printed out: 1) They appear to need helper files available in another download from: http://www.python.org/ftp/python/doc/1.5.2p1/ (thanks to Andrew Kuchling) download file: latex-1.5.2p1.tgz and unpack. The xml*.tex files must be in the same directory with the files in Python-1.5.2p1/texinputs(just unpacked). 2) run: $ pdflatex xml-howto.tex #if it hollers, answer q $ pdflatex xml-ref.tex There should now be two pdf files in the same directory which acroreader can print. I know that this is probably not cool, but it worked for me. -- Small is Beautiful From fdrake@acm.org Thu Apr 27 19:54:06 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 27 Apr 2000 14:54:06 -0400 (EDT) Subject: [XML-SIG] *.tex files in dist In-Reply-To: <39087363.695853DC@tcac.net> References: <39079BA3.E99CD981@tcac.net> <39087363.695853DC@tcac.net> Message-ID: <14600.36046.894152.976304@seahag.cnri.reston.va.us> Albert Wagner writes: > For those who are seriously Latex impaired like myself. Here is how I > got xml-howto.tex and xml-ref.tex printed out: This will all be much easier by the time Python 1.6 is released. I hope to have a "tools" package available that can be used by authors of Python "How-To" documents (or manuals) that makes it a lot easier to deal with this stuff. I'm sorry for it being so confusing! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From larsga@garshol.priv.no Thu Apr 27 21:30:12 2000 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 27 Apr 2000 22:30:12 +0200 Subject: [XML-SIG] Schema + python examples? In-Reply-To: <390858B2.C0F1A7CD@darmstadt.gmd.de> References: <390858B2.C0F1A7CD@darmstadt.gmd.de> Message-ID: * Robb Shecter | | Has anyone done anything with (say, w3c-spec) schemas and python? I'm | working on a project, and it's be great to get some pointers to some | examples of what others have done. As a learning exercise (and test of my own APIs) I did a DTD to schema converter, which does basic attribute group reverse engineering. I plan to release this with xmlproc 0.70. --Lars M. From uogbuji@fourthought.com Thu Apr 27 05:39:12 2000 From: uogbuji@fourthought.com (Uche Ogbuji) Date: Wed, 26 Apr 2000 22:39:12 -0600 Subject: [XML-SIG] Python 1.6a2 Unicode experiences? In-Reply-To: Message from Andrew Kuchling of "Wed, 26 Apr 2000 22:08:22 EDT." <200004270208.WAA01413@newcnri.cnri.reston.va.us> Message-ID: <200004270439.WAA01521@localhost.localdomain> > I'm asking because there are lengthy debates about the 1.6a2 Unicode > support on the python-dev list at the moment, and I thought that > hearing from actual users would be helpful in resolving the issues. Looking at 1.6a2 is on my impossibly-long to-do list, so no luck, but I am terribly curious as to exactly what the debate is about. -- Uche Ogbuji Senior Software Engineer uche.ogbuji@fourthought.com +01 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-9036, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python From alwagner@tcac.net Fri Apr 28 00:41:30 2000 From: alwagner@tcac.net (Albert Wagner) Date: Thu, 27 Apr 2000 18:41:30 -0500 Subject: [XML-SIG] *.tex files in dist References: <39079BA3.E99CD981@tcac.net> <39087363.695853DC@tcac.net> <14600.36046.894152.976304@seahag.cnri.reston.va.us> Message-ID: <3908D02A.8F72BC4@tcac.net> No need for apologies, Fred. I learn something new everytime I have a problem. This isn't the first or last time I've had to deal with *.tex files. I need to learn Latex anyway. -- Small is Beautiful From paul@prescod.net Fri Apr 28 03:21:44 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 27 Apr 2000 21:21:44 -0500 Subject: [XML-SIG] Python 1.6a2 Unicode experiences? References: <200004270208.WAA01413@newcnri.cnri.reston.va.us> <001c01bfb033$96bf66d0$01ac2ac0@boulder> Message-ID: <3908F5B8.9F8D8A9A@prescod.net> Andy Robinson wrote: > > - you can work with old fashioned strings, which are understood > by everyone to be arrays of bytes, and there is no magic > conversion going on. The bytes in literal strings in your script file > are the bytes that end up in the program. Who is "everyone"? Are you saying that CP4E hordes are going to understand that the syntax "abcde" is constructing a *byte array*? It seems like you think that Python users are going to be more sophisticated in their understanding of these issues than Java programmers. In most other things, Python is simpler. > ... > > I'm also convinced that the majority of Python scripts won't need > to work in Unicode. Anything working with XML will need to be Unicode. Anything working with the Win32 API (especially COM) will want to do Unicode. Over time the entire Web infrastructure will move to Unicode. Anything written in JPython pretty much MOST use Unicode (doesn't it?). > Even working with exotic languages, there is always a native > 8-bit encoding. Unicode has many encodings: Shift-JIS, Big-5, EBCDIC ... You can use 8-bit encodings of Unicode if you want. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From petrilli@amber.org Fri Apr 28 05:12:29 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Fri, 28 Apr 2000 00:12:29 -0400 Subject: [Python-Dev] Re: [XML-SIG] Python 1.6a2 Unicode experiences? In-Reply-To: <3908F5B8.9F8D8A9A@prescod.net>; from paul@prescod.net on Thu, Apr 27, 2000 at 09:21:44PM -0500 References: <200004270208.WAA01413@newcnri.cnri.reston.va.us> <001c01bfb033$96bf66d0$01ac2ac0@boulder> <3908F5B8.9F8D8A9A@prescod.net> Message-ID: <20000428001229.A4790@trump.amber.org> Paul Prescod [paul@prescod.net] wrote: > > I'm also convinced that the majority of Python scripts won't need > > to work in Unicode. > > Anything working with XML will need to be Unicode. Anything working with > the Win32 API (especially COM) will want to do Unicode. Over time the > entire Web infrastructure will move to Unicode. Anything written in > JPython pretty much MOST use Unicode (doesn't it?). I disagree with this. Unicode has been a very long time, and it's not been adopted by a lot of people for a LOT of very valid reasons. > > Even working with exotic languages, there is always a native > > 8-bit encoding. > > Unicode has many encodings: Shift-JIS, Big-5, EBCDIC ... You can use > 8-bit encodings of Unicode if you want. Um, if you go: JIS -> Unicode -> JIS you don't get the same thing out that you put in (at least this is what I've been told by a lot of Japanese developers), and therefore it's not terribly popular because of the nature of the Japanese (and Chinese) langauge. My experience with Unicode is that a lot of Western people think it's the answer to every problem asked, while most asian language people disagree vehemently. This says the problem isn't solved yet, even if people wish to deny it. Chris -- | Christopher Petrilli | petrilli@amber.org From mal@lemburg.com Fri Apr 28 10:39:37 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 28 Apr 2000 11:39:37 +0200 Subject: [Python-Dev] Re: [XML-SIG] Python 1.6a2 Unicode experiences? References: <200004270208.WAA01413@newcnri.cnri.reston.va.us> <001c01bfb033$96bf66d0$01ac2ac0@boulder> <3908F5B8.9F8D8A9A@prescod.net> <20000428001229.A4790@trump.amber.org> Message-ID: <39095C59.A5916EEB@lemburg.com> [Note: These discussion should all move to 18n-sig... CCing there] Christopher Petrilli wrote: > > Paul Prescod [paul@prescod.net] wrote: > > > Even working with exotic languages, there is always a native > > > 8-bit encoding. > > > > Unicode has many encodings: Shift-JIS, Big-5, EBCDIC ... You can use > > 8-bit encodings of Unicode if you want. > > Um, if you go: > > JIS -> Unicode -> JIS > > you don't get the same thing out that you put in (at least this is > what I've been told by a lot of Japanese developers), and therefore > it's not terribly popular because of the nature of the Japanese (and > Chinese) langauge. > > My experience with Unicode is that a lot of Western people think it's > the answer to every problem asked, while most asian language people > disagree vehemently. This says the problem isn't solved yet, even if > people wish to deny it. Isn't this a problem of the translation rather than Unicode itself (Andy mentioned several times that you can use the private BMP areas to implement 1-1 round-trips) ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From tree@basistech.com Fri Apr 28 11:56:50 2000 From: tree@basistech.com (Tom Emerson) Date: Fri, 28 Apr 2000 06:56:50 -0400 (EDT) Subject: [I18n-sig] Re: [Python-Dev] Re: [XML-SIG] Python 1.6a2 Unicode experiences? In-Reply-To: <39095C59.A5916EEB@lemburg.com> References: <200004270208.WAA01413@newcnri.cnri.reston.va.us> <001c01bfb033$96bf66d0$01ac2ac0@boulder> <3908F5B8.9F8D8A9A@prescod.net> <20000428001229.A4790@trump.amber.org> <39095C59.A5916EEB@lemburg.com> Message-ID: <14601.28274.667733.660938@cymru.basistech.com> M.-A. Lemburg writes: > > > Unicode has many encodings: Shift-JIS, Big-5, EBCDIC ... You can use > > > 8-bit encodings of Unicode if you want. This is meaningless: legacy encodings of national character sets such Shift-JIS, Big Five, GB2312, or TIS620 are not "encodings" of Unicode. TIS620 is a single-byte, 8-bit encoding: each character is represented by a single byte. The Japanese and Chinese encodings are multibyte, 8-bit, encodings. ISO-2022 is a multi-byte, 7-bit encoding for multiple character sets. Unicode has several possible encodings: UTF-8, UCS-2, UCS-4, UTF-16... You can view all of these as 8-bit encodings, if you like. Some are multibyte (such as UTF-8, where each character in Unicode is represented in 1 to 3 bytes) while others are fixed length, two or four bytes per character. > > Um, if you go: > > > > JIS -> Unicode -> JIS > > > > you don't get the same thing out that you put in (at least this is > > what I've been told by a lot of Japanese developers), and therefore > > it's not terribly popular because of the nature of the Japanese (and > > Chinese) langauge. This is simply not true any more. The ability to round trip between Unicode and legacy encodings is dependent on the software: being able to use code points in the PUA for this is acceptable and commonly done. The big advantage is in using Unicode as a pivot when transcoding between different CJK encodings. It is very difficult to map between, say, Shift JIS and GB2312, directly. However, Unicode provides a good go-between. It isn't a panacea: transcoding between legacy encodings like GB2312 and Big Five is still difficult: Unicode or not. > > My experience with Unicode is that a lot of Western people think it's > > the answer to every problem asked, while most asian language people > > disagree vehemently. This says the problem isn't solved yet, even if > > people wish to deny it. This is a shame: it is an indication that they don't understand the technology. Unicode is a tool: nothing more. -tree -- Tom Emerson Basis Technology Corp. Language Hacker http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From fredrik@pythonware.com Fri Apr 28 13:15:06 2000 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 28 Apr 2000 14:15:06 +0200 Subject: [Python-Dev] Re: [XML-SIG] Python 1.6a2 Unicode experiences? References: <200004270208.WAA01413@newcnri.cnri.reston.va.us> <001c01bfb033$96bf66d0$01ac2ac0@boulder> <3908F5B8.9F8D8A9A@prescod.net> <20000428001229.A4790@trump.amber.org> <39095C59.A5916EEB@lemburg.com> Message-ID: <00d101bfb10b$68585800$0500a8c0@secret.pythonware.com> Christopher Petrilli wrote: >=20 > Paul Prescod [paul@prescod.net] wrote: > > > Even working with exotic languages, there is always a native > > > 8-bit encoding. > > > > Unicode has many encodings: Shift-JIS, Big-5, EBCDIC ... You can use > > 8-bit encodings of Unicode if you want. >=20 > Um, if you go: >=20 > JIS -> Unicode -> JIS >=20 > you don't get the same thing out that you put in (at least this is > what I've been told by a lot of Japanese developers), and therefore > it's not terribly popular because of the nature of the Japanese (and > Chinese) langauge. >=20 > My experience with Unicode is that a lot of Western people think it's > the answer to every problem asked, while most asian language people > disagree vehemently. This says the problem isn't solved yet, even if > people wish to deny it. this is partly true, partly caused by a confusion over what unicode really is. there are at least two issues involved here: * the unicode character repertoire is not complete unicode contains all characters from the basic JIS X character sets (please correct me if I'm wrong), but it doesn't include all characters in common use in Japan. as far as I've understood, this is mostly personal names and trade names. however, different vendors tend to use different sets, with different encodings, and there has been no consensus on which to add, and how. so in other words, if you're "transcoding" from one encoding to another (when converting data, or printing or displaying on a device assuming a different encoding), unicode isn't good enough. as MAL pointed out, you can work around this by using custom codecs, mapping the vendor specific characters that you happen to use to private regions in the unicode code space. but afaik, there is no standard way to do that at this time. (this probably applies to other "CJK languages" too. if anyone could verify that, I'd be grateful). * unicode is about characters, not languages if you have a unicode string, you still don't know how to display it. the string tells you what characters to use, not what language the text is written in. and while using one standard "glyph" per unicode character works pretty well for latin characters (no, it's not perfect, but it's not much of a problem in real life), it doesn't work for asian languages. you need extra language/locale information to pick the right glyph for any given unicode character. and the crux is that before unicode, this wasn't really a problem -- if you knew the encoding, you knew what language to use. when using unicode, you need to put that information somewhere else (in an XML attribute, for example). * corrections and additions are welcome, of course. From guido@python.org Fri Apr 28 14:24:29 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 28 Apr 2000 09:24:29 -0400 Subject: [Python-Dev] Re: [XML-SIG] Python 1.6a2 Unicode experiences? In-Reply-To: Your message of "Fri, 28 Apr 2000 11:39:37 +0200." <39095C59.A5916EEB@lemburg.com> References: <200004270208.WAA01413@newcnri.cnri.reston.va.us> <001c01bfb033$96bf66d0$01ac2ac0@boulder> <3908F5B8.9F8D8A9A@prescod.net> <20000428001229.A4790@trump.amber.org> <39095C59.A5916EEB@lemburg.com> Message-ID: <200004281324.JAA15642@eric.cnri.reston.va.us> > [Note: These discussion should all move to 18n-sig... CCing there] > > Christopher Petrilli wrote: > > you don't get the same thing out that you put in (at least this is > > what I've been told by a lot of Japanese developers), and therefore > > it's not terribly popular because of the nature of the Japanese (and > > Chinese) langauge. > > > > My experience with Unicode is that a lot of Western people think it's > > the answer to every problem asked, while most asian language people > > disagree vehemently. This says the problem isn't solved yet, even if > > people wish to deny it. [Marc-Andre Lenburg] > Isn't this a problem of the translation rather than Unicode > itself (Andy mentioned several times that you can use the private > BMP areas to implement 1-1 round-trips) ? Maybe, but apparently such high-quality translations are rare (note that Andy said "can"). Anyway, a word of caution here. Years ago I attended a number of IETF meetings on internationalization, in a time when Unicode wasn't as accepted as it is now. The one thing I took away from those meetings was that this is a *highly* emotional and controversial issue. As the Python community, I feel we have no need to discuss "why Unicode." Therein lies madness, controversy, and no progress. We know there's a clear demand for Unicode, and we've committed to support it. The question now at hand is "how Unicode." Let's please focus on that, e.g. in the other thread ("Unicode debate") in i18n-sig and python-dev. --Guido van Rossum (home page: http://www.python.org/~guido/) From Johan.De-Smedt@village.uunet.be Sun Apr 30 22:57:00 2000 From: Johan.De-Smedt@village.uunet.be (Johan De Smedt) Date: Sun, 30 Apr 2000 23:57:00 +0200 Subject: [XML-SIG] Windows install problems Message-ID: <01BFB306.0859C5E0@JOHAN> Hi, I've had the following problem while trying to install the python xml package on windows NT: =========== D:\users\Jo\Python\xml\PyXML-0.5.4>python setup.py build Executing 'build' action... D:\users\Jo\Python\xml\PyXML-0.5.4>python setup.py install Executing 'build' action... Executing 'install' action... Traceback (innermost last): File "setup.py", line 185, in ? func() File "setup.py", line 174, in install_unix copytree('build/xml', dest_dir) File "setup.py", line 105, in copytree os.mkdir(dst) OSError: [Errno 2] No such file or directory: 'd:\\Program Files\\Python/lib/pyt hon1.5/site-packages/xml/' D:\users\Jo\Python\xml\PyXML-0.5.4> ============== Can you give me the rigth pointers - thanks. Johan De Smedt