Seeing that Perl and Python are the two most advanced languages when it comes to XML support, there is some thinking about how we could get the two communities to exchange ideas. Both sides have really good ideas here and there that could be ported both ways, or could have been specified jointly.
We could kick some jAss (Java Application Server System).
So what do you think would be the best way of going about this? I've been talking with Uche Ogbuji and we're looking for ideas. Any suggestion, even silly, is welcome :)
The flexibility of our languages is our advantage.
-Dom
Re:Languages with Power[tm]
darobin on 2003-03-25T14:50:09
And that's exactly what would happen in Java or C#. You'd take an XML Schema and have it generate some code.
.Net does that natively, Java has things like Castor for that purpose. It works rather well, but there's an extra step that we don't need :) (and we can choose to use something better than XML Schema).
Good idea. Given that we can both use the excellent libxml2 and libxslt, it seems sensible to try and co-operate where we can. Just because I use Perl does not mean that I hate Python.
In his column Environment, behavior, and scripting, Jon Udell complains that many scripting languages use the same libraries, but provide widely differing interfaces to them, it hardly make sense.
However to play the devil's advocate, sometimes a one interface fits all gives you a good fit no where, or as in DOM, something that is okay in Java, but a bit of a pain everywhere else.
Re:libxml2 and libxslt
darobin on 2003-03-25T14:58:47
I've been going back and forth on the widely different interfaces thing. On the one hand, it's best for implementors to do what's idiomatic in their language. It makes life easier for users of that language. On the other hand, it's a pain for people like that have to change between languages frequently (I code against the DOM in three different languages). Remembering all the small differences between the languages is a pain. I used XML::LibXML for month with very few problems, then was stuck doing mostly Java and EcmaScript for two months. The first small script I wrote when I came back to Perl uncovered three bugs in XML::LibXML in less than ten lines -- I had clearly modified my usage pattern.
But I have to say, I'm not so interested about the interface side. Mostly I'm thinking about:
- Ideas: there are ways to approach XML processing that haven't yet been explored. Altogether too often, they are explored by one community and not shared by the others. That's a waste.
- Algos: some things are hard to implement well or efficiently. Having the opportunity to discuss implementation details with other people working on implementing the same thing in another language could be extremely useful. For instance, just the other day I found out about a way to process an XML tree as if it were a b-tree that is more efficient than all automata-based processors I'd ever seen. It was common knowledge in one community, unheard of elsewhere.
- Specs: some things can be cross-language, such as XBind or XPipe, because they're definitions of XML formats (and input from multiple implementors is actually very important). There could definitely be some workload sharing in that space.
If we can get to work together on these things, I don't really mind if we all have differing APIs
;)
I've seen situations in the Perl community where people will advocate fixing a test to address what may, and may not, be ambiguous behavior rather than investigating the ambiguous behavior. Also, testing Perl programs against known output sometimes doesn't really exercise things, IMO.
Perhaps a test suite where a dynamic web site (like a news site or Freshmeat or something) could be downloaded, processed into XML, processed back into XHTML and the final results compared. The various stages of this process could be mix and match implemented in various (all?) combinations of Perl and Python.
Failing cases could be captured and used for static regression testing later, too.
Another area would be the interfacing to the external C libraries like libxml/libslt/expat. I know there are efforts to compile Python to Parrot, but how much has been done to rationalize the various languages external interfaces? This might be an opportunity for a real-world trial.
Re:Testing
darobin on 2003-03-25T19:16:51
Testing is definitely an area of interest. I'm unsure as to how far we can go crossing language boundaries (though there could be a Test::Python built on Inline::Python that would produce the proper output...hmmm) but interop workshops are clearly good ways to spot bugs and under-specified areas in a spec (the longest and hardest discussions I've seen in the SVG WG stemmed from that sort of problem).
I don't know if we could have something as generic as the website you describe since a lot of this is infrastructural code (it doesn't produce anything, at least not by itself) but it's waaaay to early to know
:) As for language bindings, rationalising the API may or may not be a good idea (it's the idiomatic vs easy-to-switch-between-language-and-saved-efforts debate) however rationalising as much work as possible out of the binding effort. SWISH supposedly does this, but unfortunately there is too much deployed XS to make an easy switch (no pun intended). I'm afraid that by the time we would get people to agree to use SWISH instead and actually do it, we would have a working Parrot core and would simply be able to use that to bind once
:) But maybe I'm misunderstanding what kind of rationalisation you are thinking of?
--Nat
Re:Cooperation
darobin on 2003-03-26T09:29:49
Oooh, great, thanks! I'll inform my correspondants from those strange and distant lands at once!
