On 03.Dec.2001 -- 04:29 PM, Stefano Mazzocchi wrote:
> Christian Haul wrote:
> > 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.
Sure enough. I still think it would improve readability. Anyway, it is
a big difference doing this transformation outside or automatically by
cocoon. AFAIC action-sets and resources are only a basic replacement
for such preprocessing.
> > 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.
Granted. Although I expected you to come up with @ID and @IDREF :-)
Still, we might have different opinions on "well". And it's not only
because XML is a tree, but as well because it's 1 dimensional. SVG can
handle complex graphs -- but at least I don't want to create or modify
them in vi. I think, the current sitemap does a good job, but I doubt
whether separating it in a map for states and one for transitions will
do any good.
IMHO transisions are best declared for the state they
start. Transitions that are applicable to more than one state are best
declared for a complex state which is currently handled by nesting (or
mounting) of pipelines. Defining transitions at destination states as
well would make maintenance difficult, unless a tools supports this.
What this whole RT didn't touch is, in which ways a flowmap could
serve to create a menu (like) navigation. Although I fear that is too
complex to handle :-(
> 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.
Agreed. And I think, it's not much that's missing.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
