This is precisely why I was using Python in a bunch of disconnected shell scripts in the orig Cordova prototype work. Agree however that using Node would be a preferable tool for the job overall. A Python shim for the bits that it cannot do is completely pragmatic.
On Wed, Feb 1, 2012 at 6:21 AM, Patrick Mueller <pmue...@gmail.com> wrote: > On Tue, Jan 31, 2012 at 15:42, Andrew Lunny <alu...@gmail.com> wrote: > >> * @pmuellr: there is no good pure JS XML parser in Node; there are bindings >> to libxml2, but we can't reasonably expect end-users to have the external >> dependencies for that. I have been using - >> https://github.com/racker/node-elementtree - but it lacks some features - >> notably support for namespaces and the concept of a document (which affects >> absolute XPath selectors) > > > I could care less about XPath, but support for namespaces is presumably > required to be able to successfully parse android XML files, right? I > assume there will be a need to do that, in the tooling, somewhere. > > The reason I asked about XML parsers for node, if it wasn't obvious, is > that I'd like to see the tooling implemented on node (and CoffeeScript :-). > But I'm not married to it. Python would be my next choice - it's widely > available on all of the desktop platforms we would support the tooling on. > WebKit has traditionally done all their tooling in Perl, but over the last > few years, mainly due to the Googlites, the tooling is migrating to Python. > The only issue that comes up is having to support old versions of Python > for ancient versions of Mac OS X. > > Another alternative would be to write most of the tooling in node, and do > the XML parsing with a single Python script, whose sole purpose in life > would be to read XML and spit out a stream of DOM nodes (or something). > Eventually there's got to be an XML parser for node, right? RIGHT? > > Another conclusion re: node not supporting XML might be: we shouldn't be > using XML for our configuration files. JSON isn't a great alternative, > since it's neither human readable or writable. Or maybe something like > this json tool helps [1]. CoffeeScript Object Notation [2] would probably > be workable. YAML maybe. > > [1] https://github.com/trentm/json > [2] https://github.com/balupton/cson.npm > > -- > Patrick Mueller > http://muellerware.org