[
Lists Home |
Date Index |
Thread Index
]
let me put all of this a different way.
when ted codd invented relational databases everyone thought it was
about getting rid of hierarchical etc databases. and it did that. but
that wasn't the point. and sometimes i think that his greatest advocates
- date and pascal - also miss the point. ted codd was a mathematician.
relational databases are a mathematical group. that's why normalisation
is important. a relational database is tables and operations that
produce tables with all the other requirements of a group. sql has
nothing to do really with relational databases except that it can
manipulate them, but it is a language - not a relational database.
that's why it has been perverted to all sorts of other non relational uses.
xml is like the tables. xslt is probably the closest to the operator bit
needed to make it a group, but as xslt can produce stuff that isn't xml
it fails.
if i was making xml 2, i'd be looking at fixing that basic problem.
here's a storage class (things like numbers etc), and here's the set of
operators that produce more "things" (valid xml documents) and make sure
they are a group(s) (identity operators etc).
then something like xslt or whatever can be a manipulative language
based on the maths of the xml model.
so here's a real challenge - what are the operators - eg + - * project
join etc (maths 101 groups are defined over operators) for xml?
xslt, ws-* etc (like sql) then become the glue from something that can
be manipulated reliably to other representations/purposes
now i have to look at xl :)
rick
Daniela Florescu wrote:
> 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
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
