[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What is declarative XML? (And what's not)

  • From: Kurt Cagle <kurt.cagle@gmail.com>
  • To: "Costello, Roger L." <costello@mitre.org>
  • Date: Sun, 31 May 2009 12:01:42 -0700

Re:  What is declarative XML? (And what's not)

In my experience, declarative is typically used as a synonym for functional programming. True declarativeness basically means that you can unconditional specify the entire state of an application at any time for any initial given set of parameters.

Declarative models are internally self consistent - there are effectively no side effects that can change the underlying state of the model without such side-effects being repeatable. A spreadsheet, for instance, is usually a declarative model - even when you have parametric changes in the model, repeating the input configuration of parameters will always reproduce the same resulting spreadsheet.

Pure XQuery is a declarative language, with a couple of important caveats. If you have a static XML repository that you query against, then the resulting query result should be identical. However, there are a few XQuery functions (or extensions) that have side effects - now() and random(), for instance, where the same call to the function will result in different values. Additionally, In a non-static repository (as is typical of an XML database) especially one in which some form of XQuery Update Facility has been implemented, and where multiple entities can make changes to the database as a consequence, such systems become weakly imperative.

That's why declarative and imperative programming shouldn't be taken as an absolute so much as a relative guideline. I find increasingly that it is often more useful to talk about explicit vs. implicit models. In a system with an explicit data model, you generally have reproducibility because you can see the state changes, and as such the model bindings to its associated presentation layer becomes obvious. In this model, randomness may exist, but the randomness is a functional model in which the same seed will always produce the same sequence of results, even if the specific function is a black box.

In an implicit data model, on the other hand, not all of the parameters can be fully specified in the model. Imperative languages tend to encourage such implicit models (one of the real advantages of OOP was that it was at least a first stab in making such models explicit, though a great deal is still not fully specified). Imperative models are more complex to debug, because you have to use stochastic methods and try to employ a large enough cross section of potential use cases to determine that a given application is not likely to fail. In a declarative, or functional model, there should, in theory, be no way to actually move out of being internally consistent because the potential range of input is highly constrained - any input parameter that is invalid will invalidate the whole model, not just the specific property descriptor.

In practice, this isn't always true, in part because its possible to underspecify or incorrectly specify the underlying data model dependencies, and in part because the more complex the model, the harder it is to fully specify it, especially when the constraint space extends across multiple domains of validation. However, by staying closer to a functional model, languages usually benefit by being far easier to debug and work with.

In that regard, the XSLT program is clearly declarative - there are no formal side effects. Note that the fact that the XSLT is expressed in XML is something of a red herring - the XML representation of the XSLT follows a clearly defined schema, works within an explicit data model, and is simply a set of assertions. The XSLT program instance, however, is declarative for other reasons; you could in theory recast this in a language such as Scheme or Haskell and it would be just as valid and just as declarative (you could even use JavaScript, come to that).

Another way of thinking about it as that declarative applications can clearly be used as filters on an incoming set of data to produce output, which in turn could be used as input for a successive state description. This means that any application can be fully described as a recursive process from a primogenitor state, and the full state space can thus be described completely at any given iteration based only upon the previous state and the filter. Imperative applications no longer have this reproducibility.

At least that's my understanding - others with a decent functional programming background may be able to elucidate this more fully.

Kurt Cagle
Managing Editor

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">
       <name>Sony HT-IS100 BRAVIA Home Theater Micro System</name>
       <cost currency="USD">299.00</cost>
       <name>ASUS Eee PC 1000HE Netbook Computer</name>
       <cost currency="USD">379.00</cost>
       <name>Sony ICD-PX720 Digital Voice Recorder</name>
       <cost currency="USD">49.00</cost>


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


Do you agree with this list?

Are there other characteristics you recommend adding?

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

   <xsl:variable name="total-cost"
                 select="sum(/purchases/merchandise/cost)" />


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

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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.