cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] from linkmaps to flowmaps
Date Tue, 06 Mar 2001 14:40:39 GMT
Tagunov Anthony wrote:
> Hello, All!
> On Mon, 05 Mar 2001 13:13:41 +0100, Stefano Mazzocchi wrote:
> >Well, since links provide navigation, thus flow, many don't even see the
> >difference.
> Stefano, please excuse me for being so dumb: the difference between
> a LINK and a FLOW? LINK is general relationship and FLOW is spcific,
> navigation relationship?

A 'flow' is a concept that defines navigation. You can have GUI
applications where its flow is not implemented using hyperlinks because
there is no notion of hyperlinks for GUI applications.

A 'link' is a concept that defines "connections", the act of connecting
one resource with another.

The fact that 'hyperlinks' were implemented associating a 'flow' aspect
with the 'link' aspect and the two aspects are not easily separated for
web hypermedia, has driven people to believe that there is no
distinction between 'flow' and 'link'.

A link does *NOT* hinder navigation, it's a connection, a relationship,
a liaison... in fact, linked information can be presented 'in-place' and
some hypertext systems allow this (even DHTML if it was portable across

A regular web hyperlink "implements" 'link' *and* 'flow', thus providing
relationship and navigation.

Is this always the case? No, not always. There could be systems were an
hyperlink implements 'link' but not 'flow' (for in-place information
placement, drop-down or pop-up visual helps, or scroll-aside text
containers) and systems where the hyperlink implements 'flow' but not

This is the case with web-applications: the 'next' or 'continue'
hyperlinks implement a flow but not a direct relationship between
resources, since the division of a flow stage in different screens is
accidental, it's due to technological constraints (and it's even more
evident for non-standard clients like phones or TV-sets).

as far as the HTTP architecture is concerned, there is no distinction
between these three types of hyperlinks since all of them have to
request a URI with the same method.... but nothing prevents us from
abstracting this into higher level paradigms.

Why? well, one thing for all: dividing a 'stage' into different
'screens' should be done by the publishing system, not by hand like it's
done today!

Paul's attempt to "Fragment Extraction" go in this direction, even if
they force concern overlap since the sitemap manager has to know "how"
the artificial-URI-space is generated by the fragment extractor

The result is admittely very cool, but it's a hack and cannot be used to
generate subsequent WAP decks out of big pages unless lots of sitemap
tricks are used and bunch of aspects crosscut across generators,
transformers and sitemap, which clearly ruins the whole SoC picture.

Sorry if I divagated a little, but I've been thinking about this for the
last two days. :)
> >So, what is a flowmap?
> <snip/>
> >So, let's see, let's take something like
> >         identification
> >               ^
> >               |
> >               v
> > (enter) ---> home ---> (exit)
> >             ...
> Idea: they've got a rether complicated flow models at UML
> (if i understand the subject correctly they are closely
> connected with state machine models)
> Maybe it would be worth looking into their OMG model
> of UML (if i understand correctly they have a meta meta
> model to desribe meta models. in this language
> UML is described as a metamodel. Following this
> meta model we can build models of applications.
> This metamodel describes, in my understanding, how
> application model can be put into data structures rather
> how this should be visually presented by a CASE tool.)
> The models expressed in UML are, as far as i know
> exportable in some unified format for interexchange
> between CASE tools. This format is XML language,
> by the way!

Yeah, it might be worth looking into that.
> So, maybe we could take OMG UML metamodel for
> describing state machines and workflow
> (their statechart and workflow diagrams),
> take a subset of it (we naturally do not need
> all!) and make use of it in one of the
> following two ways:
> 1) make our own xml language for building sitemaps
>     that would be different from the UML interexchange
>     format (smth inspired by the sitemaps), BUT
>     SUBSET SEMANTICS actually, only in a different
>     syntax.
> 2) explore if we could use the OMG UML interexchage
>     format directly
> In the  case 2) CASE modelling instruments could
> be applied to designing flowmaps direclty,
> In the  case 1) our flowmaps could probably
> be convertable either to UML interexchange format
> to be viewed by CASE tools, but maybe also back
> And even we find OMG UML model directly unusable
> we still could find in their models ground to inspire
> building of our flowmaps.
> Pro-s: of this approach:
>        --it is better to use what already has
>        been developed for this purpose
>        --hypothetical ability to use CASE tools
> Conra-s:
>        --much effort is needed to get to a clear
>        understanding of OMG models and how
>        much applicable they are

Good suggestion, unfortunately I don't have the time to follow on this
at the moment... I just wanted to drop in my RT to seed discussions.
(see my next email).

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message