cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <coc...@lojjic.net>
Subject Re: W3C XML Processing working group
Date Mon, 02 Jan 2006 16:17:01 GMT
Gianugo Rabellino wrote:
> On 1/1/06, Michael Wechner <michael.wechner@wyona.com> wrote:
> 
>>>I'm not that much interested into yet another DSL expressed in XML,
>>>and I don't feel alone at all. Actually I'd much rather drift towards
>>>a programmatic pipeline API.
>>>
>>
>>what do you mean by a programmatic pipeline API?
> 
> 
> Uhm, part of the story is on my blog[1] but I'll give you an excerpt
> and save you a click ;-)
> 
> It strikes me how, in early 2006, people are still thinking that
> another XML domain-specific language is the way to go. We are all
> learning the hard way how the XML verbiage has been useless and, to
> some extents, detrimental: from Jelly onwards (and yes, I deserve some
> blame as well) it became crystal clear how programming in XML leads to
> unmaintainable, opaque and unreadable stuff. The fake myth that XML
> can be written by grandmas, coupled with the low entry barrier in
> creating new languages (no compiler's compiler needed, yay!) has
> produced a plethora of half-baked solutions that just don't get how
> grandmas aren't going to code anyway, while angle brackets get heavily
> in the way of anyone who understands even just the basics of
> programming.
> 
> Now, don't get me wrong: XML is great when properly used. That is,
> data (some grandmas might even write data at a certain point),
> information interchange and tool-oriented stuff. But please, pretty
> please, when talking about programming (that is, data processing and
> component connections), take those angle brackets out of the picture
> and give us the power of effective syntaxes. There might be some
> exceptions: transformation languages such as XSLT, having to deal with
> XML all the way, are consistently expressed in XML, but that's not the
> case for XML pipelines.
> 
> Pipelines are about connecting, chaining, concatenating: there's
> nothing there that needs XML to be expressed. It's meta-XML, in a way,
> a side order to the main XML dish. What we (well, I at least) need are
> APIs: a standard and effective way to tie XML processing components
> together so that data manipulation can work in a multistage
> environment. We then need some machinery around it that provides
> transparent adapters between the different XML processing world (SAX,
> DOM, StAX) and we could definitely use some services (logging,
> management, security) on top of it. But we don't need XML for that. We
> might want to use it at a later point, as a sort of wrapper around the
> pipeline language if, and only if, there is a clear need for tooling
> that could use a well-established and easy to parse data format, but
> please save our aging eyes and our carpal tunnels from angle brackets
> whenever possible.

I agree that a programmatic pipeline API would be a great thing to have, 
but please don't underestimate the usefulness and appeal of an XML 
format.  I think that those reading this mailing list don't get to hear 
the success stories of how things like Cocoon's XML sitemap format 
actually *do* lower the bar and allow less-technical people or those 
more comfortable with markup to implement Cocoon-based sites.  It's not 
a myth, there actually *are* people out there who aren't programmers and 
aren't comfortable with Java or JS or other procedural code, but who are 
very good at XML markup (not just grandmas!), and the XML sitemap is 
ideal for these people.  I know... I was one of them when I started 
using Cocoon and it's one of the main reasons I got hooked.

So I'd say that the API you and others have suggested is a great idea, 
but having an XML wrapper/implementation of (a subset of) that API would 
be a must.  Just because you wouldn't want to use it doesn't mean nobody 
would.  Just my two cents.

--Jason

Mime
View raw message