From fredrik@pythonware.com Mon Feb 1 08:57:21 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 1 Feb 1999 09:57:21 +0100 Subject: [XML-SIG] Python 1.5.2b1's xmllib.py Considered Harmful Message-ID: <002b01be4dc0$e2743a00$f29b12c2@pythonware.com> This is a multi-part message in MIME format. ------=_NextPart_000_0026_01BE4DC9.42E0DA30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I wrote: >xmllib.py currently got a completely new interface in 1.5.2b1. >The new interface silently breaks all existing implementations >(it no longer calls start and end handlers), something that has >caused us a LOT of trouble lately. For example, our highly >successful xmlrpclib.py implementation doesn't work at all >under 1.5.2b1. The attached patch solves some of the compatibility problems introduced by the new xmllib.py. The most important change is that it now preloads the elements dictionary with pointers to any "start" and "end" handlers defined by subclasses, like earlier versions. It also adds some code to avoid cyclic references and unexpected modifications to the elements dictionary. With this in place, xmlrpclib.py works just fine also with the new version of xmllib.py. Cheers /F fredrik@pythonware.com http://www.pythonware.com ------=_NextPart_000_0026_01BE4DC9.42E0DA30 Content-Type: application/octet-stream; name="patch1" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch1" *** r:\BleedingEdge\python\dist\src\Lib\xmllib.py Mon Dec 28 15:38:03 1998 --- xmllib.py Mon Feb 01 09:36:26 1999 *************** *** 90,95 **** --- 90,132 ---- def __init__(self): self.reset() + # duplicate class dictionaries + self.attributes = self.attributes.copy() + self.elements = self.elements.copy() + + # COMPATIBILITY: find all start and end handlers and add them + # to the elements dictionary. Don't override already installed + # versions. + self.__preload(self.__class__) + + def __preload(self, cls): + # find all start/end handlers declared by this class + for event in dir(cls): + # look for start and end tag handlers + if event[:6] == "start_": + tag = event[6:] + elif event[:4] == "end_": + tag = event[4:] + else: + continue + # don't override already installed handlers + if self.elements.has_key(tag): + continue + # fetch start and end handlers. use None for + # missing handlers + try: + start = getattr(self, "start_" + tag) + except AttributeError: + start = None + try: + end = getattr(self, "end_" + tag) + except AttributeError: + end = None + self.elements[tag] = (start, end) + # check base classes + for base in cls.__bases__: + self.__preload(base) + # Interface -- reset this instance. Loses all unprocessed data def reset(self): self.rawdata = '' *************** *** 122,127 **** --- 159,165 ---- # Interface -- handle the remaining data def close(self): self.goahead(1) + self.elements = {} # nuke potential cyclic reference # Interface -- translate references def translate_references(self, data, all = 1): ------=_NextPart_000_0026_01BE4DC9.42E0DA30-- From stuart.hungerford@webone.com.au Mon Feb 1 23:21:44 1999 From: stuart.hungerford@webone.com.au (Stuart Hungerford) Date: Tue, 2 Feb 1999 10:21:44 +1100 Subject: [XML-SIG] Industrial-strength XML to HTML conversion? Message-ID: <004001be4e39$a1ffa260$0301a8c0@restless.com> Hi all, I'd like to start using XML for creating/editing website content. Has anyone on the list had experiences in doing this in a production environment they could share with us? I'm not quite sure which is the best approach to take with the current crop of web browsers: - Convert XML to HTML using custom conversion scripts and fixed presentation - Convert XML to HTML+CSS, but using CSS classes etc - Convert XML + XSL stylesheet to HTML with some kind of XSL tool Can anyone tell me if I'm on the right path here? Stu From mazito@softlab.com.ar Wed Feb 3 16:38:02 1999 From: mazito@softlab.com.ar (Mario A. Zito) Date: Wed, 03 Feb 1999 13:38:02 -0300 Subject: [XML-SIG] Re: Industrial-strength XML to HTML conversion? References: <199902021702.MAA25478@python.org> Message-ID: <36B87B6A.7348EE36@softlab.com.ar> > From: "Stuart Hungerford" > I'd like to start using XML for creating/editing website content. Has > anyone on the list had experiences in doing this in a production > environment they could share with us? > > I'm not quite sure which is the best approach to take with the current > crop of web browsers: > > - Convert XML to HTML using custom conversion scripts and fixed > presentation > - Convert XML to HTML+CSS, but using CSS classes etc > - Convert XML + XSL stylesheet to HTML with some kind of XSL tool > > Can anyone tell me if I'm on the right path here? > > Stu I am dealing with a similar situation now, IMHO the XML+XSL style sheet option will be better as a long term solution. I think that Microsoft XSL processor is free (at least for now) and can do exactly that job. As far as I know that is the way they are using to render XML. Bye. From remarbach@yahoo.com Thu Feb 4 20:58:15 1999 From: remarbach@yahoo.com (Randall Marbach) Date: Thu, 4 Feb 1999 12:58:15 -0800 (PST) Subject: [XML-SIG] pyDOM examples Message-ID: <19990204205815.15970.rocketmail@send1e.yahoomail.com> Can anybody point me to a good source of pyDOM examples? I'm a newby to pyDOM and XML and have been struggling with the documentation that comes with xml-0.5 Any help would be deeply appreciated. TIA Randy _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From jfarr@real.com Sat Feb 6 01:21:21 1999 From: jfarr@real.com (Jonothan Farr) Date: Fri, 5 Feb 1999 17:21:21 -0800 Subject: [XML-SIG] Python SMIL parser Message-ID: <0c6101be516f$01697220$eb0210ac@two235.dev.prognet.com> I have created a validating SMIL parser based on the Python 1.5.1 xmllib library. I have also created a library called xmlvlib, which contains a class called ValidatingXMLParser. SMILParser is derived from ValidatingXMLParser, which is derived from xmllib.XMLParser. The xmlvlib is very much a work in progress. It works well enough for the SMIL DTD, and should work well enough for most applications. I also intend to write a library to produce a validating parser derived class from a DTD. SMIL parser: http://www.speakeasy.org/~jfarr/xml/smillib.py Validating XML parser: http://www.speakeasy.org/~jfarr/xml/xmlvlib.py Please direct any questions or comments to: jfarr@speakeasy.org Thank you, Jonothan Farr From larsga@ifi.uio.no Sat Feb 6 09:09:30 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: 06 Feb 1999 10:09:30 +0100 Subject: [XML-SIG] Python SMIL parser In-Reply-To: <0c6101be516f$01697220$eb0210ac@two235.dev.prognet.com> References: <0c6101be516f$01697220$eb0210ac@two235.dev.prognet.com> Message-ID: * Jonothan Farr | | The xmlvlib is very much a work in progress. It works well enough | for the SMIL DTD, and should work well enough for most | applications. I also intend to write a library to produce a | validating parser derived class from a DTD. This is nice, but I hope you are aware that we already have validating parser written in Python: xmlproc. The current version does not handle parameter entities inside declarations, but the version I'm currently working on does. In fact, I would have released this version already, if it hadn't been for a memory leak in the SAX driver. --Lars M. From gstein@lyra.org Sat Feb 6 10:08:40 1999 From: gstein@lyra.org (Greg Stein) Date: Sat, 6 Feb 1999 02:08:40 -0800 (PST) Subject: [XML-SIG] Python SMIL parser In-Reply-To: Message-ID: IMO, nothing wrong with having more than one validating parser... On 6 Feb 1999, Lars Marius Garshol wrote: > * Jonothan Farr > | > | The xmlvlib is very much a work in progress. It works well enough > | for the SMIL DTD, and should work well enough for most > | applications. I also intend to write a library to produce a > | validating parser derived class from a DTD. > > This is nice, but I hope you are aware that we already have validating > parser written in Python: xmlproc. The current version does not handle > parameter entities inside declarations, but the version I'm currently > working on does. In fact, I would have released this version already, > if it hadn't been for a memory leak in the SAX driver. > > > > --Lars M. -- Greg Stein, http://www.lyra.org/ From larsga@ifi.uio.no Sat Feb 6 10:20:40 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: 06 Feb 1999 11:20:40 +0100 Subject: [XML-SIG] Python SMIL parser In-Reply-To: References: Message-ID: * Greg Stein | | IMO, nothing wrong with having more than one validating parser... Indeed, it would be much better than having just one. It would probably inspire me to improve my parser more than I otherwise would, and at the same time it would make Python an even more attractive language for doing XML work in, simply because one would have some alternatives. However, I wouldn't want Jonothan to reimplement something that already exists if that's not what he wants. If that's what he wants then I'm all for it. --Lars M. From jfarr@real.com Sun Feb 7 00:52:19 1999 From: jfarr@real.com (Jonothan Farr) Date: Sat, 6 Feb 1999 16:52:19 -0800 Subject: [XML-SIG] Re: Python SMIL parser Message-ID: <0d7e01be5234$1d2df240$eb0210ac@two235.dev.prognet.com> >This is nice, but I hope you are aware that we already have validating >parser written in Python: xmlproc. Thanks for the info. I have already downloaded and tried the xmlproc parser. I was looking for something simpler and easier to use. Originally, I just wrote the smil parser based directly on the xmllib parser, but decided to break out the xmlvlib as an exercise in code reuse. It was also a nice way for me to learn more about xml. --jfarr From larsga@ifi.uio.no Sun Feb 7 12:12:19 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: Sun, 7 Feb 1999 13:12:19 +0100 (MET) Subject: [XML-SIG] xmlproc: Version 0.60 is out! Message-ID: <199902071212.NAA24061@ifi.uio.no> xmlproc 0.60 has now been released, slightly delayed by memory leak problems, which have now finally been resolved. This version is a major improvement over the previous one, both in terms of better general support for XML and in terms of better compliance with the specification. An upgrade to the new version is recommended because of the many improvements and bug fixes. Also, the documentation has been extended and improved, and some example applications and files have been added to the distribution. xmlproc can still be found at: Enjoy! --Lars M. === Changes to xmlproc since version 0.52: --- High-level changes: - xmlproc now supports parameter entity references inside declarations. This means that support for conditional sections is now also functional. - The DTD parser object used by xmlproc is now made available to applications, and can be used separately from the rest of the package to parse DTDs. - xmlproc now supports namespaces through an external parser filter. - Conformance to the XML Recommendation has been improved. Among other things, data events are now no longer reported after well-formedness errors and default attribute values are validated when they are declared. Various bugs have also been fixed. - Error recovery is now a bit more graceful, and memory leaks have been removed. --- API changes: - xmlproc no longer reports data events after a well-formedness error, as required by the XML Recommendation. xmlproc can be told to report data events even after such errors with the set_data_after_wf_error method. - The Parser interface now has a deref method that can be called to break circular references in the parser when the object is to be garbage collected. If this method is not called the parser will not be deleted. When the method has been called the parser object becomes non-functional. - The ElementType interface now has a get_content_model method that can be used to get the content model of an element. - The Entity interface (only external entities) now has a method get_notation that can be used to get the notation of the entity. - The DTDParser interface and module has been introduced. - The namespace module has been introduced. From larsga@ifi.uio.no Sun Feb 7 14:24:32 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: 07 Feb 1999 15:24:32 +0100 Subject: [XML-SIG] Re: Python SMIL parser In-Reply-To: <0d7e01be5234$1d2df240$eb0210ac@two235.dev.prognet.com> References: <0d7e01be5234$1d2df240$eb0210ac@two235.dev.prognet.com> Message-ID: * Jonothan Farr | | Thanks for the info. I have already downloaded and tried the xmlproc | parser. I was looking for something simpler and easier to use. | Originally, I just wrote the smil parser based directly on the | xmllib parser, but decided to break out the xmlvlib as an exercise | in code reuse. Sounds like a good decision, since it can then be made completely general. I looked a bit more closely at the source now, and as far as I can see it should be possible to make a general validating parser with the approach you use. (Ie: one that doesn't need a 'precompiled' DTD.) Assuming that that is what you are trying to do, of course. Please keep us informed of your progress, and when you've come to the point where the parser can be used on any document[1] I'll write a SAX driver for it (unless you want to do that yourself). --Lars M. [1] Or before that, if anyone wants it. From uche.ogbuji@fourthought.com Mon Feb 8 13:54:35 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Mon, 08 Feb 1999 06:54:35 -0700 Subject: [XML-SIG] Announcement: 4DOM 0.7.0 Message-ID: <199902081354.GAA02885@malatesta.local> FourThought LLC (http://FourThought.com) announces the release of 4DOM 0.7.0 ----------------------- A CORBA-aware implementation of the W3C's Document Object Model in Python 4DOM is a close implementation of the DOM, including DOM Core level 1, DOM HTML level 1, Node Iterator and Node Filter from DOM Level 2, and a few utility and helper components. 4DOM was designed from the start to work in a CORBA environment, although an ORB is no longer required. For using 4DOM in an ORB environment, Fnorb and ILU are supported. 4DOM is designed to allow developers rapidly design applications that read, write or manipulate HTML and XML. New in 4DOM 0.7.0 ----------------- - Added support for "orbless" configuration. Now neither ILU nor Fnorb are requred and 4DOM can be run purely locally, but still with a consist ent interface. Naturally, the orbless config is much faster than the ilu or fnorb configs. - Many fixes to improve consistency over an ORB interface (an example using an ORB has been added to demos). - Fixes to NodeList and NamedNodeMap - Added an Ext package for DOM extensions, and moved many of the existing extensions there. See docs/Extensions.html. - Added to Ext an extensive factory interface for creation of nodes, consistent for local and ORB use. - Added to Ext a ReleaseNode helper function to reclaim unused nodes, necessary for ORB usage, and also for local usage because of circular references. - Added NodeIterators and Node Filters from DOM Level 2 - Added a visitor and walker system (to Ext). These generalize the NodeIterator concept for cases where pre-order traversal is not suitable: for instance printing. - Removed the repr functions from Node interfaces in favor of print walker/visitors. - Added Print and PrettyPrint helper functions to Ext for printing and pretty-printing node trees. - Added Strip helper function to Ext to strip all ignorable white-space text nodes from a node tree. - Moved all tools to construct a DOM tree from XML and HTML text to a Builder module in Ext, with two functions: FromXML and FromHTML. - Added options to FromXML that allow specification of whether to keep ignorable whitespce int he resultant node tree, and options on whether to validate. - Innumerable minor and miscellaneous fixes But what about PyDOM? --------------------- Please note that the XML-SIG is working on a separate DOM implementation, and there is currently discussion regarding the relative roles of 4DOM and PyDOM. PyDOM follows a more Python-like interface, returning a dictionary of nodes, for instance, where the DOM spec specifies an object with NamedNodeMap interface. This was a deliberate choice for the convenience of Python programmers. Also, PyDOM can build and write HTML, but only supports HTML nodes through the DOM core interface. 4DOM strictly follows the DOM interface specs and supports all HTML element capabilities. However, 4DOM is a bit more heavyweight. More info and Obtaining 4DOM ---------------------------- Please see http://OpenTechnology.org/projects/4DOM 4DOM is distributed under the terms of the GNU Library Public License (LGPL). http://www.gnu.org/copyleft/lgpl.html -- Uche Ogbuji uche.ogbuji@fourthought.com Consulting Member, FourThought LLC http://FourThought.com http://OpenTechnology.org From just@letterror.com Tue Feb 9 21:56:07 1999 From: just@letterror.com (Just van Rossum) Date: Tue, 9 Feb 1999 22:56:07 +0100 Subject: [XML-SIG] XML-newbie says hello Message-ID: Hi Folks, (I am very new to XML, and unfortunately I have missed the XML tutorial at the recent conference -- if only I had known then how important it wouldbe to me now...). Is this list appropriate for questions about using the XML implementation(s) this sig has put forth? I'll start off with two off-topic questions... Together with a bunch of people from my field we will try to design a DTD (or set of DTDs) for a complex kind of specialized data. Most of us have no experience with designing DTDs. - Would any of you kind souls be willing to tell me which of the books advertized on the sigs homepage (or other books non-advertized) covers DTD-design in a comprehensible way? (I own "XML - A Primer", and that's a nice XML introduction if you come from HTML, but is rather useless if you need to invent DTDs...) - What would be an appropriate forum for discussions about DTD design? Thanks in advance. Just From gstein@lyra.org Tue Feb 9 22:38:44 1999 From: gstein@lyra.org (Greg Stein) Date: Tue, 09 Feb 1999 14:38:44 -0800 Subject: [XML-SIG] XML-newbie says hello References: Message-ID: <36C0B8F4.592A1654@lyra.org> Just van Rossum wrote: > ... > Is this list appropriate for questions about using the XML > implementation(s) this sig has put forth? yup. > I'll start off with two off-topic questions... > Together with a bunch of people from my field we will try to design a DTD > (or set of DTDs) for a complex kind of specialized data. Most of us have no > experience with designing DTDs. > - Would any of you kind souls be willing to tell me which of the books > advertized on the sigs homepage (or other books non-advertized) covers > DTD-design in a comprehensible way? (I own "XML - A Primer", and that's a > nice XML introduction if you come from HTML, but is rather useless if you > need to invent DTDs...) See http://www.schema.net/. Right on the front page, there is a list of three books that should be appropriate. > - What would be an appropriate forum for discussions about DTD design? This forum has seen a number of DTD design discussions. It looks like schema.net has a mailing list, but I'm not sure what topics ared covered. You may want to peruse schema.net, also... there may be a DTD for you already (or one that is close). Cheers, -g -- Greg Stein, http://www.lyra.org/ From Fred L. Drake, Jr." References: Message-ID: <14016.47761.104547.408941@weyr.cnri.reston.va.us> Just van Rossum writes: > - Would any of you kind souls be willing to tell me which of the books > advertized on the sigs homepage (or other books non-advertized) covers Eve Maler's book "Developing SGML DTDs" is pretty good; I've not read Dave Megginson's or Rick Jeliffe's books, so I can't say how they compare. > - What would be an appropriate forum for discussions about DTD design? comp.text.sgml comp.text.xml -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From paul@prescod.net Tue Feb 9 22:23:04 1999 From: paul@prescod.net (Paul Prescod) Date: Tue, 09 Feb 1999 16:23:04 -0600 Subject: [XML-SIG] XML-newbie says hello References: Message-ID: <36C0B548.B0B3BBA@prescod.net> Just van Rossum wrote: > > Is this list appropriate for questions about using the XML > implementation(s) this sig has put forth? Sure. > I'll start off with two off-topic questions... > Together with a bunch of people from my field we will try to design a DTD > (or set of DTDs) for a complex kind of specialized data. Most of us have no > experience with designing DTDs. > - Would any of you kind souls be willing to tell me which of the books > advertized on the sigs homepage (or other books non-advertized) covers > DTD-design in a comprehensible way? (I own "XML - A Primer", and that's a > nice XML introduction if you come from HTML, but is rather useless if you > need to invent DTDs...) Probably David Megginson's "Structuring XML Documents" is the most appropriate for DTD design issues. > - What would be an appropriate forum for discussions about DTD design? The XML-dev mailing list is pretty good place to answer questions. It's pretty voluminous but if you get in, ask your question, collect the replies and get out you should be okay. :) -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey From larsga@ifi.uio.no Tue Feb 9 23:07:55 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: 10 Feb 1999 00:07:55 +0100 Subject: [XML-SIG] XML-newbie says hello In-Reply-To: References: Message-ID: * Just van Rossum | | Is this list appropriate for questions about using the XML | implementation(s) this sig has put forth? Definitely. :) | - Would any of you kind souls be willing to tell me which of the | books advertized on the sigs homepage (or other books | non-advertized) covers DTD-design in a comprehensible way? David Megginsons 'Structuring XML Documents' is very good, and also covers architectural forms (which may or may not be important, but can be very useful). Note that the main focus is on designing DTDs for documents and not for RPC/serialization/Beans Markup or any of that new-fangled stuff. | - What would be an appropriate forum for discussions about DTD design? Like Fred says I think the newsgroups are the right places to go. --Lars M. From just@letterror.com Tue Feb 9 23:11:02 1999 From: just@letterror.com (Just van Rossum) Date: Wed, 10 Feb 1999 00:11:02 +0100 Subject: [XML-SIG] XML-newbie says hello In-Reply-To: <36C0B8F4.592A1654@lyra.org> References: Message-ID: (Thanks for all your replies!) >See http://www.schema.net/. Right on the front page, there is a list of >three books that should be appropriate. Cool. "Developing SGML DTDs : From Text to Model to Markup" seems to be one of the standard works. Should I be afraid that it is about SGML rather than XML? I only know XML is a subset of SGML, but I have no idea what to look out for in the sense of XML vs. SGML pitfalls. Maybe Paul's suggestion "Structuring XML Documents" is more suited for me? >> - What would be an appropriate forum for discussions about DTD design? > >This forum has seen a number of DTD design discussions. It looks like >schema.net has a mailing list, but I'm not sure what topics ared >covered. You may want to peruse schema.net, also... schema.net seems a *very* useful site indeed. >there may be a DTD for you already (or one that is close). Nah, our application is way too specialized/obscure... But I'm sure I can learn a lot from other DTDs, if that's what you mean... Thanks again, Just From Fred L. Drake, Jr." References: Message-ID: <14017.38770.353353.377821@weyr.cnri.reston.va.us> Just van Rossum writes: > Cool. "Developing SGML DTDs : From Text to Model to Markup" seems to be one > of the standard works. Should I be afraid that it is about SGML rather than > XML? I only know XML is a subset of SGML, but I have no idea what to look > out for in the sense of XML vs. SGML pitfalls. Maybe Paul's suggestion > "Structuring XML Documents" is more suited for me? As I mentioned earlier, I can't really compare the two as I haven't read Megginson's book (yet). I can assure you that there's very little in Maler's book that doesn't apply to XML; most of it is about breaking content analysis and information structuring with an eye to reuse. It also deals with the "political" issues of designing a DTD in an organization where a lot of people will be involved, but those parts should be pretty easy to skip over or skim. And it's a decent read: she made the traditional cookbook example sound quite plausible! ;-) (Yes, that was a compliment, not my typical sarcasm.) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From larsga@ifi.uio.no Wed Feb 10 15:19:55 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: 10 Feb 1999 16:19:55 +0100 Subject: [XML-SIG] XML-newbie says hello In-Reply-To: References: Message-ID: * Just van Rossum | | Maybe Paul's suggestion "Structuring XML Documents" is more suited | for me? Well, it's really a rather traditional SGML book as well, although it does point out differences between XML and SGML throughout the text. Note that calling it a 'traditional SGML book' is not meant disparagingly, quite the contrary, but that it's not aimed at typical XML uses. (For example, the attention given to the documents being easy to edit manually is not a concern for many XML DTDs, where the content is generated automatically.) | schema.net seems a *very* useful site indeed. It is. I usually look for what I want there first, and if I can find it I try the more complete (but less easily navigated) --Lars M. From michael@graphion.com Wed Feb 10 18:16:26 1999 From: michael@graphion.com (Michael Sanborn) Date: Wed, 10 Feb 1999 10:16:26 -0800 Subject: [XML-SIG] SQL -> XML ? Message-ID: <36C1CCF9.E622365E@graphion.com> A month ago, I had been working on an XML project as a way of learning Python. It was quite rewarding, in a way, but now that I'm returning to it, I think that I need advice on my approach. At my work, we get in database files that need to be converted into directories. There are many variations on the theme, but a typical directory structure would be (in XML syntax): Alameda County Alameda Dermatology Groups Affiliates In Dermatology Med Grp
2241 Central Ave
(510) 523-9866 Graham, Richard S. Hilger Jr., Leslie G. Paslin, David A. These are expressed as consecutive one-to-many relationships in a set of database tables. What I've been trying to do is to read the tables using SQL statements in Python and then translate the data into XML using PyDOM. My first approach was to make one big SQL statement like (pause for breath): SELECT COUNTY.COUNTYNAME, PPOPROV.CITY, SPECALTY.SPECIALTYH, PPOPROV.AGREEMENTT, PPOPROV.PROVIDERNU, PPOPROV.NAME, PPOPROV.ADDRESS, PPOPROV.PHONE, MEMBER.NAME FROM MEMBER RIGHT JOIN (SPECALTY INNER JOIN (COUNTY INNER JOIN PPOPROV ON COUNTY.COUNTYCODE = PPOPROV.COUNTYCODE) ON SPECALTY.SEQNUM = PPOPROV.SPECIALTYH) ON MEMBER.PROVIDERNU = PPOPROV.PROVIDERNU ORDER BY COUNTY.COUNTYNAME, PPOPROV.CITY, SPECALTY.SPECIALTYH, PPOPROV.AGREEMENTT, PPOPROV.NAME, PPOPROV.PROVIDERNU, MEMBER.NAME; and then made a Reader object that recursively directed Builder.py to create DOM nodes, weaving up and down the tree as the various levels of grouped headings changed. (Sorry if this is unclear; I'm new to trees, and am not certain what the standard programming terminology is for what I'm doing. A minuscule amount of Design Pattern knowledge is a dangerous thing. :-}) It worked, but it was very slow, and when I tried to adapt it to varying structures, I found it to be very brittle as well. So I thought of breaking down the SQL statements by level, like this (to just use the two topmost levels): from xml.dom.builder import Builder from calldll import odbc from calldll import odbc_installer builder = Builder() installer = odbc_installer installer.config_data_source(installer.ODBC_ADD_DSN, 'Microsoft FoxPro Driver (*.dbf)', 'DSN=myData;DBQ=.;') environment = odbc.environment() connection = environment.connection() connection.connect('myData') builder.startElement('physician') record_set = connection.query('SELECT DISTINCT COUNTY.COUNTYNAME FROM COUNTY, PPOPROV WHERE COUNTY.COUNTYCODE = PPOPROV.COUNTYCODE ORDER BY COUNTYNAME;') record_set = record_set[1:] for i in record_set: builder.startElement('county') builder.text(i[0]) record_set1 = connection.query('SELECT DISTINCT PPOPROV.CITY FROM COUNTY, PPOPROV WHERE COUNTY.COUNTYCODE = PPOPROV.COUNTYCODE AND COUNTY.COUNTYNAME=\'' + i[0] + '\' ORDER BY PPOPROV.CITY;') record_set1 = record_set1[1:] for j in record_set1: builder.startElement('city') builder.text(j[0]) builder.endElement('city') builder.endElement('county') builder.endElement('physician') print builder.document.toxml() But this is already quite slow, and I've hardly scratched the surface. So, can anyone provide me with a little guidance here? Should I be looking at a SAX approach, rather than DOM? Does the fact that I'm using the ODBC library in calldll matter, rather than, say, mxODBC? Is there some standard approach to this problem? Should I just go back to South Dakota? Any help would be very much appreciated. Thanks, Michael Sanborn Graphion From jday@csihq.com Wed Feb 10 20:21:40 1999 From: jday@csihq.com (John Day) Date: Wed, 10 Feb 1999 15:21:40 -0500 Subject: [XML-SIG] SQL -> XML ? In-Reply-To: <36C1CCF9.E622365E@graphion.com> Message-ID: <3.0.1.32.19990210152140.0129a11c@mail.csihq.com> Looks like you want to "group by" county,city, specialty,type and provider and then make a list of the provider members. Save the group-by headers to make your nested wrappers around each member list. -jday At 10:16 AM 2/10/99 -0800, Michael Sanborn wrote: >A month ago, I had been working on an XML project as a way of learning >Python. It was quite rewarding, in a way, but now that I'm returning to >it, I think that I need advice on my approach. > >At my work, we get in database files that need to be converted into >directories. There are many variations on the theme, but a typical >directory structure would be (in XML syntax): > > > Alameda County > Alameda > Dermatology > Groups > > Affiliates In Dermatology Med Grp >
2241 Central Ave
> (510) 523-9866 > Graham, Richard S. > Hilger Jr., Leslie G. > Paslin, David A. > > > > > > > >These are expressed as consecutive one-to-many relationships in a set of >database tables. What I've been trying to do is to read the tables using >SQL statements in Python and then translate the data into XML using >PyDOM. My first approach was to make one big SQL statement like (pause >for breath): > >SELECT COUNTY.COUNTYNAME, PPOPROV.CITY, SPECALTY.SPECIALTYH, >PPOPROV.AGREEMENTT, PPOPROV.PROVIDERNU, PPOPROV.NAME, PPOPROV.ADDRESS, >PPOPROV.PHONE, MEMBER.NAME FROM MEMBER RIGHT JOIN (SPECALTY INNER JOIN >(COUNTY INNER JOIN PPOPROV ON COUNTY.COUNTYCODE = PPOPROV.COUNTYCODE) ON >SPECALTY.SEQNUM = PPOPROV.SPECIALTYH) ON MEMBER.PROVIDERNU = >PPOPROV.PROVIDERNU ORDER BY COUNTY.COUNTYNAME, PPOPROV.CITY, >SPECALTY.SPECIALTYH, PPOPROV.AGREEMENTT, PPOPROV.NAME, >PPOPROV.PROVIDERNU, MEMBER.NAME; > >and then made a Reader object that recursively directed Builder.py to >create DOM nodes, weaving up and down the tree as the various levels of >grouped headings changed. (Sorry if this is unclear; I'm new to trees, >and am not certain what the standard programming terminology is for what >I'm doing. A minuscule amount of Design Pattern knowledge is a dangerous >thing. :-}) > >It worked, but it was very slow, and when I tried to adapt it to varying >structures, I found it to be very brittle as well. So I thought of >breaking down the SQL statements by level, like this (to just use the >two topmost levels): > >from xml.dom.builder import Builder >from calldll import odbc >from calldll import odbc_installer > >builder = Builder() >installer = odbc_installer >installer.config_data_source(installer.ODBC_ADD_DSN, 'Microsoft FoxPro >Driver (*.dbf)', 'DSN=myData;DBQ=.;') >environment = odbc.environment() >connection = environment.connection() >connection.connect('myData') >builder.startElement('physician') >record_set = connection.query('SELECT DISTINCT COUNTY.COUNTYNAME > FROM COUNTY, PPOPROV > WHERE COUNTY.COUNTYCODE = PPOPROV.COUNTYCODE > ORDER BY COUNTYNAME;') >record_set = record_set[1:] >for i in record_set: > builder.startElement('county') > builder.text(i[0]) > record_set1 = connection.query('SELECT DISTINCT PPOPROV.CITY > FROM COUNTY, PPOPROV > WHERE COUNTY.COUNTYCODE = PPOPROV.COUNTYCODE AND >COUNTY.COUNTYNAME=\'' + i[0] + '\' > ORDER BY PPOPROV.CITY;') > record_set1 = record_set1[1:] > for j in record_set1: > builder.startElement('city') > builder.text(j[0]) > builder.endElement('city') > builder.endElement('county') >builder.endElement('physician') >print builder.document.toxml() > > >But this is already quite slow, and I've hardly scratched the surface. > >So, can anyone provide me with a little guidance here? Should I be >looking at a SAX approach, rather than DOM? Does the fact that I'm using >the ODBC library in calldll matter, rather than, say, mxODBC? Is there >some standard approach to this problem? Should I just go back to South >Dakota? > >Any help would be very much appreciated. > >Thanks, > >Michael Sanborn >Graphion > > >_______________________________________________ >XML-SIG maillist - XML-SIG@python.org >http://www.python.org/mailman/listinfo/xml-sig > > > From akuchlin@cnri.reston.va.us Wed Feb 10 21:07:09 1999 From: akuchlin@cnri.reston.va.us (A.M. Kuchling) Date: Wed, 10 Feb 1999 16:07:09 -0500 Subject: [XML-SIG] XML-newbie says hello In-Reply-To: <14017.38770.353353.377821@weyr.cnri.reston.va.us> References: <14017.38770.353353.377821@weyr.cnri.reston.va.us> Message-ID: <199902102107.QAA00447@207-172-96-74.s265.tnt4.ann.erols.com> Fred L. Drake writes: > parts should be pretty easy to skip over or skim. And it's a decent > read: she made the traditional cookbook example sound quite plausible! Hmm. I have a collection of recipes that's currently a bunch of scraps of paper stuffed in a cookbook, and recently was thinking of computerizing them, just so I don't have to worry about losing the piece of paper with, say, that great tortellini soup recipe. So I really could use a cookbook DTD! Anyone know of such a thing? (Doesn't seem to be...) -- A.M. Kuchling http://starship.python.net/crew/amk/ Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information on it. -- Samuel Johnson From betty@eccnet.eccnet.com Wed Feb 10 22:58:41 1999 From: betty@eccnet.eccnet.com (Betty Harvey) Date: Wed, 10 Feb 1999 17:58:41 -0500 (EST) Subject: [XML-SIG] XML-newbie says hello In-Reply-To: <199902102107.QAA00447@207-172-96-74.s265.tnt4.ann.erols.com> Message-ID: On Wed, 10 Feb 1999, A.M. Kuchling wrote: > Fred L. Drake writes: > > parts should be pretty easy to skip over or skim. And it's a decent > > read: she made the traditional cookbook example sound quite plausible! > > Hmm. I have a collection of recipes that's currently a bunch of > scraps of paper stuffed in a cookbook, and recently was thinking of > computerizing them, just so I don't have to worry about losing the > piece of paper with, say, that great tortellini soup recipe. So > I really could use a cookbook DTD! Anyone know of such a thing? > (Doesn't seem to be...) > Many years ago standard SGML courses used the recipe as a learning exercise. Maybe someone who took one of these courses has their recipe DTD lieing around (unfortunately I took my first SGML course while working for DoD - so our exercise was a tech manual |-). However, a cookbook DTD is a great idea. If you are like me, you have tons of cookbooks and the ones from church and civic organizations are my favorites. A lot of organizations write them as fund raiser. Betty /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 301-540-8251 FAX: 4268 Electronic Commerce Connection, Inc. | 13017 Wisteria Drive, P.O. Box 333 | Germantown, Md. 20874 | harvey@eccnet.eccnet.com | Washington,DC SGML/XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/sgmlug/ /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ From just@letterror.com Thu Feb 11 18:03:01 1999 From: just@letterror.com (Just van Rossum) Date: Thu, 11 Feb 1999 19:03:01 +0100 Subject: [XML-SIG] generating a DTD from a sample document?? Message-ID: I vaguely remember someone at the Houston conference mentioning that it is possible to generate a DTD from a sample document. If this is true, does any of the Python XML packages do this? How? (Seems like a real quick way to learn a bit more about writing DTDs ;-) Thanks a lot in advance, Just From gwachob@aimnet.com Thu Feb 11 19:02:43 1999 From: gwachob@aimnet.com (Gabe Wachob) Date: Thu, 11 Feb 1999 11:02:43 -0800 (PST) Subject: [XML-SIG] generating a DTD from a sample document?? In-Reply-To: Message-ID: On Thu, 11 Feb 1999, Just van Rossum wrote: > I vaguely remember someone at the Houston conference mentioning that it is > possible to generate a DTD from a sample document. If this is true, does > any of the Python XML packages do this? How? > (Seems like a real quick way to learn a bit more about writing DTDs ;-) Well, generating a DTD mechanically may not be as useful as you may think. its probably easier to find a common DTD (linuxdoc, perhaps) and then look at many examples. Also, pick up Dave Megginson's book entitled "Structuring XML Documents". To answer your original question, generating a really useful DTD from and XML document probably isn't possible, depending on the complexity of the document you are starting from and your definition of useful. You can always generate an "enabling" DTD, a DTD to which the sample XML document conforms. I can generate one right now: Of course, you could do better, even mechanically, depending on the input document. However, a single XML document may not contain examples of all the possible content models for certain elements (ie a element in the sample document may only contain a subelement, but may not contain a element even though that would otherwise be a valid subelement of -- mechanical generation of a DTD from that document would not have any way of knowing about the element). That being said, mechanical generation of DTDs is useful in the very first steps of reverse engineering a DTD from XML documents. It doesn't get your far, though. I know there is one tool out there that does this for you, but in practice, these sort of things don't help you that much unless you have really large XML documents. -Gabe ------------------------------------------------------------------------ Gabe Wachob - http://www.findlaw.com - http://www.aimnet.com/~gwachob As of today, the U.S. Constitution has been in force for 76,935 days When this message was sent, there were 27,953,837 seconds before Y2K From michael@graphion.com Thu Feb 11 20:17:51 1999 From: michael@graphion.com (Michael Sanborn) Date: Thu, 11 Feb 1999 12:17:51 -0800 Subject: [XML-SIG] SQL -> XML ? References: <3.0.1.32.19990210152140.0129a11c@mail.csihq.com> Message-ID: <36C33AEE.B5AAB67B@graphion.com> John Day wrote: > Looks like you want to "group by" county,city, > specialty,type and provider and then make a list > of the provider members. Save the group-by headers > to make your nested wrappers around each member list. Um, having had a chance to think this over a bit, I guess I should have been more specific with my question, sorry. It would be very useful for me to create a document as a DOM tree, based on data that I can easily access with SQL statements. I'm wondering whether there are well-known design tips for converting table oriented data structures into tree structures, that would come in handy for this sort of task, in terms of efficiency and reusability? Michael From cg@cdegroot.com Thu Feb 11 21:13:05 1999 From: cg@cdegroot.com (Cees de Groot) Date: Thu, 11 Feb 1999 22:13:05 +0100 Subject: [XML-SIG] Functional interface to XML? Message-ID: <199902112113.WAA19382@evrl.xs4all.nl> Hi, I'm busy evaluating the best way for SGMLtools to convert DocBook SGML into groff (for high-quality ASCII output and manpage source), and I have decided to convert DocBook into XML (with help from Jade and/or sgmlnorm) and work from there with Python. In case you don't know SGMLtools: it's a repackaging of well-known SGML components (Jade validating parser and DSSSL engine, DocBook DTD, Norm Walsh' DocBook stylesheets, and JadeTeX) plus a shell around them in Python. I've been wondering weither something functional/stylesheet-ish exists on top of Python's XML stuff. I have thrown together a quick example (see below) and for what I'll need to do I have the feeling that such an approach would be the easiest. My example, though, is a tad slow I think so I rather use someone elses quality stuff before hacking up my own :-) Here's what I have in mind: --- 8< --- snip from xml.sax import saxexts, saxlib, saxutils import sys,string driver=None p=saxexts.make_parser(driver) p.setErrorHandler(saxutils.ErrorPrinter()) class FunctionalDocumentHandler(saxlib.DocumentHandler): def __init__(self): self.stack = [] def _makeName(self, startwith, numelems): retval = '' for i in self.stack[0:numelems]: retval = i + '_' + retval return startwith + '_' + retval[0:len(retval)-1] def startElement(self, name, atts): self.stack.insert(0, name) for numelems in range(len(self.stack), 0, -1): funcname = self._makeName('start', numelems) if hasattr(self, funcname): getattr(self, funcname)(atts) break def endElement(self, name): for numelems in range(len(self.stack), 0, -1): funcname = self._makeName('end', numelems) if hasattr(self, funcname): getattr(self, funcname)() break del self.stack[0] def characters(self, ch, start, length): print string.strip(ch[start:start+length]) # # This is what this is all about - a kinda stylesheet interface # class MyDocumentHandler(FunctionalDocumentHandler): def start_PARA(self, atts): print "

" def end_PARA(self): print "

" def start_AUTHORBLURB_PARA(self, atts): print "

" def end_AUTHORBLURB_PARA(self): print "

"; dh = MyDocumentHandler() try: p.setDocumentHandler(dh) p.parse('test.xml') except IOError,e: print str(e) except saxlib.SAXException,e: print str(e) ---- 8< --- snap --- Is this a sensible way to process XML in Python? From paul@prescod.net Thu Feb 11 21:34:40 1999 From: paul@prescod.net (Paul Prescod) Date: Thu, 11 Feb 1999 15:34:40 -0600 Subject: [XML-SIG] SVG: 2D graphics References: <002101be55f6$02f1a820$4a4df60d@stoll-pc.xis.xerox.com> Message-ID: <36C34CF0.B3E7940E@prescod.net> Perry Stoll wrote: > > I meant VML, an XML-based 2D-vector markup language > http://www.w3.org/TR/1998/NOTE-VML-19980513, and not XML. Sorry. VML became obsolete today. Sorry. :) The W3C released th first draft of SVG which will eventually become the Web's "official" structured vector graphics specification. This is an important event for anyone interested in vector graphics in the Web context but also more generally. Still, this is very rough so we have a long way to go before it is complete, standardized and widely implemented. http://www.w3.org/TR/WD-SVG -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 From uche.ogbuji@fourthought.com Fri Feb 12 04:22:41 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Thu, 11 Feb 1999 21:22:41 -0700 Subject: [XML-SIG] SQL -> XML ? In-Reply-To: Your message of "Thu, 11 Feb 1999 12:17:51 PST." <36C33AEE.B5AAB67B@graphion.com> Message-ID: <199902120422.VAA08435@malatesta.local> > It would be very useful for me to create a document as a DOM tree, based on > data that I can easily access with SQL statements. I'm wondering whether > there are well-known design tips for converting table oriented data > structures into tree structures, that would come in handy for this sort of > task, in terms of efficiency and reusability? There has been a good deal of discussion in the XML-DEV list about such matters, and I haven't read any useful solutions to the basic impedance mis-match between tabular and tree-based structure. Maybe as the DB manufacturers rush to swallow XML whole, they'll come up with something clever, but I wouldn't hold my breath. I don't think there is much for it but the brute-force method. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From srn@techno.com Fri Feb 12 16:06:32 1999 From: srn@techno.com (Steven R. Newcomb) Date: Fri, 12 Feb 1999 10:06:32 -0600 Subject: [XML-SIG] SQL -> XML ? In-Reply-To: <199902120422.VAA08435@malatesta.local> (uche.ogbuji@fourthought.com) References: <199902120422.VAA08435@malatesta.local> Message-ID: <199902121606.KAA01331@bruno.techno.com> > > It would be very useful for me to create a > > document as a DOM tree, based on data that I can > > easily access with SQL statements. I'm wondering > > whether there are well-known design tips for > > converting table oriented data structures into > > tree structures, that would come in handy for > > this sort of task, in terms of efficiency and > > reusability? [Uche Ogbuji:] > There has been a good deal of discussion in the > XML-DEV list about such matters, and I haven't > read any useful solutions to the basic impedance > mis-match between tabular and tree-based > structure. Maybe as the DB manufacturers rush > to swallow XML whole, they'll come up with > something clever, but I wouldn't hold my breath. > > I don't think there is much for it but the > brute-force method. Would you consider the grove paradigm a "brute-force" method? It seems to me to answer the impedance-mismatch problem, here. It also seems to me much too elegant to be describable as "brute-force". -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA From michael@graphion.com Fri Feb 12 16:20:29 1999 From: michael@graphion.com (Michael Sanborn) Date: Fri, 12 Feb 1999 08:20:29 -0800 Subject: [XML-SIG] SQL -> XML ? References: <199902120422.VAA08435@malatesta.local> <199902121606.KAA01331@bruno.techno.com> Message-ID: <36C454CC.D6F1005C@graphion.com> "Steven R. Newcomb" wrote: > [Uche Ogbuji:] > > > I don't think there is much for it but the > > brute-force method. > > Would you consider the grove paradigm a > "brute-force" method? Grove paradigm? Can you recommend any good pointers to learn more about this? Michael From spiritware@yahoo.com Fri Feb 12 22:35:38 1999 From: spiritware@yahoo.com (Bill Barnhill) Date: Fri, 12 Feb 1999 14:35:38 -0800 (PST) Subject: [XML-SIG] Re: auto-generating a DTD Message-ID: <19990212223538.15488.rocketmail@send203.yahoomail.com> This is my first post in this group, and I am new to XML as well, but it seems to me that the main reason for DTD is for validation of XML tag structure. I would imagine that most RL XML objects (Objects->root element? I'm not sure of the right term but I mean the object an XML file represents) will have varying tags depending on the individual file. For example not all elements will have a element. If I am off base on the above, please correct me. :) On another topic: I am jumping feet first into XML with a person who wants me to explore the idea of setting up their website to accept credit cards, without going through one of the expensive online middlemen store front sites. I am trying to decide between OTP and OFX. Could someone out there tell me how to decide? If this is something I can get help from the bank or credit card company on, I'd like to know that as well. I've downloaded the std specs, but it seems like SGML in that it's designed to cover EVERYTHING. Ideal would be an example of a site that use OTP or OFX. Thanks for the help, Bill _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From paul@prescod.net Fri Feb 12 23:15:53 1999 From: paul@prescod.net (Paul Prescod) Date: Fri, 12 Feb 1999 17:15:53 -0600 Subject: [XML-SIG] Re: auto-generating a DTD References: <19990212223538.15488.rocketmail@send203.yahoomail.com> Message-ID: <36C4B629.2B10F11D@prescod.net> Bill Barnhill wrote: > > This is my first post in this group, and I am new to XML as well, but > it seems to me that the main reason for DTD is for validation of XML > tag structure. I would imagine that most RL XML objects (Objects->root > element? I'm not sure of the right term but I mean the object an XML > file represents) will have varying tags depending on the individual > file. > > For example not all elements will have a element. That is why DTDs allow optional elements. > On another topic: I am jumping feet first into XML with a person who > wants me to explore the idea of setting up their website to accept > credit cards, without going through one of the expensive online > middlemen store front sites. I am trying to decide between OTP and > OFX. Could someone out there tell me how to decide? If this is > something I can get help from the bank or credit card company on, I'd > like to know that as well. OTP and OFX are financial interchange protocols. You can't use them if your bank or credit card doesn't. You should see what they use and conform to it. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco If you spend any time administering Windows NT, you're far too familiar with the Blue Screen of Death (BSOD) which displays the cause of the crash and gives some information about the state of the system when it crashed. -- "Microsoft Developer Network Magazine" From srn@techno.com Sat Feb 13 00:58:19 1999 From: srn@techno.com (Steven R. Newcomb) Date: Fri, 12 Feb 1999 18:58:19 -0600 Subject: [XML-SIG] SQL -> XML ? In-Reply-To: <36C454CC.D6F1005C@graphion.com> (message from Michael Sanborn on Fri, 12 Feb 1999 08:20:29 -0800) References: <199902120422.VAA08435@malatesta.local> <199902121606.KAA01331@bruno.techno.com> <36C454CC.D6F1005C@graphion.com> Message-ID: <199902130058.SAA02464@bruno.techno.com> > Grove paradigm? Can you recommend any good > pointers to learn more about this? You might find Paul Prescod's paper interesting: http://cito.uwaterloo.ca:80/~papresco/PySgml/PyGrove/ ... but I'm not sure it will show you why I said what I said in the XML-DEV list. And Paul and I debate lots of issues all the time (we work in the same suite of offices at ISOGEN International in Dallas), so it would be typical for me to find something in it to disagree with. There's also the relevant portion of the relevant ISO standard (good luck deciphering its abstruse and lawyerly language): http://www.ornl.gov/sgml/wg8/document/n1920/html/clause-A.4.html You might find it revealing to take a look at the GroveMinder technology described at http://www.techno.com/gminder3.htm (BTW, this website is about to be overhauled, and so is this file). We're providing demos of the GroveMinder technology only under nondisclosure agreements, at least for now. Let me know if you want to go that route. It includes a Python interface and an on-the-fly HTML server written in Python (in source code form). -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA From uche.ogbuji@fourthought.com Sat Feb 13 23:21:49 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Sat, 13 Feb 1999 16:21:49 -0700 Subject: [XML-SIG] SQL -> XML ? In-Reply-To: Your message of "Fri, 12 Feb 1999 10:06:32 CST." <199902121606.KAA01331@bruno.techno.com> Message-ID: <199902132321.QAA10937@malatesta.local> > > There has been a good deal of discussion in the > > XML-DEV list about such matters, and I haven't > > read any useful solutions to the basic impedance > > mis-match between tabular and tree-based > > structure. Maybe as the DB manufacturers rush > > to swallow XML whole, they'll come up with > > something clever, but I wouldn't hold my breath. > > > > I don't think there is much for it but the > > brute-force method. > > Would you consider the grove paradigm a > "brute-force" method? It seems to me to answer > the impedance-mismatch problem, here. It also > seems to me much too elegant to be describable as > "brute-force". I know what groves are from a basic data-structure POV, and I've read posts by Paul Prescod on groves in XML-DEV, but I must say that I am not at all familiar with the grove spec for SGML/XML. But you have certainly piqued my interest enough that I shall take a look at the URLs you provided in another message. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From paul@prescod.net Sun Feb 14 13:11:44 1999 From: paul@prescod.net (Paul Prescod) Date: Sun, 14 Feb 1999 07:11:44 -0600 Subject: [XML-SIG] SQL -> XML ? References: <199902120422.VAA08435@malatesta.local> <199902121606.KAA01331@bruno.techno.com> Message-ID: <36C6CB90.8D171912@prescod.net> "Steven R. Newcomb" wrote: > > Would you consider the grove paradigm a > "brute-force" method? It seems to me to answer > the impedance-mismatch problem, here. It also > seems to me much too elegant to be describable as > "brute-force". As is often the case on mailing lists, I think that we have lost some context. Steve has described a paradigm for *representing* tables as trees. That paradigm must still be *implemented*. Michael's original question was about implementation strategies. I don't know of an implementation strategy that overcomes the basic impedence mismatch between relational data and tree data. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco If you spend any time administering Windows NT, you're far too familiar with the Blue Screen of Death (BSOD) which displays the cause of the crash and gives some information about the state of the system when it crashed. -- "Microsoft Developer Network Magazine" From tismer@appliedbiometrics.com Sun Feb 14 16:56:37 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Sun, 14 Feb 1999 17:56:37 +0100 Subject: [XML-SIG] XML-newbie says hello References: Message-ID: <36C70045.6BB78D37@appliedbiometrics.com> Just van Rossum wrote: > > (Thanks for all your replies!) > > >See http://www.schema.net/. Right on the front page, there is a list of > >three books that should be appropriate. > > Cool. "Developing SGML DTDs : From Text to Model to Markup" seems to be one > of the standard works. Should I be afraid that it is about SGML rather than > XML? I only know XML is a subset of SGML, but I have no idea what to look > out for in the sense of XML vs. SGML pitfalls. Maybe Paul's suggestion > "Structuring XML Documents" is more suited for me? To be sure what is SGML but not XML, I personally found this document from James Clark extremely helpful: "Comparison of SGML and XML" http://www.w3.org/TR/NOTE-sgml-xml-971215 ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From srn@techno.com Sun Feb 14 22:23:54 1999 From: srn@techno.com (Steven R. Newcomb) Date: Sun, 14 Feb 1999 16:23:54 -0600 Subject: [XML-SIG] SQL -> XML ? In-Reply-To: <36C6CB90.8D171912@prescod.net> (message from Paul Prescod on Sun, 14 Feb 1999 07:11:44 -0600) References: <199902120422.VAA08435@malatesta.local> <199902121606.KAA01331@bruno.techno.com> <36C6CB90.8D171912@prescod.net> Message-ID: <199902142223.QAA01508@bruno.techno.com> [Paul Prescod:] > As is often the case on mailing lists, I think > that we have lost some context. Steve has > described a paradigm for *representing* tables > as trees. That paradigm must still be > *implemented*. Michael's original question was > about implementation strategies. I don't know of > an implementation strategy that overcomes the > basic impedence mismatch between relational data > and tree data. I was assuming that the metaphor, "impedance mismatch," refers to the phenomenon of signal degradation the interface between two electronic components, one of which is supplying a signal to the other, but the electrical characteristics of the signal produced by the sending are inappropriate to the electrical characteristics of the receiver. In electronic design, transformers (or trickier, more active things) are used to overcome impedance mismatches, so that the signal is not degraded. Perhaps I misunderstood the question (and perhaps I still misunderstand it), but I thought the essential question was: how can transformations be done that allow these two very different kinds of information (two kinds of signals, if you will) to be losslessly converted into one another. In other words: What does the transformer (or other trickier thing) do, and, more to the point, what is the science on which it is based? I was suggesting that one "science" on which such a "transformer" could be based is the grove paradigm, which was developed precisely for the purpose of allowing things that are naturally and inevitably trees, such as interchangeable XML documents, to accurately reflect the information content -- the "signal" -- of information whose inherent structure, in its most useful form, is completely arbitrary (and could therefore be an RDBMS, to mention just one example). The implementation strategy is to apply the grove paradigm. This involves expressing the model to which the RDBS data most usefully and naturally conforms as a property set -- in effect, the abstract API to the semantics of the RDBS. If the schema of the RDBMS and the property set of its semantics resemble one another, no one should be surprised; they are ideally alternative ways of looking at the same information set. However, because RDBMSs have inherent strict limitations on their modeling capabilities (tables having exactly two dimensions, for example), the design of such databases doesn't always reflect the natural structure of the information that the data represent, nor does the information always present itself to applications, directly from the database, in a fashion which is the most convenient or natural. So, a special interface is usually built that provides a more intuitive or more summarized interface, for the convenience of applications. But, in RDBMS-land, the natural underlying semantic structure of the information -- the signal -- is not formalized all the way up to this "convenience API". The "convenience API" actually is, however, the best available expression of the raison d'etre of the information and the anticipated applications of it. If the convenience API were rationalized, formalized, codified, and interchanged as a model of the information set, rather than as a set of procedure calls, it would improve the reliability with which the information set could be accurately interchanged, and it would widen the scope of applications that could make use of the information. The "property sets" formalism of the grove paradigm is designed to be an internationally standard modality of codifying and interchanging just such abstract "convenience" APIs. (By the way, it is no big deal to make an RDBS appear to be a grove, if only you have first codified the real information set as a property set. If your information really is two-dimensional tables, or even n-dimensional tables, it's not a problem.) Assuming you have made the RDBMS look like a grove, the transformation of the information in the RDBMS into interchangeable form as an XML document is more or less straightforward. You have to create a DTD that can represent the information set nonredundantly, and transformations between the grove and interchangeable forms of the information set should be clearly specified in an "Architecture Definition Document" that includes the DTD and the property set. Finally, software that performs the transformation -- an "architecture engine" which, like an impedance-matching device, may or may not be bi-directional -- is written. (The GroveMinder system provides tools that facilitate this process, as well as permitting multiple architecture engines to be used concurrently with the same multiple-architecture-inheriting interchangeable information. But this business of GroveMinder and this other business of multiple architecture inheritance are other juicy topics for other occasions.) I do feel that the grove paradigm is an elegant way to meet all the requirements of reliable industry-wide information interchange in an open, multivendor, arbitrary-application, arbitrary-information-set, arbitrary-storage-facility environment -- in other words, in the real world, with all its actual warts. It's not an accident that the grove paradigm is the subject of the only international standard for defining what an application sees when processing information that must be interchanged according to some arbitrary interchange representation, such as XML (but not limited to XML, and, unlike the DOM, fully capable, from first principles, of incorporating DTD-specific semantics and supporting addressing based on arbitrary properties as well as structural phenomena). The grove paradigm allows the accuracy and reliability of information interchange to be whatever people are prepared to pay for; it can be used in quick and dirty ways, but it outshines all others when information must be handled with respect for its integrity. One thing you can't do with the grove paradigm is to conceal the ways in which you chose to be quick and dirty. I think that's good for information interchange. It's good news for information owners, creators, maintainers, and users. It's probably not good news for traditional software business models. (Who cares?) -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA From paul@prescod.net Mon Feb 15 15:18:20 1999 From: paul@prescod.net (Paul Prescod) Date: Mon, 15 Feb 1999 09:18:20 -0600 Subject: [XML-SIG] SQL -> XML ? References: <199902120422.VAA08435@malatesta.local> <199902121606.KAA01331@bruno.techno.com> <36C6CB90.8D171912@prescod.net> <199902142223.QAA01508@bruno.techno.com> Message-ID: <36C83ABC.699013A6@prescod.net> "Steven R. Newcomb" wrote: > > Perhaps I misunderstood the > question (and perhaps I still misunderstand it), > but I thought the essential question was: how can > transformations be done that allow these two very > different kinds of information (two kinds of > signals, if you will) to be losslessly converted > into one another. The question was, how can this sort of transformation be done *efficiently*. The progenitor of the thread already had a solution to the tranformation problem. It just was not efficient. Losslessly encoding an RDBMS as a text file is easy with or without groves. Doing it efficiently can be difficult in either case. > The implementation strategy is to apply the grove > paradigm. But what algorithms, data structures and SQL queries does one use to do this efficiently? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco If you spend any time administering Windows NT, you're far too familiar with the Blue Screen of Death (BSOD) which displays the cause of the crash and gives some information about the state of the system when it crashed. -- "Microsoft Developer Network Magazine" From gherman@darwin.in-berlin.de Mon Feb 15 15:21:12 1999 From: gherman@darwin.in-berlin.de (Dinu C. Gherman) Date: Mon, 15 Feb 1999 16:21:12 +0100 Subject: [XML-SIG] XML-Howto update References: <199902141701.MAA27928@python.org> Message-ID: <36C83B68.D9722F42@darwin.in-berlin.de> Y'day I found an update of Andrew's XML-Howto over the last few days or weeks with some more new flesh added to the DOM sections, at least. Unfortunately, this update holds only for the individual HTML pages, not the other formats and not even the bundled HTML pages. Can we expect this to change soon (so I don't have to print single pages right now)? Hoping-not-to-reveal-stuff-to-be-announced'ly, Dinu -- Dinu C. Gherman : Mit Berlin kannste mir jagen! ................................................................ LHS International AG : http://www.lhsgroup.com 8050 Zurich : http://www.zurich.ch Switzerland : http://pgp.ai.mit.edu : mobile://49.172.3060751 From michael@graphion.com Mon Feb 15 20:45:04 1999 From: michael@graphion.com (Michael Sanborn) Date: Mon, 15 Feb 1999 12:45:04 -0800 Subject: [XML-SIG] SQL -> XML ? References: <199902120422.VAA08435@malatesta.local> <199902121606.KAA01331@bruno.techno.com> Message-ID: <36C88750.FC66ED20@graphion.com> "Paul Prescod" wrote: > "Steven R. Newcomb" wrote: > > > > Would you consider the grove paradigm a > > "brute-force" method? It seems to me to answer > > the impedance-mismatch problem, here. It also > > seems to me much too elegant to be describable as > > "brute-force". > > As is often the case on mailing lists, I think that we have lost some > context. Steve has described a paradigm for *representing* tables as > trees. That paradigm must still be *implemented*. Michael's original > question was about implementation strategies. I don't know of an > implementation strategy that overcomes the basic impedence mismatch > between relational data and tree data. > Thanks to everyone for the comments so far. I found the Grove material interesting, but it's true that I didn't gather a lot that helps me solve my problem. I'm surprised that there doesn't seem to be more material on the subject. So, I've posted my original rickety solution to: http://www.graphion.com/michael/SQL2DOM.py in the hopes that someone might be able to offer me suggestions regarding it. Disclaimer: I'm not an experienced programmer, but I'm aware that this code isn't so much designed as flung about. I recognized the name of Builder.py from the Gang of Four book, and thought that what I needed to do was to try to implement a Director of some sort. So I've got Director objects constructing themselves recursively to manipulate the Builder as needed. One question might be, am I better off writing this as a recursive method of a Director object? The result of this effort was that, once the tree was built, I was able to convert it to my company's proprietary markup with only a couple of lines of code (not included in my posting), which was most pleasing. But as soon as I tried to re-use this approach on a similar structure, it fell apart like a house of cards. It was then that I realized I needed help. Michael Sanborn Graphion From larsga@ifi.uio.no Mon Feb 15 21:14:42 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: 15 Feb 1999 22:14:42 +0100 Subject: [XML-SIG] generating a DTD from a sample document?? In-Reply-To: References: Message-ID: * Just van Rossum | | I vaguely remember someone at the Houston conference mentioning that | it is possible to generate a DTD from a sample document. It is possible, although the DTD will of course be nowhere near perfect. There exist some packages that do it, including a Java one for XML, which was just removed from its website by its creator Michael Kay. I've sent him an email about it and will post here if it reappears. --Lars M. From larsga@ifi.uio.no Mon Feb 15 21:22:09 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: 15 Feb 1999 22:22:09 +0100 Subject: [XML-SIG] Functional interface to XML? In-Reply-To: <199902112113.WAA19382@evrl.xs4all.nl> References: <199902112113.WAA19382@evrl.xs4all.nl> Message-ID: * Cees de Groot | | I've been wondering weither something functional/stylesheet-ish | exists on top of Python's XML stuff. Only saxutils.mllib, as far as I know. And that's basically just a reimplementation of the xmllib interface on top of SAX. Something that uses CSS selectors or XSL patterns to fire actions would be nice, but does not currently exist. I've always been thinking about writing something easier to use on top of SAX, but have never been able to find the time so far. (Or had sufficient need of it.) | [Code snipped] | | Is this a sensible way to process XML in Python? Yes, I definitely think so. --Lars M. From mike.olson@fourthought.com Mon Feb 15 21:37:14 1999 From: mike.olson@fourthought.com (Mike Olson) Date: Mon, 15 Feb 1999 15:37:14 -0600 Subject: [XML-SIG] Functional interface to XML? References: <199902112113.WAA19382@evrl.xs4all.nl> Message-ID: <36C8938A.3B7A57B8@fourthought.com> We are currently working on an XSL processor that sits ontop of 4DOM which inturn sites ontop of sax. It does not fire events in the sax fashion, but will return a DOM tree of formatting objects, when given a XML DOM tree with xml-stylesheet processing instructions. 4XSL is currently in the pre-alpha versions, and we hope to have a beta release in a couple of weeks. If anyone is interested, I can tar up the latest code and make it available. Just let me know. Mike Lars Marius Garshol wrote: > * Cees de Groot > | > | I've been wondering weither something functional/stylesheet-ish > | exists on top of Python's XML stuff. > > Only saxutils.mllib, as far as I know. And that's basically just a > reimplementation of the xmllib interface on top of SAX. > > Something that uses CSS selectors or XSL patterns to fire actions > would be nice, but does not currently exist. I've always been thinking > about writing something easier to use on top of SAX, but have never > been able to find the time so far. (Or had sufficient need of it.) > > | [Code snipped] > | > | Is this a sensible way to process XML in Python? > > Yes, I definitely think so. > > --Lars M. > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig -- Mike Olson Member Consultant FourThought LLC http://www.fourthought.com http://opentechnology.org --- "No program is interesting in itself to a programmer. It's only interesting as long as there are new challenges and new ideas coming up." --- Linus Torvalds From akuchlin@cnri.reston.va.us Mon Feb 15 22:40:32 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Mon, 15 Feb 1999 17:40:32 -0500 (EST) Subject: [XML-SIG] XML-Howto update In-Reply-To: <36C83B68.D9722F42@darwin.in-berlin.de> References: <199902141701.MAA27928@python.org> <36C83B68.D9722F42@darwin.in-berlin.de> Message-ID: <14024.41250.460216.346349@amarok.cnri.reston.va.us> Dinu C. Gherman writes: >sections, at least. Unfortunately, this update holds only >for the individual HTML pages, not the other formats and not >even the bundled HTML pages. Can we expect this to change ... >Hoping-not-to-reveal-stuff-to-be-announced'ly, I sent an announcement about the revision some time ago, so you're not revealing anything secret. (This is open source software; *nothing's* secret.) More comments on the documentation would be welcome. Anyway, the issue is fixed now; the PDF, PS, dvi, and bundled HTML files should now all have been updated to the current version on python.org; the mirror sites will catch up soon. -- A.M. Kuchling http://starship.python.net/crew/amk/ I'm sorry, Your Majesty. The bastard hard disk's crashed again, but this hardware's still better than Roger Bacon's mechanical head. -- Hob Gadling dreams of Queen Elizabeth I, in SANDMAN: "Season of Mists", episode 1 From paul@prescod.net Mon Feb 15 23:45:44 1999 From: paul@prescod.net (Paul Prescod) Date: Mon, 15 Feb 1999 17:45:44 -0600 Subject: [XML-SIG] Functional interface to XML? References: <199902112113.WAA19382@evrl.xs4all.nl> <36C8938A.3B7A57B8@fourthought.com> Message-ID: <36C8B1A8.9F45AA0D@prescod.net> Mike Olson wrote: > > We are currently working on an XSL processor that sits ontop of 4DOM which > inturn sites ontop of sax. It does not fire events in the sax fashion, > but will return a DOM tree of formatting objects, when given a XML DOM > tree with xml-stylesheet processing instructions. This is very exciting. Let me ask two questions, however. First, why not generate SAX events and then use your existing DOM builder to make the formatting object tree. That way you would be able to daisy chain XSL filters and other filters. Second, is the API such that some of the facilities are useful from Python? For instance can you easily look up nodes given a pattern, or do an XSL pattern-based "visit" of a node tree? I'm not sure if it is clear what I am getting at. XSL processing could be regarded as a special case of "pattern-based tree visiting." That might allow us to use an XSL visitor pattern in ordinary Python code. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco If you spend any time administering Windows NT, you're far too familiar with the Blue Screen of Death (BSOD) which displays the cause of the crash and gives some information about the state of the system when it crashed. -- "Microsoft Developer Network Magazine" From uche.ogbuji@fourthought.com Tue Feb 16 02:43:47 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Mon, 15 Feb 1999 19:43:47 -0700 Subject: [XML-SIG] Functional interface to XML? In-Reply-To: Your message of "Mon, 15 Feb 1999 15:37:14 CST." <36C8938A.3B7A57B8@fourthought.com> Message-ID: <199902160243.TAA01125@malatesta.local> > We are currently working on an XSL processor that sits ontop of 4DOM which > inturn sites ontop of sax. It does not fire events in the sax fashion, > but will return a DOM tree of formatting objects, when given a XML DOM > tree with xml-stylesheet processing instructions. Ha! Mike shows that he hasn't joined me on the xsl list, yet. Mike, just FYI, if you want to bring up XSL FOs, don your thickest asbestos. But seriously, 4XSL just deals with the transformation part of the spec, and so is purely a server-side solution. It does support a lot of the XSL transformations that you can use as effectively to emit HTML as XML-based FOs. In fact, our new web-site is entirely generated from a series of XML files using 4XSL. But I'd like to note that 4XSL doesn't yet implement many of the more esoteric parts of the transformation spec, but Mike has already mentioned the possible release schedule, and our willingness to accommodate alpha-testers. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From mike.olson@fourthought.com Tue Feb 16 02:40:10 1999 From: mike.olson@fourthought.com (Mike Olson) Date: Mon, 15 Feb 1999 20:40:10 -0600 Subject: [XML-SIG] Functional interface to XML? References: <199902112113.WAA19382@evrl.xs4all.nl> <36C8938A.3B7A57B8@fourthought.com> <36C8B1A8.9F45AA0D@prescod.net> Message-ID: <36C8DA8A.ED35BB64@fourthought.com> Paul Prescod wrote: > > First, why not generate SAX events and then use your existing DOM builder > to make the formatting object tree. That way you would be able to daisy > chain XSL filters and other filters. I guess in a sense, we really do use events to generate the tree, however just 1, match. I have defined a bunch of the templates as extensions to the element node. These are put into a tree by a XSL builder. The XSL templates then match (the one event) based on the hierachy of the XSL tree. Each template implementation returns a list of FO objects that are the result of doing the match. Each template also calls the match on any of its children that are XSL objects (Which will be all of the children) > > Second, is the API such that some of the facilities are useful from > Python? For instance can you easily look up nodes given a pattern, or do > an XSL pattern-based "visit" of a node tree? What do you mean useful from python? The patterns are completely different entities then the templates. You can have a pattern, and call its match method giving it a node. It will return either a list of nodes, or a boolean value (depending on what type of pattern it is). This could easily be used to create a pattern based visitor/filter. > I'm not sure if it is clear what I am getting at. XSL processing could be > regarded as a special case of "pattern-based tree visiting." That might > allow us to use an XSL visitor pattern in ordinary Python code. > I am confused when you say "ordinary Python code". Do you mean outside of the realm of DOM/XML/XSL? -- Mike Olson Member Consultant FourThought LLC http://www.fourthought.com http://opentechnology.org --- "No program is interesting in itself to a programmer. It's only interesting as long as there are new challenges and new ideas coming up." --- Linus Torvalds From srn@techno.com Tue Feb 16 01:05:22 1999 From: srn@techno.com (Steven R. Newcomb) Date: Mon, 15 Feb 1999 19:05:22 -0600 Subject: [XML-SIG] SQL -> XML ? In-Reply-To: <36C83ABC.699013A6@prescod.net> (message from Paul Prescod on Mon, 15 Feb 1999 09:18:20 -0600) References: <199902120422.VAA08435@malatesta.local> <199902121606.KAA01331@bruno.techno.com> <36C6CB90.8D171912@prescod.net> <199902142223.QAA01508@bruno.techno.com> <36C83ABC.699013A6@prescod.net> Message-ID: <199902160105.TAA00796@bruno.techno.com> [Paul Prescod:] > The question was, how can this sort of > transformation be done *efficiently*. The > progenitor of the thread already had a solution > to the tranformation problem. It just was not > efficient. Losslessly encoding an RDBMS as a > text file is easy with or without groves. Doing > it efficiently can be difficult in either case. "Efficiently" is too vague. Which kinds of expenses are we attempting to minimize, and in what proportions? In some cases, at least, applying the grove paradigm is a big win in terms of overall efficiency. But the up-front cost of using the grove paradigm is pretty significant; you have to do a lot of rigorous thinking, and that isn't cheap. Like the setup charge for doing 4-color high-speed presswork, it makes no sense to incur such a setup charge for a run of 500 copies, and the break-even point often over 10,000 copies. But there is no cheaper way to make 20,000 or more color copies, and the more copies you make, the cheaper it gets. There is no way to make the setup charge cheaper without increasing the overall cost per copy, throughout the marketable life of the printed product. > > The implementation strategy is to apply the grove > > paradigm. > But what algorithms, data structures and SQL > queries does one use to do this efficiently? These things all depend on the nature of the information, the importance of being able to do things with the information that you might not be able to anticipate, and the breadth of the known application space, among many other things. How could it possibly be otherwise? I don't see how there can possibly be one efficient algorithmic answer for all cases, even without considering the number and breadth of applications for which RDBMSs are suboptimal, but have been used anyway for reasons that had little to do with efficiency. In many cases, a quick and dirty solution is very appropriate; such solutions are always immediate-need-driven and efficiency may matter very little. If you need only two copies, it's perfectly reasonable to use some sort of brute force method, while expecting the cost per copy to be extremely high, compared to the cost per copy of an optimized run of 20,000. However, in cases where a comparatively high upfront "setup charge" for a given information set is not an obstacle, it's nice to know there's a technologically supportable paradigm, itself supported by a cogent philosophy, for developing a solution. The specific algorithms and data structures will suggest themselves when the grove paradigm is thoughtfully applied, and in every situation, they will be somewhat different. (There are, of course, some archetypical solutions that one should know about and apply, such as the notions of hyperlinking, addressing, use by reference, namespace management, activity policies, popular graphical user interfaces, widespread display protocols like HTML, etc. etc. Significant efficiency enhancements can often be realized by applying existing methodologies, existing interchange syntaxes, and existing software.) -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA From uche.ogbuji@fourthought.com Tue Feb 16 03:47:00 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Mon, 15 Feb 1999 20:47:00 -0700 Subject: [XML-SIG] Functional interface to XML? In-Reply-To: Your message of "Mon, 15 Feb 1999 17:45:44 CST." <36C8B1A8.9F45AA0D@prescod.net> Message-ID: <199902160347.UAA01183@malatesta.local> > Mike Olson wrote: > > We are currently working on an XSL processor that sits ontop of 4DOM which > > inturn sites ontop of sax. It does not fire events in the sax fashion, > > but will return a DOM tree of formatting objects, when given a XML DOM > > tree with xml-stylesheet processing instructions. Paul Prescod: > First, why not generate SAX events and then use your existing DOM builder > to make the formatting object tree. That way you would be able to daisy > chain XSL filters and other filters. I don't think we've thought of this, and it's actually a good idea. We primarily use it to emit HTML or transformed (non-FO) XML for now, but we could provide a SAX interface to make it more useful. Just as interestingly, though, your suggestion exposes a weakness in 4DOM that I had already planned to rectify by 0.7.1. Currently our Builder module hard-codes a SAX handler. The handler class itself should be a parameter so that users can chain filters all they want while building DOM nodes from SAX events. > Second, is the API such that some of the facilities are useful from > Python? For instance can you easily look up nodes given a pattern, or do > an XSL pattern-based "visit" of a node tree? > > I'm not sure if it is clear what I am getting at. XSL processing could be > regarded as a special case of "pattern-based tree visiting." That might > allow us to use an XSL visitor pattern in ordinary Python code. Well, I'm still not sure I get your meaning, but the pattern-matching code is pretty well de-coupled from the tree-visiting portion. This is to allow easier updates as the XSL WG modifies their spec. I'm not sure how usable the API would be when exposed outside 4XSL, but we can certainly keep such potential use in mind. Are you thinking of maybe extending the transformation facilities of a style-sheet using Python, rather than the erstwhile ECMAScript? -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From paul@prescod.net Tue Feb 16 17:35:15 1999 From: paul@prescod.net (Paul Prescod) Date: Tue, 16 Feb 1999 11:35:15 -0600 Subject: [XML-SIG] Functional interface to XML? References: <199902160347.UAA01183@malatesta.local> Message-ID: <36C9AC53.4727FE4D@prescod.net> uche.ogbuji@fourthought.com wrote: > > I don't think we've thought of this, and it's actually a good idea. I'd better go patent it! > We > primarily use it to emit HTML or transformed (non-FO) XML for now, but we > could provide a SAX interface to make it more useful. If you are just emitting HTML wouldn't it be easier and more efficient to use a "reverse SAX" output engine instead of building and walking a DOM. I believe XSL is designed so that you can output everything as you generate it. > Well, I'm still not sure I get your meaning, but the pattern-matching code is > pretty well de-coupled from the tree-visiting portion. This is to allow > easier updates as the XSL WG modifies their spec. I'm not sure how usable the > API would be when exposed outside 4XSL, but we can certainly keep such > potential use in mind. > > Are you thinking of maybe extending the transformation facilities of a > style-sheet using Python, rather than the erstwhile ECMAScript? Well that goes without saying. :) What I am *really* interested in is answer Cee's de Groot's question (which is also mine) of an API that *Python programmers* can use that acts like XSL or DSSSL but uses Python syntax. Think of it this way: if XSL does 90% of what you want then you want to just extend it with Python. If XSL only does 20% of what you want then you want those XSL features in Python without the XSL stylesheet syntax. Imagine something like this: """ Warnings: Of course you should use your own descretion in deciding whether implementing this idea makes sense, especially since you've already done so much work. I move between the DOM, the grove and a few other APIs so I can never keep them straight in my head. So the method calls and class names below are mostly fanciful. Also, I've left out the required __init__ methods to set up object data. """ visitor = xsllib.XSLPatternVisitor() def DoSomethingWithDocTitles( node, engine ): blah engine.ApplyTemplates( node, "TITLE" ) blah engine.ApplyTemplates( node, ".//FN" ) visitor.register( DoSomethingWithTitles, "DOC/TITLE") def DoSomethingWithChapterTitles( node, engine ): blah engine.ValueOf( node ) blah visitor.register( DoSomethingWithTitles, "CHAPTER/TITLE") def DoSomethingWithFootnotesInChapters( node, engine ): blah for i in node.Children: # or is "Content" in DOM blah blah visitor.register( DoSomethingWithFootnotesInChapters, "CHAPTER//FN" ) """ Do you see what I'm getting at? Now you could imlement "real" XSL in terms of these primitives. """ class ApplyTemplatesNode( ElementNode ): def invoke( self ): self.engine.ApplyTemplates( self ) class LiteralResultNode( ElementNode ): def invoke( self ): self.result.ElementEvent( self.TagName ) class LiteralResultTextNode( TextNode ): def invoke( self ): self.result.TextEvent( self.TextValue ) ... (somewhere else) class xsl_templateRuleNode( ElementNode ): def __init__( self, visitor, tagName, template, attrs... ): self.visitor.register( self.template.invoke, attrs["PATTERN"] ) Hope that helps! -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco If you spend any time administering Windows NT, you're far too familiar with the Blue Screen of Death (BSOD) which displays the cause of the crash and gives some information about the state of the system when it crashed. -- "Microsoft Developer Network Magazine" From uche.ogbuji@fourthought.com Wed Feb 17 01:35:33 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 16 Feb 1999 18:35:33 -0700 Subject: [XML-SIG] Functional interface to XML? In-Reply-To: Your message of "Tue, 16 Feb 1999 11:35:15 CST." <36C9AC53.4727FE4D@prescod.net> Message-ID: <199902170135.SAA03139@malatesta.local> > > We > > primarily use it to emit HTML or transformed (non-FO) XML for now, but we > > could provide a SAX interface to make it more useful. > > If you are just emitting HTML wouldn't it be easier and more efficient to > use a "reverse SAX" output engine instead of building and walking a DOM. I > believe XSL is designed so that you can output everything as you generate > it. Probably. I'll be the first to admit that we've been working in "quickest way from A to B" mode, and haven't seriously enough incorporated performance concerns to our approach. This might limit 4SXL's general usefulness until we optimize it. I'll cache this among the growing list of "excellent Prescod suggestions" in our design process. > > Well, I'm still not sure I get your meaning, but the pattern-matching code is > > pretty well de-coupled from the tree-visiting portion. This is to allow > > easier updates as the XSL WG modifies their spec. I'm not sure how usable the > > API would be when exposed outside 4XSL, but we can certainly keep such > > potential use in mind. > What I am *really* interested in is answer Cee's de Groot's question > (which is also mine) of an API that *Python programmers* can use that acts > like XSL or DSSSL but uses Python syntax. Think of it this way: if XSL > does 90% of what you want then you want to just extend it with Python. If > XSL only does 20% of what you want then you want those XSL features in > Python without the XSL stylesheet syntax. Aah, the light dawns. And I guess this one also goes into the list of useful suggestions. I like the idea a lot, and I can already forsee many useful applications. The main problem will be how much effort into modifying the current design would be required. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From jae@kavi.com Wed Feb 17 22:22:48 1999 From: jae@kavi.com (John Eikenberry) Date: Wed, 17 Feb 1999 14:22:48 -0800 (PST) Subject: [XML-SIG] non-xml format to xml Message-ID: Hello, I'm beggining to work on an set of xml tools (dtd, conversion tools) for Redhat's packages (rpms). I was curious if there was a 'best way' to convert to/from non-xml formats (rpm's package building description files, aka. .spec files) to xml format. I was thinking of using DOM, and adding methods for building the tree from the .spec file and outputtin the tree to this format. I choose this over sax with the idea that it would be easier to integrate into other apps over time (perhaps a gui packaging interface or the like). How have other people done this? Thanks in advance for any tips, --- John Eikenberry [jae@kavi.com - http://taos.kavi.com/~jae/] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin From tismer@appliedbiometrics.com Fri Feb 19 17:50:42 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 19 Feb 1999 18:50:42 +0100 Subject: [XML-SIG] Wink converter, anyone? (was: [Crew] python.net domain suggestion) References: <19990219174155.17249.qmail@lannert.rz.uni-duesseldorf.de> Message-ID: <36CDA472.5B796D88@appliedbiometrics.com> lannert@lannert.rz.uni-duesseldorf.de wrote: > > "Christian Tismer" wrote: > [...] > > > > just-realized-that-the-Tim-Peters--isn_t-XML-compatible - chris > > Oh, migration should be easy. > Like translating Python code into XML syntax. > > from xml.dom import WinkConverter > > ;-) > > Detlef > > _______________________________________________ > Crew maillist - Crew@starship.python.net > http://starship.python.net/mailman/listinfo/crew Well, fine solution. The remaining question is wether we should re-process the whole mail archives to correct this? I'm also preparing a RFC about how future emoticons should be embedded as XML. (RFC4711) ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From joe@strout.net Fri Feb 19 18:03:44 1999 From: joe@strout.net (Joseph J. Strout) Date: Fri, 19 Feb 1999 10:03:44 -0800 Subject: [XML-SIG] yet another newbie Message-ID: Hi all, I'm just starting to look into XML; I've browsed the recent archives of the sig and poked around in the documentation and web sites. My specific goal is to start keeping all our documentation in XML, and have this converted to HTML for human browsing. I was surprised that I didn't find a DTD for documentation anywhere. I thought this would be a very common application? Or is there some reason this isn't a good idea? Thanks for any advice, -- Joe ,------------------------------------------------------------------. | Joseph J. Strout Biocomputing -- The Salk Institute | | joe@strout.net http://www.strout.net | `------------------------------------------------------------------' From Fred L. Drake, Jr." References: Message-ID: <14029.43603.814292.539808@weyr.cnri.reston.va.us> Joseph J. Strout writes: > My specific goal is to start keeping all our documentation in XML, > and have this converted to HTML for human browsing. I was surprised that I > didn't find a DTD for documentation anywhere. I thought this would be a > very common application? Or is there some reason this isn't a good idea? Take a look at DocBook; it's available in both SGML & XML flavors. Start with http://www.oasis-open.org/docbook/. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From print2live@altavista.net Sun Feb 21 00:16:11 1999 From: print2live@altavista.net (print2live@altavista.net) Date: Sun, 21 Feb 1999 00:16:11 Subject: [XML-SIG] AD:Family Reunion T Shirts & More Message-ID: <199902210845.DAA13252@python.org> Message sent by: Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052, 1-800-810-4330. This list will NOT be sold. All addresses are automatically added to our remove list. Hello. My name is Bill from Kuppler Graphics. We do screenprinting on T Shirts, Sweatshirts, Jackets, Hats, Tote Bags and more! Do you or someone you know have a Family Reunion coming up? Kuppler Graphics would like to provide you with some great looking T Shirts for your Reunion. Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity (church, school, business etc.) We are a family owned company with over 15 years of experience. All work is done at this location. No middle man. Our prices are great! Click reply to email us or call 1-800-810-4330 for more info Bill Kuppler Graphics From gherman@darwin.in-berlin.de Sun Feb 21 21:01:48 1999 From: gherman@darwin.in-berlin.de (Dinu C. Gherman) Date: Sun, 21 Feb 1999 22:01:48 +0100 Subject: [XML-SIG] XSL support? Message-ID: <36D0743C.679E5D35@darwin.in-berlin.de> Hello all, I found a nice Java package called TeXML, made by IBM, which will generate TeX and HTML from some simple XML. As a means of getting deeper into the Python XML package I thought of trying to port it to Python. Now TeXML makes use of XSL and I can't remember having read anything about support for that in the Python XML packages. Is that so or am I utterly wrong? Dinu -- Dinu C. Gherman : Mit Berlin kannste mir jagen! ................................................................ LHS International AG : http://www.lhsgroup.com 8050 Zurich : http://www.zurich.ch Switzerland : http://pgp.ai.mit.edu : mobile://49.172.3060751 From uche.ogbuji@fourthought.com Mon Feb 22 00:56:19 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Sun, 21 Feb 1999 17:56:19 -0700 Subject: [XML-SIG] XSL support? In-Reply-To: Your message of "Sun, 21 Feb 1999 22:01:48 +0100." <36D0743C.679E5D35@darwin.in-berlin.de> Message-ID: <199902220056.RAA28418@malatesta.local> > I found a nice Java package called TeXML, made by IBM, which will > generate TeX and HTML from some simple XML. As a means of getting > deeper into the Python XML package I thought of trying to port it > to Python. Now TeXML makes use of XSL and I can't remember having > read anything about support for that in the Python XML packages. > Is that so or am I utterly wrong? That is so for now. We are working on an XSL processor for Python, and it should be available in alpha soon, but it won't at first support all matching patterns, just the ones we have found most common, with the support growing in further releases. Porting TeXML to Python might be a heavy task to undertake for just "getting deeper into the Python XML package". It's pretty sophisticated, from my experiments with it. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From krussll@cc.UManitoba.CA Wed Feb 24 02:23:11 1999 From: krussll@cc.UManitoba.CA (Kevin Russell) Date: Tue, 23 Feb 1999 20:23:11 -0600 Subject: [XML-SIG] DOM walker examples Message-ID: <36D3628F.2A9E3EDC@cc.umanitoba.ca> I notice the XML howto still has a blank space for examples of DOM walking. I've finally wrapped my head around CVS (by the way, is it a good idea for the howto to talk about stuff that's only available through CVS and not from the ordinary web-site?) and played around with it. A couple of my toy programs might be appropriate howto-examples, so here they are. -- Kevin Russell -------------- """killnote.py A DOM-walker example: remove all "note" elements from a document """ from xml.dom import utils, walker from sys import argv class NoteKiller (walker.Walker): def startElement(self,node): if node.nodeName == 'note': node.parentNode.removeChild(node) if __name__ == '__main__': f = utils.FileReader() doc = f.readFile(argv[1]) NoteKiller().walk(doc) print doc.toxml() --------------- """renumber.py A DOM-walker example: give each element a unique ID attribute """ from xml.dom import utils, walker from sys import argv class NumberingWalker (walker.Walker): counters = {} def startElement(self,node): try: self.counters[node.nodeName] = self.counters[node.nodeName] + 1 except KeyError: self.counters[node.nodeName] = 1 node.setAttribute('id', '%s%s' % (node.nodeName, self.counters[node.nodeName])) if __name__ == '__main__': f = utils.FileReader() doc = f.readFile(argv[1]) NumberingWalker().walk(doc) print doc.toxml() From gherman@darwin.in-berlin.de Wed Feb 24 11:27:50 1999 From: gherman@darwin.in-berlin.de (Dinu C. Gherman) Date: Wed, 24 Feb 1999 12:27:50 +0100 Subject: [XML-SIG] XSL support? References: <199902221701.MAA28999@python.org> Message-ID: <36D3E236.68553EBF@darwin.in-berlin.de> Uche Ogbuji wrote: > That is so for now. We are working on an XSL processor for Python, and it > should be available in alpha soon, but it won't at first support all matching > patterns, just the ones we have found most common, with the support growing in > further releases. Well, that makes sense. The XSL spec is a real monster document... Do you already provide official information about it? Will it be self-contained or make use of xmlproc given it's ability to handle namespaces now? Will it make use of DOM, or build its own formatting trees? > Porting TeXML to Python might be a heavy task to undertake for just "getting > deeper into the Python XML package". It's pretty sophisticated, from my > experiments with it. I'm not quite sure. There are two Java files in source code which don't look that difficult to port, but there are also some classes in a Jar file without source code and that might cause some prob- lems, of course. Anybody aware of the latest decompiling achieve- ments for java? ;-) Dinu -- Dinu C. Gherman : Mit Berlin kannste mir jagen! ................................................................ LHS International AG : http://www.lhsgroup.com 8050 Zurich : http://www.zurich.ch Switzerland : http://pgp.ai.mit.edu : mobile://49.172.3060751 From Jeff.Johnson@icn.siemens.com Wed Feb 24 16:03:28 1999 From: Jeff.Johnson@icn.siemens.com (Jeff.Johnson@icn.siemens.com) Date: Wed, 24 Feb 1999 11:03:28 -0500 Subject: [XML-SIG] CVS instructions don't seem to work for me Message-ID: <85256722.00580F6C.00@li01.lm.ssc.siemens.com> When I try to get friends of mine to use Python and the XML package I always have to get my CVS batch file from work because the instructions on the XML SIG web page don't work (for me at least). I have included my batch file below. I have two of them, one which does the initial checkout (below) and one that updates. To create the update batch file, just comment out the line that checks out and uncomment the last line. If the web page instructions really are incorrect, could we get them updated? Thanks :) set HOME=\cvs set CVSROOT=:pserver:xmlcvs@cvs.python.org:/projects/cvsroot REM cvs login REM cvs -z3 update -d -P cvs -d :pserver:xmlcvs@cvs.python.org:/projects/cvsroot login REM This line checks out cvs -z3 -d :pserver:xmlcvs@cvs.python.org:/projects/cvsroot co xml REM This line updates whatever was checked out REM cvs -z3 update -d -P From larsga@ifi.uio.no Thu Feb 25 11:53:51 1999 From: larsga@ifi.uio.no (Lars Marius Garshol) Date: 25 Feb 1999 12:53:51 +0100 Subject: [XML-SIG] XBEL to HTML converter demo Message-ID: As a demo for a tutorial I'm giving I've a simple XBEL to HTML converter using SAX. I'm posting it here, since it could probably be a useful addition to the demo directory. Please let me know if it will be added, since I'll post it on the web myself if it isn't. --Lars M. """ A simple XBEL to HTML converter written with SAX. """ # Limitations: will screw up if a folder lacks a 'title' element. # no checking of the command-line args import sys from xml.sax import saxlib,saxutils,saxexts # --- HTML templates top=\ """ %s

%s

""" bottom=\ """
Converted from XBEL by sax_xbel, using %s.
""" # --- DocumentHandler class XBELHandler(saxlib.HandlerBase): def __init__(self,parser,writer=sys.stdout): self.stack=[] self.writer=writer self.last_url=None self.parser=parser self.inside_ul=0 self.level=0 def startElement(self,name,attrs): self.stack.append(name) if name=="bookmark": self.last_url=attrs["href"] def characters(self,data,start,length): if self.stack==[]: return if self.stack[-1]=="title" and self.stack[-2]=="xbel": data=data[start:start+length] self.writer.write(top % (data,data)) self.state=None if self.stack[-1]=="desc" and self.stack[-2]=="xbel": self.writer.write("

%s

\n" % data[start:start+length]) if self.stack[-1]=="title" and self.stack[-2]=="bookmark": if not self.inside_ul: self.inside_ul=1 self.writer.write("
    \n") self.writer.write('
  • %s. \n' % (self.last_url,data[start:start+length])) if self.stack[-1]=="desc" and self.stack[-2]=="bookmark": self.writer.write(data[start:start+length]+"\n\n") if self.stack[-1]=="title" and self.stack[-2]=="folder": self.writer.write("
  • %s\n" % data[start:start+length]) self.writer.write("
      \n") self.inside_ul=1 def endElement(self,name): del self.stack[-1] if name=="folder": self.writer.write("
    \n") def endDocument(self): self.writer.write("
\n") self.writer.write(bottom % self.parser) # --- Main program p=saxexts.make_parser() p.setDocumentHandler(XBELHandler(p.get_parser_name())) p.setErrorHandler(saxutils.ErrorPrinter()) p.parse(sys.argv[1]) From Fred L. Drake, Jr." References: Message-ID: <14037.23261.482799.722130@weyr.cnri.reston.va.us> Lars Marius Garshol writes: > As a demo for a tutorial I'm giving I've a simple XBEL to HTML > converter using SAX. I'm posting it here, since it could probably be a > useful addition to the demo directory. Please let me know if it will > be added, since I'll post it on the web myself if it isn't. Lars, I think this would make a very good example for the distribution and HOWTO. The size is just right. I can't promise that Andrew will add it to the CVS archive, though. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From spepping@scaprea.hobby.nl Fri Feb 26 19:42:54 1999 From: spepping@scaprea.hobby.nl (Simon Pepping) Date: Fri, 26 Feb 1999 20:42:54 +0100 Subject: [XML-SIG] DOM walker examples In-Reply-To: <36D3628F.2A9E3EDC@cc.umanitoba.ca>; from Kevin Russell on Tue, Feb 23, 1999 at 08:23:11PM -0600 References: <36D3628F.2A9E3EDC@cc.umanitoba.ca> Message-ID: <19990226204254.A716@scaprea.hobby.nl> On Tue, Feb 23, 1999 at 08:23:11PM -0600, Kevin Russell wrote: > """renumber.py > A DOM-walker example: give each element a unique ID attribute > """ > > from xml.dom import utils, walker > from sys import argv > > class NumberingWalker (walker.Walker): > counters = {} Note that in this way counters is a class attribute, shared by all objects. It is better to initialize it in __init__: def __init__(self): self.counters = {} Simon Pepping email: spepping@scaprea.hobby.nl From wes@rishel.com Sun Feb 28 08:12:30 1999 From: wes@rishel.com (Wes Rishel) Date: Sun, 28 Feb 1999 00:12:30 -0800 Subject: [XML-SIG] XML-Howto update--->Where? In-Reply-To: <14024.41250.460216.346349@amarok.cnri.reston.va.us> Message-ID: <000001be62f2$163da920$69510018@c79145-a.almda1.sfba.home.com> > Dinu C. Gherman writes: > >sections, at least. Unfortunately, this update holds only > >for the individual HTML pages, not the other formats and not > >even the bundled HTML pages. Can we expect this to change Kuchling writes: > Anyway, the issue is fixed now; the PDF, PS, dvi, and bundled HTML > files should now all have been updated to the current version on > python.org; the mirror sites will catch up soon. Where are people finding these updates, especially the downloads in a complete package? http://www.python.org/topics/xml/docs.html contains the documents that Ghreman is and Kuchling are probably referring to, but only as a set of discrete HTML files. http://www.python.org/topics/xml/download.html contains a link to http://www.python.org/sigs/xml-sig/files/xml-0.4.tgz which is advertised as "the complete package" and seemingly has not changed since 8/6/98. http://www.python.org/sigs/xml-sig/files/ contains no files that have changed since Dec 4. Thanks in advance. BTW, one recognizes that those who are busy advancing the state of the code base need to minimize the time spent documenting, but someone might consider bringing http://www.python.org/topics/xml/download.html up to release 0.5, since it has been out for nearly three months. Being a newby, I struggled with rel 4 for a long time, because the page seemed authoritative and I was not sure of the status of stuff in the bare .../files directory.