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
