cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Falko Braeutigam <fa...@smb-tec.com>
Subject Re: [RT] from linkmaps to flowmaps
Date Tue, 06 Mar 2001 18:39:21 GMT
On Tue, 06 Mar 2001, you wrote:
> 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
> browsers!).
> 
> 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
> 'link'.
> 
> 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!

It shouldn't be done by hand, this one is for sure. But I'm not sure if it
should/can be done by the publishing system. The 'stage' of an application
often is related to the stage of the underlying database-EJB-whatever system.
The stage of a database is represented and handled via transactions. AFAIK
today Coccon has no notion to handle transactions of the underlying data source
(global transaction, 2-phase-commit, etc.). Therefore it cannot be
responsible to divide (application stages into different screens. Am I wrong?


Falko

> 
> 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
> transformer.
> 
> 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 slashdot.org:
> > >         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
> >     THAT WOULD EXPRESS THE OMG UML
> >     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.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com


Mime
View raw message