Re: [xml-dev] What is declarative XML? (And what's not)

[Dimitre Novatchev <dnovatchev@gmail.com>]

Any expression that does not have side effects is "declarative".

This does not prevent such expression (whenever it has free variables)
to be interpreted/evaluated as part of a "computation".

We may speak about "declarative programming", and it is mainly about
the programming style of constructing "executable definitions".

An example: here is the definition (in XPath) of the maximum prime
factor of a natural number $pNum:


    "if(f:isPrime($pNum))
       then $pNum
       else
         for $vEnd in xs:integer(floor(f:sqrt($pNum, 0.1E0))),
              $vDiv1 in (2 to $vEnd)[$pNum mod . = 0][1],
              $vDiv2 in $pNum idiv $vDiv1
           return
             max((f:maxPrimeFactor($vDiv1),f:maxPrimeFactor($vDiv2)))

To make this definition executable, just wrap it in an <xsl:function> :

 <xsl:function name="f:maxPrimeFactor" as="xs:integer">
   <xsl:param name="pNum" as="xs:integer"/>

   <xsl:sequence select=
    "if(f:isPrime($pNum))
       then $pNum
       else
         for $vEnd in xs:integer(floor(f:sqrt($pNum, 0.1E0))),
             $vDiv1 in (2 to $vEnd)[$pNum mod . = 0][1],
             $vDiv2 in $pNum idiv $vDiv1
           return
             max((f:maxPrimeFactor($vDiv1),f:maxPrimeFactor($vDiv2)))
    "/>


And then evaluate it like this:

   <xsl:sequence select="f:maxPrimeFactor(600851475143)"/>


which will produce:

6857


We may also note that there may be more than one definition describing
the same thing and  that a given executable definition will be "more
efficient" than another one if it is much more specific than rather
general. To put it another way, the more knowledge we have about
something, the more efficient an executable definition we will be able
to construct.



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play


On Sun, May 31, 2009 at 6:23 AM, Costello, Roger L. <costello@mitre.org> wrote:
>
> Hi Folks,
>
> Just because a document is expressed using XML does not mean it's declarative. Non-declarative, procedural logic can be expressed as readily in XML as in FORTRAN.
>
> So, what are the distinguishing characteristics of declarative XML documents?
>
> Below I have taken a stab at answering this question. I am interested in hearing your thoughts.  /Roger
>
>
> EXAMPLE OF A DECLARATIVE XML DOCUMENT ----------------------------------------------------------
> <purchases date="2009-05">
>    <merchandise>
>        <name>Sony HT-IS100 BRAVIA Home Theater Micro System</name>
>        <cost currency="USD">299.00</cost>
>    </merchandise>
>    <merchandise>
>        <name>ASUS Eee PC 1000HE Netbook Computer</name>
>        <cost currency="USD">379.00</cost>
>    </merchandise>
>    <merchandise>
>        <name>Sony ICD-PX720 Digital Voice Recorder</name>
>        <cost currency="USD">49.00</cost>
>    </merchandise>
> </purchases>
> ----------------------------------------------------------
>
>
> DISTINGUISHING CHARACTERISTICS OF DECLARATIVE XML DOCUMENTS
>
> Characteristic #1
>
> The markup (elements, attributes) are nouns or noun phrases with an agreed upon definition.
>
>   <purchases>, <merchandise>, <name>, <cost>,
>   and the "currency" attribute are all nouns.
>
>
> Characteristic #2
>
> There are no processing semantics associated with the markup. However, processing semantics may be added *locally* by users.
>
>    The <merchandise> element has no semantics beyond
>    the dictionary meaning of the noun "merchandise."
>    Users are free to layer on their own local
>    processing semantics. For example, one user may
>    store the contents of <merchandise> into a database.
>    Another user may retrieve the value of <name> and
>    display it on a screen.
>
>
> Characteristic #3
>
> There is a unifying theme for the data, i.e. the data falls within a single domain.
>
>   These values - 2009-05, Sony HT-IS100 BRAVIA Home Theater
>   Micro System, $299 USD - are all in the domain of buying
>   and selling merchandise.
>
>
> Characteristic #4
>
> Domain-specific questions can be asked of the document.
>
>   For the above document you can ask:
>     - Which merchandise cost the most?
>     - How many items were purchased?
>     - What's the total cost of all the merchandise?
>     - When was the merchandise purchased?
>
>
> Characteristic #5
>
> User-interface forms can be created to enable users to change the data.
>
>   For the above document you can create a form that lets users:
>     - Change the purchase date
>     - Add new merchandise
>     - Delete merchandise
>     - Modify a merchandise item
>
>
> QUESTIONS
>
> Do you agree with this list?
>
> Are there other characteristics you recommend adding?
>
>
>
> EXAMPLE OF AN XML DOCUMENT THAT IS *NOT* DECLARATIVE
> ----------------------------------------------------------
> <?xml version="1.0"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
>                version="2.0">
>
>    <xsl:variable name="total-cost"
>                  select="sum(/purchases/merchandise/cost)" />
>
> </xsl:stylesheet>
> ----------------------------------------------------------
>
> Let's see how well the stylesheet document satisfies the characteristics:
>
> Characteristic #1
>
> The markup (elements, attributes) are nouns or noun phrases with an agreed upon definition.
>
>   The "select" attribute is a verb.
>
>
> Characteristic #2
>
> There are no processing semantics associated with the markup. However, processing semantics may be added *locally* by users.
>
>    The markup has inherent processing semantics. For
>    example, <xsl:variable> *creates* a new variable.
>
>
> Characteristic #3
>
> There is a unifying theme for the data, i.e. the data falls within a single domain.
>
>   The data - 2.0, total-cost, sum(/purchases/merchandise/cost) -
>   is disjointed: '2.0' is in the domain of XSLT, 'total-cost'
>   is in the domain of buying and selling merchandise, and
>   'sum(/purchases/merchandise/cost)' is in the domain of
>   XPath.
>
>
> Characteristic #4
>
> Domain-specific questions can be asked of the document.
>
>   There are no domain-specific questions that can be
>   reasonably asked.
>
>
> Characteristic #5
>
> User-interface forms can be created to enable users to change the data.
>
>   There are no domain-specific values that can be changed.
>
>
> QUESTION
>
> Do you agree that this stylesheet document is not a declarative XML document?
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>