michael et al,
as i have often stated here. my interest in xml is to extend the
declarative model we use for databases (which is progressing, albeit a
bit slower than i'd like).
all the things you and others mention about scalability, stability, etc
work remarkably well with declarative style programming. and it's very
efficient.
however it has it's limits. it's like the difference between a picture
and movie. as long as time is not part of the equation, declarative
works well. but as soon as a number of operations must be sequenced,
then you need some sort of glue to join the various declarative bits
together. the difference if you like between an order entry program
(which can be delared declaratively) and an order processing work flow -
which uses order entry as one of it's components along with invoicing,
picking, procurement, etc.
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)
personally i distinguish the two approaches on the existence of
syntactic elements. looping in particular, and branching to a lesser
extent imply procedural; looping effects and branching effects without
explicit syntax imply declarative.
rick
Michael Champion wrote:
>On Tue, 30 Nov 2004 16:16:49 -0800, Dare Obasanjo <> wrote:
>
>
>>>-----Original Message-----
>>>
>>>
>
>
>
>
>>One of the things I've found interesting about discussions with the
>>RDF/Semantic Web crowd is that many of them fail to see that moving to
>>ontologies and the like basically is swapping one mapping mechanism
>>(e.g. transformations using XSLT or regular code in your favorite OOP
>>language) for another (e.g. creating ontolgies using technologies like
>>OWL or DAML+OIL). At the end of the day one still has to transform
>>format X to format Y to make sense of it whether this mapping is done
>>with XSLT or with OWL is to me incidental. However the Semantic Web
>>related mapping technologies don't allow for the kind of complex and
>>messy mappings that occur in the real world.
>>
>>
>
>
>This is one of the many things I just don't grok about the world. So
>much effort is spent on removing the necessity to write procedural
>code! For whatever reason I find it easier to think in terms of
>sequences of operations to do something rather than to think in terms
>of the abstract definition of what is to be done. But maybe I'm weird.
>
>This motivated me to Google for "declarative procedural" to refresh my
>memory on what the theoretical advantages of the declarative approach
>are. Oddly enough, hit number 3 is a post from an xml-dev thread 4
>years ago, which it appears that I started
>http://lists.xml.org/archives/xml-dev/200011/msg00059.html
>(Actually it was Paul Tchistopolskii's response that got the high page
>rank - http://lists.xml.org/archives/xml-dev/200011/msg00068.html)
>
>That thread is pretty interesting reading ... It did establish to my
>satisfaction that XSLT is not really "declarative", but I'm pretty
>sure the approach that Dare and I are talking about of creating
>ontologies that would then be used by some tool to generate the
>transformation would be a pure declaratie approach.
>
>But back to the issue of the advantages of a declarative approach:
>They seem to be, in theory anyway, from what I learned re-reading the
>old thread:
>
>- procedural approaches don't scale well; think of how much better SQL
>(or XQuery!) DBMS work than the old hierarchical or CODASYL navigation
>model did. A more modern analogy would be the difference between
>using XPath (quasi-declarative) vs raw DOM operations (procedural) to
>search an XML document for some pattern.
>
>- Ordinary mortals can use GUI tools to declare relationships (e.g CSS
>stylesheets); nobody has really been able to automate the hard part of
>procedural programming, and a relatively small percentage of people
>seem to be comfortable thinking that way.
>
>- The declarative approach is more amenable to parallelization, e.g. a
>PDF (declarative) formatter could process each page in a separate
>process whereas a PostScript program (procedural) could not because it
>has to run from the beginning to setup the necessary state for a given
>page.
>
>- Overall declarative approaches allow complexity to be managed -- at
>least within some coherent domain -- because the poor humans just deal
>with defining concepts and relationships one at a time, and the more
>patient machines plow through all the implications.
>
>So, do these theoretical advantages of the semantic web approach to
>transformation over just writing code in your favorite OOP language
>actually hold up in practice? Or is it just a matter of transferring
>the messy grunt work from somebody called a "software engineer" to
>somebody called an "ontology engineer"?
>
>-----------------------------------------------------------------
>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>
>
>
>
