cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [RT] resource views, error handling, pipeline debugging
Date Sat, 01 Jul 2000 07:22:24 GMT
Stefano Mazzocchi wrote:

> Niclas Hedhman wrote:
> > > > It is easy to see/define how a stream is split, but the hard part is how
> > > > it joined back?
> > > > And even worse, how is this detailed in the Sitemap??
> > >
> > > :-? Sorry, I don't understand you here.
> >
> > My issue right now is, where does the MetaData stream end up??
> On another view.

Then I lost you again.
I thought the MetaData stream was to accompany the Data stream with additional
information, such as logging data, tracing and other information directly coupled to
the processing of the main Data stream, No??
If not, then I fail to see the difference from ordinary data processing.
If yes, then the problem remains, because the the main data stream must still be
processed as before, and sequencing is still a problem.

> Then I went over all the optical modulation techniques used to transit
> data as photons inside optical fibers (remember: this is what my day-job
> is supposed to be).... and I came to the conclusion that "merging" the
> two polarization planes is just one of the possible alternatives.

I think you need to see a doctor :o)  Lost it completely...
Talk about applying a "Golden Hammer" far outside the problem domain.

> Example: the "hyperlink" view contains information about hyperlinks
> *only*.... but "browsable" contains both "semantics", "content",
> "style", "hyperlinks", so "browsable" is not part of the base for this
> solution space but it's formed with the combination of other "aspects"
> of the resource.


> So, when you are "requesting" a resource, you are "projecting" the
> n-dimensional resource onto your m-dimensional window (the browser)
> where n <= m.

I do?? I thought my window is 2D only ;o)

> For HTML, n = m. This is why there was no notion of this
> "hyperprojection".

Right ?!?

> For XML, on the other hand, we have a technology that allows us to
> separate the concerns on orthogonal planes, thus n <= m. If (n < m) we
> are projecting and we end up loosing some information.

Ok, so far I follow. But fail to see the relevance.

> The idea reflects obvious geometrical behaviors: when you are projecting
> a 3D space on a 2D view, you must "rotate" it to understand it's 3D
> geometry. In fact, human visions indicates that it's enough to have 2 2D
> snapshots from two different points to "estimate" the third dimension.
> (stereography and psycoacustics are another of my hobbies)

Correct (sort of). But also don't forget that in the time-space equilibrium, time can
not be neglected and in the case of your rotation (opposed to your simultanous
snapshots) will take place in the time dimension. You then introduce the "inaccuracy"
to your dimensions, if any of the planes has changed over time.

> So, this (apparently complex) reasoning brought me to this: I must have
> a way to "rotate" my browser view so that I grasp the multi-dimensional
> shape of the requested resource. Most of the time, the "normal" view is
> the most useful one, but in some situations other views might be even
> more important.

The Metadata stream for me has absolutely nothing to do with views, and perhaps
that's where our imaginations part. I get the feeling that the Metadata streams are
somewhat an infrastructure for delivering views, in your model. Fine, but then there
are hardly any difference between the data and metadata stream. Or?

I had the notion that the metadata stream is to be delivered on the same time plane.
And having a destination that is or is not equal to the data destination.

> For example, semantic crawlers might ask for "semantic view" of a
> resource, where they obtain the semantic network used in that resource.
> Or they could ask for the "schema view", or the "hyperlink view" and so
> on. Humans might ask for "normal" view if they want to simply browse the
> resource, or "debug view" if they want to know what happened when the
> resource was created (timing, caching, tracing, logs, etc...), or
> "content edit view" if they want to change its content or "style edit
> view" if they want to change the style and so forth.

But how do you achieve this is real dynamic content?? Due to the time-factor, tracing
and debugging can not be reproduced, which means it must be stored from the previous
execution of the normal data stream, which involves an incredible headache of storing
a lot of irrelevant data.

> > The MetaData event stream will be something similar, but how would that stream
> > synchronize with the Data event stream? The XSLT processor have no clue when
> > the Xalan holds SAX events.
> When the request comes, Cocoon will know what "view" was requested and
> drive the sitemap accordingly.
> This basically means: Cocoon switches the servlet output stream to the
> output of the serializer connected to the meta-event handlers that come
> from the pipeline.
>   request -> g -> f -> s -------------->o
>              |    |    |                 \
>              |    |    |                  o---> response
>              v    v    v
>              +----+----+--> f -> s ---->o
>                                           ^
>                                           |
>                                     view selector

I understand your approach (although can't see the connection with optical
modulation), but I don't 'feel' it solves the debugging, tracing and so forth.

> > >   3) resource (what Niclas proposes)
> >
> > Not really what I proposes...
> No?

I just indicated one way to do it, not necessarily the best

> > >   4) query (what I proposed)
> > >
> > >      path/resource -> normal view
> > >      path/resource?cocoon-view="tracing" -> tracing view
> > >
> > > So the choice is between 3 and 4.
> >
> > but again, <map:match pattern="*?cocoon-view=tracing">
> > is then the same thing??? (presuming now that ? and = is not part of regexp.)
> > And what you are trying to achieve is syntax reduction.
> Niclas, the point is that I want to AVOID having to write this into
> matchers!!!!

I KNOW, and I don't oppose it. It was a matter of reasoning myself through the pro's
and con's.

> So, to avoid having to write it, we must make it "implicit" and we must
> create a design pattern for it. Here we are trying to decide which one
> is the best design pattern to encode a view into a URI.

3 choices;
a)  Extension to the path.
b) cocoon-view parameter
c) any parameter indicated by a configuration property.

I vote for b.

> > b) Introduction of a 'notion' or 'concept' that otherwise would be
> > recommendations. By introducing the 'feature' straight into the syntax, one will
> > highlight the use.
> Exactly. I'm very afraid of people "missing" the notion of views
> entirely. You could use OOP paradigms even in C if you were a good
> programmer (Apache modules, are, in fact, OOP), but creating a syntax
> for it forces you to adapt to that way of thinking.... which, sometimes,
> if the thinking is smart enough, it's not a limitation, but rather a
> power increase.

I agree. Although the anarchy is the ultimate level of freedom, people are not wise
enough to live with rules and guidelines. It is impossible for everyone to realize
what is best for oneself and for a larger community. We are now touching the core
difference between humans and other animals. We teach each other, rather than
everybody do their own research of every aspect of life.

> > Now, this has led me into another deduction. If the 'view' concept can be
> > achieved with the existing (interesting concept - "existing" in future tense)
> > matching proposal, could then this 'extension' be pluggable into the sitemap
> > specification? (Smells golden hammer, I know).
> I know, I know.... don't tell me, I went so far down this direction that
> I had to clean my whiteboard and start over.
> The "redutio ad unum" design pattern (which I just made up, so be
> careful) indicates that if you make a layer functionally complete and
> the ability to extend it, you cover up all space.

And what's wrong with that? Adding too much complexity?

> But on the other hand, the "multiple thin layers of glass reflect"
> design pattern (which I just made up as well), indicate that you might
> loose functionality if you require many levels of extentions to achieve
> some very common functionality.


> This is why I do agree that <view> doesn't add any new functionality,
> but adds a great deal of new "semantic" content to the sitemap and since
> languages are for humans, not for machines, "semantics" are very
> important and must not be underestimated.

Agree wholeheartedly.
Any HTML/CSS coder, I think, has been through the agony of not using 'semantic'
capabilities of CSS, such as using the rendering properties (of the initial spec) as
IDs, instead of using IDs based on content. And that 3 months later, there are
changes made to the rendering properties, and a lot of work has to be redone instead
of changing a couple of stylesheets.

> > But assume for a second that each tag in the sitemap is handled by a component
> > defined in the cocoon.xml (or actually in a separate
> > sitemap-config) configuration, it would allow for interesting possibilities of
> > the future. The drawback?? I don't know at this moment.
> Sitemap extentions like XSLT-extentions. Hmmmm, smells like FS at this
> point...

I know, but I also believe that that the difference in the initial implementation is
close to none, and hence can be introduced (non-supported at first), for experimental
use further down the line.

> I will consider the sitemap finished as soon as a good model for views
> is introduced. I'm working on it right now. As soon as this is done,
> we'll vote to "finalize" the sitemap WD and we'll move to
> implementation. (Giacomo is already working on it).
> When implementation is done, we'll make the first alpha release and
> people will have real-life feedback. At that time, we'll reconsider the
> notion of sitemap extentions, but not before.
> is this plan ok with you people?

Have anyone ever been opposing implementations??
Of course not...


View raw message