cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: W3C XML Processing working group
Date Mon, 02 Jan 2006 04:10:45 GMT
Gianugo Rabellino wrote:
> On 12/30/05, Sylvain Wallez <sylvain@apache.org> 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

Mime
View raw message