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

[Frank Manola <fmanola@acm.org>]

Roger--

A few comments below.

On May 31, 2009, at 9:23 AM, Costello, Roger L. 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.

Suppose the markup is in some language I don't understand, so I can't  
tell what parts of speech the elements are, or whether they have an  
"agreed on definition".  Does this mean I won't be able to tell  
whether the document is declarative or not?

>
>
>
> 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.
>

Given some arbitrary markup (not necessarily the simple example you  
have here), how do you know someone can't associate processing  
semantics with it?

Suppose I have a reasonably complete music markup language.  From one  
point of view this is pretty declarative, since it just describes the  
notes, sequences, rhythms, etc. (e.g. consider an ordinary piece of  
sheet music).  On the other hand, it has a pretty obvious "processing  
semantics":  you play it on something, and while part of those  
"processing semantics" may be local (e.g., what you decide to play it  
on) another isn't "local" (you follow the note sequence, etc.,  
specified in the music).  So in this case your distinction between  
"declarative" and not doesn't seem all that stark.

>
> 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.
>

It's not clear this has anything to do with the distinction between  
declarative and non-declarative.  A program has a "unifying theme"  
doesn't it (e.g., the algorithm it implements)?

>
> 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?
>

This would also seem to be true of a non-declarative document  
(although perhaps not of the example you cite below;  how many  
examples of "non-declarative" documents have you looked at?).

>
> Characteristic #5
>
> User-interface forms can be created to enable users to change the  
> data.

This would also seem to be true of a non-declarative document (if I  
specified a program in XML, couldn't I change the code via a user- 
interface form?)

>
>
>   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?
>

Could you say a bit about what your goals are for making this  
distinction?

--Frank


>
>
> 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?
> _______________________________________________________________________