Re: [RT] resource views, error handling, pipeline debugging

[Niclas Hedhman <ni...@localbar.com>]

Stefano Mazzocchi wrote:

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

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

Ok...

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

ok.

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

Niclas

Re: [RT] resource views, error handling, pipeline debugging

[Niclas Hedhman <ni...@localbar.com>]

Not making this longer than necessary...

I am too tired to argue, and presume that your insight fulfills the majority of the needs.

The discussion about "rotations" is a bit over my head, and I strongly believe that you
have additional meaning to "rotation" based on your Italian/Latin (Greek?) background.
In a world where time can not be halted, nor can all dimensions be accurately recorded
along the time baseline, I feel your reasoning is somewhat academic, and not based on the
cruel reality.
I also contend that you can model many dimensions with math in the computer pretty easily,
but if you introduce a true time scale into that model, where an infinite continum
evolves, your model becomes very "thin", or like a string, with one dimension completely
dominating the total space (time).

In the real-world, outside the computers, daily events, sensoric equipment, phone calls,
and so forth, would require immense resources if the complete dataset including the time
dimension should be kept. And hence, your rotation of views in respect of time falls
outside the frames of practicality.

That said, I will not persue the difference in approaches, until I can present a practical
solution to anything else.

So, let's proceed with what we have and then deduce from it.

Niclas

Stefano Mazzocchi wrote:

> Niclas Hedhman wrote:
> >
> > Stefano Mazzocchi wrote:
> >
> > > 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.
> >
> > Hmmmm....
> > 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??
>
> Yes, but it's not automatic it should be merged with the "data" output
> stream.

>
>
> > If not, then I fail to see the difference from ordinary data processing.
>
> The difference is not technical but semantical.
>
> > If yes, then the problem remains, because the the main data stream must still be
> > processed as before, and sequencing is still a problem.
>
> What do you mean with "sequencing"?
>
> > > 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.
>
> Nah, this is just walking a long way in other fields to understand
> design patterns applied and try to translate them in other domains.
>
> > > 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.
> >
> > Ok...
> >
> > > 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)
>
> how blinding! :-)
>
> > > 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.
>
> Keep going, I should have told you I like walking :)
>
> > > 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.
>
> Wrong, such rotation is itself a 3D object (x,y,t) just like it's a
> time-less geometrical 3D object (x,y,z). There is no inaccuracy, you
> just changed the "base" of your vector space.
>
> > > 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.
>
> Ah, now I see your point!
>
> I agree with you. I came to the conclusion than metaevents are another
> dimension of the same view and not another view. This is why I placed
> different elements for views and error-handling in the sitemap.
>
> > > 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.
>
> I know, I know. My question is: how relevant this is? I mean: metaevents
> are useful only for pipeline debugging and tracing. So you decide "a
> priori" which one of the two dimensions you want to project on your
> view, loosing the other one. (well, logging is always saved someplace,
> this is just to speed up pipeline debugging).
>
> > > > 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),
>
> The selector is the equivalent of a polarization filter: one
> polarization gets thru, the other is blocked.
>
> > but I don't 'feel' it solves the debugging, tracing and so forth.
>
> Why not?
>
> > > > >   3) resource (what Niclas proposes)
> > > >
> > > > Not really what I proposes...
> > >
> > > No?
> >
> > I just indicated one way to do it, not necessarily the best
>
> ok
>
> > >
> > >
> > > > >   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.
>
> ok
>
> > > 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.
>
> +1
>
> > > > 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.
>
> Great vision, it completely resonnates with my feelings.
>
> > > > 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.
> >
> > ok.
> >
> > > 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.
>
> I agree, CSS is extremely powerful and sometimes perfect for the job
> where XSLT is just too heavy. On the other hand, it's very hard to
> understand good patterns of usage and the syntax is so "flat" it doesn't
> help you indicating a semantic, a metric to estimate the quality of the
> stylesheet in terms of useability, future compatibility and so forth.
>
> > > > 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'd suggest to concentrate on having more feedback from users on what we
> agreed so far instead of increasing complexity simply to test the idea
> and no apparent reason.
>
> > > 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...
>
> Good.
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------

Re: [RT] resource views, error handling, pipeline debugging

[Stefano Mazzocchi <st...@apache.org>]

Niclas Hedhman wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > 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.
> 
> Hmmmm....
> 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??

Yes, but it's not automatic it should be merged with the "data" output
stream.

> If not, then I fail to see the difference from ordinary data processing.

The difference is not technical but semantical.

> If yes, then the problem remains, because the the main data stream must still be
> processed as before, and sequencing is still a problem.

What do you mean with "sequencing"?
 
> > 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.

Nah, this is just walking a long way in other fields to understand
design patterns applied and try to translate them in other domains.
 
> > 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.
> 
> Ok...
> 
> > 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)

how blinding! :-)
 
> > 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.

Keep going, I should have told you I like walking :)
 
> > 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.

Wrong, such rotation is itself a 3D object (x,y,t) just like it's a
time-less geometrical 3D object (x,y,z). There is no inaccuracy, you
just changed the "base" of your vector space.

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

Ah, now I see your point!

I agree with you. I came to the conclusion than metaevents are another
dimension of the same view and not another view. This is why I placed
different elements for views and error-handling in the sitemap.

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

I know, I know. My question is: how relevant this is? I mean: metaevents
are useful only for pipeline debugging and tracing. So you decide "a
priori" which one of the two dimensions you want to project on your
view, loosing the other one. (well, logging is always saved someplace,
this is just to speed up pipeline debugging).
 
> > > 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), 

The selector is the equivalent of a polarization filter: one
polarization gets thru, the other is blocked.

> but I don't 'feel' it solves the debugging, tracing and so forth.

Why not?
 
> > > >   3) resource (what Niclas proposes)
> > >
> > > Not really what I proposes...
> >
> > No?
> 
> I just indicated one way to do it, not necessarily the best

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

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

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

Great vision, it completely resonnates with my feelings.
 
> > > 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.
> 
> ok.
> 
> > 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.

I agree, CSS is extremely powerful and sometimes perfect for the job
where XSLT is just too heavy. On the other hand, it's very hard to
understand good patterns of usage and the syntax is so "flat" it doesn't
help you indicating a semantic, a metric to estimate the quality of the
stylesheet in terms of useability, future compatibility and so forth.
 
> > > 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'd suggest to concentrate on having more feedback from users on what we
agreed so far instead of increasing complexity simply to test the idea
and no apparent reason.
 
> > 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...

Good.

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