TITLE OF PAPER: Acceptance of XML in the Python Community URL OF PRESENTATION: --not available-- PRESENTED BY: Fred L Drake, Jr. REPRESENTING: Zope Corp CONFERENCE: PyCon 2005 DATE: March 25, 2005 LOCATION: Marvin Theater -------------------------------------------------------------------------- REAL-TIME NOTES / ANNOTATIONS OF THE PAPER: {If you've contributed, add your name, e-mail & URL at the bottom} [Started VERY late] xml support every majoor modern language has it It's in XML so i's kind of ugly. Very True he's right, it can be very ugly but often just moderately ugly but it can also be useful We do have tools to work with it standard library for simple things third-party libraries for everything else (api hasn't changed, leaves me to believe we haven't finished Phillip Eby blogged about it (can't find exact reference; had some very unkind things to say about xml) PJE doesnt like XML maybe I justn't read blogs ook, I normally don't but phillip's a smart guy considers XML truly vile it does have a few warts (sometimes we have to use XML, despite what phillip says, lots of legacy behind it) It's not just phillip we don't make it easy enough which libraries do I need to use, there's a ton of them multiple implementations that implement different subsets: dom, sax, ... These are not beautiful APIs. Not everything uses them. Not everything implements exctly the same So what's the problem? Pythonistas don't like alphabet soup There are too many spearate specifications it's har d to know which apply sometimes but that's not python's fault Tools are hard to choose few that support several specifications Little documentation Lots of disagreement about the API What's wrong with our tools? Too many sijmilar models w3c DOM, ElementTree, libxml2 DOM SAX, libxml2 SAX (at leasst xmllib is dead; sorry Sjoerd!) APIs don't feel Pythonic Many were adopted from JAVA (and feels too JAVA-y, don't feel like we've adapted them well in Python) Too little documentation "But we're programmers, not writers!" Get over it already. (I've made libxml2 work, but it was in spite of the documentation) What about ElementTree it's not Java Buit it's even more basic... We can't even decide about how to represent characters some packages use Unicode Some use UTF-8 We can't decide about namespaces some use (namespaceURI,localName) Others use '{namespaceURI}localname' What's wrong with that? Choose what's best for each application (good) Use the representation we like to use (good, kinda) Might not be able to choose both: We take what the libraries we choose give us We use the models from libraries that implement the right part of the alphabet So maybe we ... We need an API For Example ... character data It should be possible ...structure nodes All DOMs need them, W3C or not Some aspects are common ...attribute collections needed by many APIs But we're geeks we can't decide on just one Let's be practical Sometimes diffeerent models are necessary http://www.python.org/moin/XmlApiDiscussion We've got to start fixing this problem. -------------------------------------------------------------------------- REFERENCES: {as documents / sites are referenced add them below} -------------------------------------------------------------------------- QUOTES: -------------------------------------------------------------------------- CONTRIBUTORS: {add your name, e-mail address and URL below} Chris Shenton Daniel Krech -------------------------------------------------------------------------- E-MAIL BOUNCEBACK: {add your e-mail address separated by commas } -------------------------------------------------------------------------- NOTES ON / KEY TO THIS TEMPLATE: A headline (like a field in a database) will be CAPITALISED This differentiates from the text that follows A variable that you can change will be surrounded by _underscores_ Spaces in variables are also replaced with under_scores This allows people to select the whole variable with a simple double-click A tool-tip is lower case and surrounded by {curly brackets / parentheses} These supply helpful contextual information. -------------------------------------------------------------------------- Copyright shared between all the participants unless otherwise stated...