RE: Choreography Declarative/Procedural Spectrum

I think this is similar to what I was getting at when I mentioned the
charactistics of a node.
At some point, what people percieve as procedural is still truly
declarative, but it is derived
from set of domain concepts that are implemented as primitives. 
 
Example: procedural markup says move down x lines and place a string foobar.
In reality, the domain must specify what "lines" are and what happens when a
string is
placed.
 
Declarative markup (<para>foobar</para>) is "better" because it separates
information from 
the presentation domain making it more reusable. (of course, better is
relative as anyone
who has dealt with marketing people who don't like the way you present a
<para>)
 
So we can really start from both directions:
    * top down in deciding what declarative domain we want to work in and
why
    * bottom up in deciding what are node domain primatives we need and how
to declare 
        interactions with them
 
For declarative choreography, what are the benefits we are looking for? What
levels of reuse,
system independence, etc?
 
Dave

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:[email protected]]
Sent: Thursday, October 17, 2002 3:30 PM
To: [email protected]
Subject: Choreography Declarative/Procedural Spectrum



It seems to me that one of the most valuable pieces of input we are going to
be giving this WG is some sort of framework for segmenting what can be done
into a hierarchy of complexity -- so that they can avoid trying to do
everything for everybody right out of the gate.  In this spirit, would it be
useful to define some sort of "way-stations" on the Declarative/Procedural
spectrum?  I am sort of assuming that the further you get into procedural --
with multiple levels, yet -- the more complex it gets.  So would it be
possible to define a "starter set" that has value and is mostly declarative?
Then a level of procedural issues that can be layered on top of that in a
second step -- and so on?