xml-dev - Re: Procedural vs Declarative XML transformation approaches (fwd)

["Clark C. Evans" <cce@clarkevans.com>]

I see the distinction between Procedural vs Declarative as
an abstraction level.  A declarative syntax describes, in
abstract terms, the output to be generated given a particular
input.  When programming a procedural program, I believe that
I have in the back of my head the declarative requirements.

Therefore, I believe this is a matter of the approprate
abstraction, which my be more tied to the maturity of
the programming environment rather than anything else.
Certainly starting with a declarative syntax may be
"slow", but in the long term, it allows for multiple
methods to store and minipulate the information without
specifyig how this storage and minipulation is performed.

> It doesn't seem like it to me, since transformations 
> are typically defined on a real chunk of XML, not an 
> abstract set of criteria.

It depends, if the "real chunk of XML" is not stored
sequentially as the corresponding text would be, then
any declarative syntax is an abstract set of criteria.

As XML storage/minipulation systems gain some of the
complexities of modern relational databases, a level of
abstaction between the applications programmer and the 
implementation will become necessary -- if only to shield
the programmer from changes in underlying storage/processing
techniques.

> Second, I believe it is an article of faith that the archetypical
> *users* of  Web technology (webmasters, site designers, page authors)
> are more comfortable with concepts that have the look and feel of
> declarative "stylesheets" than of those that have the look and feel of
> "programs". Right?

I think so.  It is a higher level of abstraction.

>  Does this concept scale to XML->XML transformation as well as
> display? Is this still true now that Javascript (oops, sorry, 
> ECMA 262) and Visual Basic, PowerBuilder, etc. have been pervasive 
> for at least 5 years in the world of web site builders?

What is interesting, is that Powerbuilder is more declarative
than procedural.  One specifies the query for a particular
data table and then attaches it to a particular grid.  
Nothing procedural in your typical "Hello World" powerbuilder
program.

> Also, I guess I should ask the meta-question -- is the
> declarative-procedural distinction still meaningful, or am I just stuck in
> the world of 1980's AI when this was a hot topic? (I guess an even nastier
> metaquestion is whether this also applies to validation as well as
> transformation ... I've heard a number of assertions that in the "real
> world", most XML users just write procedural code to validate content
> models, data types, and business rules all at once, and are not exactly
> waiting with bated breath for any of the declarative schema languages ...
> but I digress).

I think that in emerging situations, where the
appropriate abstractions have not been discovered
(or successfully communicated to the user communtity),
then procedural descriptions probably work better.

And, not to contradict myself, but my first understanding
of SQL came from a detailed description translating
the syntax into a procedure.  Once the translation 
from the declarative syntax into a generic procedure
was understood, I was more than happy to use the
declarative syntax.

In short, the declarative syntax acts as an 
abstraction barrier allowing far more implementation
permutations than a procedural library.

> My suspicion is that the different approaches both are appropriate to
> certain audiences under certain conditions -- I want to understand those
> conditions better, not re-start any religious wars.  Thanks in advance for
> any help.

Correct.  I think the less mature the product, the
more procedural the descriptions must be untill 
enough concensus grows in the community to allow
a declarative description.

But, perhaps I have it exactly backwards...  *smirk*

Best,

Clark