From uche.ogbuji@fourthought.com Mon Nov 1 05:52:55 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Sun, 31 Oct 1999 22:52:55 -0700 Subject: [XML-SIG] Hello In-Reply-To: Your message of "Sat, 30 Oct 1999 16:58:45 EDT." <19991030165845.B15238@trump.amber.org> Message-ID: <199911010552.WAA01077@localhost.localdomain> > Without wishing to start a "flame war", I would argue that storing your > data in XML has little if any value... being able to represent it in XML > which needed is much more important. XML is from my perspective a data > interchange format, one which easily surpases nearly all others. It's not > a database format, however. Maybe I've just been scared off by all the > hype. It's far more than that, but your description is a start. > Anyway, as for Zope (since I'm one of the product manager), DTML was > never inteded to be XML + XSL/T, for a couple reasons: > > o DTML predates XML by year and years > o XSL/T is a moving target > o XSL is way too burdensome for most users Oh please. First of all, DTML's precedence means nothing. Would you suggest users go back to VSAM? The main thing is that XML has truly global support by many industries. This will be hard for any proprietary standard to top. As for XSLT, it is frozen, and only waits final W3C approval (and the TBL annointment) to become a W3C rec. There goes the "moving target" argument. There are several processors that support the final standard: XT, Saxon, LotusXSL, and, in part 4XSLT in Python. Please explain what you mean by "burdensome". If you mean because it is declarative, I'll point out that some people learn XSLT much more quickly than procedural programming. Python programmers are probably not automatically sympathetic to declarative programming, but remember that it takes all sorts. If you mean optimization, there is already a lot of work on this in the xsl-list, and I think that the theory of XSLT optimization, because driven by a broader community and rooted in more CS history, will progress faster than proprietary alternatives. > As for the last, I put forward that if it takes myself or someone else > I work with HOURS to figure out how to do something that we do in DTML > trivially, then it's not as simple as it should be. DTML provides things > like tree representation with automatic handling of expansion/closing, > as well as batch management. It is a REPORTING language, not a transform > language, there is a fundemental difference in the targets. Exactly. You should have said that, rather than shooting general broadsides at XSLT. I would imagine an XML reporting language more as a DOM-based framework around XQL than XSLT. > Having said that, we're commited to using XML where it's appropriate, > and have some cool stuff that works with DOMs right now. It will be > driven by customer needs, however, rather than blind adhearance to > standards. Let me note that entities such as Microsoft and the old, bad IBM often defended their avoidance of open standards by talking disdainfully about "blind" adoption. Clear statement of problems with standards and open discussions of improvements is more fruitful. I'd like to hear more precise explanations of areas where you or the Zope community think XML is unsuitable. Mind you, I have no argument with Zope: Zope 2.0 is very nifty. I just want useful discussion of the issues with no off-hand dismissals. -- 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 uche.ogbuji@fourthought.com Mon Nov 1 06:16:10 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Sun, 31 Oct 1999 23:16:10 -0700 Subject: [XML-SIG] Hello In-Reply-To: Your message of "Fri, 29 Oct 1999 11:45:32 BST." <199910291045.LAA31274@pukapuka.inrialpes.fr> Message-ID: <199911010616.XAA01192@localhost.localdomain> > Another good news is that the FourThought guys have released recently > parts of their 4Suite, including the XSLT and XPath packages. I haven't > tried them yet, so I'm not in a position to comment whether the > implemented subset of the W3C recommendation (PR-xslt-19991008) will > suffice for my task. (I can only regret that James Clark's XT was written > in Java, and not in Python. I'll tell Vincent Quint to convert him ;-) The most significant parts of the PR that are not yet implemented are sorting, numbering and output specifiers. You may have noticed that development is proceeding swiftly, especially since the volume of feedback, patches and suggestions has been growing rapidly. We expect to round things off in a month or two and move on to focus on optimization. > So, I wonder whether I really have today the Python basic bricks to perform > the following: > > 0) Define my DTD and deduce the user-friendly forms for 1). I believe Alphaworks has a few good tools for form-generation from DTD, and Schemas should truly accelerate this important area. > 1) Fill my content via user-friendly forms (a la Zope) > 2) This content is wrapped and stored in XML. My understanding is that you can already do this using Zope and generating XML (and very well, too), so rather than look for an "a la Zope", why not just use Zope? > 3) The XML files are processed according to my stylesheets and the XSLT > processor. As long as you don't depend on sorting, numbering and output-tweaking, and you don't mind that it's not yet optimized, I encourage you to look at 4XSLT. > 4) The formatted result (currently in valid HTML 4.0) shines on my screen > (when I click on Zope's preview, for example) It should be straightforward to create a python script to do take the output from the Zope forms, transform it with XSLT (or XT if it suits you better), and then launch netscape to preview the result. Hopefully someone is working on Python scripting for Mozilla, which would really be a slam-dunk. > I wish that the people at DC consider a strategical move for Zope, > so that this excellent product incorporates (or is interfaced with) > the W3C standards. Damn, even the examples in Zope are not in valid HTML! > DTML is good (it was developped before the current standards), but a shift > or a bidirectional converter DTML<->XSL/T would be a major win. Whether > this is doable is another story. I don't know too much of the details yet, > but I plan to get at full speed shortly :-) My impression has been that even though you hear the occasional XML put-down from the Zope camp, Zope is embracing XML. Hopefully XHTML and HTML 4.0 comes along for the ride. -- 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 uche.ogbuji@fourthought.com Mon Nov 1 06:21:44 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Sun, 31 Oct 1999 23:21:44 -0700 Subject: [XML-SIG] Installing 4Suite Message-ID: <199911010621.XAA01214@localhost.localdomain> I should mention, since several have made the well-justified comments about 4Suite needing too much time to set-up, that we have RPMs for all ftp://ftp.FourThought.com/pub/mirrors/python4linux/redhat/i386 Of course non-linux users are neglected for now, but we're working towards Windows packaging. For Redhat, Mandrake, SuSE, etc. users (and Debian through alien), it's as easy as downloading 4DOM-0.8.2-1.noarch.rpm 4Suite-base-0.6.1-1.noarch.rpm 4XPath-0.7.2-1.i386.rpm 4XSLT-0.7.2-1.i386.rpm and rpm -i 4*.rpm -- 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 a.eyre@optichrome.com Mon Nov 1 11:47:21 1999 From: a.eyre@optichrome.com (Adrian Eyre) Date: Mon, 1 Nov 1999 11:47:21 -0000 Subject: [XML-SIG] pyexpat & xmlproc Message-ID: <000001bf245e$db27d610$3acbd9c2@peridot.optichrome.com> Is there any reason why pyexpat (written in C) is slower than xmlproc (written in Python)? -------------------------------------------- Adrian Eyre Optichrome Computer Solutions Ltd Maybury Road, Woking, Surrey, GU21 5HX, UK Tel: +44 1483 740 233 Fax: +44 1483 760 644 http://www.optichrome.com -------------------------------------------- From uche.ogbuji@fourthought.com Mon Nov 1 21:36:41 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Mon, 01 Nov 1999 14:36:41 -0700 Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: Your message of "Mon, 01 Nov 1999 11:47:21 GMT." <000001bf245e$db27d610$3acbd9c2@peridot.optichrome.com> Message-ID: <199911012136.OAA03690@localhost.localdomain> > Is there any reason why pyexpat (written in C) is slower than xmlproc > (written in Python)? I've noticed this too. My first guess would be that pyexpat requires a lot of round-trips from Python to C and back (C back to Python can be expensive). -- 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 a.eyre@optichrome.com Tue Nov 2 10:02:46 1999 From: a.eyre@optichrome.com (Adrian Eyre) Date: Tue, 2 Nov 1999 10:02:46 -0000 Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: <199911012136.OAA03690@localhost.localdomain> Message-ID: <001001bf2519$695c9af0$3acbd9c2@peridot.optichrome.com> >> Is there any reason why pyexpat (written in C) is slower than xmlproc >> (written in Python)? > I've noticed this too. My first guess would be that pyexpat requires a lot of > round-trips from Python to C and back (C back to Python can be expensive). Are there any parsers for the XML kit which are faster than xmlproc? -------------------------------------------- Adrian Eyre Optichrome Computer Solutions Ltd Maybury Road, Woking, Surrey, GU21 5HX, UK Tel: +44 1483 740 233 Fax: +44 1483 760 644 http://www.optichrome.com -------------------------------------------- From fredrik@pythonware.com Tue Nov 2 10:25:11 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 2 Nov 1999 11:25:11 +0100 Subject: [XML-SIG] pyexpat & xmlproc References: <001001bf2519$695c9af0$3acbd9c2@peridot.optichrome.com> Message-ID: <003f01bf251c$8c0b3540$f29b12c2@secret.pythonware.com> > Are there any parsers for the XML kit which are faster than xmlproc? some alternatives: qp_xml (an optimized layer on top of pyexpat): http://www.lyra.org/greg/python/qp_xml.py sgmlop (about as fast as can be, but a bit incomplete) http://www.pythonware.com/madscientist/index.htm From a.eyre@optichrome.com Tue Nov 2 10:37:31 1999 From: a.eyre@optichrome.com (Adrian Eyre) Date: Tue, 2 Nov 1999 10:37:31 -0000 Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: <003f01bf251c$8c0b3540$f29b12c2@secret.pythonware.com> Message-ID: <001101bf251e$442a6960$3acbd9c2@peridot.optichrome.com> > some alternatives: > [snip] What's the deal with the Fourthought bits and pieces? Are they any better that the rest of the Python XML bits? Are they freely redistributable? Are there any plans to integrate them into the standard Python XML distribution? -------------------------------------------- Adrian Eyre Optichrome Computer Solutions Ltd Maybury Road, Woking, Surrey, GU21 5HX, UK Tel: +44 1483 740 233 Fax: +44 1483 760 644 http://www.optichrome.com -------------------------------------------- From uche.ogbuji@fourthought.com Tue Nov 2 16:20:25 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 02 Nov 1999 09:20:25 -0700 Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: Your message of "Tue, 02 Nov 1999 10:37:31 GMT." <001101bf251e$442a6960$3acbd9c2@peridot.optichrome.com> Message-ID: <199911021620.JAA06037@localhost.localdomain> > What's the deal with the Fourthought bits and pieces? > > Are they any better that the rest of the Python XML bits? Thay are largely complementary to the Python XML package. The only overlap right now is the DOM implementation. I'm a bit biased, as one of the 4DOM developers, but I'd say that PyDOM has suffered a bit from lack of development lately. It used to have several pythonic features that set it apart from 4DOM, but I think 4DOM has caught up, with py-list derived NodeList, py-dict derived NamedNodeMap, smarter node __repr__, etc. It is also quite a bit faster, apparently because of the proxying system for automatic circ ref prevention in PyDOM. We also experimented with such an approach and didn't like the results, so we just left it to explicit deep node removal. The CORBA legacy was also long a knock on 4DOM for non-CORBA users, but we've had an "orbless" config for a while now. There are still "__skel" files and other CORBA-isms, but they're all dummies. We soon plan to make a major overhaul to exorcize CORBA from the core even in appearance. We shall still support CORBA, but through an optional wrapper about the core classes, as it probably should have been at the start. > Are they freely redistributable? Yes. All the 4Suite tools use a similar license as Python itself. > Are there any plans to integrate them into the standard > Python XML distribution? Now that's one for long discussion... -- 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 uche.ogbuji@fourthought.com Tue Nov 2 16:31:38 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 02 Nov 1999 09:31:38 -0700 Subject: [XML-SIG] 4DOM future Message-ID: <199911021631.JAA06063@localhost.localdomain> Well with all the recent discussion, I thought I'd discuss our near-term plans for 4DOM and seek feedback. As I've said, we plan to remove even the appearnace of CORBA from the next version. There won't even be a "make". It will ship as a straight Python package. There will be separate add-on libs for Fnorb and ILU support, but most users needn't concern themselves with those. Also, we are thinking of eliminating the getSpam() and setEggs() convention. Right now, one uses node.getParent() to access the DOM attribute node.parent We are thinking of simply doing the same thing in Python. The problem is that DOM adherence is still very important to us, and there are some things we'd have to do that require __getattr__ and __setattr__, and I know that these can slow things down quite a bit. I'm assuming that's why PyDOM uses node.get_parent() Any comment about the "right" way, Python as well as DOM-wise? Thanks. -- 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 ken@bitsko.slc.ut.us Tue Nov 2 18:29:29 1999 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 02 Nov 1999 12:29:29 -0600 Subject: [XML-SIG] 4DOM future In-Reply-To: uche.ogbuji@fourthought.com's message of "Tue, 02 Nov 1999 09:31:38 -0700" References: <199911021631.JAA06063@localhost.localdomain> Message-ID: uche.ogbuji@fourthought.com writes: > Also, we are thinking of eliminating the getSpam() and setEggs() > convention. Right now, one uses > > node.getParent() > > to access the DOM attribute > > node.parent > > We are thinking of simply doing the same thing in Python. > > The problem is that DOM adherence is still very important to us, and > there are some things we'd have to do that require __getattr__ and > __setattr__, and I know that these can slow things down quite a bit. > > I'm assuming that's why PyDOM uses > > node.get_parent() > > Any comment about the "right" way, Python as well as DOM-wise? My take on ``language bindings'' means to use conventions of the target language in defining in the binding API[*]. In the case of node.get_parent(), if that means using underscore instead of mixed case, because it's more common in Python, I agree with that. More specifically, in the case of node.parent, there's already precedence for that in the DOM spec itself, the ECMA Script binding: [* others disagree, preferring to use a strict transliteration of the Java binding because it's there in the spec and widely implemented in Java.] -- Ken MacLeod ken@bitsko.slc.ut.us From uche.ogbuji@fourthought.com Tue Nov 2 19:28:13 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 02 Nov 1999 12:28:13 -0700 Subject: [XML-SIG] 4DOM future In-Reply-To: Your message of "02 Nov 1999 12:29:29 CST." Message-ID: <199911021928.MAA07458@localhost.localdomain> Uche: >> > Any comment about the "right" way, Python as well as DOM-wise? Ken MacLeod : > My take on ``language bindings'' means to use conventions of the > target language in defining in the binding API[*]. In the case of > node.get_parent(), if that means using underscore instead of mixed > case, because it's more common in Python, I agree with that. > > More specifically, in the case of node.parent, there's already > precedence for that in the DOM spec itself, the ECMA Script binding: > > > > [* others disagree, preferring to use a strict transliteration of the > Java binding because it's there in the spec and widely implemented in > Java.] Hmm. I'm a bit unclear as to which way you're leaning: node.get_parent() or node.parent? I see clearly that you think either is preferable to mixed-case (getParent()), and I agree with you in this particular domain, but I'm also interested in your (and others') opinions as to * Whether the greater pythonic feel of get_parent() or parent is worth the disruption to current users of 4DOM. * Whether get_parent or parent is superior: there is the Pydom precedent for get_parent() and the ECMAScript precedence for parent. * Whether the __getattr__ & __setattr__ overhead of parent would be worth it for a pure attribute idiom that after all seems to be the intent of the DOM rec. -- 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 ken@bitsko.slc.ut.us Tue Nov 2 20:01:52 1999 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 02 Nov 1999 14:01:52 -0600 Subject: [XML-SIG] 4DOM future In-Reply-To: uche.ogbuji@fourthought.com's message of "Tue, 02 Nov 1999 12:28:13 -0700" References: <199911021928.MAA07458@localhost.localdomain> Message-ID: uche.ogbuji@fourthought.com writes: > Hmm. I'm a bit unclear as to which way you're leaning: > node.get_parent() or node.parent? I see clearly that you think > either is preferable to mixed-case (getParent()), and I agree with > you in this particular domain, I prefer node.parent. > but I'm also interested in your (and others') opinions as to > > * Whether the greater pythonic feel of get_parent() or parent is > worth the disruption to current users of 4DOM. I think the most important point is that all the Python DOM implementations share the same binding spec, so the important issue is the disruption of current users of any DOM impl. to the agreed upon spec. For that, I'm in the ``do it right, and the sooner the better'' camp. Then, after that, I prefer node.parent over node.get_parent(). > * Whether get_parent or parent is superior: there is the Pydom > precedent for get_parent() and the ECMAScript precedence for parent. FWIW, I don't like get/set routines when a language offers better solutions. > * Whether the __getattr__ & __setattr__ overhead of parent would be > worth it for a pure attribute idiom that after all seems to be the > intent of the DOM rec. I don't process megabytes of XML in short spans of time, any overhead would be minimal for me. Others do process megabytes of XML in short spans of time, you should test an implementation both ways since a lot of performance issues are already inherent in DOM. If I were designing a system to do large XML instances, I would probably still accept 10-15% (though I'd suspect it would be even less than that). Between node.parent and node.get_parent() would be node.parent() for get and node.parent(value) for set. I should note that I'm probably not a representative user, I'm not a heavy DOM user. I generally prefer to convert in to and out of application objects using SAX. My application objects almost always use the node.parent style of attribute access. -- Ken MacLeod ken@bitsko.slc.ut.us From uche.ogbuji@fourthought.com Tue Nov 2 21:58:45 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 02 Nov 1999 14:58:45 -0700 Subject: [XML-SIG] 4DOM future In-Reply-To: Your message of "02 Nov 1999 14:01:52 CST." Message-ID: <199911022158.OAA07799@localhost.localdomain> > > Hmm. I'm a bit unclear as to which way you're leaning: > > node.get_parent() or node.parent? I see clearly that you think > > either is preferable to mixed-case (getParent()), and I agree with > > you in this particular domain, > > I prefer node.parent. > > > but I'm also interested in your (and others') opinions as to > > > > * Whether the greater pythonic feel of get_parent() or parent is > > worth the disruption to current users of 4DOM. > > I think the most important point is that all the Python DOM > implementations share the same binding spec, so the important issue is > the disruption of current users of any DOM impl. to the agreed upon > spec. For that, I'm in the ``do it right, and the sooner the better'' > camp. Then, after that, I prefer node.parent over node.get_parent(). Agreed. Unfortunately it may take longer to agree upon and publish a python binding that it would to simply come up with an implementation. For instance, if we go with my leanings, which are towards an attribute-based approach, it would differ in a key way from PyDOM. Then to get a standard Python binding, we'd have to hash it out. That's why it would be nice to hear from some of the PyDOM implementors. It's not going to be an easy issue to resolve, but I believe it is worth the effort. > > * Whether get_parent or parent is superior: there is the Pydom > > precedent for get_parent() and the ECMAScript precedence for parent. > > FWIW, I don't like get/set routines when a language offers better > solutions. Agreed. > > * Whether the __getattr__ & __setattr__ overhead of parent would be > > worth it for a pure attribute idiom that after all seems to be the > > intent of the DOM rec. > > I don't process megabytes of XML in short spans of time, any overhead > would be minimal for me. Others do process megabytes of XML in short > spans of time, you should test an implementation both ways since a lot > of performance issues are already inherent in DOM. If I were > designing a system to do large XML instances, I would probably still > accept 10-15% (though I'd suspect it would be even less than that). > > Between node.parent and node.get_parent() would be node.parent() for > get and node.parent(value) for set. Ah, thank you very much for an option I had overlooked. so now we have four options: A. The PyDOM way value = node.get_parent() node.set_parent(value) B. The 4DOM 0.8 way value = node.getParent() node.setParent(value) C. The pure attribute way value = node.parent node.parent = value D. The attribute-named method way value = node.parent() node.parent(value) My leaning is to C, Ken McLeod agrees. I'd love to hear from others. -- 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 Nov 2 21:56:50 1999 From: Mike.Olson@FourThought.com (Mike Olson) Date: Tue, 02 Nov 1999 14:56:50 -0700 Subject: [XML-SIG] 4DOM future References: <199911022158.OAA07799@localhost.localdomain> Message-ID: <381F5E22.D9A1B88C@FourThought.com> This is a cryptographically signed message in MIME format. --------------msBF1118FE9D8E6CAB36BB29BC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit uche.ogbuji@fourthought.com wrote: > > A. The PyDOM way > > value = node.get_parent() > node.set_parent(value) > > B. The 4DOM 0.8 way > > value = node.getParent() > node.setParent(value) > > C. The pure attribute way > > value = node.parent > node.parent = value > > D. The attribute-named method way > > value = node.parent() > node.parent(value) > I vote for C as well. One note, D is not appealing at all for 4DOM because of CORBAs lack of default parameter values. > > My leaning is to C, Ken McLeod agrees. I'd love to hear from others. > > -- > 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 > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig -- ---------------- Mike Olson Consulting Member FourThought LLC http://www.fourthought.com http://opentechnology.org --------------msBF1118FE9D8E6CAB36BB29BC Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKpgYJKoZIhvcNAQcCoIIKlzCCCpMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDIwggT8MIIEZaADAgECAhBgV5Y2xbIHJpkIwhs+UflwMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDUwNjAwMDAw MFoXDTAwMDUwNTIzNTk1OVowggEXMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCk1pa2UgT2xzb24xKTAnBgkqhkiG9w0B CQEWGm1pa2Uub2xzb25AZm91cnRob3VnaHQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQCuk+Frgbi1QG7ni53t3TaFTU5IXKp/aOYYXaR/iPN9Ure9P6fAajZIDUXyR+bCIe8U Sq1kHjMNbb/ziX3/oPPeUy3Cy1sVZ/Cq2FPofSInSaLl0EB+k0aMbEBtmyVxTGByoNaPL3Lj Er/aLaIkNcPIaCzT0okEOA/pu9RU0efBaQIDAQABo4IBjzCCAYswCQYDVR0TBAIwADCBrAYD VR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEa PVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcg VmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2 M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0 N2RhNWQzZjIxNDFiZWFkYjJiZDJlODkyMTNhZTZhZjlkZjExNDk5OWEzYjg0NWY5ZjNlYTQ1 MGMwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQB8SeBjPc9TSSC1iwIP0gVMzQVGkcPG4I/yoMUFK1CfgW6T dvtP5z9WNcSIfQ8mIjsl/jbwnfYevfK0EiCjU5slnsOjrbIiWwRe7qYBuGqE6gnfkhMRt8l3 ZJe2AqRptWZYY8axL5nQm0iSnVEmYoZAtAnQkkldheTU4n+x9vlUHjCCAy4wggKXoAMCAQIC EQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBo u5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+H Sr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIB Fh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPK ZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjj F7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCC AjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkv UlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBD bGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQC EGBXljbFsgcmmQjCGz5R+XAwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw05OTExMDIyMTU2NTBaMCMGCSqGSIb3DQEJBDEWBBTgpCzv nah98ad1m2ZDZUS3Qbq03jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG 9w0BAQEFAASBgBRb+bjhq0v3wwvReoB6G/APPwmtv2Mk4Qxoo0BmuvHXV1LX61NzCGvWL39K 1ppR19sHYDYKL7y6IxlUO42amTW10c51P++O/gPN9up0mn8dNqMYzLnKrUVyO7Mpb8O9VqyO 0b8MC+mGAYufYkUXkcvqTW7oBoEz4kQEbHTDx1Hh --------------msBF1118FE9D8E6CAB36BB29BC-- From Amos@digicool.com Wed Nov 3 00:37:25 1999 From: Amos@digicool.com (Amos Latteier) Date: Tue, 2 Nov 1999 19:37:25 -0500 Subject: [XML-SIG] 4DOM future Message-ID: <613145F79272D211914B0020AFF6401932023B@gandalf.digicool.com> Uche Ogbuji wrote: >A. The PyDOM way > >value = node.get_parent() >node.set_parent(value) > >B. The 4DOM 0.8 way > >value = node.getParent() >node.setParent(value) > >C. The pure attribute way > >value = node.parent >node.parent = value > >D. The attribute-named method way > >value = node.parent() >node.parent(value) I too prefer C; it seems the cleanest. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com From tpassin@idsonline.com Wed Nov 3 13:26:31 1999 From: tpassin@idsonline.com (Thomas B. Passin) Date: Wed, 3 Nov 1999 08:26:31 -0500 Subject: [XML-SIG] Re: XML-SIG digest, Vol 1 #392 - 11 msgs References: <199911030605.BAA21718@python.org> Message-ID: <002201bf25ff$0ba341c0$6cfbb1cd@tomshp> > From: uche.ogbuji@fourthought.com [snip] > Also, we are thinking of eliminating the getSpam() and setEggs() convention. > Right now, one uses > > node.getParent() > > to access the DOM attribute > > node.parent > > We are thinking of simply doing the same thing in Python. > > The problem is that DOM adherence is still very important to us, and there are > some things we'd have to do that require __getattr__ and __setattr__, and I > know that these can slow things down quite a bit. > > I'm assuming that's why PyDOM uses > > node.get_parent() > > Any comment about the "right" way, Python as well as DOM-wise? > > If you are going to deviate from the published API, make sure it is done in a consistent way so that the new api can be machine-generated from the standard. This will also help humans write the correct calls by hand. Pure object-orented folks want node.getParent() instead of node.parent so the caller is not messing with the internals of the called object itself. A redesign could totally change the way in which getParent() works without changing the call at all, which is desirable. In Python, is it possible and efficient to redefine node.getParent() to simply return node.parent? If so, you could have the benefits of both ways. Regards, Tom Passin From paul@prescod.net Wed Nov 3 14:19:30 1999 From: paul@prescod.net (Paul Prescod) Date: Wed, 03 Nov 1999 08:19:30 -0600 Subject: [XML-SIG] 4DOM future References: <199911022158.OAA07799@localhost.localdomain> Message-ID: <38204472.A3082C4D@prescod.net> uche.ogbuji@fourthought.com wrote: > > For instance, if we go with my leanings, which are towards an attribute-based > approach, it would differ in a key way from PyDOM. I think that the attribute-based approach should be a short-cut for get_parent and set_parent and get_parent/set_parent should be optimizations for .parent. Years ago, I suggested that Python should have special language features for declaring "computed properties" because the __get__ hacks are slow and error prone. Maybe Python 2. Anyhow, what's the contradiction with PyDom? It does both: def __getattr__(self, key): if key[0:4] == 'get_' or key[0:4] == 'set_': raise AttributeError, repr(key[4:]) func = getattr(self, 'get_'+key) return func() Paul Prescod From akuchlin@mems-exchange.org Wed Nov 3 14:49:22 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 3 Nov 1999 09:49:22 -0500 (EST) Subject: [XML-SIG] 4DOM future In-Reply-To: <199911022158.OAA07799@localhost.localdomain> References: <199911022158.OAA07799@localhost.localdomain> Message-ID: <14368.19314.916935.93313@amarok.cnri.reston.va.us> uche.ogbuji@fourthought.com writes: >For instance, if we go with my leanings, which are towards an attribute-based >approach, it would differ in a key way from PyDOM. Then to get a standard >Python binding, we'd have to hash it out. That's why it would be nice to hear >from some of the PyDOM implementors. It's not going to be an easy issue to >resolve, but I believe it is worth the effort. The PyDom Node class has __getattr__/__setattr__ functions which redirect attribute references to the corresponding get_*/set_* function. ExtensionClass would be helpful for doing computed attribute values, but I've been reluctant to require it for the XML tools; if the Distutils-SIG makes it trivial to install new extensions and ExtensionClass is neatly packaged, maybe that additional requirement isn't too bad. I I'm glad to hear that 4DOM will soon be able to run without an ORB; we should figure out whether PyDOM is needed at all, in that case, because I hate duplication of effort, and because the existence of 4XSL and 4XPath give 4DOM an advantage. -- A.M. Kuchling http://starship.python.net/crew/amk/ Most reformers wore rubber boots and stood on glass when God sent a current of Commonsense through the Universe. -- Elbert Hubbard From ken@bitsko.slc.ut.us Wed Nov 3 17:04:02 1999 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 03 Nov 1999 11:04:02 -0600 Subject: [XML-SIG] 4DOM future In-Reply-To: uche.ogbuji@fourthought.com's message of "Tue, 02 Nov 1999 14:58:45 -0700" References: <199911022158.OAA07799@localhost.localdomain> Message-ID: Just a quick note, after checking the DOM rec again I noticed that the main DOM API defines attributes as attributes, not as get/set APIs. Get/set is only in the Java binding appendix. So as far as ``compatiblity with the DOM rec'' goes, it clearly can go either way. -- Ken MacLeod ken@bitsko.slc.ut.us From akuchlin@mems-exchange.org Wed Nov 3 17:31:03 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 3 Nov 1999 12:31:03 -0500 (EST) Subject: [XML-SIG] 4DOM future In-Reply-To: References: <199911022158.OAA07799@localhost.localdomain> Message-ID: <14368.29015.69809.286188@amarok.cnri.reston.va.us> Ken MacLeod writes: >Just a quick note, after checking the DOM rec again I noticed that the >main DOM API defines attributes as attributes, not as get/set APIs. >Get/set is only in the Java binding appendix. So as far as >``compatiblity with the DOM rec'' goes, it clearly can go either way. In the section "DOM Interfaces and DOM Implementations", there's some text which reads: 1. Attributes defined in the IDL do not imply concrete objects which must have specific data members - in the language bindings, they are translated to a pair of get()/set() functions, not to a data member. (Read-only functions have only a get() function in the language bindings). 2. DOM applications may provide additional interfaces and objects not found in this specification and still be considered DOM compliant. In other words, they didn't want to mandate having actual attributes or properties in the spec, because in some languages such as C++ that would be a serious constraint on implementors. (No __getattr__ hook there, after all.) Part of my reasoning for having both attributes and get_/set_ is for compability with Java -- users familiar with Java DOM implementations don't have to remember to use attributes instead of accessors, and code might be portable between CPython+PyDOM and JPython+a Java DOM implementation. -- A.M. Kuchling http://starship.python.net/crew/amk/ Feistel and Coppersmith rule. Sixteen rounds and one hell of an avalanche. -- Stephan Eisvogel in de.comp.security From gstein@lyra.org Thu Nov 4 01:35:03 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 3 Nov 1999 17:35:03 -0800 (PST) Subject: [XML-SIG] 4DOM future In-Reply-To: <199911022158.OAA07799@localhost.localdomain> Message-ID: On Tue, 2 Nov 1999 uche.ogbuji@fourthought.com wrote: > C. The pure attribute way > > value = node.parent > node.parent = value This is the style that qp_xml uses. Clean, simple, Pythonic... -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Nov 4 02:47:49 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 3 Nov 1999 18:47:49 -0800 (PST) Subject: [XML-SIG] Re: XML-SIG digest, Vol 1 #392 - 11 msgs In-Reply-To: <002201bf25ff$0ba341c0$6cfbb1cd@tomshp> Message-ID: On Wed, 3 Nov 1999, Thomas B. Passin wrote: > Pure object-orented folks want node.getParent() instead of node.parent so > the caller is not messing with the internals of the called object itself. A > redesign could totally change the way in which getParent() works without > changing the call at all, which is desirable. That is an incorrect generalization. I'm a "pure object-oriented" person and I prefer node.parent. Object-orientation does not mean use a method for everything. It can certainly mean that well-defined attributes are available for objects' clients. Further, the Python way of doing things is to expose the attributes. It is not considered an "internal" of the object, but part of the object's defined API. And the phrase "we're all adults" is well-used in this context, too -- if the attribute is internal, then don't screw with it. [ good Python design usually signals "internal" attributes with a leading underscore ] > In Python, is it possible and efficient to redefine node.getParent() to > simply return node.parent? If so, you could have the benefits of both ways. No. A function/method call is nowhere near as efficient as an attribute access. Note that you example of node.getParent is *both* an attribute access and a function all. 1) get the value of node.getParent (a bound method in this case), then 2) call the resulting object with no params. In other words, you can make the function calls in Python as fast as you'd like, but you'll never hit zero-time, so func calls will always be slower. Part of the Python programming gestalt :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From fhorch@ecoaccess.org Thu Nov 4 03:49:25 1999 From: fhorch@ecoaccess.org (Fred Wilson Horch) Date: Wed, 03 Nov 1999 22:49:25 -0500 Subject: [XML-SIG] XML to PDF Message-ID: <38210245.9A0A9035@ecoaccess.org> Can anyone recommend a good open source tool for creating PDF output from XML? Right now I'm using xmlproc and pdfgen (part of Piddle), but I have to write all my own code for line and page breaks. How do other people produce PDF files from XML using Python? Not using Python? Thanks, Fred From mgushee@havenrock.com Thu Nov 4 04:39:17 1999 From: mgushee@havenrock.com (Matt Gushee) Date: Wed, 3 Nov 1999 23:39:17 -0500 (EST) Subject: [XML-SIG] XML to PDF In-Reply-To: <38210245.9A0A9035@ecoaccess.org> References: <38210245.9A0A9035@ecoaccess.org> Message-ID: <14369.3573.808055.654983@gargle.gargle.HOWL> Fred Wilson Horch writes: > Can anyone recommend a good open source tool for creating PDF output > from XML? I'm a fan of Jade and JadeTeX myself -- shows you how twisted I am. Of course, that would probably require a bit of hacking on your part, too -- and DSSSL hacking instead of Python, at that. Anyway, the URL is http://www.netfolder.com/DSSSL/index.html Sorry for the non-Python suggestion. Matt Gushee Portland, Maine, USA mgushee@havenrock.com From paul@prescod.net Thu Nov 4 11:01:59 1999 From: paul@prescod.net (Paul Prescod) Date: Thu, 04 Nov 1999 05:01:59 -0600 Subject: [XML-SIG] XML to PDF References: <38210245.9A0A9035@ecoaccess.org> Message-ID: <382167A6.D5F97D8B@prescod.net> Fred Wilson Horch wrote: > > Can anyone recommend a good open source tool for creating PDF output > from XML? > > Right now I'm using xmlproc and pdfgen (part of Piddle), but I have to > write all my own code for line and page breaks. > > How do other people produce PDF files from XML using Python? Not using > Python? Going directly from XML to PDF is probably not a good idea. As you've pointed out, PDF is very low-level. Something like TeX, RTF, Lout etc. is usually the right middle ground. Therefore I would suggest you convert XML to TeX using Python (or Jade) and then convert TeX to PDF using PDFTex. Paul Prescod From fdrake@acm.org Thu Nov 4 17:52:13 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 4 Nov 1999 12:52:13 -0500 (EST) Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: <199911021620.JAA06037@localhost.localdomain> References: <001101bf251e$442a6960$3acbd9c2@peridot.optichrome.com> <199911021620.JAA06037@localhost.localdomain> Message-ID: <14369.51149.413124.364911@weyr.cnri.reston.va.us> uche.ogbuji@fourthought.com writes: > developers, but I'd say that PyDOM has suffered a bit from lack of > development lately. It used to have several pythonic features that I agree. > derived NamedNodeMap, smarter node __repr__, etc. It is also quite a bit > faster, apparently because of the proxying system for automatic circ ref > prevention in PyDOM. We also experimented with such an approach and didn't > like the results, so we just left it to explicit deep node removal. I'd actually like to require explicit destruction for PyDOM as well; the proxy cost is way too high. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From da@ski.org Fri Nov 5 00:36:53 1999 From: da@ski.org (David Ascher) Date: Thu, 4 Nov 1999 16:36:53 -0800 (PST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911050019.TAA29258@python.org> Message-ID: On the topic of whether to do foo.bar or foo.get_bar(), I would like to point out a cautionary tale. When doing NumPy, Jim Hugunin chose the .foo notation (as it happens, only for some attributes, not for all, for reasons best left between Jim and his therapist ). While that is appealing, it had the problem in the NumPy world that it made subclassing from his array type quite difficult. While having a __[g|s]etattr__ mechanism is fine for a Python 'expert', it is not something that one should force users to use if they wish to subclass from a given class. It is too easy to screw up and get stack overflows. In other words, *if subclassing is an issue for the class under discussion* if you use the .foo notation, make sure to have default __getattr__ hooks which would call the get_foo() hooks, so that the user can just define those get/set functions which she needs to. --david From jack@oratrix.nl Fri Nov 5 10:44:23 1999 From: jack@oratrix.nl (Jack Jansen) Date: Fri, 05 Nov 1999 11:44:23 +0100 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Message by David Ascher , Thu, 4 Nov 1999 16:36:53 -0800 (PST) , Message-ID: <19991105104423.5FB3935BB1E@snelboot.oratrix.nl> > On the topic of whether to do foo.bar or foo.get_bar(), I would like to > point out a cautionary tale. When doing NumPy, Jim Hugunin chose the .foo > notation (as it happens, only for some attributes, not for all, for > reasons best left between Jim and his therapist ). While that is > appealing, it had the problem in the NumPy world that it made subclassing > from his array type quite difficult. While having a __[g|s]etattr__ > mechanism is fine for a Python 'expert', it is not something that one > should force users to use if they wish to subclass from a given class. It > is too easy to screw up and get stack overflows. Ah, that's a good one. Maybe we should put the foo.bar functionality in a mixin class, and caution people only to include this mixin at the highest level in their class hierarchy? There's also something in the foo.bar scheme that will bite even experts. Let's assume I have a class representing something with an xml-attribute bar, and I need to create a subclass that shows the same attribute bar but somehow modified (converted to all upper case, for instance). Something like class Super(Base): def get_bar(self): return string.toupper(Base.get_bar(self)) will work fine, but I can't think of how to do this with the foo.bar access scheme. On the other hand, maybe this isn't a problem because I shouldn't try to do this with subclassing but with wrapper classes. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From uche.ogbuji@fourthought.com Fri Nov 5 15:25:42 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 05 Nov 1999 08:25:42 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "Thu, 04 Nov 1999 16:36:53 PST." Message-ID: <199911051525.IAA00995@localhost.localdomain> > On the topic of whether to do foo.bar or foo.get_bar(), I would like to > point out a cautionary tale. When doing NumPy, Jim Hugunin chose the .foo > notation (as it happens, only for some attributes, not for all, for > reasons best left between Jim and his therapist ). While that is > appealing, it had the problem in the NumPy world that it made subclassing > from his array type quite difficult. While having a __[g|s]etattr__ > mechanism is fine for a Python 'expert', it is not something that one > should force users to use if they wish to subclass from a given class. It > is too easy to screw up and get stack overflows. This is an good point, David, and one I hadn't thought of wrt the "node.parent" approach which I've been advocating, and which seems to be very popular. Probably the best response is that newbies can inherit from DOM classes, using regular methods for the interface they expose, and just accessign the parent attributes as any user would. class MyNode(Node): def foo(self): result = my_process(self.parent) return result Of course the fact that MyNode's interface is a hodge-podge of inherited attributes and added methods may be confusing to its users. The real mess comes about if MyNode's programmer wants to use __[g/s]etattr__ for whatever reason. So the list of knocks against "node.parent" is now: * Probably slower * Complex behavior masked in a supposedly simple attribute access * Possible confusion and complexity in sub-classing situations So far, its main plusses are that it's clean, pythonic, and in close correspondence to the W3C API specifications. Note that I don't like the idea of the Python binding officially supporting two approaches, i.e. "node.parent" _and_ "node.get_parent()". I think it's great for implementations to provide alternatives, but the binding should require one unequivocally. -- 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 fhorch@ecoaccess.org Fri Nov 5 16:34:43 1999 From: fhorch@ecoaccess.org (Fred Wilson Horch) Date: Fri, 05 Nov 1999 11:34:43 -0500 Subject: [XML-SIG] XML to PDF Message-ID: <38230723.FFBD97D0@ecoaccess.org> Paul Prescod wrote: > > How do other people produce PDF files from XML using Python? Not using > > Python? > > [snip] > Therefore I would suggest you convert XML to TeX using Python (or Jade) > and then convert TeX to PDF using PDFTex. Okay, what do people use to convert XML to TeX using Python? Or am I better off giving up on Python and just use Jade? Fred From fdrake@acm.org Fri Nov 5 16:32:57 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 5 Nov 1999 11:32:57 -0500 (EST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911051525.IAA00995@localhost.localdomain> References: <199911051525.IAA00995@localhost.localdomain> Message-ID: <14371.1721.802305.285593@weyr.cnri.reston.va.us> uche.ogbuji@fourthought.com writes: > Note that I don't like the idea of the Python binding officially supporting > two approaches, i.e. "node.parent" _and_ "node.get_parent()". I think it's > great for implementations to provide alternatives, but the binding should > require one unequivocally. I think the "right" way would be for someone to look at the CORBA mapping the DO-SIG put together and follow that strictly; I think it's pretty much through the OMG process. I've not been following that as closely as I'd like due to time constraints. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From uche.ogbuji@fourthought.com Fri Nov 5 18:34:05 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 05 Nov 1999 11:34:05 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "Fri, 05 Nov 1999 11:32:57 EST." <14371.1721.802305.285593@weyr.cnri.reston.va.us> Message-ID: <199911051834.LAA01423@localhost.localdomain> > uche.ogbuji@fourthought.com writes: > > Note that I don't like the idea of the Python binding officially supporting > > two approaches, i.e. "node.parent" _and_ "node.get_parent()". I think it's > > great for implementations to provide alternatives, but the binding should > > require one unequivocally. > > I think the "right" way would be for someone to look at the CORBA > mapping the DO-SIG put together and follow that strictly; I think it's > pretty much through the OMG process. I've not been following that as > closely as I'd like due to time constraints. Unfortunately, there is no specification for CORBA attributes in the do-sig Python binding. I don't recall any discussion on the topic as long as I've followed that list, but I can't imagine it is an easy topic, especially when you consider that Python ORBs often already need to hijack __[g/s]etattr__ for ORB run-time magic, marshalling, and all that. The seemingly obvious approach of "CORBA attributes == Python attributes" could lead to a nightmare for Python/CORBA users, considering the delicacy of __[g/s]etattr__, especially in the presence of inheritance. -- 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 fdrake@acm.org Fri Nov 5 18:33:00 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 5 Nov 1999 13:33:00 -0500 (EST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911051834.LAA01423@localhost.localdomain> References: <14371.1721.802305.285593@weyr.cnri.reston.va.us> <199911051834.LAA01423@localhost.localdomain> Message-ID: <14371.8924.995114.613109@weyr.cnri.reston.va.us> uche.ogbuji@fourthought.com writes: > Unfortunately, there is no specification for CORBA attributes in the do-sig > Python binding. I don't recall any discussion on the topic as long as I've That doesn't sound good at all. Let me take a quick look... Ok, in the 2-Aug-1999 document from the OMG archive (I think that's current), at the top of page 17 (section 4.4): "If an interface defines an attribute name, the attribute is mapped into an operation _get_name, as defined If the attribute is not readonly, there is an additional operation _set_name, as defined in chapter 3.11 of CORBA 2.2. These operations may raise exceptions, as defined by the CORBA Components submission (orbos/99-04-16)." (The weird ending of the first sentence is a correct quote.) So, it looks like we should be writing node._get_parent(). *Really* ugly, but if compliance is what matters, that's compliance. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From jkraai@murl.com Fri Nov 5 19:14:29 1999 From: jkraai@murl.com (jim kraai) Date: Fri, 05 Nov 1999 13:14:29 -0600 Subject: [XML-SIG] pyexpat & xmlproc References: <001001bf2519$695c9af0$3acbd9c2@peridot.optichrome.com> <003f01bf251c$8c0b3540$f29b12c2@secret.pythonware.com> Message-ID: <38232C95.62DADE2F@murl.com> Ooh, I am ignorant. Let me show you the extent. What's it going to take for me to build sgmlop on UN*X? I see a few things in the sgmlop.mak file that don't appear to be in my code/library trees. Humbly yours, --jim Fredrik Lundh wrote: > > > Are there any parsers for the XML kit which are faster than xmlproc? > > some alternatives: > > qp_xml (an optimized layer on top of pyexpat): > http://www.lyra.org/greg/python/qp_xml.py > > sgmlop (about as fast as can be, but a bit incomplete) > http://www.pythonware.com/madscientist/index.htm > > From xml-sig@teleo.net Fri Nov 5 21:20:13 1999 From: xml-sig@teleo.net (Patrick Phalen) Date: Fri, 5 Nov 1999 13:20:13 -0800 Subject: [XML-SIG] Cocoon Message-ID: <99110513324502.02687@quadra.teleo.net> Searching egroups, I find no prior mention of Cocoon, the Java publishing framework, on this or the JPython SIGs. http://java.apache.org/cocoon/ Although only a proof of concept, I'm enamored of this initiative, particularly the notion of eXtensible Server Pages. I'm unaware of anything quite like it. Is this just tunnel vision on my part? Likewise, I'm unaware of any early efforts to provide Python hooks into this, but am anxious to be proven wrong. From gstein@lyra.org Fri Nov 5 22:22:03 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 5 Nov 1999 14:22:03 -0800 (PST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911051525.IAA00995@localhost.localdomain> Message-ID: On Fri, 5 Nov 1999 uche.ogbuji@fourthought.com wrote: >... > The real mess comes about if MyNode's programmer wants to use __[g/s]etattr__ > for whatever reason. Presuming your DOM uses those already. > So the list of knocks against "node.parent" is now: > > * Probably slower > * Complex behavior masked in a supposedly simple attribute access > * Possible confusion and complexity in sub-classing situations IFF __getattr__ is used. If the attribute actually exists, then this is the fastest approach possible. This is why qp_xml is so quick -- it has all the attributes already assigned and clients just grab the values. > So far, its main plusses are that it's clean, pythonic, and in close > correspondence to the W3C API specifications. Definitely. > Note that I don't like the idea of the Python binding officially supporting > two approaches, i.e. "node.parent" _and_ "node.get_parent()". I think it's > great for implementations to provide alternatives, but the binding should > require one unequivocally. I'm in "violent agreement" here :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul@prescod.net Fri Nov 5 19:01:27 1999 From: paul@prescod.net (Paul Prescod) Date: Fri, 05 Nov 1999 13:01:27 -0600 Subject: [XML-SIG] foo.bar vs. foo.get_bar() References: <14371.1721.802305.285593@weyr.cnri.reston.va.us> <199911051834.LAA01423@localhost.localdomain> <14371.8924.995114.613109@weyr.cnri.reston.va.us> Message-ID: <38232987.B3F1D290@prescod.net> "Fred L. Drake, Jr." wrote: > > uche.ogbuji@fourthought.com writes: > > Unfortunately, there is no specification for CORBA attributes in the do-sig > > Python binding. I don't recall any discussion on the topic as long as I've > > That doesn't sound good at all. Let me take a quick look... > Ok, in the 2-Aug-1999 document from the OMG archive (I think that's > current), at the top of page 17 (section 4.4): Is anyone yet willing to agree with me that computed attributes should be a language feature? Say uncle dammit! Paul Prescod From uche.ogbuji@fourthought.com Fri Nov 5 23:45:56 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 05 Nov 1999 16:45:56 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "Fri, 05 Nov 1999 13:01:27 CST." <38232987.B3F1D290@prescod.net> Message-ID: <199911052345.QAA03942@localhost.localdomain> Paul Prescod: > Is anyone yet willing to agree with me that computed attributes should > be a language feature? Say uncle dammit! I'll confess that I didn't entirely understand what you meant by "computed attributes" as opposed to __[g/s]etattr__, and I'm sure I missed your arguments about it in the misty past. Could you give an example? Could your ideas be implemented without slowing things down a la __[g/s]etattr__? -- 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 uche.ogbuji@fourthought.com Fri Nov 5 23:51:19 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 05 Nov 1999 16:51:19 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "Fri, 05 Nov 1999 14:22:03 PST." Message-ID: <199911052351.QAA03963@localhost.localdomain> > > The real mess comes about if MyNode's programmer wants to use __[g/s]etattr__ > > for whatever reason. > > Presuming your DOM uses those already. > > > So the list of knocks against "node.parent" is now: > > > > * Probably slower > > * Complex behavior masked in a supposedly simple attribute access > > * Possible confusion and complexity in sub-classing situations > > IFF __getattr__ is used. If the attribute actually exists, then this is > the fastest approach possible. This is why qp_xml is so quick -- it has > all the attributes already assigned and clients just grab the values. Yes, but a large part of the DOM REC can't be followed using pure attributes without __[g/s]etattr__. I know that one can choose to implement subsets and approximations to the W3C DOM that don't run into such problems, but that doesn't suit everyone's needs. Some of us are looking for full DOM compliance, and that's why we're dealing with these issues. -- 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 gstein@lyra.org Sat Nov 6 00:02:02 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 5 Nov 1999 16:02:02 -0800 (PST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911052351.QAA03963@localhost.localdomain> Message-ID: On Fri, 5 Nov 1999 uche.ogbuji@fourthought.com wrote: > Yes, but a large part of the DOM REC can't be followed using pure attributes > without __[g/s]etattr__. I know that one can choose to implement subsets and > approximations to the W3C DOM that don't run into such problems, but that > doesn't suit everyone's needs. Some of us are looking for full DOM > compliance, and that's why we're dealing with these issues. Woah. That's pretty annoying. Can you give an example of such an attribute? thx, -g -- Greg Stein, http://www.lyra.org/ From martin@mira.isdn.cs.tu-berlin.de Sat Nov 6 00:24:26 1999 From: martin@mira.isdn.cs.tu-berlin.de (Martin v. Loewis) Date: Sat, 6 Nov 1999 01:24:26 +0100 Subject: [DO-SIG] Re: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <14371.8924.995114.613109@weyr.cnri.reston.va.us> (fdrake@acm.org) References: <14371.1721.802305.285593@weyr.cnri.reston.va.us> <199911051834.LAA01423@localhost.localdomain> <14371.8924.995114.613109@weyr.cnri.reston.va.us> Message-ID: <199911060024.BAA12971@mira.isdn.cs.tu-berlin.de> > That doesn't sound good at all. Let me take a quick look... > Ok, in the 2-Aug-1999 document from the OMG archive (I think that's > current), at the top of page 17 (section 4.4): > > "If an interface defines an attribute name, the attribute is > mapped into an operation _get_name, as defined If the > attribute is not readonly, there is an additional operation > _set_name, as defined in chapter 3.11 of CORBA 2.2. These > operations may raise exceptions, as defined by the CORBA > Components submission (orbos/99-04-16)." > > (The weird ending of the first sentence is a correct quote.) > So, it looks like we should be writing node._get_parent(). *Really* > ugly, but if compliance is what matters, that's compliance. Oops. That should be If an interface defines an attribute name, the attribute is mapped into an operation _get_name, as defined in chapter 3.11 of CORBA 2.2. If the attribute is not readonly, there is an additional operation _set_name. (perhaps wording could be better). I'm not sure which part of it you consider ugly, let me guess: 1. using accessor functions, instead of mapping to attributes. There is a number of reasons not to use attributes: a) Conformance to the Core. The referenced CORBA/Core section says #An attribute definition is logically equivalent to declaring a pair #of accessor functions; one to retrieve the value of the attribute #and one to set the value of the attribute. So even though the syntax says 'attribute', it is *not* 'state'. Instead, the object implementation must ultimately deliver the value. On the server side, this means methods. Specifying how the __getattr__ of an implementation interworks with the ORB's own __getattr__ code is just not feasible. b) encapsulation Some people think that directly setting attributes is evil, you ought to have accessor methods. There is some value to that point, especially as setting the attribute leads to a round-trip (to the server), something that is not all that clear from foo.bar = 3 c) consistency across implementation languages Attribute access means methods/functions in almost all languages. d) support for exceptions in attributes. With CORBA 3.0, you can say interface I{ readonly attribute long foo raises(Bar); } when you write print bla.foo you may expect an AttributeError, but you normally don't expect a CORBA.UserException. With print bla._get_foo() this is more obvious. 2. Choice of the specific names. Again, this choice is suggested by the Core: # The attribute declarations are equivalent to the following # pseudo-specification fragment: ... # float _get_radius (); # void _set_radius (in float r); although it clearly says # The actual accessor function names are language-mapping specific. In C++ and Java, they use overloading, but we don't have overloading. Plain 'get_' and 'set_' is ruled out because it would create conflicts: interface I{ readonly attribute long bla; void set_bla(in long newvalue, in Cred credentials); }; The '_set_' and '_get_' prefixes don't create conflicts, since IDL identifiers must not start with underscores. Since this is the first time this came up in a long time, I'd say that either a) attributes are rarely used, and don't happen in real life, or b) users of the mappings get used to the API and don't consider it *really* ugly. If you are still not satisfied: OMG will soon start collecting issues. If you feel this is a bug in the spec, please let us know. Regards, Martin From c.evans@clear.net.nz Sat Nov 6 00:33:59 1999 From: c.evans@clear.net.nz (Carey Evans) Date: 06 Nov 1999 13:33:59 +1300 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: uche.ogbuji@fourthought.com's message of "Fri, 05 Nov 1999 08:25:42 -0700" References: <199911051525.IAA00995@localhost.localdomain> Message-ID: <87ln8c1mrs.fsf@psyche.evansnet> uche.ogbuji@fourthought.com writes: > So the list of knocks against "node.parent" is now: > > * Probably slower Has anyone tried this? PyDOM includes __getattr__ and __setattr__, but doesn't actually use them. As a simple test, I ran a small program that parses a 30K XML file into a DOM tree (as in the xml-howto), then prints it out (using the dump method), using PyDOM. With __get/setattr__ the average runtime was 9.1 seconds. With those methods commented out, the average runtime was 4.1 seconds, so it was more than twice as fast. I wonder how much slower it would be if the methods were ever actually used? -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "This is where your sanity gives in..." From uche.ogbuji@fourthought.com Sat Nov 6 01:09:36 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 05 Nov 1999 18:09:36 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "06 Nov 1999 13:33:59 +1300." <87ln8c1mrs.fsf@psyche.evansnet> Message-ID: <199911060109.SAA00876@localhost.localdomain> > > So the list of knocks against "node.parent" is now: > > > > * Probably slower > > Has anyone tried this? PyDOM includes __getattr__ and __setattr__, > but doesn't actually use them. As a simple test, I ran a small > program that parses a 30K XML file into a DOM tree (as in the > xml-howto), then prints it out (using the dump method), using PyDOM. > > With __get/setattr__ the average runtime was 9.1 seconds. With those > methods commented out, the average runtime was 4.1 seconds, so it was > more than twice as fast. I wonder how much slower it would be if the > methods were ever actually used? Any class with __[g/s]etattr__ is automatically slower, whether or not the methods are actually used. This is for a simple reason: without these hooks, attribute access involves basic C pointer magic within the interpreter, which is of course blazingly fast. Whenever the hooks are present, the interpreter must invoke the hooks for every attribute access, even if it turns out the hooks aren't used. As I've mentioned before, round trips from the C engine to Python interpreted code incur a steep performance penalty. -- 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 uche.ogbuji@fourthought.com Sat Nov 6 01:17:29 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 05 Nov 1999 18:17:29 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "Fri, 05 Nov 1999 16:02:02 PST." Message-ID: <199911060117.SAA00898@localhost.localdomain> > On Fri, 5 Nov 1999 uche.ogbuji@fourthought.com wrote: > > Yes, but a large part of the DOM REC can't be followed using pure attributes > > without __[g/s]etattr__. I know that one can choose to implement subsets and > > approximations to the W3C DOM that don't run into such problems, but that > > doesn't suit everyone's needs. Some of us are looking for full DOM > > compliance, and that's why we're dealing with these issues. > > Woah. That's pretty annoying. Can you give an example of such an > attribute? Um, almost all DOM classes are affected. From a brief survey of core Node (attributes can raise exceptions) NamedNodeMap (attributes can raise exceptions) Attr (specified has rules about what must happen when user changes it) ProcessingInstruction (attributes can raise exceptions) I'm actually surprised that Element wouldn't require __[g/s]etattr__. However, the fact that Node does is the major damage. -- 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 uche.ogbuji@fourthought.com Sat Nov 6 01:27:35 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 05 Nov 1999 18:27:35 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "Fri, 05 Nov 1999 16:02:02 PST." Message-ID: <199911060127.SAA00939@localhost.localdomain> > On Fri, 5 Nov 1999 uche.ogbuji@fourthought.com wrote: > > Yes, but a large part of the DOM REC can't be followed using pure attributes > > without __[g/s]etattr__. I know that one can choose to implement subsets and > > approximations to the W3C DOM that don't run into such problems, but that > > doesn't suit everyone's needs. Some of us are looking for full DOM > > compliance, and that's why we're dealing with these issues. > > Woah. That's pretty annoying. Can you give an example of such an > attribute? After reading your message again, I think I might have fallen a bit shy of answering your actual question. Here's another try. The W3C spec for Node requires that if the user tries to modify the nodeValue interface, one exception must be raised if the node is read-only, and another if the new content overflows the platform's string length limits. But now that I examine the heart of the matter, I guess it's not as bad as I'd thought. We have not been planning to implement readonly nodes in 4DOM, and we'd leave string-overflow issues to the Python interpreter, so actually we wouldn't need to use __[g/s]etattr__ for Node, and this really brightens things. Node, Element and Text would be hook-free, and another common class, Attr, would only need the hook if we insisted on arcane W3C rules with regard to specified attributes which don't make much sense without DTD support anyway. Thanks for making me look into it some more. Maybe "node.parent" doesn't need to be such a hog. Of course, I haven't looked into how DOM level 2 changes things. -- 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 uche.ogbuji@fourthought.com Sat Nov 6 02:42:59 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 05 Nov 1999 19:42:59 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "Fri, 05 Nov 1999 18:27:35 MST." <199911060127.SAA00939@localhost.localdomain> Message-ID: <199911060243.TAA01099@localhost.localdomain> > But now that I examine the heart of the matter, I guess it's not as bad as I'd > thought. We have not been planning to implement readonly nodes in 4DOM, and > we'd leave string-overflow issues to the Python interpreter, so actually we > wouldn't need to use __[g/s]etattr__ for Node, and this really brightens > things. Node, Element and Text would be hook-free, and another common class, > Attr, would only need the hook if we insisted on arcane W3C rules with regard > to specified attributes which don't make much sense without DTD support anyway. Well, scratch that after all. I forgot all about DOM_HIERARCHY_REQUEST_ERROR. That puts Node squarely back into the "needs __[g/s]etattr__" camp again. Ah, tant pis. -- 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 akuchlin@mems-exchange.org Sat Nov 6 02:42:55 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Fri, 5 Nov 1999 21:42:55 -0500 (EST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <87ln8c1mrs.fsf@psyche.evansnet> References: <199911051525.IAA00995@localhost.localdomain> <87ln8c1mrs.fsf@psyche.evansnet> Message-ID: <14371.38320.64.927368@amarok.cnri.reston.va.us> Carey Evans writes: >Has anyone tried this? PyDOM includes __getattr__ and __setattr__, >but doesn't actually use them. As a simple test, I ran a small Huh? Doesn't use them? Are you sure this is with the current version of PyDOM? It most certainly will not work without the __getattr__; the test suite crashes when you try it (Internally, though, the code never uses bar attributes like .parentNode, calling .get_parentNode() to save the expense of going through __getattr__ to call .get_parentNode(), so the stuff in dom.core.py might well work without the __getattr__ method. Callers will definitely break, though.) -- A.M. Kuchling http://starship.python.net/crew/amk/ Mathematics transfigures the fortuitous concourse of atoms into the tracery of the finger of God. -- Herbert Westren Turnbull From gstein@lyra.org Sat Nov 6 03:13:02 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 5 Nov 1999 19:13:02 -0800 (PST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911060243.TAA01099@localhost.localdomain> Message-ID: On Fri, 5 Nov 1999 uche.ogbuji@fourthought.com wrote: > > But now that I examine the heart of the matter, I guess it's not as bad as I'd > > thought. We have not been planning to implement readonly nodes in 4DOM, and > > we'd leave string-overflow issues to the Python interpreter, so actually we > > wouldn't need to use __[g/s]etattr__ for Node, and this really brightens > > things. Node, Element and Text would be hook-free, and another common class, > > Attr, would only need the hook if we insisted on arcane W3C rules with regard > > to specified attributes which don't make much sense without DTD support anyway. > > Well, scratch that after all. I forgot all about DOM_HIERARCHY_REQUEST_ERROR. > That puts Node squarely back into the "needs __[g/s]etattr__" camp again. Ack. Too bad... looks like you were onto something there. However, could you still avoid the hook for most of the attributes, or is that exception possibly raised by *any* attribute access? (eek!) Obviously, I'm a DOM illiterate... just asking questions from the peanut gallery here :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From paul@prescod.net Sat Nov 6 04:39:46 1999 From: paul@prescod.net (Paul Prescod) Date: Fri, 05 Nov 1999 22:39:46 -0600 Subject: [XML-SIG] foo.bar vs. foo.get_bar() References: <199911052345.QAA03942@localhost.localdomain> Message-ID: <3823B112.C2C62A33@prescod.net> uche.ogbuji@fourthought.com wrote: > > I'll confess that I didn't entirely understand what you meant by "computed > attributes" as opposed to __[g/s]etattr__, and I'm sure I missed your > arguments about it in the misty past. http://x43.deja.com/getdoc.xp?AN=268185266&CONTEXT=941863506.472907815&hitnum=5 Looking back, I see that David Ascher said at the time that it was more trouble than it was worth. He may or may not have changed his mind considering the headaches he has outline. Paul Prescod From c.evans@clear.net.nz Sat Nov 6 06:14:23 1999 From: c.evans@clear.net.nz (Carey Evans) Date: 06 Nov 1999 19:14:23 +1300 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: "Andrew M. Kuchling"'s message of "Fri, 5 Nov 1999 21:42:55 -0500 (EST)" References: <199911051525.IAA00995@localhost.localdomain> <87ln8c1mrs.fsf@psyche.evansnet> <14371.38320.64.927368@amarok.cnri.reston.va.us> Message-ID: <87hfj0170g.fsf@psyche.evansnet> "Andrew M. Kuchling" writes: > Huh? Doesn't use them? Are you sure this is with > the current version of PyDOM? It most certainly will not work > without the __getattr__; the test suite crashes when you try it > > (Internally, though, the code never uses bar attributes like > .parentNode, calling .get_parentNode() to save the expense of going > through __getattr__ to call .get_parentNode(), so the stuff in > dom.core.py might well work without the __getattr__ method. Callers > will definitely break, though.) This is what I meant - even though PyDOM's internal code doesn't need the __getattr__ method, it's still twice as fast if the method is removed. I did some profiling a few months ago, and found that PyDOM spent a lot of its time recursively calling __getattr__ (via getattr) to find out whether any get_* or set_* methods existed anywhere in the class hierarchy for a particular attribute being accessed, and much of the time there was spent in creating AttributeError object instances. I guess my point is that I don't want my programs to take twice as long to run if only one attribute needs to be handled specially, when accessor functions like the Java bindings are almost as easy to use. However, it may be that if most access is only getting existing attributes directly from the object's __dict__, then accessor functions might be slower, and I'd like to know before deciding which method I prefer. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ "Intel's software development efforts ... are directed primarily at finding useful ways to consume more microprocessor cycles." From da@ski.org Sat Nov 6 07:09:15 1999 From: da@ski.org (David Ascher) Date: Fri, 5 Nov 1999 23:09:15 -0800 (Pacific Standard Time) Subject: [XML-SIG] Re: foo.bar vs. foo.get_bar() In-Reply-To: <199911060606.BAA18977@python.org> Message-ID: Paul sez: > http://x43.deja.com/getdoc.xp?AN=268185266&CONTEXT=941863506.472907815&hitnum=5 > > Looking back, I see that David Ascher said at the time that it was more > trouble than it was worth. He may or may not have changed his mind > considering the headaches he has outline. Wow. Talk about having one's words fed back two years later! Yes, I think that I'm coming around to your point of view, Paul. I'm not at all sure whether we can come up with reasonable semantics of a class which defines both __getattr__ and __get_foo__, and how subclassing would affect things, though. A useful discussion for Python 2.0 in any case. (I note that this was back in prehistory when Guido read the newsgroup =) --david From jtauber@jtauber.com Sat Nov 6 17:23:52 1999 From: jtauber@jtauber.com (James Tauber) Date: Sat, 6 Nov 1999 12:23:52 -0500 Subject: [XML-SIG] XML to PDF References: <38210245.9A0A9035@ecoaccess.org> Message-ID: <02b701bf287b$b22682e0$eb020a0a@bowstreet.com> > How do other people produce PDF files from XML using Python? Not using > Python? I use an XSLT engine (like James Clark's XT) and FOP, my XSL formatter. FOP is written in Java, although it was prototyped in Python a long time ago. see http://www.jtauber.com/fop/ James Tauber From stuart.hungerford@webone.com.au Sun Nov 7 10:32:31 1999 From: stuart.hungerford@webone.com.au (Stuart Hungerford) Date: Sun, 07 Nov 1999 21:32:31 +1100 Subject: [XML-SIG] Python access to XML datastores? References: <199911070605.BAA23817@python.org> Message-ID: <3825553F.F445B726@webone.com.au> Hi all, I've noticed a group of XML-enabled or XML-aware datastore products appearing these days: eXcelon, db.org, etc. There's also Metakit which is not specifically XML, but seems very adaptable for structured data storage. My question is whether anyone is working on Python wrappers or interfaces to these datastores for storing XML documents? Such an interface or wrapper could present a very pythonic view of a datastore that understood XML elements, attributes and documents and handled the translation to the lower level datatypes transparently. Perhaps it could present an XPath or XQL interface too. I'm no DBMS expert, but I'd guess the large DBMS vendors are working on something similar for C/C++/Java. Comments? Stu From gstein@lyra.org Sun Nov 7 13:29:43 1999 From: gstein@lyra.org (Greg Stein) Date: Sun, 7 Nov 1999 05:29:43 -0800 (PST) Subject: [XML-SIG] new qp_xml.py Message-ID: I've updated the qp_xml.py module and placed a new version at: http://www.lyra.org/greg/python/qp_xml.py (see ..../python/ for more info) Specifically, there is a new header on the thing that details where it comes from, contains a CVS Id for tracking it, and clarifies the licensing of the thing (Public Domain). Also, I finally got around to changing the attribute handling. The "attrs" attribute of the element is now a dictionary mapping (namespace_URI, attribute_name) to attribute_value. [ it used to be an object with .ns, .name, and .value attributes ] Suggestions/changes/etc are welcome! (Laurent... :-) And yes... I'd still like to see this placed somewhere in the XML-SIG distribution. No, I won't argue to remove the DOM :-), but I will argue that it should be in there since it is very useful... Cheers, -g -- Greg Stein, http://www.lyra.org/ From larsga@garshol.priv.no Sun Nov 7 18:26:48 1999 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 07 Nov 1999 19:26:48 +0100 Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: <000001bf245e$db27d610$3acbd9c2@peridot.optichrome.com> References: <000001bf245e$db27d610$3acbd9c2@peridot.optichrome.com> Message-ID: (Sorry for the late response, but I've been offline the past week.) * Adrian Eyre | | Is there any reason why pyexpat (written in C) is slower than | xmlproc (written in Python)? My immediate response to this would have been that pyexpat is of course much faster, but since the others seem to agree that it is not there must be something more to this. In any case, I believe we were a bit too quick here: pyexpat should definitely be faster than xmlproc and if it is not there must be something wrong, perhaps with the SAX driver. I will try to find some time to work on speeding this up (I'm working on SAX right now anyway), and if anyone else is interested I would be glad to hear what your results and thoughts are. As for calls from Python to C I don't think that is the reason, since there shouldn't be any during the parse apart from when there are errors. --Lars M. From uche.ogbuji@fourthought.com Sun Nov 7 19:02:22 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Sun, 07 Nov 1999 12:02:22 -0700 Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: Your message of "07 Nov 1999 19:26:48 +0100." Message-ID: <199911071902.MAA09282@localhost.localdomain> > In any case, I believe we were a bit too quick here: pyexpat should > definitely be faster than xmlproc and if it is not there must be > something wrong, perhaps with the SAX driver. Since I was one of those commenting, I should note that I haven't done any proper benchmark of the two. It has just always been my impression that xmlproc is faster. -- 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 dieter@handshake.de Sat Nov 6 19:13:14 1999 From: dieter@handshake.de (Dieter Maurer) Date: Sat, 6 Nov 1999 20:13:14 +0100 (CET) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911060109.SAA00876@localhost.localdomain> References: <87ln8c1mrs.fsf@psyche.evansnet> <199911060109.SAA00876@localhost.localdomain> Message-ID: <14372.31508.232234.128203@lindm.dm> --Multipart_Sat_Nov__6_20:13:14_1999-1 Content-Type: text/plain; charset=US-ASCII uche.ogbuji@fourthought.com writes: > Any class with __[g/s]etattr__ is automatically slower, whether or not the > methods are actually used. This is for a simple reason: without these hooks, > attribute access involves basic C pointer magic within the interpreter, which > is of course blazingly fast. Whenever the hooks are present, the interpreter > must invoke the hooks for every attribute access, even if it turns out the > hooks aren't used. As I've mentioned before, round trips from the C engine to > Python interpreted code incur a steep performance penalty. I think this is not generally true for "__getattr__": reason: "__getattr__" is only used, if an attribute cannot be found by "normal" lookup. The attached script, for example produced the following timing: __main__.C1 0.43 __main__.C2 0.43 __main__.C2 0.44 __main__.C1 0.43 There is no significant difference between C1 (without) and C2 (with __getattr__). This only changes, when attributes are looked up that are not found by looking into the __dict__, e.g. because they do not exist at all. - Dieter --Multipart_Sat_Nov__6_20:13:14_1999-1 Content-Type: application/x-python Content-Disposition: attachment; filename="x.py" Content-Transfer-Encoding: 7bit '''measuring the effect of 'getattr'.''' import time class C1: a=1 class C2: a=2 def __getattr__(self,k): pass def test(c,n=10000): i= 0 s= time.clock() while i < n: c.a; c.a; c.a; c.a; c.a; c.a; c.a; c.a; c.a; c.a i= i+1 e= time.clock() print c, e-s test(C1) test(C2) test(C2) test(C1) --Multipart_Sat_Nov__6_20:13:14_1999-1-- From jack@oratrix.nl Sun Nov 7 23:08:53 1999 From: jack@oratrix.nl (Jack Jansen) Date: Mon, 08 Nov 1999 00:08:53 +0100 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Message by Paul Prescod , Fri, 05 Nov 1999 13:01:27 -0600 , <38232987.B3F1D290@prescod.net> Message-ID: <19991107230858.0AAF6EA117@oratrix.oratrix.nl> Recently, Paul Prescod said: > Is anyone yet willing to agree with me that computed attributes should > be a language feature? Say uncle dammit! If and only if you can come up with an efficient implementation. If it means that for every attribute "foo" declared somewhere in a base class the interpreter will not only have to look up "foo" but also "__getcomputedattr__" in every intermediate class I think it will slow things down too much, for all programs using inheritance. But, of course, I'm perfectly willing to be convinced it can be done efficiently. The __getattr__ hook is much to lowlevel a feature for something useful like computed attributes. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From ken@bitsko.slc.ut.us Thu Nov 4 08:07:55 1999 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 04 Nov 1999 02:07:55 -0600 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: uche.ogbuji@fourthought.com's message of "Fri, 05 Nov 1999 19:42:59 -0700" References: <199911060243.TAA01099@localhost.localdomain> Message-ID: uche.ogbuji@fourthought.com writes: > > But now that I examine the heart of the matter, I guess it's not > > as bad as I'd thought. We have not been planning to implement > > readonly nodes in 4DOM, and we'd leave string-overflow issues to > > the Python interpreter, so actually we wouldn't need to use > > __[g/s]etattr__ for Node, and this really brightens things. Node, > > Element and Text would be hook-free, and another common class, > > Attr, would only need the hook if we insisted on arcane W3C rules > > with regard to specified attributes which don't make much sense > > without DTD support anyway. > > Well, scratch that after all. I forgot all about > DOM_HIERARCHY_REQUEST_ERROR. That puts Node squarely back into the > "needs __[g/s]etattr__" camp again. I don't understand why raising a different exception is a problem with attributes or how get/set methods make the problem any simpler to grok. Martin v. Loewis suggests in his post that method syntax makes a broader range of exceptions "more obvious". Why would that be? When you read the library reference on a module that raises exceptions, you're going to see the exceptions listed regardless of whether they're through accessor syntax or method syntax. Martin states that one "normally" should only expect AttributeError exceptions from attribute access. A quick glance through the library reference shows that "anydbm" (and it's variants) use other exceptions, I'm sure there are more examples. -- Ken MacLeod ken@bitsko.slc.ut.us From ken@bitsko.slc.ut.us Thu Nov 4 08:14:07 1999 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 04 Nov 1999 02:14:07 -0600 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Paul Prescod's message of "Fri, 05 Nov 1999 13:01:27 -0600" References: <14371.1721.802305.285593@weyr.cnri.reston.va.us> <199911051834.LAA01423@localhost.localdomain> <14371.8924.995114.613109@weyr.cnri.reston.va.us> <38232987.B3F1D290@prescod.net> Message-ID: Paul Prescod writes: > Is anyone yet willing to agree with me that computed attributes > should be a language feature? Say uncle dammit! I agree. The proposed implementation (calling private _get_FOO/_set_FOO in place of __getattr__/__setattr__) elegantly supports both attribute access syntax and subclassing. -- Ken MacLeod ken@bitsko.slc.ut.us From ken@bitsko.slc.ut.us Thu Nov 4 09:00:36 1999 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 04 Nov 1999 03:00:36 -0600 Subject: [DO-SIG] Re: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: "Martin v. Loewis"'s message of "Sat, 6 Nov 1999 01:24:26 +0100" References: <14371.1721.802305.285593@weyr.cnri.reston.va.us> <199911051834.LAA01423@localhost.localdomain> <14371.8924.995114.613109@weyr.cnri.reston.va.us> <199911060024.BAA12971@mira.isdn.cs.tu-berlin.de> Message-ID: "Martin v. Loewis" writes: > If an interface defines an attribute name, the attribute is > mapped into an operation _get_name, as defined in chapter > 3.11 of CORBA 2.2. If the attribute is not readonly, there is > an additional operation _set_name. > > (perhaps wording could be better). I'm not sure which part of it you > consider ugly, let me guess: > > 1. using accessor functions, instead of mapping to attributes. There > is a number of reasons not to use attributes: > > a) Conformance to the Core. The referenced CORBA/Core section says > > #An attribute definition is logically equivalent to declaring a pair > #of accessor functions; one to retrieve the value of the attribute > #and one to set the value of the attribute. This sounds more like a "MAY" requirement than a "MUST" requirement. Since Python, like several languages, supports accessor syntax it seems logical to use it. > So even though the syntax says 'attribute', it is *not* > 'state'. Instead, the object implementation must ultimately deliver > the value. On the server side, this means methods. Specifying how > the __getattr__ of an implementation interworks with the ORB's > own __getattr__ code is just not feasible. I don't see how this is relevant. CORBA is already calling them attributes with the assumption that it's not state. Python supports the same. > b) encapsulation > > Some people think that directly setting attributes is evil, you > ought to have accessor methods. There is some value to that point, > especially as setting the attribute leads to a round-trip (to the > server), something that is not all that clear from > > foo.bar = 3 Implementation of attributes that support encapsulation has been discussed at length in this thread. > c) consistency across implementation languages > > Attribute access means methods/functions in almost all languages. It's very possible that the reason for that is that those languages don't support accessor syntax. One of the biggest problems with recent "language independent" architectures is that they all seem to have been born out of or heavily influenced by C++ and it's draconian approach to OOP. The reason these architectures define support for and often recommend accessor methods is because C++, the largest influence of the architecture and it's most common client, doesn't support anything else. > d) support for exceptions in attributes. > > With CORBA 3.0, you can say > > interface I{ > readonly attribute long foo raises(Bar); > } > > when you write > > print bla.foo > > you may expect an AttributeError, but you normally don't expect a > CORBA.UserException. With > > print bla._get_foo() > > this is more obvious. Several Python modules support attribute exceptions besides AttributeError. > If you are still not satisfied: OMG will soon start collecting > issues. If you feel this is a bug in the spec, please let us know. The bug in this case seems to be very subtle. Clearly, the CORBA specs recognize attributes and would seem to suggest using them as easily as possible, yet it is common practice in primary and secondary specs, and in discussions of them, to only reference languages (most commonly C++ or Java) that don't support attribute access. This fosters and spreads the notion that all implementations _must_ use method accessors whenever attributes are suggested. -- Ken MacLeod ken@bitsko.slc.ut.us From tpassin@idsonline.com Mon Nov 8 02:28:57 1999 From: tpassin@idsonline.com (Thomas B. Passin) Date: Sun, 7 Nov 1999 21:28:57 -0500 Subject: [XML-SIG] foo.bar vs. foo.get_bar() References: <199911060232.VAA14716@python.org> Message-ID: <002501bf2991$035ebb80$0101a8c0@tomshp> > uche.ogbuji@fourthought.com writes: >> > Note that I don't like the idea of the Python binding officially supporting >> > two approaches, i.e. "node.parent" _and_ "node.get_parent()". I think it's >> > great for implementations to provide alternatives, but the binding should >> > require one unequivocally. >> >> I think the "right" way would be for someone to look at the CORBA >> mapping the DO-SIG put together and follow that strictly; I think it's >> pretty much through the OMG process. I've not been following that as >> closely as I'd like due to time constraints. >Unfortunately, there is no specification for CORBA attributes in the do-sig >Python binding. I don't recall any discussion on the topic as long as I've >followed that list, but I can't imagine it is an easy topic, especially when >you consider that Python ORBs often already need to hijack __[g/s]etattr__ for >ORB run-time magic, marshalling, and all that. The seemingly obvious approach >of "CORBA attributes == Python attributes" could lead to a nightmare for >Python/CORBA users, considering the delicacy of __[g/s]etattr__, especially in >the presence of inheritance. >-- >Uche Ogbuji I'd like to remind everyone in this discussion that it is desirable for any Python-DOM bindings to be obtained in a "regular" way - one that can be programatically generated from the basic definitions. To quote from the DOM standard: "As stated earlier, all object definitions are specified in XML. The Java bindings, OMG IDL bindings, and ECMA Script bindings are all generated automatically from the XML source code. This is possible because the information specified in XML is a superset of what these other syntax need. This is a general observation, and the same kind of technique can be applied to many other areas: given rich structure, rich processing and conversion are possible. For Java and OMG IDL, it is basically just a matter of renaming syntactic keywords; for ECMA Script, the process is somewhat more involved." Python bindings should follow this principle. This means that there should not be different ways of naming different parts of the binding - so it would either be spam.parent or spam.getParent() EVERYWHERE there are similar calls - pick one style or the other. If there are exceptions, it will be hard or impossible to do programmatic generation of the bindings. I'm getting the sense that the tide is running on the side of spam.getParent(). Regards, Tom Passin From tpassin@idsonline.com Mon Nov 8 13:49:55 1999 From: tpassin@idsonline.com (Thomas B. Passin) Date: Mon, 8 Nov 1999 08:49:55 -0500 Subject: [XML-SIG] foo.bar vs. foo.get_bar() References: <199911080605.BAA22661@python.org> Message-ID: <005401bf29f0$5556b960$81fbb1cd@tomshp> To bring someone else's thoughts on this subject in, here are a few sections from Martin Fowler's book, "Refactoring - Improving The Design Of Existing Code", Addison Wesley, 1999. This seems to be a most excellent book, by the way. The specific example language is Java, but it applies to object oriented programming in general. On page 206: "One of the principal tenets of object orientation is encapsulation, or data hiding. This says that you should never make your data public. When you make your data public, other objects can change and access data values without the owning object knowing about it. ... This is seen as a bad thing because it reduces modularity of the program. When the data and behavior that uses it are clustered together, it is easier to change the code, because the changed code is in one place rather than scattered all over the program." This passage strongly supports using setting/getting functions, rather than direct access to the attribute. Read on for more: On page 300: "Providing a setting method implies that a field may be changed. If you don't want that field to change once the object is created, then don't provide a setting method (and make the field final ) [this is a javaism - TP]. That way, your intention is clear and you often remove the very possibility that the field will change." Fowler is very strong on having the construction of your code reflect its intent as closely as possible, to aid maintenance and changes later on. The problems people had using numpy, which were posted earlier in this thread by David Ascher, when subclassing classes without getters/setters, would seem to reflect what Fowler says here. More support for spam.getParent()! Regards, Tom Passin From Alain.Michard@inria.fr Mon Nov 8 14:00:49 1999 From: Alain.Michard@inria.fr (Alain Michard) Date: Mon, 08 Nov 1999 15:00:49 +0100 Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: <199911071902.MAA09282@localhost.localdomain> References: Message-ID: <3.0.5.32.19991108150049.00971790@pop-rocq.inria.fr> At 12:02 07/11/99 -0700, uche.ogbuji@fourthought.com wrote: >Since I was one of those commenting, I should note that I haven't done any >proper benchmark of the two. It has just always been my impression that >xmlproc is faster. > I've done some comparisons (weeks ago) on a few relatively large XML files. On some of them pyexpat was a bit faster, and on the others xmlproc was better. Was not systematic for any of them. Alain From fdrake@acm.org Mon Nov 8 15:03:55 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 8 Nov 1999 10:03:55 -0500 (EST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911052351.QAA03963@localhost.localdomain> References: <199911052351.QAA03963@localhost.localdomain> Message-ID: <14374.58971.369022.478622@weyr.cnri.reston.va.us> uche.ogbuji@fourthought.com writes: > Yes, but a large part of the DOM REC can't be followed using pure attributes > without __[g/s]etattr__. I know that one can choose to implement subsets and > approximations to the W3C DOM that don't run into such problems, but that > doesn't suit everyone's needs. Some of us are looking for full DOM > compliance, and that's why we're dealing with these issues. The W3C recommendation gives IDL, and there is a Python IDL binding. The ._get_() and ._set_() syntax I described is the result, and is (however ugly) conformant with the W3C DOM recommendation. I think I understand why the binding is the way it is, but I don't know if IDL attributes are intended to support updatable values. This would require digging around the CORBA spec a bit. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Mon Nov 8 15:11:20 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 8 Nov 1999 10:11:20 -0500 (EST) Subject: [DO-SIG] Re: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911060024.BAA12971@mira.isdn.cs.tu-berlin.de> References: <14371.1721.802305.285593@weyr.cnri.reston.va.us> <199911051834.LAA01423@localhost.localdomain> <14371.8924.995114.613109@weyr.cnri.reston.va.us> <199911060024.BAA12971@mira.isdn.cs.tu-berlin.de> Message-ID: <14374.59416.389928.980474@weyr.cnri.reston.va.us> Martin v. Loewis writes: > 2. Choice of the specific names. ... > The '_set_' and '_get_' prefixes don't create conflicts, since IDL > identifiers must not start with underscores. Martin, I think the _[gs]et_ *names* are ugly, but I do understand the rationale, and I certainly don't have any better ideas about how to do it. Paul has it right; Python needs to define computed attributes as a language feature to all the creation of a "nice" way to do this. As far as expecting non-AttributeError exceptions, that's always a possibility with __[gs]etattr__, and you shouldn't normally need to know if an object is using that or not (unless you're subclassing). So a programmer has to expect anything as it stands. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Mon Nov 8 15:27:04 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 8 Nov 1999 10:27:04 -0500 (EST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: <199911060243.TAA01099@localhost.localdomain> References: <199911060127.SAA00939@localhost.localdomain> <199911060243.TAA01099@localhost.localdomain> Message-ID: <14374.60360.832447.613125@weyr.cnri.reston.va.us> uche.ogbuji@fourthought.com writes: > Well, scratch that after all. I forgot all about DOM_HIERARCHY_REQUEST_ERROR. > That puts Node squarely back into the "needs __[g/s]etattr__" camp again. That only requires __setattr__; __getattr__ can still be avoided, perhaps. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From ken@bitsko.slc.ut.us Fri Nov 5 00:47:05 1999 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 04 Nov 1999 18:47:05 -0600 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: "Thomas B. Passin"'s message of "Sun, 7 Nov 1999 21:28:57 -0500" References: <199911060232.VAA14716@python.org> <002501bf2991$035ebb80$0101a8c0@tomshp> Message-ID: "Thomas B. Passin" writes: > I'm getting the sense that the tide is running on the side of > spam.getParent(). Odd, I'm getting exactly the opposite. Most people seemed to prefer spam.parent as long as there are no major performance issues*. If people are saying they want spam.getParent() simply because of the performance issue in the _current_ Python implementation, by all means let me know and I'll help get the patch rolling! (* other issues, such as encapsulation and API style, have been addressed.) -- Ken MacLeod ken@bitsko.slc.ut.us From ken@bitsko.slc.ut.us Fri Nov 5 03:01:09 1999 From: ken@bitsko.slc.ut.us (Ken MacLeod) Date: 04 Nov 1999 21:01:09 -0600 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: "Fred L. Drake, Jr."'s message of "Mon, 8 Nov 1999 10:03:55 -0500 (EST)" References: <199911052351.QAA03963@localhost.localdomain> <14374.58971.369022.478622@weyr.cnri.reston.va.us> Message-ID: "Fred L. Drake, Jr." writes: > uche.ogbuji@fourthought.com writes: > > > Yes, but a large part of the DOM REC can't be followed using pure > > attributes without __[g/s]etattr__. I know that one can choose > > to implement subsets and approximations to the W3C DOM that don't > > run into such problems, but that doesn't suit everyone's needs. > > Some of us are looking for full DOM compliance, and that's why > > we're dealing with these issues. > > The W3C recommendation gives IDL, and there is a Python IDL > binding. The ._get_() and ._set_() > syntax I described is the result, and is (however ugly) conformant > with the W3C DOM recommendation. From those who understand the details of the DOM and CORBA specs it's not clear to me yet that using attribute syntax is _not_ also conformant (i.e. the Python IDL binding may have been unnecessarily restricted). The spec fragments from DOM and CORBA posted here both seem to support and allow attribute syntax, as well as providing a convention for languages that don't have attribute syntax or the necessary internals. > I think I understand why the binding is the way it is, but I don't > know if IDL attributes are intended to support updatable values. > This would require digging around the CORBA spec a bit. The DOM IDL uses a "readonly" declaration on some attributes, which would seem to imply that if it weren't declared readonly then it would be updatable or writable. -- Ken MacLeod ken@bitsko.slc.ut.us From fdrake@acm.org Mon Nov 8 18:20:02 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 8 Nov 1999 13:20:02 -0500 (EST) Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: References: <199911052351.QAA03963@localhost.localdomain> <14374.58971.369022.478622@weyr.cnri.reston.va.us> Message-ID: <14375.5202.786218.365139@weyr.cnri.reston.va.us> Ken MacLeod writes: > From those who understand the details of the DOM and CORBA specs it's > not clear to me yet that using attribute syntax is _not_ also > conformant (i.e. the Python IDL binding may have been unnecessarily > restricted). The spec fragments from DOM and CORBA posted here both What's conformant is what's in the binding. Perhaps IDL features could have been mapped to Python differently, though I do understand why the current mapping is considered acceptable. I'm not saying that a different binding could not have been written, just that it wasn't. > seem to support and allow attribute syntax, as well as providing a > convention for languages that don't have attribute syntax or the > necessary internals. The DOM is merely an application in this arena, and has no impact on the CORBA mapping. Since the DOM is specified in terms of IDL, the Python DOM implementation is constrained by the adopted mapping. There is nothing that says the DOM client stubs can't provide the magic __getattr__ and __setattr__ code, only that it's a (potentially) non-portable extension of the mapping. The DOM server may be more tightly constrained, but I'm not sure. > The DOM IDL uses a "readonly" declaration on some attributes, which > would seem to imply that if it weren't declared readonly then it would > be updatable or writable. Ok, good point. I was thinking more from the implementation side, but I don't think that really makes a difference. If we have the IDL: interface bar { attribute a : int; readonly attribute b : int; } then we can expect Python code that's essentially: class bar: def _get_a(self): return self.__a def _set_a(self, new_a): self.__a = new_a def _get_b(self): return self.__b -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From uche.ogbuji@fourthought.com Mon Nov 8 19:16:44 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Mon, 08 Nov 1999 12:16:44 -0700 Subject: [XML-SIG] foo.bar vs. foo.get_bar() In-Reply-To: Your message of "04 Nov 1999 21:01:09 CST." Message-ID: <199911081916.MAA05097@localhost.localdomain> > >From those who understand the details of the DOM and CORBA specs it's > not clear to me yet that using attribute syntax is _not_ also > conformant (i.e. the Python IDL binding may have been unnecessarily > restricted). The spec fragments from DOM and CORBA posted here both > seem to support and allow attribute syntax, as well as providing a > convention for languages that don't have attribute syntax or the > necessary internals. I would have agreed with you a few minutes ago, but the inestimable Martin Loewis just pretty much demolished the argument for __[g/s]etattr__ as the binding for CORBA attributes on the do-sig. I therefore pretty much give up the argument that we should use Python attributes because the W3C used CORBA attributes. I still like using Python attributes just because they are clean and Pythonic, and I think that it can be done in a way that doesn't foul up inheritance too badly. Like everyone else, though, I'm coming around to Paul's view that Python needs efficiently-implemented attributes-with-behavior. Petitions to Guido, anyone? In the unlikely event that I have some free time in the near future, I might look into a demo patch. -- 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 larsga@garshol.priv.no Tue Nov 9 12:02:14 1999 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 09 Nov 1999 13:02:14 +0100 Subject: [XML-SIG] pyexpat & xmlproc In-Reply-To: <3.0.5.32.19991108150049.00971790@pop-rocq.inria.fr> References: <3.0.5.32.19991108150049.00971790@pop-rocq.inria.fr> Message-ID: * Alain Michard | | I've done some comparisons (weeks ago) on a few relatively large XML | files. On some of them pyexpat was a bit faster, and on the others | xmlproc was better. Was not systematic for any of them. Alain, if you could either be systematic or release the files and your applications that would be much appreciated. I've now done relatively thorough testing and have found pyexpat to be consistently much faster over different documents and applications. I will post my results as soon as I can, but it would be very interesting to see your results as well, since that might make it possible to find out on what kinds of documents/applications pyexpat takes a performance penalty. --Lars M. From tpassin@idsonline.com Tue Nov 9 14:01:41 1999 From: tpassin@idsonline.com (Thomas B. Passin) Date: Tue, 9 Nov 1999 09:01:41 -0500 Subject: [XML-SIG] Re: foo.bar vs. foo.get_bar() References: <199911090606.BAA00415@python.org> Message-ID: <001601bf2aba$f32a9100$3cfbb1cd@tomshp> Ken MacLeod wrote: >From those who understand the details of the DOM and CORBA specs it's >not clear to me yet that using attribute syntax is _not_ also >conformant (i.e. the Python IDL binding may have been unnecessarily >restricted). The spec fragments from DOM and CORBA posted here both >seem to support and allow attribute syntax, as well as providing a >convention for languages that don't have attribute syntax or the >necessary internals. It is stronger than "seem to support and allow". The DOM rec clearly illustrates how to represent the interface in both attribute and get/set ways. Here are some fragments from the "Node" interface that demonstrate the point: In the IDL interface definition for Node: readonly attribute DOMString nodeName; attribute DOMString nodeValue; Notice that we have both read-only and non-read-only attributes. In the Java binding, this is translated to: public String getNodeName(); public String getNodeValue() throws DOMException; public void setNodeValue(String nodeValue) throws DOMException; Notice that there is no setNodeName(), since Node is read-only. In the ECMAScript (Javascript) binding, this is translated to the following: The Node object has the following properties: nodeName This property is of type String. nodeValue This property is of type String. Notice that attributes (called properties in the binding) are used here. There are no get/set functions defined elsewhere in the binding for Node names or values. In this particular example, the DOM clearly wants the name of a Node to never change once the Node is created. Java can enforce this, ECMAScript cannot. Python can't really enforce it either, but it doesn't have to provide an easy way to get around the read-only intent. So Ken is correct and the DOM rec does not tie you to any particular way to translate the IDL in an actual binding. Regards, Tom Passin From l.szyster@ibm.net Tue Nov 9 13:50:08 1999 From: l.szyster@ibm.net (Laurent Szyster) Date: Tue, 09 Nov 1999 14:50:08 +0100 Subject: [XML-SIG] new qp_xml.py References: Message-ID: <38282690.F47773EA@ibm.net> This is a multi-part message in MIME format. --------------CD99275CDBC6A2EA4902452C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg Stein wrote: > > Suggestions/changes/etc are welcome! (Laurent... :-) Here are some suggestions (partly implemented in the attached myXML.tar.gz archive): . Split the building of the tree between a "Parser" class that instanciates the nodes and the "DOM" class that stores them (and eventually index them). This allow for more combination of features, hence better code re-use and extendability. Here the important is the definition of the interface between the "Parser" and the "DOM": the "Element" class and the "DOM.append()" method. . Allow for direct mapping of XML to the Python namespace, in such way that you could refer to the second

element of the first in a document as dom.root.chapter[0].p[1] That's very pythonic. It is implemented in a "DOM", and therefore can be combined with different "Parsers". . Allow for direct mapping of XML Namespaces to Python classes and functions. Which is also quite pythonic. This is a feature putted in a "Parser", independently of the "DOM". The attached myXML.tar.gz archive provides a first implementation of these ideas. That source also includes some support for XPath and XSLT (though you'll need to install kjBuckets for that). It's allready working quite decently but I expect public review to show many shortcomings and even bugs ;-) You'll get a better understanding of myXML by reading the "paper-submission.html" document included in the archive. Comments are warmely welcom, specially about interface. Laurent Szyster --------------CD99275CDBC6A2EA4902452C Content-Type: application/x-gzip; name="myXML.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="myXML.tar.gz" H4sIAKMlKDgAA+Rba3PbRpbNZ1XpP/TwQ0hmKFJ+JVnZUkaWmYQzfo3NjJN1uVwg0CRhgWgG D1OcrP/7nnO7GwBlko6yTtVurT6IEtiP2/d57u2LxfrnJ48HX/ypP+ru8Tf37qkvlFLffH1X Pm/dtZ/u5xjfHN+6fXz79te37+Db4+PjO1+oe38uWfanzIsgU+qLJP/UOJ19Ysj/xZ+FyH8Z LHV2lJeTRZznsUn782KRfLY9IM5vnLy3yP/uN/fufFPL/9Ztfnvn9r0v1PFno2DPz/9z+T/4 y6NnF+Nfng/Vj+Mnj9Xznx4+Hl2o1tFg8OrOxWDwaPzIfnG3f6zGWZDmcQH9CJLBYPi0dXZ4 8IDfyufw/BE+IdAHT4bjc8waPz8a/vOn0b9OWxcmLXRaHI3XS91SF8+ejodPx6etQl8VA2ra fRXOgyzXxWmcm6Nvv733H0e3Ws3Fnp4/GZ62fhg+Hb44Hz970Vjjifl3nCTBAPR9o17r9I3q /Hzr1n01uq8ex2l5pW73j/t3vlbx199+3VWvn+oiD6Hsb4T2gSP6wcNnj37BJ/66wKrDF3Kg W/LN2YPvsZd6OfrP4elf756JvTwY8NnZgwG+HWDcg0E1rV7icVBmOLR6+e91XuiMa704ezA6 exyHOg1jrXSqXuIzDbUahiY1i/jXUqsjdQ72rnOtvgwWy/tqWJSRfjAYnVUL/JTG76GLcaFx xEmmVaTVw6y80kmiczfy+Rl4npdJEYCCIzXW4TyNwyBRj/QyyAq9AGV2wVcmS6JVjDVGmAAJ gxx9FJrFQmf4s/Nq9HLYlRW/2jzmw8fPLv7xz5+ejYdn4NL5JC+yICzIk4rS8TzOlfgWtcx0 jj1zVcy1AgvxOLwMZlpNdKqDYq4CtYijKNGrACcCpYmODg+Gi6CvxpjhRy8z8x605iovl0uT FWpqMkx9vi7mJlWPnj3pyeJPg4XOMQcDg1ytwJnDA/yRm4VWU2wHyeTKTNXP0JFLTHkuFKSR +vnl43G/4iGO8Bzc4kiSDWpIwDsd4tGEHxCEwhEL4wlTZJfqgCqwL1mrF6OnwzHYt4rliNNE X8WTRGOGSbBmUOCoqXofJHEUQJ4koaCVcQE8zmJTgmwNxUiLOMAppjFm89ugyPvqPIfw3+vE LJdxOlMxzCybyrFBVaCKeEFRQq4Lfv3OTHpqhNkhnBm4C46B7Ki05yDfkiCdleBzrjJwBGID ianSV0sNw8eYWRYs56JHdIeN/YRnkH2tE01T2Ks5F5mO4iKvFWds/KHI8Z4X7iqwyrNMgkLY A6mEcwNr6qvvoQWLIF2rTAc5zts/PDgPMkx6FRQgMW+ry3cPy/BSF2qBA8NOFHZIixJ6toYK htAXWXxh8kLFC6oWLcekGks9LAtFARp8ctDKZJfc/YdMz9TLQsdpT/0dCopfKZS8p77HkbL4 Uj0u08jqlSE388MDexaNvymJlSmTSKWmUPMA3I3wDXRULcpwrvr9vmzKB1O9UqGJdP/3cvjH 2/gcpYVIl6IHI8lafNXwZsdnMLrAqo5OZ3GqK8cmC1DfY8v0zWFWc1dwvGppVlAEKMnw0UgN 4EPA7hRsnkGdV8G6r0bwM3OIbqLh72C58SzVES3GK32vofFkVQY2wxKgixkMPi0XE2wAbueL gGY8gRDgnZawJAUjz0VbJ7pYcX3RgSieTrW43oZ+wlVeaiFSHiLepJjYOzy4ePkvBTKCSQCX C02H5OEaqE7ZJQgtl4phynqhlGoiujLNzEK1oL1D6u2j0ZfpJF/ex/9PAj5YwuW1+uJDvtdY hZx0LuDJ6MkQbLRGay0+9rwUcWlqnVBg4AlTiH4RxLR8PNIBNENWoBfv213VsFZl8XARDHwh zpbOZaIrVkcqmAVxmkMkEGqcQR7TOJWIDg49gz2ZEmG4R5Fn4tlSo2Y6jeGEMI3+jcqQIDCd qLUpQR39CIRZwMXKKedmJe4QfKdAYdggfxaHYqNFmYKKZN2TyYsAsjLUb8uawwMgAPHKTU9k uUjuV2oSkGBENZGS1cujagKpjnQI7QnErZHBiTE5toXyQMgwxlT8/IkcBvAvjYKMUsAYuhTR DDG7IC9opu+AEcmaJGqnjDhJYlaHB/ePutTuOiSJ73ChwkaUfJ0WwZWQMCUt2MuG3vxEPRiP z75Mivt4QI+mYXR4AoX0X4AaRBj3uBqO8ybr6w8h39ItIJvVa1+5BcDFX8By6kM+Z4T12+aW +X5GnIYJ8IabpOCKteAlHGqTr4cHFcPXbmFsptOGrltf11c/QiUyPUXInUNUPbFekCBOALyC 2MMsXhYUY7UmT3GhEsAbxEAQef58JP7ewhJEwiOEosj6JTjTv4iSnBeWzIUhj324tsJxJkDF oSHBEXx/fjF2orkCMQlcWzGnDvpgqxhrYRcvY2IinCWn6of0CoGaGRPB/xTBkaeZmhIi/hSi Ybo22BP1MyIc3FBhIQZ2UB0hlIscGYQA+qW8KKdTai/DjKiRB0/kkFnqrjWFYUBgwcPRThgW JDRWqn21SMC3/lJ8r3zlqJ3GGRTUSuXwQF+RkbllNWQDrIj5cYrRjG+UBphXmAKYva8YArHS SAXRe0JErFZm9BKHB5gCQsiGqCf+p6CYG16YJNBR2OVNFhFXwOgzItgw0VAdCW6I2TY6Ix+z kl9zHGQ+YcxZMkNg3PTuzWEwztFJ3tS5wwPoaZ4T/VG+ZRo6F3ee5IZycuTU1CKAFB7uFB/5 GnDLxj1xJl5Ha3EjGApzrYBGwkA8ForGFu8evRz9UKEtp4Tg9Jxwjqsi96YZTBpmQbcvRhFj ZewGL3YpPMSADYTRhreaLRBPJEqlNkLRon+FLkARxJgBgFMqLtIAOCIwkPBNPdTJLC4XnBgU WGfF+dRFJgmRZT/NjFlP38IzG3Q8yLD50FZokcRFgdM5UW5Ci2cZ/JCgH2wWICAs1h7nzeDL FMBb6WETgolBuAeIEzURcA8L4AGHV8ugcMfr/J2gX11AfS671jcu17oaoDoNiOa+d/xRMqBT w7muZRaHXL6bCG7M3SIbsLJLvomV2uwEULtgfLXe3iHNE+vSrfp6adj903zb0ytI/fLaI5xi vilJeZwnhX/6kXTunNGg8phQKWNqBNbLMwti57rKbHACb2+SNtg5nKImJsuA8CILeGoOYbcf JSAQz6kgkdjntYZ5DlUQqRx1rKgtoHJJZQo0MDeRubKIDtpiCot4kFlMS6AJHhIhcEYcLna5 IuikuqxgrrAfqMJLgwdz8clURWVWSKaYG0NGONp1G/BYQkTmGO/EZKEQs0KYufcYNh+bZ5p+ ShyKxYFi7MyftMfH8L5xqCZlnETiThITXnosIFkp/8BpxG/JWv3NRIiUvRieyVd+4AmxvBVo 8zdJVW/fEri9fdshaOmpr766XHVPto3e9VtxYv/t2ygOsUy/XBIgdrDKnk2JJ8xUtrzpZupU tVrqr25Xx8AbLEB/GVKbZIEQfjO6EQV7KctBWNh3p+vWVDqkt0cIiDy60E4MN+QJsEvnrcS/ oZV3T+n+WzmaCEF2aH7f0dt34DQiKqjWqXoq2GMrwUk9cOuIfQQ9GFA9WTPbUNrzXOBfrnUz ZyhsCiu2H+d1GnZSmQCeCqoOYCpBeglbsrGcyYmUoFy2FMZZKIAAAJJoInSIgUbmrbTH2pGm N0G8IrCRQhScUiLpx/OLR+fj8z7LW7J07u1ywxwVQbFLwCI1WUuG5LyEJYb/W43g5gvNvNTh +LdFMGt4a8fjJqC3XGyOQQTJmv+LSWxCeKeA3nXB86xVS47fIjUL6Nx7YpyyMMQpoWSAHfFI ce5qaPSskkK/Y/Qr4Mq+69YplTufS32s80/i2bxIxC/G0xgrNBwqeSAOUqJznNrDbbhY1qTI dsuDHpPbkkjso3jcyBIF7kzKpHKZBFBIHKhQlIusV06SOGyk9D0rFmKCPa70uZzwBp40MosL zjwVty3cPj3u7ltAmOhmx+myLLonO6xFahAMom0fgHp19hQL1imJyCXzUIIQ8yKjugW5XVqy KQ2JQK+sbWwYh1XjSAeJrVhBkTdU3Qq6JyZa67fVLVc7oxZYAHCCiMvpAAAqWAXrBlxeaYHQ AuMDiI1VEkHNUK/Dg9GUp2pnxJmZzQ8jk7YZ+RnLDbN+qSAJOteE+zq4zBtlB0EQM6ks2ATB HUDKuVxPCPelYfzpHUCmizJLuQDRi/cmlcK71VOLK32KEspRAXy5spsTSznWG4gXUr7UYTyF cwic1yCBkgTI+bdmJkie1tSTABlWz5qmAw6swp7s0V0codIk98Xv0eE/hAMyY+rosVPVOcpp uj7l2BvuFU+V/kxhu0n11oB34yX1R2gIT+im8+6NDolk9DMd0mpz46x7RMNCSBo54Xjne1P5 fC4WIJAuIRdLRr3mTBdcENGyJ5p2s0WhPFz387CWK/Udz25Ix+eT7zX+vLa8eQPOvdZvdsQQ qYSujHNFiIjW8wmqoc9jAGCsFVN1RroJK9ypnY4AMHV9tY8Ao75+88HD+UC4OtZn+UTMzscU myNpYIEgipTgnNzVMCQg1GjDOUFkb/PgfWxKqQEwuQwmpr5Ic5gggHvOxIm6Eq+ZWkxWOVm3 hysbpP7KT7JCCS+biI3VsjyNl8vtLrdR/VTI+KanrcU6L9asADLNbokPbhZswRcWAdLTVhV+ OWiLmDlrcjaOC8ZUX5etpxf8ojUQCgaTsx02XpeE65nL7Rvu1LeqgDy4+bxJ9gcmDVwRe+uJ 3r59u/OkrHntZqacoWbDFOqIkK7zPfwf7F9x0CjDbzU7d5Myh7bTNBIiOcby7crknB/MpgPf AkjJ//sWKE67tjTMZIdosy+W2u17CraneEvAQGh03x167xifyO44itxWxwwP1ZVSpdOuXFPZ GGnrOTwvGytGg3hSFtqWoeCvZgSCvCPzVaeNG3hXdaoul+S2Syp/E+3LrvHUIix57DCW0OHL uCC5zPXGHZI4A48WXcWKINXCS5Z5y9yb/dPaN/AWRC7bprG9eTsCXlVzs2TnhTt9oyznqkPb izVSE5MCqLsydjKnBVsEVzmlPfHi9yYmP7143KtwcK+WQ26TE7dhbhOejjuB/W9v+nJtm4rk /PT1m0Y65BZEiNmZ3rwihoad2NKm3dqGHikCVLg66l0H1MxSY3t7Vu8vFwLVv/ZejzU6CUyB 5Ud9gS3C8DEJWmmxudUfX/veGFsx0O7B4Y2bgvH1AgGvBKVijUyVoSyL3/uyaKO866a4YjF3 XbDM4btD5MKRpdE6je267KvaWyKwy4MZCbd7GEpu2tmdaq7EOEhZUYkgUEVJM1nw5sztUHNB LhE3C5WxTZ+cpdtSZl2iYfI3j1nnKa4txb3gomMdXcu86gxSBB8kvn5Ky60l325ot7DDuV2w fr1ROK+BS2P3TU46QnhHY0B1T3q6gmnByew42XB3VaOCLB/5u78dlGXadTVVPUVcjnktMZRZ LABL6I6qm7CNi21elpF17lrHTN5Ls08HMxZkecGsGLpz/6hbwZm1vzVx7TmT+nzGXlI2DsMq d2ZAdC5yOLcyXHv9cu7Yz3doqkJ1tm1KuaYbCN7edRwe2OJ5EUtdDmGYCXrlwincS+K5Utpo 7GKUt2/7YsNVA6uJekh/jbZuOWQDg9DCWwk4i6yvHmteTc2MmkgNyyhCR7DeMkxfBdzI2Tgg aC2t7aZja9Eti+YsxJtrvacczSvVND8hDDyVefvHTc3+URWS5IInWzGn9N+2BpsjqyAt/90I fU7NyQYAdevtRKEyfg8QlfmfA43KQn8UkpLKP4RKG+TfHJpi1/1Ysj7TDSHqJ1cebOhBpR2D WonxDKq9IyaMpjQz28Shr2VHrgieNsynt6c05WnobMa9feWGnQCE/SBxoqva1eFBv9/nB0+b 0lorQFbR1tm6WnteFMuTwWC1WvVXd/ommw3GLwavHh1xpXZv65zf2v4s7ZPqWB+2D/2wC1I/ NSuyVhAN3R4bm3ZnBv44ndf2hG8+yhHyP5QjFH3Pyl10PtdZbtJULgpGFQT+tWQnhr93rSqh vsLrCpzXbmgY63gxKgjId6p6pMQr3c2Sb6Ztv4crqdr2SxfXs0ZzW53ds++kmVEwckBT/S22 6kyC6Luud/8b0HETijjwVdUzPrpjPzxwKJ+30/4eOJDWOwIeORSh5iwxE0CWeptcFwJBAaAX AU2XeWI41z0nkEYQDWRbFsDKLOlJt44ry3i48olKcKcJwP+n2cQNy4Ju68t3hAGbC9281Izz Q9Pb7ZvPnGsA1yzfc8m5//fhQQ0NWGN748SFv3/74G9cN0W03dDgn/bfh85KQV2VunHRa+KG plPLkqRx4TXyFpG760c2YIUmcX1M2q3YrIBtayPx8iIu3jgzLxzshVrasIJ6QF0n/Ajs21I0 IXgspUarl/Ui0l/SaLGw53bg5qOzu+vf3amNn7gjoiiRkJb0FNLbfp1dF7Nft4mu2iysVuKl V8UfuzzlT7lHrdeBZo9sT0xgmbTSE7KDPABvK8nY2sMWT+OiRIqAsStEfFxWkDX2Gv3/1ohp GX9iT9B3Uv0Ar3Fd9Xwt3p6gCoh2GIWGdH+XrERh2ahcNOoIcv1v94s2VHlHVpA4j8BIFF8L u26d7aqYeNLjPg+7i8gX2rYMuJvPT2SrJkWErlK61dwktdn7FEwS1FeSgS90kFrPs5KoK+qJ fDRHpkTDr7LSKlmwPQ7QxDiV1lh51cH1RwoCkIy+ttisTOUun8rLO2qpzkkbPiuBclfOS2Vp 6ljZXkJIAMghWmMLW3ez9T0p27F9S8H1Ip+rL69d9kyR1xe+jb5zqZx4LtSpIy8fpO88MgRh dacILciv810TSrA52+EI76k2Oux8T1jVPRxU9YpLYiZ31VK13NpGwYeNRkHpZbduW96ZabbX k40br0NtVoR8yl3He1fc66llUsrlse06WQRFOO8I4fUNDtufr1+Fe5NwvGDLrm+FEYbLQo22 dZe1WA6fs1bafGXKvivFVxMg785aF13/Mhb10TZnShlJtIQQEYMRhjB6afKcrz9tt0ChqDDZ YACWh7CogIW0jetvgsLXf6PxnA7s/dVALpzkUXVjNlJRbF+rWcuFFfWJHiFd29qTfe9KlJHO nf7aFh2qioXt9oY+rtgAC25lZcj3raBu9r0dGlm+ksKHtM2ydDEBqp1OY77SV9i3E7h2dejD g6O6kSgsM6kIUY349omyWwiT7x913XEHAznwnepkD3UYeOvzGuuV1XbZjM7YWgmYpCO+kkWI mm++z1HRiGBk6+V0nC2LROIssjdU2PesMp6W06zQ1+1Br7aIHyaCsy2k4JhK54n0h/CcVTC0 tUjRaWPfH7XiqAusQZatseQCEo9D6mfVeg2fJHDEv280ca6Hb+vILvLKz0dN+6K6vlXGp2Y8 ZxZHvvTpSGdasICd8/256lKx9rX1KzJKHJGb/M5MBF9l9fsP0sZty3NS9WL1z19DCmcPD0wY ltY38YUmlroquUvt0XemLFyLW9WPbnv3oY7XXwF7lvJF0jltx/nLRsLT4fxLKW27W1LxMlB6 tummYtTdk20dxjMjb1WtjcOC7oIFXKag7GsttTNg4Y2FhFxulIReZpKJmVGadrh9Sc97nu21 BWfep62rlnv7tWPNe3LaWrfUf6m/hd1d9+JS37ahTF/RvUrPWse+3eA8IWiq4grliO1Um7/b rt+Ql9hVZG4HbStAKFcADN6+atumZNupRb1rDA7btmFLCK5dbVv+dwtZETdnTa5tsW5Ld96P d3GiC8MXf+XPcWXvdBiwbZekWv/a6ACIJehYP+p6E3261m32I/7e7gDlmwN+T3Lqc9M/JQfd 0qZ009ne3dh076azKTWZ+onGDHljz3aHSphsePbqVsdX3ejmduBRoOxgBuTcuXz3kmWGy3c/ EEh0P1wLib+1CaIbA3+Ti5wTJf9+6O4i9zySTvXqxsxUOZ+UdXjbxja1yXp3knaTliM1ZJ91 Qwq/rxmI9wrDmynK8PXxm34QNVX4hvNv2fk7KLpx+8/Gsf+7vSvvbttI8n+b7+U7YKBxAFoU D0mWEo4oW7HlxDuO47GU7M5QDB9EQhIiXiFIy4rj/exbR59Ag6Qc25ndJd6MQwHd1Vd1dVd1 1a8NH5+Qhyhsx52yGt+wbdS7U/bcdUAxG+K4V/jYrowKi3TVqiaglKXhHefXkRwfpEGDw/Q/ yE/r6OP4Rx3JobxbDQrp/QRtPMLhxeaJ8847t29Ru3/6KO0urv/H7IyP5sa2YPganTZ1M7K7 ZvY/ydtOcXcbOTs/Ay3BSe/ee0XavHQxEztLChccSDdgS4ty73RqlvpCe55bued5fF60xyE7 stjJqVhirkihtqftHhgCQeeqaPZMC5QwFNNo+RC5WS7gC+y4L0ohiMeAqx50YHZ6D/AF73E6 MNzwdwjjDlsn/KsN+5mOaBW8POcsINSq1NVp4TnFc1SqtKFAqlC4SsURhnJjVHo8ZR9tNLUN 4myHxFhExG5KYkT0vlBrFQHZ9XoY8HAjN+scsCHGT+2OZCAH7YFztlxhjpgmaLxMQT1U27hX 7NBIQyC2c6yg0v5/kAwTirSMcdRGGAeJAcGvGjs7vK+WPlLfvfKOdx+iHYY0AwK3+aKE6DZU 8veow1PQrlEc7T8o9hcPZFAhTjFQP2LTMMGDkM4TXZP/C4acoiVAOyzg3pi2Lbj3ZIs1UrnE kAD0oAWln9CAbrVmy4ANoOpcmDYcS6lCQzePrzdAoA8soB9PgIDUzKSvGfY6qx+/Kc2LY5WF LypbLzAWk8LvqyDOZ7FWuzR6hHbbQNOiaEcag/rHen/UE3aQTB9y77qgEWCrj+mbIogXd8AU 3s7q6WBAahcemIhtEog9hmKJOc6RdLu9+n3Zrtl4BuorjonEdYC2ROdoTAGNNvV2VNIvSqIw MYKpcJXFY8d5LLdyaCeA9Ar4hMcSpUEckQ6M0YqzLQziESKFUhgKt8o6Bi0aD184wjOl8aft a4TIRsJ9d7dar9e/KOlIDeRe1esyNJpMRamMFiOTJ4V+Qn3GE2hO8lvE1tCbKEHHEQHcMZmn HFU+vhlRyPkTNK5MhUHnXACzSKHQl0LS0ARRdAiRwKoox1iPOc7teQC6YYrmEMk67nkUj8bz yytxRELhqD2ybuGGTOjIFDBNjap636uBpgR4kjrMTtIKGvwGYwrywUj/aBCdJ4Nkdit8o6aC B1+MxxSVL+pHxVCRSQ8SYxOGxNRRegXLGyj/ZJlCd7znh/F8cvVlHPVgJP42TNKhAJRqkqWJ zaInL05dYdx4fomeShQrrGO4MQt6Kp1z0DMIo7ivaJ3Mh0OK+Ka/2HsnpXc4jYWYhcaZMFDS 1NrU3pwCBIhEOkXSkOsqxdhSVgPtiLV85HjhdjUhPo1S053QMkB8UZKSlzCgtIlTxAGyAYXi 30dv4hHay2B6kV1dHPlgFSADW9iBA/DUBgfmZTyThnTTQ1XYj1HBEuZSCiPMYoZoc8nzmXSO o2O7c8J8gJ7EkYIJH5HzjbJYMrSF9lZ9dfhPVAbHBNZDtq2UwCuU+6MaARH63fQQ603DZFQp shqBPvDgfhaPeL1i7j5nKKSET/qTmV4a0JuNp0rEIZjhNL5ETzEMzJSTEdfcHgh8aBbCHA2j 2/O4jILn9iZi27GBYYNIF+iKkJqgQbCqM5INxgloCx0O3hDeI0CGQPhQGEFknsvYCaGSvMCw HBCIPQk5SKAD8RwS9qATsC3o0NNkc+P5/DIl+JoLYIiZACuo0i6GgeSA9RkW78+G91v6MP6j NMxUJ7efoIxGvb5XjP+IbxuI/1h/uLOz36gj/ud24+HOGv/xczzdLvB6t4uHnwGfOAUVL5DH x/gbxB3+h8yP9ANPhjv//py9flZ5JP6r8B/5JGUsmf/7uzt7nre3v79PCfdw/hP+73r+f/rH 9/3S2+FAcECJrNi8/0rZX50OunHPBRv9UMIDmEdOuH35ddIVUDrNn8slgdjU10qhoij25e5A 6VLpG1RJUA0WSAEV74pOyzS0T+8atkAE+wPJsfIl4SPDgfKl0gy2MiVPBeQwnRLvN7zn9PZ4 Oh1PMRFthKjijC2VzVUqxZgUhGO3ixtJkJObXlCllwF8tdFaEK7Wo38KAVpKcsUrAl9RCRQd C3NF55fWWsaNUO9tmBRGnQBNXmdUmbOQJz2Jd4K9KFPKAGRdLScoCXzOQpCUPBtwBP5eAC8C KbDpskcx8H1Bb+b60TgVynegI2ZdJaJ4dLtvrLhy69OC4GiVjqyVVq5cDHe+hkXnKKW7lCz4 Xj+O4GKye+qoZ02fZ8ff41s1NZbT4ShlK6lqEY1ydqygs3Uv2GXYHKVTldUkEzgemiu6ZDBE NRUq0tjb+WqXXx+/PH1++vz4BI/qAtipNL3gALctl/TzEH/+Oh+T71rg41/RcIK/vwzeL5zA Ji5IlgHlNzaV0k8HH8ZpPNPEHKwIbx3MyI5w8O8CJjMSWhUKy3ZFpTizZooQFfNp7guFsbIs FJGET8gX3CA7qZ6gTUgM3Xfsz62E08np0etTI+3xqF+Q8vjlUyPdk6sIMXzi6dNoFmWTEp6P Xfu3VNN8n+egWZxdTyR4eODrgimVsM9AyCgvXqvFfwZB2U6Hz/SNrPDbCXdeKGrQKFuJ86OJ DxsVG/kPVGEgzXAw6GAn5ouaD2VnHqg7mTzdFAtqHAS56prPORR/7fzqoJVWvHph1TB9y6uj C4Vm1OKq5gvWNPK5UoONScCd0F4hlPWjd+htka/eNEKITKoNiAoiIS29/BYkB+KFZeuyqBEW TZ1Qr+Fsf3DP8CqLVl1Tc30xhYSWYzQJxSSg03ZeOfKC2VFfpp4X8vhsWFg5RvCgFlS4hopj qFBsBGjyVTxaQ1pUHV7JWu/ew0/azbSQ7fRuBP90c4LaPLTaHWPrdG8DrTsDNp4xdQ8XLzyq mN5aeyXy9J0i4m9YRzv7KOTOqXjbmTktV9w2/5t0cAEUvzcbHbvfuXt4obXCKjNuFvm1EcWw a/3FnjS2WDqxc62W/eJY6/Gx1gLFWTnPH8fGSKwSuuIFa1GOODscrURS9SJxLywMmnc/BtMO 8bBiPiF7IMP30ZAEonMDB+acXpny/W9scPnBbe+Cz1ajM990q2mNE+3uoYPoB7U8dnMK7nqL dIMBhhy3zO/trUYnl8RQFiB19s0m13kBk8RCceGi+Gc2V4nVn3QWisbjIi/gDZiRZLhccKDC luWBU8unI2b/8Bnh6qFLjDdr+ad+7fCHUUx/1w5Pb8YHNZH1MGCaQp5OSJj+2dr5p3/Y/mNE EH2CMhbbfxqNh3s72v67vYv2n53d3bX953M80v4jOaDU7XZLIvpJYnhouA5zwRemG1zGUrak mPEWRozBmKABpgTOKwJEK3w6TDHS6puOhMEQf6Ku40IdsZ1ptVSyfIqZFDupM44ihpKEZe2n YUZu6VCYkjJH2fev0LLwFgOYTNQHwt+OvMmYzh+RJHSMqK6uSj/GxZRwq9j5gcSRPOoLsGIG 1Soa3tQ5vtFYjWFiQZkrJBNyu6bhgQZTbItCVr9llITx5TQasrYgzrzwyE0fmMZvk5SOIlWh JXlFCiYU7jZ/2yq7zW1FGDgr2s5GqVT6s4HktjIuz/2yNoVJTtWmH1n0nYWa/QJgHXvVhoTQ HPg3o1RLj4eW5n6ZYINPSekIWG9BJRu8wxo2eYTfkzOwiJXg+iN0jEFJRMV46qQ5EMUFAlHa rpbBsi2jUSbBXIWoCqJWktfeizpdCOR64S10ZW5fYa87vZyLmy2MwA49HzSSKTk1mQF5JXvF v4xnz/7xMiTVYJSe0M0HPBAJbmeIShVD1zlJ0BQLN+xqElQAtwylWSzmoaBDfp+oXJABgHeU pfwGxZULkrabScfMivv+Zidjsl2Cw7SQEbWvQgHukj3AVjCz/sMYFCOFgwMNaCUlq6/jW/Y1 +PH1c1uTGdxaQiLV4trcHeu2VgvsZw4T9xLLmE02k1iTE+iCL0/kptdw/bDG3TK5yUwuK7AY f7IkBs0s0XYQdN4v04NMGu9L2U/P1IpnfcZFb5QqK77RDuk2aZeE6TFkGjIZs74gsbP89gWZ czvmkBeKBwVY4LVjacgPqDDoEHZWwUURWcbJi9ZqKmGHRrNkanoIPnPAYRnUqCYXIUidtIVG OyXAVVXK5Wqe01azB9oM585TvvPs+OSjiucrFxXn4P57mIsuBXyo0U10sc0qVhA9j0zdWrxd MAuz+bI5CqooV9bU3HjSnonMBwIX4CJ5W9IFUXcxxEBuAcvvUdAemzHGxhS4r/YTct2p6F1S eRUrWqHVtOgptLpZBrYPoCta35ILKfxzG5YXnZZtKJDYRKI+8lZHdYHY7Dg6Tu4kP4GhkVpj 9kVx2+6h+VHgrtmweLYoWN3ySLfOKVtjp3QPXya8frebex3c9AQMPRbkpUKseJ7CHtp7TbJc ulZIbc3MrpTuwaLKpRVZQcH3HDaUY3z5OPheDz5rhFavBalQndCBt+rMd8HzxhCSMnyp8Lzh ovhswSU/pW00lHKTwEd0f5XdBbm7TH2VFmV5nOqwJi+npGeMhlXmuYNYeLgXH83wYh8dH+au 6h0qs7ZafwartbEoXaFPLXl2oOTb4pgJ7amb0UbNNvAyqZTn8gfUw6rLh9i/hSSoLMoDIvO5 Fw3SsbnAzhGhD4So2kPL4PIUNFDcEg4hrXGes9Cy7jQmKy3t3fu7GpSjZtakfN7832hUZvuv BCn6NGUs8f/b23m4Tfbfvfr+Xn0b739v7DW21/bfz/GgTc/mgVLpiG505DgHwz+PA4a88Uhf nlaxsLJxgyxxJKrsShhHaYJ+fwJphIyv8vZecdsrwZ+Qc74OlJcmrtIontFtyyrAiayvbGNR Vou/QFm3E3kttWFjKUDS0gnE2+Ht92Ty1B/kG71FqiqNzkAT4z7DP3VWkGWw8vLej1Na9mcy y2pbq8pWBIiVr0k5X5ZN1GkyVqo2DCvn5dXKgNkCKTVNYHH58fWLUAKDDcbQrVfjdFZTujls NQO7DhfxrHcVpwoQjcLEjFilywSBcNB8SsNnyG1sgIaNVCMq7nYSNvaUbsecJbP5TAEVy9yi hw2LAnqgcvvobuWL3P1DClALq4ocKQHJMaJDAJIj/FiU8K0SaJ8C6tSLbKu0TeHYU4PkvIKg dPK/NCkqkLPYQq7nToVnzYomcxsLsqJxQRZaF7PGQ4nCaL+1ERbVN1VEBvzRYcq7k7PlKn6N dvkm/bt7XapqOj0u+aI7TYf+ztVQvMValh0dtICysRmxTLfv3pek4RtnHoISciVSmFSkS8Uz mIYVCsIlopB7RlfhUixyBeRcdCmQTSTvVeUPokfkLHe2DYaYE6Foqffd6ekrcVd2T0ZH3aaw obG2jFQh0jcxAcPhcO3oZUb9vMA9FmzcRiHPjOp8RK6XITakvd3sWKYAmz5Oqgy5K6Am5loV qxtyyTarwNozn00xzAu2esG3x6cB95sjFTN7GBz10PsVXUHRHbqmxdsqqScDEBO59MACYiqF GSV6OsUIugr+GKaX6N8uZ9wVaq3TGBTgTB6cN5wNe2a77vBwo54mAhcE/7uC4m57tj2JRhQ7 2iOzBUrq9v20czbyvJA4gwXT/bQcePc9BtDkFiychFYRP44UTBwVIAYby0Gi/CflZ3dk4zwm Q+d6hMfFXCVoMq00ssos0Oy6bIigUT52UsdnkCVIidPlXSF8LHyZYFRz3HedqZjwzVWlPpgH NyiIVfK8U7a8BGaiEzn9/S4m1d5gnMqxFPJMWmwN3Fr+m49R9PKthQhwDyWuXkVp9zq+NT4Z hClJGz51HP2nP7IjMtt6ZDFZUqqOpQ00P2QiVOUBeGbZZohkvYORu5ZSCRO+Rh/vaazgrYOf w/bPG50H5fBRcyOsPiiXH/0V5iD1AqYP5fmxfTLAdqSWx4sBNoOJVxlJkZF0ZKcZrti8VpqS 9RfYmIQCQbbiDauX0/F8EjYMeWaLZFP4ydTbRmru1OwAmqJX0sssoProGWvD7ZBJc1IEjYwy B3kvO9yLJToT9oxxoN2ud1aQKQWZF4iITA7JO3bCTKJ8mEdpY2triyE04IdD10eD8Z+taf17 PkL344vEP1EZi/X/7b3d7T3l/7W9XyeXsPr+Wv//HI+h/wMPlEpPWMQaqkSj6j1D0NsJCC8O ne+NRxcD1IcQ4lrdRiEcansIksn3AslPcrJKAE95N5AFyOD5IlK/dj7u3/rCjQuRRwbRxDz9 leAwPqZrP076rXp9v+NXPV3l7ar3GjZSuJAcpHzNB+Mb0r1nhwLs8TwdD+Z8jx9dlDuJkil6 q8mCDhBEMcb7macxArpoPFSGzxHf0dqONkt1hQ7dxiGJ0K0cfGFiKm+9lQXj7j2RkBOMCGJC P6vDDvrvzipt8qvVms+H46u3CpFbEUxFwSw9KGjfXEXYCEAfaqloIizgFzCREHIjjhE7Q1pr GTOUsELUEC5obLcrfz2Qbod0oThahRF1ArF89H111LHUVPRQk/31ej6yGfhbcaxLoMy5W++q FucQs9MRVG+G+A9sgojZgHMez25igY6tJoT2cxDsSq55qo4KCRrRQgZvYjV/cHjI3m2EXBqH z9oMhqgaqUkzxxrf0AaXgDPYUCHdNt7FBkZ7iTBFubU4wmTi0MDT+uZnW1uGbg/ZJYmOvS5a oBlWT06f/vDjqWEHYi+xVIKW6DtpGKU/d6OA9BHxkhmfusYWMnLWhQzBbBlsBq8tGmG0Dtu3 oMCS7Dm6N1vADeM1UbOJQAZi0Cgx0Mc4+ASjkr3hjQBaJYA2zaiUL7IXXVQtkQHIMv/0OJro +Q93N/ewQacrahEaisVx3g2Ssbnw6ir6U2+djR0Ru3kaL7iHjRdqUO1bd/S+dZUAYthLdvX4 YOhwl5rS7cIvREWHX/ndYU9fT2MZFbAgapzjRE443NBvsoHQLzaE2F6OaMVk2zP2IWHphJp0 /nxW6FE8ArT1D2WbzF5Xpts79KGkU7W+59qsqp5pNyEKoXFOncn691OflWQr34J9tUlEBnkH uRooT66CvFaikALd+NumF5QzpkMx2VqEshUGg2h43o88kD7BJmcq2303SSbSq8qULRPHYSkx Qd45KlFsSglCA7awoiAL7UBqlX1SJSfp0Kh6mCz0THFmiTMH/6x6dGnWddUdWa72+WIaz3ht 1I4PatkAxhzzdZkaR0E2j7JCF/TnwwljR4G4GUbTaxHX9Irih7iXZtrXnksUBdCBAOJFq2N3 PUBG7Qy7MU+ldtyRzbcbZthuHKHk5/MLVN6CA2QjEUNuSZ3EiWFrda+gQf8BFvTupy2cGjgz EpNrVEgRrvRFQkwNKJLbDA6DTZmtnGO1nqibmxI+RWPe013jLNyEXSi76xcc1O6nh9hI0W0r sSm3qoYn0GqhoTo6xZziuo8v5tSdZXnprmRGqlKlbflLctkiKWcRyQzBB4sbx1r0B8WNKTJk 6YnNGAtG8t+DLVmyyUYUdqQtJs2KL91Z9Ko8SHmhsqRq2ep1WRIuqGWhMFpBEC0VQnnB8hn7 YpHUsLY8UIUuakFOcfDhsz4zJTNTWIIQFKzqlqHfHyYpKT0BTUjTWIzXl0H9t7D+h74xh5Zs rWz6kq40KFhUpd7JqrZxvuzbvcQidbFg+QPSYwXJoapjvRCjrCa+a5SVRlHjRjmHbRk/aJGJ E6pWo12ieneHxWIRY+j3FG1MW8vjindUwQ2miUJzJwZQi15/zMipvAkb50bb6mK5NyJ6AnWb FO/4Ei9OwItdyIeAYFkVuK8sSjIbhkkoMnQ/pm0bSLWpQa6MFWlBahaPvYkqfo8MN6iTi/oQ Em1xXoYiJ3NN5x7hjyxJe++e0PUJxZTBdwd0NY87Y6Ruz5JoqLq1SSq7QNzTiQFLg8sxyLKr 4YoNlnW/a8OZhsjNpAoaMJhdEf5vBodaDDKVKbsBkVflfUmaPeWFdMKARrf9VCSIqqz2ILmO BxqKWHs4kgFV2Jiq7io+QE4WCNg+m97QxuZLxkuJOheO13vEGD8K7TeosbMLVADk1nnS78ej v2TkS+ZPMQaiAyu46xa/i/NFhPVKzSP7p3T2JKuhjMBVR4bKNcwcGHIcO9c3Yt2K/la+H3zL j0Yzz8KTeIx4Xdg6c6bf4Mlv/W/eza/4X0u0U2wBd7WU8WiIsJmW8sM/m17Deg8Ci7Lmt25U Evxj5iDiNzFB8BG5B0zz5ldbTplqKFlxF6xQGx6lYJbgFYD4OUltGxnfXUTe5CKfYOKA8geO eDHDPqy2XQTkpGxmVflDIjrI0I60SlTbLPn7HbHjiulqEjbXlHNNZYv2wrZybDRXboyH/NSg Co4DsGRmC8t1oGgCUY9pfFEJAkPrt/ZU8tbSQkOeap5SybSZdIn5rysWzr5t7+PL41XsnqHH iTfL1m/twy/or+4Nbql3mRhGe4aoieFWBmcOy2C+gPaM9xQddYTvLMzcafG1nTZN1eEIokVn yuKaz4JkBXXDoq4romk6saqt24IhelztdXRy6Z5x7cjh6IvrBb1gyi09POxRKVcBviNj1E8N kE70dVRARbdGkJxcpp0lUMX0Qp6LZM0PflEQI4fPzUh6IupM1ukg502TL76NdytJJ7yMxrwQ 5bCAFM6j2YIImA2GxhdHE+pUVPe6uHN8EI8u1f0WyZSOrGhDZ1DiNdvauPgGpR7Cr7NZCw16 vrnb8AmCxzk8Y8QxeoMnWH00mYsl35lULGZqvFRXVIExc6Pl6njsjFDsz2ewO59904T/yhVr C/4Wv8tZ9lGyreHm6ZJZ2SNlLTVPIAmWg+4opw5iSS/PgPDbRWK6eEtiWS2OFg1LfzPGSMaH qqtCxPZPTht1tqjPxVVuynMSrzZH7L5WWYEZaYosVCLxl4DPdPalOeYbSvNQl+zkVRDaShmH lXL7aFDBVhTzrjrIzHAt0Eg/kP0GMgrJZkErzRzS6K4bgDyxv2fiMBschzkoO4OrNRnGfsu+ 2fLmLlGfeAeCqluuYx3nsIXLkHMx38UgoosYtPZB4eS0j08uXRB3XamY35HfiI0xjcl4Duui PBCw1iLLItC1zQDkrOCyDxjySjj/R0pusYxFNBr79kR1Ha24hyZRTg7iJPxC3gQ9nuC9MKRM CG5mFBO8doWv5B7hGfvExD6eXU35rpfMraH4N5KwptPSHqdbufKcXRz6T6kxl+P0arXR+bAR Mh87A6sJ7l3eBt1onz/F0r2Us0RrYatvWrctWwZ1uosywnN/GMDgv01fenL+K20I3jBRTXB2 MA4Txn0oGYSOTkYETokQQ/TmW35QITA3NzfVm53qeHpZO31de338ZIuuQNCh4u8CvQEMmuae 3ggnD2TLMYX8bX6n/sGP9MP8wjZI/CSNtuZXhrtoikNs9eF9xZNRjdRP1EslPLmXsSXoZt/t og9ItxsYmoZEeLpFRINkaCyZKYWMBAfCUwuXtgPq1qjfx6tdWv6gmv6GYQPTx8n5sDqKZ/7h i2hO2vcJfzioYQ7KyjHKnDGeJteU5zz2D4/hD1iXvSfj3vVBbTam1OjuxYvpweTwu8TDRJWD 2kS9u2JLBnkNzcb96PaR/np+2NwqH9TOZWLvigwbLf82Tv3Dg0TW8qCWHHoHaXLJlyN7Sb/l 1+vbuw9f/P0/nu7XdxrHR98+fLr/j926XzvU5Guycgc11TeBCK7pY3CE5x/0QG6xF9Hh2YgX 4DwOwFeGJOCM+K8EmDXf+Gejg5pB07BLA3uKgTKUHQYIQM5t+QsZ26d24K+m0iZJRLR8HDn/ 8Bn824QGURJiutqh7xl/yuSPxehSV1kEi4uYjf3D0/EnI0++hYf8jebZHfJOPjBjMGk/Ntmt E9SYVfToHAZGJJYp/dzxBgRH9PKk4i0RUZjoveF3Yem+MhQBUpZNDbhQ8+UK0QLun8rbo9JR MqmcjYCjDS4dcgC2BtEJdZCaxNMpm+TQjiyNfmQdJVdKeIsQHnK2GBXj/TotHuiL1gWR24ed frdrUT0b6bAOvWvQZJqSMqfHaVPSXY9TjW7jw39EF6zUtL6MScpQgB1ij97HyoSIAuAYBYCx k3fsCQhHGfoX95F4vTGTjywyR5IM3d+bp4GpI0HjSNFQPXUfze50yHBf3V7OfxiHIRj7g/mx hYyAYVIJDvW9HtQTZOa+j/alXooHkT3NRuIQtdAO6Op89/gjpcXdrWpnsL9wQTYqeDYyqvhn e2V/vkf4fouo7U9TxjL///39fe3/v8Px/w/ra///z/FI/FfhknrEpxFbF9MEts2wmX8qZ/QP jATwvY0EgKL1+pdzviaUcUMrJaG+iWscWVpaPrSEDKCv5hzA7meOl0BK7DhxmEInYqPxaAs9 gPvRlK+xlTdFlsy7E9X1jcL5/PyWLgbsDSLU+xBQxD5TkkWW6DSMzjkI4vRY1+qE7mE09sWn hney9EMO2ascN2GxkptmcHy1du8eqLT32mizZ62eA++PQI2ky4YVDu2hpWbO8qVZZFU2JE/v bLjye6rOBxxjapAXYflSWgepZ4dI36txlgwhcrZXfr8z1ODMPJnGORtGvtlvSOWObyng/jzO Xg9s0qy5GkXUMR7WIHyBVzAipchVcMUumKjcpfBaT/rNGzVIRhdjowYZQtINHQ/I0Jhu+K/w JuDXeTRIPV/ZwtBmGWA5AbK9f1QffvNfvlUdLLD9GIm1dLYvvceYqSUymCx274E3HykGl9eR ooo0wjk2nlHsCXUc6+wwn7QSmWFTmHb9OQadrNBgHhxupmCXKz4+1D48QdIPyHoK8x1UrH1h Q4FmipLaSOQxK2D7VruqVeGqarrhT2N2vRcws1KJhWUeRn8YgXxCCVDRV7Wjuz7F03A+KcXU JWB0DXwFDcpJj/777TSarArS8FHvBFP5/1/dBSZL+XhXgjHilWDIPCAr8qb9mtmNgkvVEmTe h6dvINZj9NGuGzNra166FTJnhu24U1ZsGbZDhjuMy52ylz+pZFA+Vp+XullbPdJ2l/uOaDWN d++NYj/NNWgbGOQ7xgMGtAlfcWwNbjUYtQAFqNgceD7hNW81Or7H9ylrIvB/UFSm0c151Ltu eimweUr3itPQ4hXdHOl1izeuZ7JF/TcRULuEhvcTKihfDbqTHXLvmhVKLULWE3mjhDCYZRgW mXffzuJRauHH/tkXvEHvq9/HUuRInRVdJEQ+B8rysV0gqrDVqI819DIfGvzBgeZXBNm3+gTR RK0pcufpcSQbT5q2hJp0QWZC04/yU+tINz/37SegfYS9gGQNQIIM1Z/c1v6fisgWw0diYW0q CLtOd1xpefY/JiLUtP94dwWaqRR5xkSQQoW8H9ySGX0ysugEamW1JBaqLhXPgOQRK4cReSZK 0nViI4Qzp1kJ/NspOHHBFAfrSdNLmEHpLqpOhciG5nQwguOQ31cQzMtI2ONGP2hdfGbCiwl7 Id6OIdxcUQTimXnE41AqdZ/Q5bCwscA7/jicsXuM0q4fyz9fxJgZ/zja+le09Ru8eppcJrhE +vWtr+HPl8BwIr9MvemJRGga3+o2q2iQzJQGL2RRpS6e+vht72x6NjqbdQRRekc5FVm/wy9U mfjqAaT/ScCJBO2f/c5mAPVmS3/4qFmt1sqbv1drv9fgf7BH7b7i/sgCmfg/Q+LQ38Ssm375 UVh98KgM/3nUfIxvsUh4XX70V79MNK5yBIxkkOvsrB1WNx+Vz8465UeYB/XZHHpKGIg8AWSp qT/KD8qPHsM378wpKTyZDDJBnpPN4EFL/NdHitQd8BmaEeQlELPM9S8477SgATkTizchf0OB TXMTk0fZb3iiJWLsemQkCOlfiZelAhfZmD4Zp8pEmrtPEQ25onuqaRxNQUgINC3IZq1e2Us5 ZSkqFlLoEZy/Ddmbw+o0vkTQFHQ5qHjB74gXtRnkVgeNHJMXr7SnaLEGE+qEQKjm6N98rQLu 4/CY1hIMUYF5TF0LIh9tneRmVc87Nxl+GJSk0Sw4XHaU6T3wCssDmqtUG0gERf2049qp5ki4 +Tc4MioWyYoZ7wTjBQX573sGdE/FqNJKa2W+nY7q1KmfdCl3YRdHCWXhOFO2+5OnhWZRA+F5 QSDxAm4v5HB9Tafc/hMROYPFIhHyUojeLRUWDGmrrhxmaRII2UfXvqCHr0Z0E7BG9CIDaWT4 ZbdyzI6QSoNsKIUWIA4mrjuZuNh/28XaX9JtobbsypLDfQj3wgKaQTYaW534BAsGc4XKultO FefWF84veuymiTazIDL1+9xh57KG37nx7g7Ax9Rj1LuF7QcpMUWvi+gcVs+4vFSWBQaupSIG a11RRleNoD9W6wvuXGdsvt3+Tz4dFqEQuFYhYqs8b+S6yc21hdzgnGQZxIJ82IZ7pfuDK9xd hEOIlAu7SVAv33X22aAPLo6yBOihCxIuy2uFs2+h7Fl59srbtywcCRXsp9AkTFjPkrrbx9a+ uAZDsYDwBlyA5FkKmr3Jyyt2Yt1NbeCSfJAPq3dyzcqsb6FESa3VgoUamUVFmPVs24LqIpc6 WXbMfRtBMxnRjQBKSWtuhekV+VKiCL4i85GHxnwxIiUDXy+dzS8ulNGd3MOKrwBk0+0bG7E4 G2f8UQymdzE4WqUvNTraNwyKJk0+uzn643ZXtnjTfPYOiVJU7Xsr/UcyI0urkEX/09iL/5iV El2vWBxL2k4D38ShuRVcYOLejxy3mX7W3rq6wfMdE8j06We3a75B26U2XLoyisxv3JuaNwX9 Vtx3VG1tvjS7rzjTijwpH8Vvn8RQaYCVXkS92Xja2la6T87VTGELTxq5b2/0x+3cx4n6SP+k ZGjzpR+vx0fKr589+Wp728ejrtk8bfkj9JYY+BhnC18bX3/9db1Rb/je25a/73u3LX/Xl8Et 7AXcG7WCF0c/vj5+eeqd/OufJ6fHrwNvPG/530znKbQ/9b1xy//P5yfHvteDt/CfyTUe7zZ2 Hu7ufVXf3X1I1BtEfdvXoTMHEUH1tvxhlAxm4+aAvXWVs/H2Daxv5G5M+etMoO5wPo4OtQMy UUaz5ajlH/347Y8np89fei+On/74xF+12g+/qj/crVOpdVHtrxbUO5pfzvG23eog7s972Wpz r25Dt34LqbwXmIZrzC7QZn2/P3r9xDt6+sPLk2V1RcpctYbZpd9H05531B/jmXh0HZGDxzfj NLUKAy6aeUNY5LeYRTTkue/Fo94YLzgGbjhPZqlZ0PaOUdCpugAXO0HGdqieuQLCU7x+wqfb mls+uw3ZjKAcMbA7ZOT7QQ2rJz2wDZ90HeHE3N5Yid3n00vglDy7Sw8EF2cqvvczjPbhnL2C A/0yHv72w5j4A9j2YzLqh7Amj6RAk/BX5dSVeRPFcoYt/xgrCldU0lK8U6B+NgqM7R2dHwQH j94OBx6GPiVj6MBGte4/OjzACh5y4nzYAC8dW42VowfSRu5VABXXZahKuTxxJ6t6OvcartyN XPZGPj9XsLftIrCdI7CdJ7CtO9b2lB7BjohU/uqK7tJCS7TdtoE3LzWV1Xy3s5cfC3bwvFW8 r4Ml3tee90o6XZ/NzmZ5x2uVziPP/Ulh6kY2OTpGIOwIegVmU4c9Gq1yNo/nXf+yJNO2GVcg A9NB5Q3EBHLcxik/tR9nxHZnQWIQG7XI9b0mpypuwWePbWnipKhzoACuRY+XCO/FRGpMpP3H qLTDx/aK9qX3OOmXvd89Z6uylExcTg5vUBcDK2Y3ILLkQDnCo6WjfaBO2tWnt+7jcdME6RI0 +GAs09s7hDoXySKjhp5wFzUmG80DOxYg5LDdiieEzLLgOTNuDrSg8QTP0MkbkT534QUuaNNL ZHJOUOX/hBjEAh/eoAWyEkzllfaYQ5sABOIEyS4ipocA/2JIiDf0jvQJLhs6apyEmIBvQd+a 4knNdj0ol8ul/0eBDutn/ayf9bN+1s/6WT/rZ/2sn/WzftbP+lk/62f9rJ/1s37Wz/pZP+tn /ayf9bN+1s/6WT/rZ/2sn/WzftbP/6HnfwBxc5xiABgBAA== --------------CD99275CDBC6A2EA4902452C-- From uche.ogbuji@fourthought.com Tue Nov 9 16:31:33 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 09 Nov 1999 09:31:33 -0700 Subject: [XML-SIG] Re: foo.bar vs. foo.get_bar() In-Reply-To: Your message of "Tue, 09 Nov 1999 09:01:41 EST." <001601bf2aba$f32a9100$3cfbb1cd@tomshp> Message-ID: <199911091631.JAA03410@localhost.localdomain> Thomas B. Passin: > In this particular example, the DOM clearly wants the name of a Node to > never change once the Node is created. Java can enforce this, ECMAScript > cannot. Python can't really enforce it either, but it doesn't have to > provide an easy way to get around the read-only intent. Oh yes Python can. With __setattr__ it's a trivial matter. Of course, that's the whole argument, isn't 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 akuchlin@mems-exchange.org Tue Nov 9 16:42:58 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Tue, 9 Nov 1999 11:42:58 -0500 (EST) Subject: [XML-SIG] xml.apache.org Message-ID: <199911091642.LAA05556@amarok.cnri.reston.va.us> Announcements about the new http://xml.apache.org site have been flying around. One piece of software is the Xerces-C validating XML parser, which is, despite the name, written in C++. It seems to be IBM's C++ XML parser. What's interesting is that the Xerces-Perl support is implemented on top of Xerces-C. Usually wrapping C++ interfaces into a scripting language requires tricky contortions, but perhaps Xerces has an API that's more suited for wrapping. Does anyone have experience with it? -- A.M. Kuchling http://starship.python.net/crew/amk/ One need not be a chamber to be haunted; / One need not be a house; / The brain has corridors surpassing / Material place. -- Emily Dickinson, "Time and Eternity" From tismer@appliedbiometrics.com Tue Nov 9 17:54:42 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Tue, 09 Nov 1999 18:54:42 +0100 Subject: [XML-SIG] foo.bar vs. foo.get_bar() References: <199911081916.MAA05097@localhost.localdomain> Message-ID: <38285FE2.F6EB4B2F@appliedbiometrics.com> uche.ogbuji@fourthought.com wrote: ... > Like everyone else, though, I'm coming around to Paul's view that Python needs > efficiently-implemented attributes-with-behavior. Well, did anybody deal with Jim Fulton's ExtensionClass already? I just did it for a larger project, and it is quite impressive. What I get is: - types which behave like classes - attribute access at raw C speed - computed attributes without the usual get/setattr hassles. This means that for true attributes, access speed is by no means lowered. Attributes are first looked up in the implemented C get/setattr. Then, a class-like attribute lookup is done, and you get class behavior. > Petitions to Guido, anyone? In the unlikely event that I have some free time > in the near future, I might look into a demo patch. Please have a look into ExtensionClass if that might be what you need. I admit that this stuff is not easy to understand, but I have been working through that for the last four weeks while implementing Python C++ wrappers in a commercial project, so feel free to ask me how it works. 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 gstein@lyra.org Wed Nov 10 21:12:03 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 10 Nov 1999 13:12:03 -0800 (PST) Subject: [XML-SIG] xml.apache.org In-Reply-To: <199911091642.LAA05556@amarok.cnri.reston.va.us> Message-ID: On Tue, 9 Nov 1999, Andrew M. Kuchling wrote: >... > What's interesting is that the Xerces-Perl support is implemented on > top of Xerces-C. Usually wrapping C++ interfaces into a scripting > language requires tricky contortions, but perhaps Xerces has an > API that's more suited for wrapping. Does anyone have experience with > it? Isn't this easier for the Perl guys because the Perl core uses C++? I looked at IBM's XML4C package a while back. A bazillion C++ classes all over the place. I don't know what it is about C++, but most C++ programmers seem to want to write a class for this and that, the other thing, their sister, and for their little dog, too. I shook my head at the beast and haven't looked back. (figuring that if somebody really wanted XML4C plugged into mod_dav, then they can do the work...) Cheers, -g -- Greg Stein, http://www.lyra.org/ From akuchlin@mems-exchange.org Tue Nov 9 20:19:42 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Tue, 9 Nov 1999 15:19:42 -0500 (EST) Subject: [XML-SIG] xml.apache.org In-Reply-To: References: <199911091642.LAA05556@amarok.cnri.reston.va.us> Message-ID: <14376.33246.293603.752073@amarok.cnri.reston.va.us> Greg Stein writes: >Isn't this easier for the Perl guys because the Perl core uses C++? I don't believe it does; Topaz, an experimental implementation that might become Perl6, is in C++, but Perl5 isn't. --amk From uche.ogbuji@fourthought.com Wed Nov 10 02:22:50 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 09 Nov 1999 19:22:50 -0700 Subject: [XML-SIG] xml.apache.org In-Reply-To: Your message of "Wed, 10 Nov 1999 13:12:03 PST." Message-ID: <199911100222.TAA11280@localhost.localdomain> Greg Stein: > I looked at IBM's XML4C package a while back. A bazillion C++ classes all > over the place. I don't know what it is about C++, but most C++ > programmers seem to want to write a class for this and that, the other > thing, their sister, and for their little dog, too. I shook my head at the > beast and haven't looked back. > (figuring that if somebody really wanted XML4C plugged into mod_dav, then > they can do the work...) It can be odd, coming from the tremendous productivity of Python development, to contemplate the typical state of large-scale C++ and Java projects. There is an interesting article in last Month's DDJ talking about a software engineering principle that I was at first shocked to discover is just being re-invented. It points out that the structured-programming movement was about moving from a graph model of code dependency and control-flow to a tree model. They then point out that the OO revolution has merely moved us back to the old problem in slightly different form: now we have a graph of object-dependencies. The whole article talks about a C++ programming practice of organizing object dependencies and flow strictly into tree-form. My first thought was that this was all quite a commonplace to be occupying the respectable pages of DDJ. There have been several books on large-scale OO programming that admonish developers to manage component dependencies as DAGs and trees to reduce complexity and improve traceability. But then I thought of the several huge projects I've worked on pre-Python, and I realized that we broke such sound sense many times because "uses" relationships often stubbornly refused to line themselves up properly. I have noticed that I am much more successful in proper hierarchical design using Python, and similar problems usually resolve themselves into far fewer actual classes with better-defined interfaces. I'm not sure exactly why this is the case, and I'm sure there's a Ph.D. dissertation in there somewhere, but despite people's insistence on knocking Python for large-scale system design, I find it many times more suitable than C++ or Java. -- 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 Alain.Michard@inria.fr Wed Nov 10 08:16:14 1999 From: Alain.Michard@inria.fr (Alain Michard) Date: Wed, 10 Nov 1999 09:16:14 +0100 Subject: [XML-SIG] pyexpat & xmlproc : irreproductible results! Message-ID: <382929CE.218F479E@inria.fr> Dear All, In a previous message I wrote that xmlproc happened to parse some files faster than pyexpat does. This was an idea I got weeks ago when doing some non systematic testing. Encouraged by a question from Lars Marius Garshol yesterday, I've spent my evening trying to reproduce the results on which my "idea" was based. This time I tried to be systematic! You'll find the results below. To make it short, on these tests, pyexpat is always faster than xmlproc, with a relative difference which can vary enormously depending on the type of xml file and on the application programme. I apologize for writing down a non supported statement in my previous mail. Best regards Alain ------------------------------------------------------------------------------ Test files: IA173.xml : Valid document, 20Ko, external DTD, ISO-8859-1 encoding. BF173.xml : The same document well-formed, without DOCTYPE declaration. IA352.xml : Valid document, 1300Ko, same DTD than for IA173, ISO-8859-1 encoding. BF352.xml : The same document well-formed, no DOCTYPE declaration. ------------------------------------------------------------------------------ First set of tests conducted with saxdemo.py, event handler for outputing canonical XML (saxutils.Canonizer(out)), standard error handler saxutils.ErrorPrinter Second set of tests conducted with parsetimer.py, minimal program, empty event handler and empty error handler. ----------------------------------------------------------------- RESULTS in seconds (PC pentium II, 233 Mhz) ----------------------------------------------------------------- Tests with saxdemo.py VAL173 BF173 VAL352 BF352 xmlproc_val 8.9 - 364 - xmlproc 5.7 5.7 320 308 pyexpat 4.9 4.9 285 287 ----------------------------------------------------------------- Tests with parsetimer.py VAL173 BF173 VAL352 BF352 xmlproc_val 4.5 1.47 106.0 83.0 xmlproc 1.1 1.1 59.0 61.1 pyexpat 0.24 0.24 9.7 9.8 ---------------------------------------------------------- Test files are available on request. From Alain.Michard@inria.fr Wed Nov 10 08:21:28 1999 From: Alain.Michard@inria.fr (Alain Michard) Date: Wed, 10 Nov 1999 09:21:28 +0100 Subject: [XML-SIG] xml.apache.org References: <199911091642.LAA05556@amarok.cnri.reston.va.us> Message-ID: <38292B07.7A975A71@inria.fr> "Andrew M. Kuchling" wrote: > Announcements about the new http://xml.apache.org site have been > flying around. One piece of software is the Xerces-C validating XML > parser, which is, despite the name, written in C++. It seems to be > IBM's C++ XML parser. > Yes, that was confirmed yesterday at the XML Forum in Paris by Simon Phipps (IBM). Alain From grove@infotek.no Wed Nov 10 10:02:11 1999 From: grove@infotek.no (Geir Ove Grønmo) Date: 10 Nov 1999 11:02:11 +0100 Subject: [XML-SIG] GPS - Groves and Property Sets for Python 0.10 Message-ID: Hi, I'm pleased to announce the first release of GPS - Groves and Property Sets for Python. Suggestions and bug reports should be sent to: grove@infotek.no Geir O. Grønmo -------------------------------------------------------------------------- Title: GPS - Groves and Property Sets for Python Version: 0.10 Released: November 10th 1999 Author: Geir O. Grønmo, grove@infotek.no License: GPL Homepage: http://www.infotek.no/~grove/software/gps/index.html - -- >>> What is GPS? GPS is an implementation of the groves and property set concepts defined in the HyTime and DSSSL standards. GPS is written in Python, and should work* on any platform to which Python have been ported - including the Java Platform. There are two implementations in the current distribution, one in-memory implemention and one that supports ZODB - the Zope Object Database. Both groves, property sets and grove plans can be made persistent by the ZODB implementation. - -- >>> Features o Loading of property sets from documents conforming to the Property Set DTD, or any derived DTD [requires architectural processing]. o Grove plans. Default grove plans is automatically created by wrapping a GrovePlan object around a property set. Inclusion and omitting of modules, classes and properties are fully supported. o Two grove node implementations, both generic classes for representing grove nodes. o ZODB - Zope Object Database versions of all grove, property set and grove plan classes. o Module for building XML groves from SAX event streams. This module also contains a class for emitting SAX events by walking XML groves. o Sample Property Sets - -- >>> Requirements - Python 1.5.2 or newer [3] - An SGML/XML parser with a SAX driver - SAX for Python [4] - xmlarch 0.25, optional unless architectural processing is needed [5] - -- >>> References [1] http://www.jpython.org/ [2] http://www.ornl.gov/sgml/SC34/ [3] http://www.python.org/ [4] http://www.stud.ifi.uio.no/~larsga/download/python/xml/saxlib.html [5] http://www.infotek.no/~grove/software/xmlarch/index.html [6] http://www.infotek.no/~grove/software/gps/licence.html * The ZODB implementation won't work in a Java environment, since the ZODB contains code written in C. --------------------------------------------------------------------------

GPS - Groves and Property Sets for Python version 0.10 an implementation of the groves and property set concepts defined in the HyTime and DSSSL standards. (10-Nov-1999) From sean@digitome.com Wed Nov 10 11:22:57 1999 From: sean@digitome.com (Sean Mc Grath) Date: Wed, 10 Nov 1999 11:22:57 +0000 Subject: [XML-SIG] GPS - Groves and Property Sets for Python 0.10 In-Reply-To: Message-ID: <3.0.6.32.19991110112257.00910710@gpo.iol.ie> At 11:02 10/11/99 +0100, you wrote: >Hi, > >I'm pleased to announce the first release of GPS - Groves and Property >Sets for Python. > The acronym GPS also stands for "Global Positioning System". There is quite a good fit between that interpretation of the acronym and Groves/Property Sets:-) regards,

This document has three erors. /p> From grove@infotek.no Wed Nov 10 11:47:08 1999 From: grove@infotek.no (Geir Ove Grønmo) Date: 10 Nov 1999 12:47:08 +0100 Subject: [XML-SIG] GPS - Groves and Property Sets for Python 0.10 In-Reply-To: <3.0.6.32.19991110112257.00910710@gpo.iol.ie> References: <3.0.6.32.19991110112257.00910710@gpo.iol.ie> Message-ID: * Sean Mc Grath | At 11:02 10/11/99 +0100, you wrote: | >I'm pleased to announce the first release of GPS - Groves and Property | >Sets for Python. | > | The acronym GPS also stands for "Global Positioning System". There | is quite a good fit between that interpretation of the acronym | and Groves/Property Sets:-) Yes. I believe it was Charles Goldfarb that not long ago said that Topic Maps can act as the Global Positioning System for the web. Things are more closely linked than we might have expected. Btw, tmproc and xmlarch should use groves shouldn't they...? Let's see what the future 'll bring. 8^) Geir O. From adwelly@hotmail.com Wed Nov 10 14:45:03 1999 From: adwelly@hotmail.com (Andy Dwelly) Date: Wed, 10 Nov 1999 06:45:03 PST Subject: [XML-SIG] ANNOUNCE: Marius v 0.6 Beta 0 Message-ID: <19991110144503.68727.qmail@hotmail.com> [This is off topic although it is XML related - but its been suggested that I post an announcement here because the next version, 0.7, is supposed to handle more than just Java as its programming language. The languages on the table at the moment are C++, Cobol, and Python.] The Marius Documentation system v 0.6 Beta 0 is now available from either myself or from www.macbel.be/marius . This is a limited release beta of the new system which is largely rewritten from version 0.5, although it is supposed to backwards compatible. Marius allows you to create Literate Programs using XML as a markup language and Java and its programming language. I wrote the first version last year and since then its been in use at a couple of places around Europe to write developers guides to various pieces of software. The latest version has been improved with the addition of a number of new elements that allow much larger documents to be written. It is supplied with a partially complete example - The Annotated Marius - which covers how to use the program and how it is constructed. The architecture has been changed so that the output system can be easily replaced. This allows manuals to be produced to existing corporate styles and easy experimenation with new formats. The standard formatter is much improved over v 0.5 and has been designed to work well in both hard copy and web format. There's also a reference guide, currently in MS word. Version 0.6 is released under the GPL, unlike earlier versions which used the Open Source Artistic License. Best Regards. Andy Dwelly (adwelly@hotmail.com, andrew.dwelly@swift.com) ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From walter@data.franken.de Wed Nov 10 09:00:42 1999 From: walter@data.franken.de (Walter Doerwald) Date: Wed, 10 Nov 1999 11:00:42 +0200 Subject: [XML-SIG] new qp_xml.py In-Reply-To: <38282690.F47773EA@ibm.net> Message-ID: <45919568@data.franken.de> On Tue, 09 Nov 1999 14:50:08 +0100 Laurent Szyster wrote: > Greg Stein wrote: > > > > Suggestions/changes/etc are welcome! (Laurent... :-) > > Here are some suggestions (partly implemented in the attached > myXML.tar.gz archive): > > . Split the building of the tree between a "Parser" class that > instanciates the nodes and the "DOM" class that stores them > (and eventually index them). This allow for more combination > of features, hence better code re-use and extendability. This parser class should have factory functions for every type of nodes it generates, which I can overwrite (something like createText(), createElement(), createComment(), etc.). This would e.g. make it possible to use different classes for the different element types. Or I could use extended node classes (probably via mixins) that provide additional functionality for all nodes. > Here the important is the definition of the interface > between the "Parser" and the "DOM": the "Element" class > and the "DOM.append()" method. > > . Allow for direct mapping of XML to the Python namespace, in > such way that you could refer to the second

element of > the first in a document as > > dom.root.chapter[0].p[1] > > That's very pythonic. It is implemented in a "DOM", and > therefore can be combined with different "Parsers". I've experimented with something similar to that. My element classes have a __getitem__ (and __setitem__ and __delitem__), when it's passed a string it returns (oder modifies or deletes) the attribute with this name, when it's passed a number i it returns the i'th child node. __getslice__ etc. or implemented for slices of child nodes to. I find this interface much more pythonic. I could post the code, if someone is interrested. > [...] Servus... Walter -- Walter Dörwald · walter@data.franken.de · Kommunikationnetz Franken e.V. From jdnier@execpc.com Wed Nov 10 19:05:40 1999 From: jdnier@execpc.com (David Niergarth) Date: Wed, 10 Nov 1999 13:05:40 -0600 Subject: [XML-SIG] Shallow Parsing with Regular Expressions Message-ID: <00d001bf2bae$9bacf310$6c6ccfa9@ep3> This is a multi-part message in MIME format. ------=_NextPart_000_00CB_01BF2B7C.49F97ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I ran across an interesting article titled "REX: XML Shallow Parsing with Regular Expressions" by Robert D. Cameron that I thought others following the XML-SIG and String-SIG might find intriguing. From the article's abstract: "The syntax of XML is simple enough that it is possible to parse an XML document into a list of its markup and text items using a single regular expression. Such a shallow parse of an XML document can be very useful for the construction of a variety of lightweight XML processing tools. However, complex regular expressions can be difficult to construct and even more difficult to read. Using a form of literate programming for regular expressions, this paper documents a set of XML shallow parsing expressions that can be used a basis for simple, correct, efficient, robust and language-independent XML shallow parsing. Complete shallow parser implementations of less than 50 lines each in Perl, JavaScript and Lex/Flex are also given." The paper was just published in Markup Languages: Theory and Practice, Volume 1, Number 3, Summer 1999, pp. 61-88 (MIT Press) but is available online as a technical report at ftp://fas.sfu.ca/pub/cs/TR/1998/CMPT1998-17.html The regex he creates ends up being about 1K (DFA and efficient), and can match just about any part of and XML document you're interested in. What you do next (entity reference extraction, attribute processing, error detection, etc.) is left to the reader. ;-) The Perl version of the regex works as-is with Python (of course). I've adjusted for Python syntax and attached 'REX.py' to this message for anyone interested. The article is clearly written and the method he uses to build up the regex out of small, well-reasoned pieces is very instructive (although his retangle and reweave literate programming tools aren't detailed). As a simple example, >>> import REX >>> print REX.ShallowParse('This is shallow parsing.') ['', 'This is ', '', 'shallow parsing', '', '.', ''] As a simple example of what can be done, I made a variation on the regex that adds named groups, e.g., (?P...), to each of the components (see ftp://starship.python.net/pub/crew/dni/REX/REX_detail.py ). The group names that are not None show exactly which parts of the regex contributed to the match, effectively categorizing each part of the document. Prettyprinted output for the string 'my &first; shallow parse' looks like D:\python> REX_detail.py MarkupSPE: '' ElemTagCE: 'tag1 att="123" att2="456">' Name: 'att2' NameStrt: 'a' NameChar: '2' AttValSE: '"456"' TextSE: 'my &first; ' MarkupSPE: '' ElemTagCE: 'i>' TextSE: 'shallow parse' MarkupSPE: '' EndTagCE: 'i>' MarkupSPE: '' EndTagCE: 'tag1>' More detail than you need, but you can see where further processing (for attributes, entities) would start. --David Niergarth ------=_NextPart_000_00CB_01BF2B7C.49F97ED0 Content-Type: text/plain; name="REX.py" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="REX.py" """REX/Python Based on Robert D. Cameron's REX/Perl 1.0.=20 Original copyright notice follows: REX/Perl 1.0 Robert D. Cameron "REX: XML Shallow Parsing with Regular Expressions", Technical Report TR 1998-17, School of Computing Science, Simon Fraser=20 University, November, 1998. Copyright (c) 1998, Robert D. Cameron.=20 The following code may be freely used and distributed provided that this copyright and citation notice remains intact and that modifications or additions are clearly identified. """ import re TextSE =3D "[^<]+" UntilHyphen =3D "[^-]*-" Until2Hyphens =3D UntilHyphen + "(?:[^-]" + UntilHyphen + ")*-" CommentCE =3D Until2Hyphens + ">?" UntilRSBs =3D "[^\\]]*](?:[^\\]]+])*]+" CDATA_CE =3D UntilRSBs + "(?:[^\\]>]" + UntilRSBs + ")*>" S =3D "[ \\n\\t\\r]+" NameStrt =3D "[A-Za-z_:]|[^\\x00-\\x7F]" NameChar =3D "[A-Za-z0-9_:.-]|[^\\x00-\\x7F]" Name =3D "(?:" + NameStrt + ")(?:" + NameChar + ")*" QuoteSE =3D "\"[^\"]*\"|'[^']*'" DT_IdentSE =3D S + Name + "(?:" + S + "(?:" + Name + "|" + QuoteSE + = "))*" MarkupDeclCE =3D "(?:[^\\]\"'><]+|" + QuoteSE + ")*>" S1 =3D "[\\n\\r\\t ]" UntilQMs =3D "[^?]*\\?+" PI_Tail =3D "\\?>|" + S1 + UntilQMs + "(?:[^>?]" + UntilQMs + ")*>" DT_ItemSE =3D "<(?:!(?:--" + Until2Hyphens + ">|[^-]" + MarkupDeclCE + = ")|\\?" + Name + "(?:" + PI_Tail + "))|%" + Name + ";|" + S DocTypeCE =3D DT_IdentSE + "(?:" + S + ")?(?:\\[(?:" + DT_ItemSE + = ")*](?:" + S + ")?)?>?" DeclCE =3D "--(?:" + CommentCE + ")?|\\[CDATA\\[(?:" + CDATA_CE + = ")?|DOCTYPE(?:" + DocTypeCE + ")?" PI_CE =3D Name + "(?:" + PI_Tail + ")?" EndTagCE =3D Name + "(?:" + S + ")?>?" AttValSE =3D "\"[^<\"]*\"|'[^<']*'" ElemTagCE =3D Name + "(?:" + S + Name + "(?:" + S + ")?=3D(?:" + S + = ")?(?:" + AttValSE + "))*(?:" + S + ")?/?>?" MarkupSPE =3D "<(?:!(?:" + DeclCE + ")?|\\?(?:" + PI_CE + ")?|/(?:" + = EndTagCE + ")?|(?:" + ElemTagCE + ")?)" XML_SPE =3D TextSE + "|" + MarkupSPE # The original Perl subroutine # # sub ShallowParse {=20 # my($XML_document) =3D @_; # return $XML_document =3D~ /$XML_SPE/g; # } def ShallowParse(XML_document): return re.findall(XML_SPE, XML_document) def _test(): print ShallowParse('This is shallow parsing.') if __name__ =3D=3D '__main__': _test() # _test() output looks like # ['', 'This is ', '', 'shallow parsing', '', '.', = ''] ------=_NextPart_000_00CB_01BF2B7C.49F97ED0-- From fdrake@acm.org Wed Nov 10 22:27:23 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 10 Nov 1999 17:27:23 -0500 (EST) Subject: [XML-SIG] CORBA compliance for the DOM in Python? Message-ID: <14377.61771.21736.963546@weyr.cnri.reston.va.us> Ok, now that we've beaten the __getattr__() v. get_foo() argument to death, is anyone interested in bringing PyDOM into compliance? (Does the FourThought crew plan to bring 4DOM into compliance with the _get_*() / _set_*() binding, or is it already?) If 4DOM is in compliance, or will be brought into compliance, I'm willing to spend some time bring PyDOM into compliance. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From Mike.Olson@Fourthought.com Wed Nov 10 22:46:58 1999 From: Mike.Olson@Fourthought.com (Mike Olson) Date: Wed, 10 Nov 1999 15:46:58 -0700 Subject: [XML-SIG] CORBA compliance for the DOM in Python? References: <14377.61771.21736.963546@weyr.cnri.reston.va.us> Message-ID: <3829F5E2.BBD54C53@Fourthought.com> "Fred L. Drake, Jr." wrote: > Ok, now that we've beaten the __getattr__() v. get_foo() argument to > death, is anyone interested in bringing PyDOM into compliance? (Does > the FourThought crew plan to bring 4DOM into compliance with the > _get_*() / _set_*() binding, or is it already?) > If 4DOM is in compliance, or will be brought into compliance, I'm > willing to spend some time bring PyDOM into compliance. > Fred, We will be bringing 4DOM into compliance when we go through and remove all of the ORB dependencies. Mike > > -Fred > > -- > Fred L. Drake, Jr. > Corporation for National Research Initiatives > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig From fdrake@acm.org Wed Nov 10 22:56:12 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 10 Nov 1999 17:56:12 -0500 (EST) Subject: [XML-SIG] CORBA compliance for the DOM in Python? In-Reply-To: <3829F5E2.BBD54C53@Fourthought.com> References: <14377.61771.21736.963546@weyr.cnri.reston.va.us> <3829F5E2.BBD54C53@Fourthought.com> Message-ID: <14377.63500.95377.361337@weyr.cnri.reston.va.us> Mike Olson writes: > We will be bringing 4DOM into compliance when we go through and > remove all of the ORB dependencies. Mike, Great; I'll add updating PyDOM to my list of tasks. If anyone objects or would rather do it themselves, scream now! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From uche.ogbuji@fourthought.com Wed Nov 10 23:48:39 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Wed, 10 Nov 1999 16:48:39 -0700 Subject: [XML-SIG] CORBA compliance for the DOM in Python? In-Reply-To: Your message of "Wed, 10 Nov 1999 15:46:58 MST." <3829F5E2.BBD54C53@Fourthought.com> Message-ID: <199911102348.QAA21580@localhost.localdomain> > > Ok, now that we've beaten the __getattr__() v. get_foo() argument to > > death, is anyone interested in bringing PyDOM into compliance? (Does > > the FourThought crew plan to bring 4DOM into compliance with the > > _get_*() / _set_*() binding, or is it already?) > > If 4DOM is in compliance, or will be brought into compliance, I'm > > willing to spend some time bring PyDOM into compliance. > > We will be bringing 4DOM into compliance when we go through and > remove all of the ORB dependencies. Just to clarify. We actually plan to implement both "node.parent" and "node._get_parent()", with the former just being a __setattr__ wrapper for the latter. We are looking into ExtensionClass, as Christian Tismer suggested, as perhaps a way to minimize the performance hit of the former. I'm not sure the argument is entirely over. If it is, I think it's time to start on a sketch of Python-DOM binding document. If eventually a different scheme than the two I mention above is chosen, we shall provide support for it in 4DOM. -- 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 larsga@garshol.priv.no Thu Nov 11 10:13:22 1999 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 11 Nov 1999 11:13:22 +0100 Subject: [XML-SIG] pyexpat & xmlproc : irreproductible results! In-Reply-To: <382929CE.218F479E@inria.fr> References: <382929CE.218F479E@inria.fr> Message-ID: * Alain Michard | | This time I tried to be systematic! You'll find the results below. | To make it short, on these tests, pyexpat is always faster than | xmlproc, with a relative difference which can vary enormously | depending on the type of xml file and on the application programme. I've done more or less the same tests myself, and my results seem to agree with yours. (I think your results when using Canonizer are due to the program spending most of its time in the DocumentHandler rather than the parser.) I did these tests on my home PC, a Pentium 166MHz with 80 MB of RAM, running Windows 95. The documents used are: othello: The othello.xml document from Jon Bosak's Shakespeare collection. No attributes. 248 K newlist: An old version of the data document used for my free XML tools index. Heavy on markup and with quite a few attributes. 74 K teij31: A small document marked up in the XML version of TEI Lite. Some attributes, comments and CDATA sections. 56 K rec-xml: The XML specification in XML. Heavy use of attributes, comments, CDATA marked sections and entities. 158 K nt: The New Testament, from Bosak's religious collection. Very simple structure, no attributes. 1 MB WD-xslt: As the XML specification. 182 K I would consider these results (except for #2) to be accurate in the two most significant digits only. Test #1, with empty DocumentHandlers othello newlist teij31 rec-xml nt WD-xslt TOTAL sgmlop 0.053 0.022 0.016 0.038 0.172 0.038 0.341 pyexpat 2.766 0.144 0.232 0.017 4.230 1.388 8.780 xmlproc 8.935 2.399 0.950 5.188 12.00 4.056 33.53 xmlproc_val 15.65 4.387 19.07 5.309 21.14 12.00 77.57 xmllib 32.29 6.982 1.902 14.80 45.14 12.22 113.3 Test #2, with xbel2html.py on an 862 K XBEL document sgmlop 6.539 pyexpat 11.82 xmlproc 41.55 xmlproc_val 59.14 xmllib 80.62 Test #3, with xml.com stats collector (goes through all attributes) othello newlist teij31 rec-xml nt WD-xslt TOTAL sgmlop 4.636 0.967 0.296 1.877 5.942 1.670 13.51* pyexpat 5.189 1.348 0.459 - 7.354 2.461 16.83 xmlproc 11.42 2.990 1.162 5.298 15.174 5.064 35.81* xmlproc_val 18.59 5.108 20.16 5.560 24.791 13.33 81.97* xmllib 34.93 7.739 2.112 17.87 47.65 15.28 107.7* *rec-xml is not included in the sum This third test unearthed a small non-conformance in xmllib version 0.2: that it reports characters outside the document (or root) element. I don't know if this still applies to the latest version of xmllib. Also note that the xmlproc version used here is the version currently in my CVS tree, and this is a little faster than 0.61. The only conclusions I can draw from this is that sgmlop is indeed the fastest parser (and very much so if it is given no DocumentHandler), that pyexpat is about twice as fast as xmlproc and that this is not affected by differences in documents or applications. --Lars M. From fdrake@acm.org Thu Nov 11 13:49:23 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Nov 1999 08:49:23 -0500 (EST) Subject: [XML-SIG] CORBA compliance for the DOM in Python? In-Reply-To: <199911102348.QAA21580@localhost.localdomain> References: <3829F5E2.BBD54C53@Fourthought.com> <199911102348.QAA21580@localhost.localdomain> Message-ID: <14378.51555.590100.164929@weyr.cnri.reston.va.us> uche.ogbuji@fourthought.com writes: > Just to clarify. We actually plan to implement both "node.parent" and > "node._get_parent()", with the former just being a __setattr__ wrapper for the Uche, I was planning to keep the __getattr__/__setattr__ support as well, simply because it's a lot easier to read client code that way, especially if there's a good bit of it. My DOM code isn't that extensive, but I find readability an issue already. > I'm not sure the argument is entirely over. If it is, I think it's time to > start on a sketch of Python-DOM binding document. If eventually a different Is there a need for a Python-specific binding document if we're compliant with the IDL mapping? Well, I guess I can see where that would be useful for people that aren't working with CORBA at all, and perhaps to document/"suggest" the use of __[gs]etattr__ to claim to be more "Pythonic." -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From berini09@ibm.net Thu Nov 11 15:17:55 1999 From: berini09@ibm.net (Laurent Szyster) Date: Thu, 11 Nov 1999 16:17:55 +0100 Subject: [XML-SIG] new qp_xml.py References: <45919568@data.franken.de> Message-ID: <382ADE23.ECAF86D0@ibm.net> Walter, Thanks for the comments. Walter Doerwald wrote: > > > Here are some suggestions (partly implemented in the attached > > myXML.tar.gz archive): > > > > . Split the building of the tree between a "Parser" class that > > instanciates the nodes and the "DOM" class that stores them > > (and eventually index them). This allow for more combination > > of features, hence better code re-use and extendability. > > This parser class should have factory functions for every type > of nodes it generates, which I can overwrite (something like > createText(), createElement(), createComment(), etc.). This > would e.g. make it possible to use different classes for the > different element types. Or I could use extended node classes > (probably via mixins) that provide additional functionality > for all nodes. Actually the objective of the design is to avoid subclassing of the "Parser" class to implement features of the DOM or the nodes. The parser is just there to spit out element nodes consumed by the DOM. > > . Allow for direct mapping of XML to the Python namespace, in > > such way that you could refer to the second

element of > > the first in a document as > > > > dom.root.chapter[0].p[1] > > > > That's very pythonic. It is implemented in a "DOM", and > > therefore can be combined with different "Parsers". > > I've experimented with something similar to that. My element > classes have a __getitem__ (and __setitem__ and __delitem__), > when it's passed a string it returns (oder modifies or deletes) > the attribute with this name, when it's passed a number i it > returns the i'th child node. __getslice__ etc. or implemented > for slices of child nodes to. I find this interface much more > pythonic. Well, I prefered not to use __getitem__, but rather directly write to the __dict__ of the node. I suppose it's faster. Also, this direct mapping to Python namespace is only one possible behaviour implemented in the "DOM" class, not in the "Element" class. Have a look at the code (in parser.py), you'll see what I mean. > I could post the code, if someone is interrested. Sure I do ;-) Laurent From fdrake@acm.org Thu Nov 11 17:02:43 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 11 Nov 1999 12:02:43 -0500 (EST) Subject: [XML-SIG] Doc-SIG application of XML Message-ID: <14378.63155.863586.615479@weyr.cnri.reston.va.us> For anyone interested in the use of XML for the Python documentation, I've just posted an analysis of possible approaches on the Doc-SIG mailing list. Please feel free to join us there if you're interested; see http://www.python.org/sigs/doc-sig/ for more information on the Doc-SIG. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From tismer@appliedbiometrics.com Fri Nov 12 13:00:20 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 12 Nov 1999 14:00:20 +0100 Subject: [XML-SIG] 4DOM future References: <199911022158.OAA07799@localhost.localdomain> <14368.19314.916935.93313@amarok.cnri.reston.va.us> Message-ID: <382C0F64.EC93559D@appliedbiometrics.com> "Andrew M. Kuchling" wrote: > > uche.ogbuji@fourthought.com writes: > >For instance, if we go with my leanings, which are towards an attribute-based > >approach, it would differ in a key way from PyDOM. Then to get a standard > >Python binding, we'd have to hash it out. That's why it would be nice to hear > >from some of the PyDOM implementors. It's not going to be an easy issue to > >resolve, but I believe it is worth the effort. > > The PyDom Node class has __getattr__/__setattr__ functions which > redirect attribute references to the corresponding get_*/set_* > function. ExtensionClass would be helpful for doing computed > attribute values, but I've been reluctant to require it for the XML > tools; if the Distutils-SIG makes it trivial to install new extensions > and ExtensionClass is neatly packaged, maybe that additional > requirement isn't too bad. Where is the problem? ExtensionClass comes as a single dynamic module and works right away. I'm using it all the time. Couldn't it simply sit in a directory where orther XML tools are already? Let it live in utils and we're done? 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 grove@infotek.no Fri Nov 12 20:32:11 1999 From: grove@infotek.no (Geir Ove Grønmo) Date: 12 Nov 1999 21:32:11 +0100 Subject: [XML-SIG] GPS - Groves and Property Sets for Python 0.20 Message-ID: Hello, I'm pleased to announce the second release of GPS - Groves and Property Sets for Python. There has been a lot of changes in this release. The most important being the support for grove managers and managed grove nodes, and a grove walker module. See the changes.txt file in the distribution for a complete list of changes. Suggestions and bug reports should be sent to: grove@infotek.no Geir O. Grønmo -------------------------------------------------------------------------- Title: GPS - Groves and Property Sets for Python Version: 0.20 Released: November 12th 1999 Author: Geir O. Grønmo, grove@infotek.no License: GPL Homepage: http://www.infotek.no/~grove/software/gps/index.html - -- >>> What is GPS? GPS is an implementation of the groves and property set concepts defined in the HyTime and DSSSL standards. GPS is written in Python, and should work* on any platform to which Python have been ported - including the Java Platform. There are two implementations in the current distribution, one in-memory implemention and one that supports ZODB - the Zope Object Database. Both groves, property sets and grove plans can be made persistent by the ZODB implementation. - -- >>> Features o Loading of property sets from documents conforming to the Property Set DTD, or any derived DTD [requires architectural processing]. o Grove plans. Default grove plans is automatically created by wrapping a GrovePlan object around a property set. Inclusion and omitting of modules, classes and properties are fully supported. o Self-managed and managed grove node implementations, both generic classes for representing grove nodes. o Grove managers that manages a repository of managed grove nodes. o ZODB - Zope Object Database versions of all grove, grove manager, property set and grove plan classes, plus some ZODB utilities. o Module for building XML groves from SAX event streams. This module also contains a class for emitting SAX events by walking XML groves. o Grove walkers, allows for selective processing of groves. o Sample Property Sets - -- >>> Requirements - Python 1.5.2 or newer [3] - An SGML/XML parser with a SAX driver - SAX 1.0 for Python [4] - xmlarch 0.25, optional unless architectural processing is needed [5] - -- >>> References [1] http://www.jpython.org/ [2] http://www.ornl.gov/sgml/SC34/ [3] http://www.python.org/ [4] http://www.stud.ifi.uio.no/~larsga/download/python/xml/saxlib.html [5] http://www.infotek.no/~grove/software/xmlarch/index.html [6] http://www.infotek.no/~grove/software/gps/licence.html * The ZODB implementation won't work in a Java environment, since ZODB contains code written in C. --------------------------------------------------------------------------

GPS - Groves and Property Sets for Python version 0.20 an implementation of the groves and property set concepts defined in the HyTime and DSSSL standards. (12-Nov-1999) From mak@mikroplan.com.pl Thu Nov 18 16:37:12 1999 From: mak@mikroplan.com.pl (Grzegorz Makarewicz) Date: Thu, 18 Nov 1999 17:37:12 +0100 Subject: [XML-SIG] Help: can't complete tests Message-ID: <000b01bf31e3$29e9f940$129e75c3@mikroplan.com.pl> Hi, After building from source xml-0.51 I have run test/test_xmllib.py and the result is: -- test_arch test test_arch failed -- Writing: '?test where="before"\012?test where="after"\012(biblio\012-\012 \012(firstname\012Anationality norwegian\012-Geir Ove\012)firstname\012(lastname\012Aht #IMPLIED\012Amodified yes\012-Gronmo\012)lastname\012(note\012Aht address\012-You can reach me at \012-grove@infotek.no\012)note\012-\012 \012-\012\012)biblio\012', expected: '?test where="before"\012?test where="after"\012(biblio\012-\012\012- \012(firstname\012Anationality norwegian\012-Geir Ove\012)firstname\012(lastname\012Aht #IMPLIED\012Amodified yes\012-Gronmo\012)lastname\012(note\012Aht address\012-You can reach me at \012-grove@infotek.no\012)note\012-\012\012- \012-\012\012)bib' ... test test_utils failed -- Writing: '1997-12-31T22:00Z', expected: '1998-01-01T05:00Z' test_xmllib 9 tests OK. 2 tests failed: test_arch test_utils -- 1. test_utils - timezone differently handled (?) in python (1.5.2c from cvs) and utils/iso8601.py, my TZ=CET-2CTD (Warsaw,Praque time GMT+01:00) 2. But why test_arch has failed ? Any help is very welcome. My platform: Window NT 4.0 SP 5 VC 6 SP 3 Python 1.5.2 (cvs) expat 1.1 (cvs) Grzegorz Makarewicz From akuchlin@mems-exchange.org Fri Nov 19 23:58:38 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Fri, 19 Nov 1999 18:58:38 -0500 (EST) Subject: [XML-SIG] CORBA compliance for the DOM in Python? In-Reply-To: <14377.61771.21736.963546@weyr.cnri.reston.va.us> References: <14377.61771.21736.963546@weyr.cnri.reston.va.us> Message-ID: <14389.58414.177822.519214@amarok.cnri.reston.va.us> Fred L. Drake, Jr. writes: > Ok, now that we've beaten the __getattr__() v. get_foo() argument to >death, is anyone interested in bringing PyDOM into compliance? (Does Reviving an old issue, should I go ahead and make this change? (Renaming get_parentNode() to _get_parentNode(), and so forth, in case you've forgotten.) My original motivation for the get_*() functions was for compatibility with Java, both from the point of view of documentation, and from using JPython with both PyDOM and Java DOM bindings. Is this compatibility question unimportant? If so, I can go ahead and do the renaming. (The get_*() probably can't go away completely, though, because of external documents such as Sean McGrath's Python/XML book.) -- A.M. Kuchling http://starship.python.net/crew/amk/ To my battle-scarred mind, documentation is never more than a hint. Read it once with disbelief suspended, and then again with full throttle skepticism. -- Gordon McMillan, 19 Oct 1998 From fdrake@acm.org Sat Nov 20 03:59:30 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Fri, 19 Nov 1999 22:59:30 -0500 (EST) Subject: [XML-SIG] CORBA compliance for the DOM in Python? In-Reply-To: <14389.58414.177822.519214@amarok.cnri.reston.va.us> References: <14377.61771.21736.963546@weyr.cnri.reston.va.us> <14389.58414.177822.519214@amarok.cnri.reston.va.us> Message-ID: <14390.7330.172541.164489@weyr.cnri.reston.va.us> I wrote: > Ok, now that we've beaten the __getattr__() v. get_foo() argument to > death, is anyone interested in bringing PyDOM into compliance? (Does Andrew M. Kuchling writes: > Reviving an old issue, should I go ahead and make this change? > (Renaming get_parentNode() to _get_parentNode(), and so forth, in case Per our conversation here, I was going to play a little with using a Java DOM implementation via JPython, just to see if we could do something that would work with both. I haven't had time yet. > (The get_*() probably can't go away completely, though, because of > external documents such as Sean McGrath's Python/XML book.) This one hurts; I really don't like leaving it in if we're actually going to change it. Do you know if the book has gone to press? This makes me want to rethink using the IDL mapping, but the catch is we need to if we are going to use general code to operate on arbitrary DOM trees, including remote ones. Without this, there's little point to using ANY specific interface. ;-( We may end up with multiple flavors of the interface, which I consider evil. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From mss@transas.com Sat Nov 20 11:44:21 1999 From: mss@transas.com (Michael Sobolev) Date: Sat, 20 Nov 1999 14:44:21 +0300 Subject: [XML-SIG] UTF-8 and python-xml Message-ID: <19991120144421.A11379@transas.com> Gentlemen! I've got a problem: the input file has to be in UTF-8. But the files my program generates are to be in known charsets. Is it possible to do this programmatically? Thanks, -- Mike From n_karger@hotmail.com Sun Nov 21 00:56:40 1999 From: n_karger@hotmail.com (interactiveinfo) Date: Sat, 20 Nov 1999 17:56:40 -0700 Subject: [XML-SIG] Software Publishers Needed Message-ID: <0065740560015b9PLATINUM@206.196.145.108> interactiveinfo is seeking new software publishers for their new web store. Shareware, Trialware, Demoware, and Liteware for Try-Before-Buy. Best Place to Buy Software! http://www.ininfo.com From dieter@handshake.de Sat Nov 20 11:33:20 1999 From: dieter@handshake.de (Dieter Maurer) Date: Sat, 20 Nov 1999 12:33:20 +0100 (CET) Subject: [XML-SIG] CORBA compliance for the DOM in Python? In-Reply-To: <14390.7330.172541.164489@weyr.cnri.reston.va.us> References: <14389.58414.177822.519214@amarok.cnri.reston.va.us> <14390.7330.172541.164489@weyr.cnri.reston.va.us> Message-ID: <14390.33928.688786.170131@lindm.dm> Fred L. Drake, Jr. writes: > Andrew M. Kuchling writes: > > (The get_*() probably can't go away completely, though, because of > > external documents such as Sean McGrath's Python/XML book.) > > This one hurts; I really don't like leaving it in if we're actually > going to change it. Do you know if the book has gone to press? > This makes me want to rethink using the IDL mapping, but the catch > is we need to if we are going to use general code to operate on > arbitrary DOM trees, including remote ones. Without this, there's > little point to using ANY specific interface. ;-( We may end up with > multiple flavors of the interface, which I consider evil. I think it is not that bad. The differences are rather small and homogenous. What about using an object factory to build DOM trees. This would be a good thing in any case, because applications could extend the DOM base classes to add support for application specific requirements. Supporting an old/different interface (for compatibility/context reasons) would simply mean changing the object factory somewhat. It could be done by importing the DOM document constructor via a special module or through an explicite initialization call. - Dieter From gabor.melis@essnet.se Sun Nov 21 12:52:37 1999 From: gabor.melis@essnet.se (Gabor Melis) Date: Sun, 21 Nov 1999 14:52:37 +0200 Subject: [XML-SIG] wstring encode Message-ID: Hi Is there a way to encode a wstring? I looked into wstrop.c but it seems that the encode method doesn't make it to Python. I can see no reason for that, though. Let's suppose we have encode() for a minute. It is still not good enough for me, because I want to encode a wstring with a specific encoding, but using numeric references ({) for characters not available in the target charset. It is no big deal, I can implement it, but I'd hate to duplicate work. Forgive my ignorance, but do we have such a beast implemented? Cheers, Gabor From gabor.melis@essnet.se Sun Nov 21 14:10:26 1999 From: gabor.melis@essnet.se (Gabor Melis) Date: Sun, 21 Nov 1999 16:10:26 +0200 Subject: [XML-SIG] wstring encode In-Reply-To: <529DFAC20CB1D2118BC900A0C9B42562269D62@HUNSERV1> Message-ID: OK, I have figured out how to encode() with wstring, but the second question still stands. G On 21-Nov-99 MIME :gabor.melis@essnet.se wrote: > Hi > > Is there a way to encode a wstring? I looked into wstrop.c but it > seems that the encode method doesn't make it to Python. I can see > no > reason for that, though. > > Let's suppose we have encode() for a minute. It is still not good > enough for me, because I want to encode a wstring with a specific > encoding, but using numeric references ({) for characters not > available in the target charset. > > It is no big deal, I can implement it, but I'd hate to duplicate > work. Forgive my ignorance, but do we have such a beast > implemented? > > Cheers, Gabor > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig > > > From Circulation@al-jumuah.freeserve.co.uk Mon Nov 22 11:45:07 1999 From: Circulation@al-jumuah.freeserve.co.uk (Circulation) Date: Mon, 22 Nov 1999 11:45:07 -0000 Subject: [XML-SIG] Request Message-ID: <001001bf34df$091fe5e0$a5c7883e@aljumuah> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF34DF.064E2840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I am looking to download a free XML reference from the internet. Could you advise of a good one please=20 Many thanks in advance Youcef Yours. ------=_NextPart_000_0007_01BF34DF.064E2840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
 
I am looking to download a free XML = reference from=20 the internet.
Could you advise of a good one please =
Many thanks in advance
Youcef
Yours.
------=_NextPart_000_0007_01BF34DF.064E2840-- From uche.ogbuji@fourthought.com Tue Nov 23 21:40:58 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Tue, 23 Nov 1999 14:40:58 -0700 Subject: [XML-SIG] CORBA compliance for the DOM in Python? In-Reply-To: Your message of "Sat, 20 Nov 1999 12:33:20 +0100." <14390.33928.688786.170131@lindm.dm> Message-ID: <199911232140.OAA03380@localhost.localdomain> > Fred L. Drake, Jr. writes: > > Andrew M. Kuchling writes: > > > (The get_*() probably can't go away completely, though, because of > > > external documents such as Sean McGrath's Python/XML book.) > > > > This one hurts; I really don't like leaving it in if we're actually > > going to change it. Do you know if the book has gone to press? > > This makes me want to rethink using the IDL mapping, but the catch > > is we need to if we are going to use general code to operate on > > arbitrary DOM trees, including remote ones. Without this, there's > > little point to using ANY specific interface. ;-( We may end up with > > multiple flavors of the interface, which I consider evil. > I think it is not that bad. The differences are rather small > and homogenous. Yes, but many of the people who buy Sean's book will probably be newbies who will not like the unpleasant surprise of getting "AttributeError" exceptions every time they attempt the merest example in the text. However, I expect that Sean would have python-xml 0.5.1 or so on the CD that comes with the book, which will still match the text, and if people come to python.org to get a new version, we can put up a big notice in corruscating periwinkle and ultramarine with blink tags that tells them that the API has changed. I'll be honest that the _get_ stuff still looks odd, so I'll be encouraging users to stick to the pythonic interface, but we've almost completed porting 4DOM to support both (and ditch the old interface), so we're committed. > What about using an object factory to build DOM trees. > This would be a good thing in any case, because applications > could extend the DOM base classes to add support for application > specific requirements. DOM level 2 already takes care of this, defining a complete set of factory methods with the exception of Entity, NodeList and NamedNodemap. Note that the re-worked 4DOM we're polishing off supports full DOM Level 2, including those factories on Document and DOMImplementation. > Supporting an old/different interface (for compatibility/context reasons) > would simply mean changing the object factory somewhat. > It could be done by importing the DOM document constructor > via a special module or through an explicite initialization > call. Not a bad idea. PyDOM could ship with a "compatability" interface that is mixed in to the nodes if a particular parameter is asserted in the factories. -- 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 gstein@lyra.org Wed Nov 24 12:49:44 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 24 Nov 1999 04:49:44 -0800 (PST) Subject: [XML-SIG] cvsweb access Message-ID: Hi all, The CVS repository for the XML-SIG is now available via your browser. Please see: http://www.lyra.org/cgi-bin/cvsweb.cgi/xml/ Please let me know if you have any problems or suggestions for enhancements. Cheers, -g -- Greg Stein, http://www.lyra.org/ From gabor.melis@essnet.se Wed Nov 24 13:24:01 1999 From: gabor.melis@essnet.se (Gabor Melis) Date: Wed, 24 Nov 1999 15:24:01 +0200 Subject: [XML-SIG] wstring encode In-Reply-To: <529DFAC20CB1D2118BC900A0C9B42562269D9D@HUNSERV1> Message-ID: Yes, it throws a ConvertError exception. I think what you propose is a good way to solve this problem, but unfortunately ;-) I found another solution to my problem which doesn't require this. Escaping legal (for a given encoding) characters is an other matter and the application should handle that, just as toxml() does in the xml.dom module. Sorry about the big latency, G On 22-Nov-99 MIME :dieter@handshake.de wrote: > Hello Gabor > > > OK, I have figured out how to encode() with wstring, but the > second > > question still stands. > What does "wstring.encode" does, when it hits a non-encodable > character? Does it raise an exception? > > What about providing an error handler to "wstring/wstrop". > The default error handler does, what is now done. > An application specific error handler might implement the > character reference encoding. By the way, what should > your encoder do with "&" that happens to be part of your > string. > > - Dieter > > > From fdrake@acm.org Wed Nov 24 19:19:59 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 24 Nov 1999 14:19:59 -0500 (EST) Subject: [XML-SIG] xml.sax.writer Message-ID: <14396.14943.860372.516859@weyr.cnri.reston.va.us> I've just checked in the xml.sax.writer module, which defines a couple of SAX DocumentHandler-protocol classes that can be used to generate XML output. There are two primary classes: XmlWriter -- basic XML generation PrettyPrinter -- adds nice indentation There are a number of supporting classes as well, that I'll document over the next couple of weeks, and hopefully provide an example. I'll also update demos/genxml/loaddata.py to use the PrettyPrinter class, which is closest to the intent. The helper classes call into two categories: syntax descriptions and DTD descriptions. The syntax descriptions can be used to control whether the output of the output drivers is XML-like, SGML-like, or XHTML-like (with that stupid extra space in front of />). You could do even more damage with them, but let's not go there! ;-) The DTD description objects can be used to provide information about the output DTD to the writers; it can be very nice to know things like which elements allow #PCDATA and which are empty. You can initialize these objects either by calling methods to set up specific elements or (for the XML/XHTML variants) by calling a method to parse the DTD using xml.parsers.xmlproc.dtdparser. I'll make this stuff easier as well in the future with some handy convenience functions. It would be really nice to have an SGML DTD parser as well. ;-) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From mss@transas.com Thu Nov 25 00:28:10 1999 From: mss@transas.com (Michael Sobolev) Date: Thu, 25 Nov 1999 03:28:10 +0300 Subject: [XML-SIG] Marked sections Message-ID: <19991125032810.A8927@transas.com> I've got another question. Does anybody know a library (that would interface with python :) that would cope with marked sections for XML? If I understand correctly, neither parser from current set of parsers in python-xml supports marked sections... Thanks, -- Mike From uche.ogbuji@fourthought.com Thu Nov 25 01:59:27 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Wed, 24 Nov 1999 18:59:27 -0700 Subject: [XML-SIG] CORBA compliance for the DOM in Python? (RE-POST) In-Reply-To: Your message of "Sat, 20 Nov 1999 12:33:20 +0100." <14390.33928.688786.170131@lindm.dm> Message-ID: <199911250159.SAA07499@localhost.localdomain> Pardon me if you get this twice, but I had problems with mail at python.org yesterday > Fred L. Drake, Jr. writes: > > Andrew M. Kuchling writes: > > > (The get_*() probably can't go away completely, though, because of > > > external documents such as Sean McGrath's Python/XML book.) > > > > This one hurts; I really don't like leaving it in if we're actually > > going to change it. Do you know if the book has gone to press? > > This makes me want to rethink using the IDL mapping, but the catch > > is we need to if we are going to use general code to operate on > > arbitrary DOM trees, including remote ones. Without this, there's > > little point to using ANY specific interface. ;-( We may end up with > > multiple flavors of the interface, which I consider evil. > I think it is not that bad. The differences are rather small > and homogenous. Yes, but many of the people who buy Sean's book will probably be newbies who will not like the unpleasant surprise of getting "AttributeError" exceptions every time they attempt the merest example in the text. However, I expect that Sean would have python-xml 0.5.1 or so on the CD that comes with the book, which will still match the text, and if people come to python.org to get a new version, we can put up a big notice in corruscating periwinkle and ultramarine with blink tags that tells them that the API has changed. I'll be honest that the _get_ stuff still looks odd, so I'll be encouraging users to stick to the pythonic interface, but we've almost completed porting 4DOM to support both (and ditch the old interface), so we're committed. > What about using an object factory to build DOM trees. > This would be a good thing in any case, because applications > could extend the DOM base classes to add support for application > specific requirements. DOM level 2 already takes care of this, defining a complete set of factory methods with the exception of Entity, NodeList and NamedNodemap. Note that the re-worked 4DOM we're polishing off supports full DOM Level 2, including those factories on Document and DOMImplementation. > Supporting an old/different interface (for compatibility/context reasons) > would simply mean changing the object factory somewhat. > It could be done by importing the DOM document constructor > via a special module or through an explicite initialization > call. Not a bad idea. PyDOM could ship with a "compatability" interface that is mixed in to the nodes if a particular parameter is asserted in the factories. -- 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 larsga@garshol.priv.no Thu Nov 25 12:38:45 1999 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 25 Nov 1999 13:38:45 +0100 Subject: [XML-SIG] Marked sections In-Reply-To: <19991125032810.A8927@transas.com> References: <19991125032810.A8927@transas.com> Message-ID: * Michael Sobolev | | I've got another question. Does anybody know a library (that would | interface with python :) that would cope with marked sections for | XML? If I understand correctly, neither parser from current set of | parsers in python-xml supports marked sections... What kind of marked sections are you thinking of? expat, RXP, xmllib and xmlproc all support CDATA marked sections. As for (INCLUDE/IGNORE) marked sections in the DTD, RXP and xmlproc also support those. --Lars M. From grove@infotek.no Thu Nov 25 13:44:30 1999 From: grove@infotek.no (Geir Ove Grønmo) Date: 25 Nov 1999 14:44:30 +0100 Subject: [XML-SIG] xml.sax.writer In-Reply-To: <14396.14943.860372.516859@weyr.cnri.reston.va.us> References: <14396.14943.860372.516859@weyr.cnri.reston.va.us> Message-ID: * Fred L. Drake, Jr. | I've just checked in the xml.sax.writer module, which defines a | couple of SAX DocumentHandler-protocol classes that can be used to | generate XML output. There are two primary classes: | | XmlWriter -- basic XML generation | PrettyPrinter -- adds nice indentation I've done something similar in xmlarch and GPS, but it's not as powerful as the xml.sax.writer module. When I developed GPS I created a in tutorial that showed how a user could interact with groves and property sets. Since new versions are released regularly and the behavior might have changed, I had to manually run though the examples to make sure that the results of the expressions were the same. This wasn't very convenient, so I developed a tool that regenerated the tutorial. One of the examples wrote an XML file to standard output using the Prettifier class. [Un]fortunately the tutorial was an HTML file, so some characters had to be escaped to be displayed correctly. I solved this by writing a stream filter that escaped characters: class HTMLEscaper: escape_chars = {"<": "<", "&": "&"} def __init__(self, writer): self.writer = writer def write(self, str): newstr = str for oldchars, newchars in self.escape_chars.items(): newstr = string.replace(newstr, oldchars, newchars) self.writer.write(newstr) def flush(self): self.writer.flush() I believe this would be very useful to have in the xml.sax.writer module as well. It should probably be solved by having a general Escaper class and several subclasses that contained specific mappings. All the best, Geir O. From mss@transas.com Thu Nov 25 14:28:45 1999 From: mss@transas.com (Michael Sobolev) Date: Thu, 25 Nov 1999 17:28:45 +0300 Subject: [XML-SIG] Marked sections In-Reply-To: ; from larsga@garshol.priv.no on Thu, Nov 25, 1999 at 01:38:45PM +0100 References: <19991125032810.A8927@transas.com> Message-ID: <19991125172845.A22938@transas.com> On Thu, Nov 25, 1999 at 01:38:45PM +0100, Lars Marius Garshol wrote: > As for (INCLUDE/IGNORE) marked sections in the DTD, RXP and xmlproc > also support those. Yes, I need INCLUDE/IGNORE marked sections. Do they support marked sections in DTD only? -- Mike From larsga@garshol.priv.no Thu Nov 25 15:49:12 1999 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 25 Nov 1999 16:49:12 +0100 Subject: [XML-SIG] Marked sections In-Reply-To: <19991125172845.A22938@transas.com> References: <19991125032810.A8927@transas.com> <19991125172845.A22938@transas.com> Message-ID: * Lars Marius Garshol | | As for (INCLUDE/IGNORE) marked sections in the DTD, RXP and xmlproc | also support those. * Michael Sobolev | | Yes, I need INCLUDE/IGNORE marked sections. Do they support marked | sections in DTD only? In XML these only exist in the DTD, but you may find this document interesting: --Lars M. From mss@transas.com Thu Nov 25 17:00:29 1999 From: mss@transas.com (Michael Sobolev) Date: Thu, 25 Nov 1999 20:00:29 +0300 Subject: [XML-SIG] Marked sections In-Reply-To: ; from larsga@garshol.priv.no on Thu, Nov 25, 1999 at 04:49:12PM +0100 References: <19991125032810.A8927@transas.com> <19991125172845.A22938@transas.com> Message-ID: <19991125200029.A25376@transas.com> On Thu, Nov 25, 1999 at 04:49:12PM +0100, Lars Marius Garshol wrote: > In XML these only exist in the DTD, Oops, I missed the word DTD while reviewing the specification. Thank you. > but you may find this document > interesting: Thank you for the link. -- Mike From sean@digitome.com Fri Nov 26 11:50:16 1999 From: sean@digitome.com (Sean Mc Grath) Date: Fri, 26 Nov 1999 11:50:16 +0000 Subject: [XML-SIG] CORBA compliance for the DOM in Python? In-Reply-To: <199911232140.OAA03380@localhost.localdomain> References: Message-ID: <3.0.6.32.19991126115016.0091b6c0@gpo.iol.ie> [Uche Ogbuji] > >However, I expect that Sean would have python-xml 0.5.1 or so on the CD that >comes with the book, which will still match the text, and if people come to >python.org to get a new version, we can put up a big notice in corruscating >periwinkle and ultramarine with blink tags that tells them that the API has >changed. > Yes. I will have 0.5.1 on the CD-ROM. I have looked at the main DOM chapter and only find two occurences of get_* so I don't think it is a big deal. I also can use the corruscating, periwinkle and ultramarine with blink tags on the books website (www.pyxie.org) to broadcast the API change. regards, From dongwon@CS.UCLA.EDU Fri Nov 26 18:32:15 1999 From: dongwon@CS.UCLA.EDU (Dongwon Lee) Date: Fri, 26 Nov 1999 10:32:15 -0800 (PST) Subject: [XML-SIG] DTD parser Message-ID: [pls reply to me directly since i'm not on the mailing list] my apology for possible interruption. i am relatively new to XML & python. i am wondering if there is the following python s/w out there. given XML DTD, i want to create a customized parse tree for the DTD. hopefully, i'd like to avoid writing a parser for this, but to re-use an existing s/w. this s/w should be able to do 1) parse any XML DTD and create some kind of parse tree of their own, and 2) provide API to the parse tree so that by traversing or modifying it, i can create my own customized parse tree out of it. i'd appreciate for any input. if there is no s/w exactly doing this, does anyone know if other language like C++ or java have one? thanks a lot. --- Dongwon Lee http://www.cs.ucla.edu/~dongwon/ Office:310.206.0068 Fax:310.UCLA.CSD CoBase Research Group 4813 Boelter Hall, CS, UCLA From uche.ogbuji@fourthought.com Fri Nov 26 21:30:12 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 26 Nov 1999 14:30:12 -0700 Subject: [XML-SIG] New 4DOM to meet unofficial Python binding Message-ID: <199911262130.OAA02247@localhost.localdomain> We have updated the core of 4DOM to meet the unofficial Python/DOM binding as we've been discussing. That means that the following conventions are followed: cn = n.childNodes cn = n._get_childNodes n.nodeValue = 'Value' n._set_nodeValue('Value') Note that NodeLists and NamedNodeMaps are still pythonic, i.e. they support all the list and dictionary interface. DOM level 1 and 2 core and traversal are supported. The HTML code has not been updated to the new binding, and so it will not work. Also the SAX2 driver is not yet updated. We hope to have a full beta available soon. Note that 4XPath and 4XSLT have not yet been updated, so be careful where you install the 4DOM alpha if you use those packages. We would appreciate comments from those who have participated in the DOM binding discussion, and, of course, from anyone who is interested in DOM in Python. Please download it from ftp://FourThought.com/pub/4Suite/4DOM The files are 4DOM-0.9.0a1.tar.gz and 4DOM-0_9_0a1.zip Note that there is no longer a make process necessary. Just unpack it to a spot in your PYTHONPATH. This also means that the difficulties on different platforms are a thing of the past. However, you still need the 4Suite-base package version 0.6.1 at ftp://FourThought.com/pub/4Suite -- 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 uche.ogbuji@fourthought.com Fri Nov 26 21:32:37 1999 From: uche.ogbuji@fourthought.com (uche.ogbuji@fourthought.com) Date: Fri, 26 Nov 1999 14:32:37 -0700 Subject: [XML-SIG] New 4Suite mailing list Message-ID: <199911262132.OAA02261@localhost.localdomain> There is now a mailing list for 4Suite (http://FourThought.com/4Suite). To subscribe or for list archives, please visit http://lists.fourthought.com/mailman/listinfo/4suite -- 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 Sat Nov 27 03:54:31 1999 From: Mike.Olson@FourThought.com (Mike Olson) Date: Fri, 26 Nov 1999 20:54:31 -0700 Subject: [XML-SIG] New 4DOM to meet unofficial Python binding References: <199911262130.OAA02247@localhost.localdomain> Message-ID: <383F55F7.F9AA57D@FourThought.com> One quick note on a typo so they is no confusion. The second example of attribute retrieval should be: cn = n._get_childNodes() Mike uche.ogbuji@fourthought.com wrote: > We have updated the core of 4DOM to meet the unofficial Python/DOM binding as > we've been discussing. That means that the following conventions are followed: > > cn = n.childNodes > cn = n._get_childNodes > n.nodeValue = 'Value' > n._set_nodeValue('Value') > > Note that NodeLists and NamedNodeMaps are still pythonic, i.e. they support > all the list and dictionary interface. > > DOM level 1 and 2 core and traversal are supported. > > The HTML code has not been updated to the new binding, and so it will not > work. Also the SAX2 driver is not yet updated. We hope to have a full beta > available soon. > > Note that 4XPath and 4XSLT have not yet been updated, so be careful where you > install the 4DOM alpha if you use those packages. > > We would appreciate comments from those who have participated in the DOM > binding discussion, and, of course, from anyone who is interested in DOM in > Python. > > Please download it from > > ftp://FourThought.com/pub/4Suite/4DOM > > The files are 4DOM-0.9.0a1.tar.gz and 4DOM-0_9_0a1.zip > > Note that there is no longer a make process necessary. Just unpack it to a > spot in your PYTHONPATH. This also means that the difficulties on different > platforms are a thing of the past. However, you still need the 4Suite-base > package version 0.6.1 at > > ftp://FourThought.com/pub/4Suite > > -- > 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 > > _______________________________________________ > XML-SIG maillist - XML-SIG@python.org > http://www.python.org/mailman/listinfo/xml-sig -- ---------------- Mike Olson Consulting Member FourThought LLC http://www.fourthought.com http://opentechnology.org From larsga@garshol.priv.no Sun Nov 28 14:14:17 1999 From: larsga@garshol.priv.no (Lars Marius Garshol) Date: 28 Nov 1999 15:14:17 +0100 Subject: [XML-SIG] DTD parser In-Reply-To: References: Message-ID: * Dongwon Lee | | given XML DTD, i want to create a customized parse tree for the | DTD. hopefully, i'd like to avoid writing a parser for this, but to | re-use an existing s/w. xmlproc has a DTD parser which you can use to get DTD information. | this s/w should be able to do | | 1) parse any XML DTD and create some kind of parse tree of their own, xmlproc allows you to do this: You can choose between letting xmlproc build the object structure, or using the event-based DTD parser to do that yourself. --Lars M.