[
Lists Home |
Date Index |
Thread Index
]
Rick,
We don't need a standard algebra for XML, we already have the
analogous of SQL for XML (XQuery), and that's enough.
Of course every implementation will have its own algebra
(there are about 30 different ones in the state of the art --
I can point you to some good ones) but we don't need a
*standard* one.
A standard algebra serves more an educational purpose then
anything else: it's not used by programmers, and not used
as such by system implementors either. It's definitely not worth
the effort to agree on one.
But I would advise you read first XQuery &comp before XL.
Best regards,
Dana
P.S. If we would only had select, project, joins and no
SQL, relational databases wouldn't have existed. Maybe
the opposite is true too, but that's less clear.
On Nov 30, 2004, at 10:51 PM, Rick Marshall wrote:
> 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
>>
>
> <rjm.vcf>--------------------------------------------------------------
> ---
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
|
