Re: W3C XML Processing working group
On Mon, 2 Jan 2006, Gianugo Rabellino wrote: 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 Hear hear ! Dw.
Re: W3C XML Processing working group
Gianugo Rabellino wrote: On 1/1/06, Michael Wechner [EMAIL PROTECTED] 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
Re: W3C XML Processing working group
Gianugo Rabellino wrote: On 12/30/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Hi all, The W3C recently set up an XML Processing working group[1] whose primary goal is to define an XML processing language (i.e. pipelines). Wow, innovation at work! :-) AFAIU the group's direction is not to reinvent something new, but to standardize what already exists, taking as inputs two pipeline languages that were submitted as W3C notes, namely Norman Walsh's[2] and XPL from Orbeon[3] (that BTW they claim to be the pipeline language that has in fact been used the most[4]. My impression is that what this WG will end up defining yet another programming language in XML, and that this language will either be very limited in the processing types it allows in order to be implemented on a wide range of platforms (including browsers), or allow a lot of extensibility, thus actually limiting its portability. WDYT, should we join the party? I think it would make sense to at least talk to them, or has this been done already? 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? Thanks Michi Anyone has the guts to start a JSR on that? :) -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/) -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: W3C XML Processing working group
On 1/1/06, Michael Wechner [EMAIL PROTECTED] 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. [1] http://www.rabellino.it/blog/?p=117 -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: W3C XML Processing working group
Gianugo Rabellino wrote: On 12/30/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Hi all, The W3C recently set up an XML Processing working group[1] whose primary goal is to define an XML processing language (i.e. pipelines). ... My impression is that what this WG will end up defining yet another programming language in XML, and that this language will either be very limited in the processing types it allows in order to be implemented on a wide range of platforms (including browsers), or allow a lot of extensibility, thus actually limiting its portability. I'm not so sure. Although I have only read the minutes of their Dec 15th and 22nd meetings. A couple of things strike me: Scripting language has two parts: having a way to specify a sequence of processes and to talk about what form the data is in as it passes through the process. It would be nice if we could do the former without constraining the latter Here the words scripting language would make one think of a programming language, but replace those two words with pattern language or template language and it may become more acceptable. At least to me, since that's why my work focused. Another interesting quote is: If you had a registry, you could identify small names for the processes that do things, like registering XSLT for the XSLT 1.0 process This seems to support my interpretation of the first quote. The language is describing a set of processes that can be used to move from one state to another. By having a hierarchy of processes, each defined by patterns, you can do something like: User: give me document X App: I have document A, B and C, but need X. Engine: how do I create X from A, B and C Engine: apply process 1 to docs B and E. You can create E by applying process 2 to A and C App: Program execution is: (A, C) - 2 = E (B, E) - 1 = X User: Thank you With respect to portability limitations, there need not be any, just imagine the processes run remotely (yes that introduces a whole load of other problems, but that is not for this WG). Such an approach does make it possible to create a high level language that need not define any complex logic through conditional execution since it is implicit rather than explicit. I have working prototypes of such systems (albeit academic proof of concepts). Of course, I'm interpreting just a few words by applying around five years of academic research and therefore have a very biased and blinkered interpretation at this time. It should be recognised that the Cocoon sitemap is surprisingly close to doing this already. This has not gone unnoticed by the WG: they [Cocoon] have a simple one-level sequence path and I've got a more hierarchical model. Processing subtrees is like having embedded pipelines. That's hard to do in Cocoon because of their syntax. WDYT, should we join the party? I think Cocoon could gain much from this discussion, even if it does turn out to be another low level XML programming language (please no). It's piqued my interest but, I don't do anything in this area any more. Nevertheless, I've joined the public list, it would be nice to actually awaken some of those parts of my brain, maybe I'll find time to return to this work. Ross
W3C XML Processing working group
Hi all, The W3C recently set up an XML Processing working group[1] whose primary goal is to define an XML processing language (i.e. pipelines). AFAIU the group's direction is not to reinvent something new, but to standardize what already exists, taking as inputs two pipeline languages that were submitted as W3C notes, namely Norman Walsh's[2] and XPL from Orbeon[3] (that BTW they claim to be the pipeline language that has in fact been used the most[4]. My impression is that what this WG will end up defining yet another programming language in XML, and that this language will either be very limited in the processing types it allows in order to be implemented on a wide range of platforms (including browsers), or allow a lot of extensibility, thus actually limiting its portability. WDYT, should we join the party? Sylvain [1] http://www.w3.org/XML/Processing/ [2] http://www.w3.org/TR/2002/NOTE-xml-pipeline-20020228/ [3] http://www.w3.org/Submission/xpl/ [4] http://www.orbeon.com/blog/2005/12/20/xml-processing-model-working-group-meetings-have-started/ -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: W3C XML Processing working group
On 12/30/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Hi all, The W3C recently set up an XML Processing working group[1] whose primary goal is to define an XML processing language (i.e. pipelines). Wow, innovation at work! :-) AFAIU the group's direction is not to reinvent something new, but to standardize what already exists, taking as inputs two pipeline languages that were submitted as W3C notes, namely Norman Walsh's[2] and XPL from Orbeon[3] (that BTW they claim to be the pipeline language that has in fact been used the most[4]. My impression is that what this WG will end up defining yet another programming language in XML, and that this language will either be very limited in the processing types it allows in order to be implemented on a wide range of platforms (including browsers), or allow a lot of extensibility, thus actually limiting its portability. WDYT, should we join the party? 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. Anyone has the guts to start a JSR on that? :) -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
