Christian Haul wrote:
>
> On 01.Dec.2001 -- 02:54 PM, Stefano Mazzocchi wrote:
> > Ovidiu Predescu wrote:
> > I like the concept of "continuations". Sitemaps are completely
> > declarative and for this reason they don't provide a simple way to
> > perceive the "flow" between stages.
>
> I'd like to second this oppinion, continuations look cool. OTOH will
> that scale? There are many around that don't like sessions because
> they require the server to devote memory for every session. OK, only
> *applications* would use them, so that's propably all right.
Yes. This is my other argument about turning the sitemap into a
procedural logic: all those published resources that don't need to
retain state are much easier to express with declarative languages (such
as current sitemap).
Also, I have the impression that even in complex web applications,
continuations are required only when performing a data entry that
requires subsequent screens and should not be required thruout the
entire webapp.
> > Yes, the flowmap alone would be kind of useless since it would be biased
> > toward flow and fail to describe states. Just like the sitemap describes
> > states but fails to describe transitions.
> >
> > The statemap should bring the two world together. What syntax we use to
> > express it, is not something I'm really concerned at this point.
>
> I think the sitemap as a representation of a FSM is quite OK. Once you
> start matching on other things than URIs (e.g. session attributes or
> referer header i.e. your *current* state in addition to the requested
> transition), all aspects of an FSM can be modelled.
>
> I think a Flowmap will not ease the maintenance a lot because a FSM is
> a highly complex graph and whatever you do, an XML file can only
> describe tree structures well. Hence, again, things start spreading
> around. The only solution I see, is to describe single states and all
> transitions available from that point on, depth 1. And that is exactly
> what the sitemap is today.
>
> In my opinion two things would be very cool: 1) the ability to use
> macros in sitemap i.e. abilitiy to use XSLT prior to sitemap parsing
> or (XSP would have some benifits, too, but I don't think it's worth
> the effort)
The experience of stylebook tells us that if we start down this path,
pretty soon people will know the "simplified markup" and forget the
power of the sitemap (people don't even know stylebook has a sitemap
underneath that is generated transforming the book descriptors!). Of
course, nothing stops you from using your own markup and your own
transformation to come up with the sitemap but I would be against making
it easier for users to do this automatically.
> 2) integrate some tool for FSM modelling. Most likely, (2)
> is for free if (1) is in place and we find some tool that writes XML
> FSMs.
It's wrong to state that since XML is a tree, it can't describe graphs
well. Example:
<function name="a">
<call function="a"/>
</function>
which is a tree describing a graph, once we have described what is the
behavior associated with the semantics.
XML syntax is not that different from Lisp syntax. Admittedly, A little
too many paranthesis, but even if xml is more verbose, is much more
readable (because the ending paranthesis contains the content of what is
ending, unlike Lisp).
In fact, in Lisp, you can use the following syntax
(html (head (title "Dynamic HTML page in Lisp")) (body (h1 "hello
there!")))
once you have defined a shitload of macros one for each HTML element.
I like XML syntax better because:
1) it's easier to indent it.
2) it's easier to recognize a mistake (without an editing tool, Lisp
programming is impossible since you *always* loose parenthesis
somewhere! this is why Emacs was invented :) in fact, it's written in
Lisp because RMS was a big time Lisp programmer.
3) the ending parenthesis contains context on what is ends (some people
use this even in java, as comment after the closing curly brace, for
example
void doSomething() {
....
} // doSomething()
Look at the readability of XSLT (XML based) vs. DSSSL (Lisp based) and
you get an idea of what I mean.
So, please, XML is a poor syntax for semantically-dense programming
languages as much as Lisp is.
Admittedly, semantically driven char-based syntaxes like C/C++, Java,
Python, Perl, Ruby, etc.. are much less verbose (Perl is king for this)
since they "encode" programming language semantics sometimes into single
characters (unlike Lisp and XML).
But they are generally much less self-descripting (again, Perl is king
in lack of self-descriptiveness), which results in higher maintenance
costs for the code.
At the same time, as in different Lisp dialects, it's good to minimize
the amount of semantics required to fully describe the programmatic
logic.
In this sense, XML stands to SGML as Scheme stands to Lisp (more or
less).
So, IMHO, the best goal is to try to increase sitemap semantics in order
to make it possible to describe both pipelines and flows, and let them
interact easily.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
