Acceptance of XML in the Python Community.notes

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 <chris@shenton.org>
Daniel Krech <eikeon@eikeon.com>

--------------------------------------------------------------------------
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...