cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] resource views, error handling, pipeline debugging
Date Fri, 30 Jun 2000 12:29:10 GMT
Niclas Hedhman wrote:

> > > It is easy to see/define how a stream is split, but the hard part is how is
> > > 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.

> How about it is added at the end of a document if a particular
> parameter is set (debug) otherwise not.

This is how I thought about it since the beginning.... using the EMW
(electro-magnetic waves), I pictured data and metadata as polarization
planes. This requires you to have the ability to use a bidimensional
output stream... which is not always the case.

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.

The most promising ones are QAM (quadrature amplitude modulation) and
WDM (wavelenght division multiplexing), so I tried to elaborate their
"http-equivalent".

I came to the conclusion that QAM is (roughly) equivalent to XML
namespaces, while WDM is (roughly) equivalent to HTTP actions. Since our
problem is transmitting something that is not marked-up, the QAM
solution must be eliminated.

So I concentrated on HTTP actions, but actions are embedded into the
browsers, you can't select from the outside the action to perform on the
link when you click it, nor does the HTTP URI has the ability to control
this.

So I had the idea of incorporating the idea of "views" as hyperplane
projections (an hyperplane is the multi-dimensional equivalent of a
plane... for example, a 3D space is an hyperplane of a 4D space-time
continuum, just like a 2d hyperplane is a regular plane in a 3D space...
).

Try to picture your web resource in a multidimensional environment where
each "axis" denotes a particular "aspect" of that resource: the
"browsable" axix, the "editable" axis, the "semantic" axis, the
"hyperlinks" axis and so on. Note: sometimes these "aspects" "crosscut"
(using AOP terminology)... in linear algebra, this means that these axis
don't form a "base" since some of them are a linear combination of some
others... in short, some views depend on information found in more than
one axis, in geometry this means that you are projecting on a rotated
plane.

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.

(here, it's nice to picture XSLT as the equivalent of matrix operations
for linear algebra)

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

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

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.

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)

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.

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.

> Then, when I started to look into the details of how this would work, there is
> another complex matter.

No shit :)
 
> The sequence of execution in a SAX based environment is not Pipelined per se. In
> fact, there is not much you can say about the order of execution of everything.
> Some processors in the pipeline receives a tag, and calls the processor
> immediately down the line with the same tag, other will collect a whole bunch of
> nodes, then do some processing, followed by spitting out hundreds of SAX events.
> And so on.

Correct.
 
> 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
            
> Let's say it is very foggy, and hours of thinking has not made it any clearer,
> in fact the opposite.

I hope I don't make it even more foggy :-)
 
> > > Not good to use "cocoon:". I have tried to use : in parameters before, and
> > > you end up with a lot of misunderstanding in many browsers and URL
> > > decoders. For it to work you then have to put in "cocoon%3A" which looks
> > > "bad".
> >
> > Damn. Any suggestion?
> 
> I basically agree with the dash (-) that you are using below.

Ok
 
> > > And if so, could not all you are trying to accomplish, already be done by
> > > matchers?
> > > <map:match pattern="*/complex-semantic">
> > >
> > > whereby the $1 is passed into the Generator.
> >
> > Yes, yes, you are totally right. The "view" element is completely
> > redundant, it doesn't add functionality you didn't have with
> > matchers.... but it gives you a way to focus more on it.
> >
> > Call it syntax sugar. Call it "Stefano would like you to see resources
> > as multidimensional objects with different views as orthogonal
> > projections".
> >
> > In fact, both filters and generators are "xml producers" but we
> > introduced the notion of them to simplify and crystalize a vision of
> > them.
> >
> > I'm trying to do the same with these views.
> >
> > Let us suppose it's not.
> >
> > How would you generate your site for off-line viewing? Cocoon offline
> > mode requires you to give it xlinking information in order to be able to
> > browse the site. And all URIs must follow a very specific pattern,
> > something like (this is pseudosyntax, just as an example)
> >
> >  <match uri="a/b">
> >   ...
> >  </match>
> >
> >  <match uri="a/b/off-line">
> >   ...
> >  </match>
> >
> > and you must do this for all of your matchers since rarely the xlinked
> > view and the normal view are the same and require the same pipeline to
> > be generated.
> >
> > So, by creating the "view" notion and the view/viewer elements, I wanted
> > to be able to reduce verbosity by introducing recurring concepts, also
> > avoiding errors due to wrong use of URI spaces.
> >
> > <view> defines a contract between users and URI spaces.
> 
> <snip>
> 
> > So, given HTTP, we have to modify the URI. A URI is composed by
> >
> >  http://host:port/path/resource?query
> >
> >   3) resource (what Niclas proposes)
> 
> Not really what I proposes...

No?
 
> >   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!!!!

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.
 
> > Admittedly, 3 has some advantages since it's independent on the HTTP
> > action and can be safely included in links, but also disadvantages since
> > it could create naming conflicts.
> 
> The naming conflicts would be equivalent, and method 4 is less so, due to a more
> limited "namespace", which could be introduced in method 3 as well,
> /path/resource/cocoon-view/tracing, and the corresponding
> pattern="*/cocoon-view/tracing"
> 
> The whole exercise as I see it is two fold;
> a) Reduction of syntax (verbosity) to clarify for the admin what the purpose of
> the construct is for.

yes

> 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.
 
> 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.

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.

Let's look at XSLT: <if> and <choose> are functionally equivalent, is it
good there is such difference? but also, they could have added <script>
capabilities and allow any scripting language to be used instead?

While the first question is mostly subjective and driven by esthetic
reasons, the second is important: many people think XSLT sucks just
because of this unnecessary overlap. I believe the exact opposite.

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.
 
> 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 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?
 
> > >(Stefano is not Mohammed - Why go to the mountain, when
> > > you can turn it... :o)
> >
> > I know somebody would have said that, I just wanted to see who was the
> > first one :)
> >
> > I guess the mountain twisting idea shows my egocentricy, doesn't it? :)
> 
> I tell you what.... It is easier to influence you than the mountain, that is for
> sure. Not sticking to principals, just for the sake of it, like mountains does.

I consider this a very nice compliment. I deeply thank you for this. :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message