[XML-SIG] Reconsidering the DOM API
Uche Ogbuji
uogbuji@fourthought.com
Tue, 27 Jun 2000 14:37:31 -0600
> <mode="pot stirring">
Eh, exactly what sort of "pot" is that? <g>
[snip]
> > Attributes:
> > * arguably more Pythonic (=easier to use)
>
> In your last post you gave the example:
>
> > a=b.childNodes[0].attributes["abc"]
> >
> > and this looks like Java:
> >
> > a=b.getChildNodes()[0].getAttributes()["abc"]
>
> Why not use the follows notation:
>
> a=b.get_childNode(0).get_attribute("abc")
>
> or perhaps the call chain should be reduced by merging methods:
>
> c = b.get(childNode=0, attribute="abc")
This is why I asked the question above. Way psychedelic, dude.
> > There are no killer arguments here, just different weights applied to
> > the various features. I don't think that we are going to agree to break
> > code today. Maybe later we'll see that there are more DOM implementors
> > than clients and their ease of implementation will take precedence.
>
> The standard Python interface may end up having to support both access
> approaches (direct and through methods), which will really make the
> interface ugly. If we had to choose one, which one will allow the
> greater flexiblity?
That is how things stand now. 4DOM (and PyDOM) support both.
> Benjamin Saller "getValues" idea looks interesting. Perhaps it is
> time to step back and ask how easy XML could be if the Python
> interface had nothing to do with SAX or DOM.
But there's plenty of (good) effort in that direction already. It's
orthogonal to the DOM mapping decision.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +01 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python