> xml and associated tools - xslt, xquery etc are the nice declarative
> bit. soap, ws-* etc are the workflow bits (although they're a bit
> hybrid being to some extent declarative in specification)
You are right, those are two different pieces in the puzzle for
programming
with XML (especially Web services). But declarative constructs and
workflow constructs
do not invalidate each other, they can co-exist as part of the same
language.
I think that there are two pieces missing in the puzzle for programming
for
Web Services: adding imperative logic to the XML world (aka statements)
and making the link between XQuery/XSLT and Web services.
XQuery and XSLT don't give us imperative logic. But XQuery gives us
(a) an abstract data model for XML
(b) a type system
(c) expressions
and all imperative languages use those three as building blocks don't
they ?
So, shouldn't we use them !?
Almost 4 years ago I was playing with extending XQuery to a full
programming
language for Web Services. The resulting language, called XL, was
implemented
by a couple of PhD students in Germany and now in ETH in Switzerland.
I think that the web site (that includes a live demo) is still
maintained by my colleague
Donald Kossmann at
http://xl.informatik.uni-heidelberg.de/index2.shtml
This experiment raised a lot of positive comments. But in the same time
the idea
of having an XML oriented programming language raised the following
comments
from Tim Bray:
An XML-Oriented Programing Language? One response has been a suggestion
that we need a language whose semantics and native data model are
optimized for XML. That premise is silly on the face of it: here are
two reasons why:
• Some decades after the advent of the relational database, we have
not seen programming languages center themselves around normalized data
models; in fact, the movement away from the C struct-centered worldview
to O-O code+data encapsulation is really a move away from the tabular
paradigm. You can embed SQL in most languages now, but normally you
don't implement any serious business logic in it. If this hasn't
happened after decades in the relational world, why would we expect it
to happen in the XML world?
• The notion that there is an "XML data model" is silly and
unsupported by real-world evidence. The definition of XML is syntactic:
the "Infoset" is an afterthought and in any case is far indeed from
being a data model specification that a programmer could work with.
Empirical evidence: I can point to a handful of different popular
XML-in-Java APIs each of which has its own data model and each of which
works. So why would you think that there's a data model there to build
a language around?
I still don't understand why something like this would be silly.
Best regards,
Dana
