You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/06/28 16:37:21 UTC
[RT] resource views, error handling, pipeline debugging
this collection of RT follows the precedent and tries to give a coherent
and abstract view of the problems associated with what the title lists,
things that we are currently missing in the pipeline or not properly
formalized.
------------------ o -------------
Pipeline revised
----------------
I recently came to the conclusion our pipe model must be enhanced. The
pipe currently passes SAX events. These are data events.
I want to add a metaevents pipeline, sort of a logging/tracing pipeline
where the components throw everything that is related to event
generation and not event payload.
Example of this are:
- pipeline tracing (knowing what's going on, XSLT messages, FOP page
generation output, pipeline timings, etc...)
- error reporting (xml non-wellformed, exception inside a component,
exception inside a server page)
So, every component is given access to the stream of events of the next
component, plus the orthogonal stream of pipeline metaevents. The
implementation of this metaevent stream is not semantic abstract like
SAX but its semantic specific (like any logging class).
Something like
public interface PipelineLogger extends Generator {
public void startPipeline();
public void endPipeline();
public void trace(Component origin, String message);
public void error(Component origin, String message, Exception e);
...
}
This doesn't change the shape of the pipeline, but since PipelineLogger
extends Generator, it is possible to use the "tracing" results of a
pipeline, XML-ize them and feed them thru another pipeline for
presentation.
This solves the issue of error handling with multiple user agents. The
pipeline as a whole becomes a generator for another pipeline.
Resource views
--------------
A "view" is a different way to look at a resource. In fact, the above
metapipeline is a different way to look at the resource generated by the
pipeline.
Another possible view is the load statistics for that resource.
Another possible view is the semantic model contained in the resource.
Another one is the xlink information.
And so on...
I'm sure there will be many others in the future.
The concept is clear: there are different "aspects" of the same resource
and we want to be able to concentrate on each one of them separately and
be able to request them independently. They are all part of the same
resource.
Views are the abstract equivalent of orthogonal projection. They are
sometimes called hyperslices (or "projections on hyperplanes").
A resource is almost always multi-dimensional. For example, XML adds
another dimension to UNICODE (markup), namespaces add infinite
dimensions to XML (independently nestable markup). But
multi-dimensionality come not only from its components, but must be
evaluated at runtime (like tracing, runtime errors or resource
statistics).
HTTP includes a very procedural idea of "views" as "actions" but since
the http URI doesn't allow you to overrule the action (it might break
operation), it cannot be considered a real "view" (changing view of a
resource shouldn't break operation of that resource).
So, HTTP is not powerful enough to stand our multi-dimensional browsing
experience (maybe BXXP, I still have to find out), but we have to use
HTTP so we much "hack" around its limitations.
How?
Well, with a particular request parameter
http://myhost/myURI/resource?cocoon:view="xxx"
where all "cocoon:*" names are reserved for future use. It's an XML-ish
hack. but it works and it's easy to parse and easy to read and easy to
edit by hand.
If no "cocoon:view" request parameter is found, a request for the
"normal" view of the resource is asked.
NOTE: views should be distinguished from styles or format types. I could
ask the "semantic" view of a resource and receive a PDF document, a JPG
graph or an RDF list.
How does this fit into the sitemap?
-----------------------------------
that's the key question and I don't have a final answer... anyway...
A "view" is a semi-pipeline and doesn't have serialization capabilities
(this is due to the fact that "views" and "format" are independent
things.
So
<view type="linking">
<generator ...>
<filter ...>
</view>
while a "viewer" is a "serializer" on steroids
<viewer type="linking">
<filter ...>
<filter ...>
<serializer ...
</viewer>
So, for example a pipeline like
g -> f1 -> f2 -> f3 -> s
can be refactored as
[ g ] [ f1 , f2 , f3 , s ]
[ g , f1 ] [ f2 , f3 , s ]
[ g , f1 , f2 ] [ f3 , s ]
[ g , f1 , f2 , f3 ] [ s ]
Sort of pipeline diagonalization.
Why this? well, mainly to reduce verbosity, the components of a view
might change, but the component of a viewer might not.
For example, for off-line capabilities, the "view" might be different
for each resource, while the "viewer" could be the same for all the
site.
<viewer type="xlink">
<filter type="xslt" src="./xslt/remove_all_but_xlink.xsl"/>
<serializer type="xml"/>
</viewer>
So, in the pipeline, you should be able to define viewers as declarative
"subpipelines" and introduce event deviation with <view> elements.
For example, for the sitemap,
<map:match pattern="complex-semantics/*">
<map:view type="semantic">
<map:generate src="./complex-semantics/{1}"/>
</map:view>
<map:filter src="./style/tohtml.xsl"/>
<map:serialize type="html"/>
</map:match>
<map:viewer type="semantic">
<map:filter src="./stylesheet/rdf-izer.xsl"/>
<map:filter src="./stylesheet/xlink-izer.xsl"/>
<map:serializer type="xml"/>
</map:viewer>
then we have
http://myhost/complex-semancics/hello
will return the "hello" resource as HTML, while
http://myhost/complex-semantics/hello?cocoon:view="semantic"
will return the "hello" resource as XML page with xlink and RDF
information. (the example is stupid, please interpolate a little by
yourself).
This pattern is mostly equivalent to called templates for XSLT.
Error handing and view switching
--------------------------------
Views cannot only be controlled by the request parameters, but also by
the sitemap itself. If a fatal error occurs and the pipeline cannot
process it, the "normal" resource view is changed to the tracing one.
While it's easy to identify a "viewer" when you are calling a "view"
specifically (their "type" attributes are equal), how do you know which
"viewer" your tracing view is associated to?
NOTE: PipelineTracer is not exactly a "view" since it may include
serializers, so the <view> element cannot be used here.
The solution I find the best (but I'm not sure and I welcome your ideas
on this) is creating <pipeline> containers for <matchers>, each with a
different "viewer" mapping for their PipelineTracer.
So the sitemap root becomes
<sitemap>
<components>
</components>
<resources>
</resources>
<viewers>
</viewers>
(<pipeline></pipeline>)+
</sitemap>
where
<pipeline viewer="xxx">
(<match></match>)+
</pipeline>
type vs. name
--------------
A small detail, but could create lots of confusion: we are using both
"type" and "name" attributes to indicate IDREFs, I think we should use
only one flavor. Which one?
--
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
Posted by Stefano Mazzocchi <st...@apache.org>.
Ian Abbott wrote:
>
> Stefano Mazzocchi wrote:
> >
> > [snip]
> >
> > Resource views
> > --------------
> >
> > A "view" is a different way to look at a resource. In fact, the above
> > metapipeline is a different way to look at the resource generated by the
> > pipeline.
> >
> > Another possible view is the load statistics for that resource.
> > Another possible view is the semantic model contained in the resource.
> > Another one is the xlink information.
> > And so on...
> >
> > I'm sure there will be many others in the future.
> >
> > http://myhost/complex-semancics/hello
> >
> > will return the "hello" resource as HTML, while
> >
> > http://myhost/complex-semantics/hello?cocoon:view="semantic"
> >
> > will return the "hello" resource as XML page with xlink and RDF
> > information. (the example is stupid, please interpolate a little by
> > yourself).
> >
>
> With user authentication somewhere in the sitemap,
...or in the servlet container, even better....
> could this be the
> basis for a Content Management System, with "reader" (default), "author"
> and "editor" views? We're still needing some kind of XML Schema / XML
> editing system, but this could possibly be the way into editing the
> documents, and also allow editing via different mechanisms (e.g. by
> WAP/lightweight-clients off-site, or heavy-duty browsers on-site).
An "editing" view.
Hmmmm, not sure this is what views are for... but maybe I'm wrong...
hmmmm....
> This is something I'd really love here, as I'd like our VFX producers to
> be able to update shoot notes from location, but right now I haven't got
> the foggiest idea where to start.
Hmmmm, I'll have to think about this offline... you are suggesting the
sitemap might not be balanced from a push/pull aspect of resources....
maybe you are right.... I'll have to think about this.... hmmmm....
> I'm familiar with all the XML family
> (XPath, XLink, XInclude, XForms and so on), but only just getting into
> Java and XSP development after a long time using Perl/DBI. I know what I
> need to do, just not how to do it yet. Of course, if someone is already
> working on the solution, it'd be nice to see it! :)
Well, this is what RT are for, trigger discussion on what's the best
percieved way of doing something and what needs to be done.
> Talking of CMS, how exactly will Prowler fit into all of this. I grabbed
> the JAR and I'm looking through things at the moment, but can this be
> fitted into the "viewer" proposals somehow?
I have honestly no idea :)
--
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
Posted by Ian Abbott <ia...@cinesite.co.uk>.
Stefano Mazzocchi wrote:
>
> [snip]
>
> Resource views
> --------------
>
> A "view" is a different way to look at a resource. In fact, the above
> metapipeline is a different way to look at the resource generated by the
> pipeline.
>
> Another possible view is the load statistics for that resource.
> Another possible view is the semantic model contained in the resource.
> Another one is the xlink information.
> And so on...
>
> I'm sure there will be many others in the future.
>
> [snip]
>
> http://myhost/complex-semancics/hello
>
> will return the "hello" resource as HTML, while
>
> http://myhost/complex-semantics/hello?cocoon:view="semantic"
>
> will return the "hello" resource as XML page with xlink and RDF
> information. (the example is stupid, please interpolate a little by
> yourself).
>
With user authentication somewhere in the sitemap, could this be the
basis for a Content Management System, with "reader" (default), "author"
and "editor" views? We're still needing some kind of XML Schema / XML
editing system, but this could possibly be the way into editing the
documents, and also allow editing via different mechanisms (e.g. by
WAP/lightweight-clients off-site, or heavy-duty browsers on-site).
This is something I'd really love here, as I'd like our VFX producers to
be able to update shoot notes from location, but right now I haven't got
the foggiest idea where to start. I'm familiar with all the XML family
(XPath, XLink, XInclude, XForms and so on), but only just getting into
Java and XSP development after a long time using Perl/DBI. I know what I
need to do, just not how to do it yet. Of course, if someone is already
working on the solution, it'd be nice to see it! :)
Talking of CMS, how exactly will Prowler fit into all of this. I grabbed
the JAR and I'm looking through things at the moment, but can this be
fitted into the "viewer" proposals somehow?
Ian
Re: [RT] resource views, error handling, pipeline debugging
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
> >3 choices;
> >a) Extension to the path.
> >b) cocoon-view parameter
> >c) any parameter indicated by a configuration property.
> >
> >I vote for b.
>
> I've always preferred option (a).
> I find query parameters aesthetically displeasing, particularly on public URLs.
> Keep query params for when there is really no other option IMHO.
I generally share your vision on this, but here is different.
We must introduce the notion of cocoon views, while the general idea of
"views" is not enforced by Cocoon but it's up to you (like for your
"noise"), cocoon-view are special views that are enforced by the sitemap
semantics.
For example, soppose you have
http://host/images/logo
then you do
http://host/images/logo/blackandwhite
http://host/images/logo/a-la-van-gogh
http://host/images/logo/for-print
http://host/images/logo/for-web
http://host/images/logo/for-wap
and so on. These are "functional views" of the same resource, but may
not apply to any other resource inside your URI space. So you must using
normal matching in the sitemap to achieve this (thru different XSLT or
reading different files... up to you).
Very different is the situation where you want, for example, to crawl a
site using XLink information. You _MUST_ know how to access that
hyperlink view, it must be a standard way of doing this.
So, you could try
http://host/path/resource/hyperlink
but then you might end up with name conflicts (having one of your
inherited sitemaps that matches this very URI and overloads this view
capabilities). Something like this would totally break the crawling
experience and leave parts of the site unexplorable.
We could try to use sort-of namespaces for URI fragments so
http://host/path/resource/cocoon-view-hyperlink
but this is nothing better than
http://host/path/resource?cocoon-view="hyperlink"
or less verbose (assuming view names are single words)
http://host/path/resource?cocoon-view=hyperlink
Even if the syntax is very similar
http://host/path/resource/cocoon-view-hyperlink
http://host/path/resource?cocoon-view=hyperlink
the two notions are completely different. Parameters seem to me more
"orthogonal" to the URI space, but admittedly this is a very subjective
idea.
Any comment or suggestion on how to encode view inside HTTP URIs?
--
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
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 14:29 +0200 30/06/00, Stefano Mazzocchi wrote:
>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.
This is very interesting.
It could almost be a description of my first XML project, "Noise".
There are a set of frames for each "thing" each providing different views
of the same data, I was even planning to make pictures of intersecting
planes to visually map the relationships, using SVG or VRML :)
My back ground is in design, where the concepts you discuss exist, but the
analogies are completely different, you are a wacky man :)
Any more talk of the Romans inventing space travel, is going to take you
over the edge :)
At 15:22 +0800 01/07/00, Niclas Hedhman wrote:
>
>> 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.
I've always preferred option (a).
I find query parameters aesthetically displeasing, particularly on public URLs.
Keep query params for when there is really no other option IMHO.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: [RT] resource views, error handling, pipeline debugging
Posted by 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
Posted by 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 ---------------------
Re: [RT] resource views, error handling, pipeline debugging
Posted by 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
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<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
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> > > This solves the issue of error handling with multiple user agents. The
> > > pipeline as a whole becomes a generator for another pipeline.
> >
> > THANK YOU!!!
> > I knew it would come to you sooner or later...
>
> Hey, how unfair, I'm not that slow... :)
We were spawning (!) on this idea a year ago, but at that time, I didn't manage
to crystalize the concept in the foggy situation that was prevalent at that
time. Somehow, someone managed to convince me to drop the idea, probably because
of the DOM-centric processing which it was based upon.
> > 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?? How about it is
added at the end of a document if a particular parameter is set (debug)
otherwise not.
Then, when I started to look into the details of how this would work, there is
another complex matter.
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.
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.
Let's say it is very foggy, and hours of thinking has not made it any clearer,
in fact the opposite.
> > 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.
> > 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...
> 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.
> 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.
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.
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).
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.
> >(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.
Niclas
Re: [RT] resource views, error handling, pipeline debugging
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 29 Jun 2000, Stefano Mazzocchi wrote:
> 3) resource (what Niclas proposes)
>
> path/resource -> normal view
> path/resource/tracing -> tracing view
>
> 4) query (what I proposed)
>
> path/resource -> normal view
> path/resource?cocoon-view="tracing" -> tracing view
>
> the first 2 are not directly controllable by Cocoon.
>
> So the choice is between 3 and 4.
>
> 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.
>
> Hmmm, I would like to know your comments on this before stating my vote.
Either way you get the possibility of name collision, right? at least you
can change the magic variable name in 4. i'd go that route.
> >(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? :)
first there is a mountain
then there is no mountain
then there is
- donald
Re: [RT] resource views, error handling, pipeline debugging
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> Stefano Mazzocchi wrote:
>
> > Pipeline revised
> > ----------------
> >
> > I recently came to the conclusion our pipe model must be enhanced. The
> > pipe currently passes SAX events. These are data events.
> >
> > I want to add a metaevents pipeline, sort of a logging/tracing pipeline
> > where the components throw everything that is related to event
> > generation and not event payload.
> >
> > Example of this are:
> >
> > - pipeline tracing (knowing what's going on, XSLT messages, FOP page
> > generation output, pipeline timings, etc...)
> >
> > - error reporting (xml non-wellformed, exception inside a component,
> > exception inside a server page)
> >
> > So, every component is given access to the stream of events of the next
> > component, plus the orthogonal stream of pipeline metaevents. The
> > implementation of this metaevent stream is not semantic abstract like
> > SAX but its semantic specific (like any logging class).
> >
> > Something like
> >
> > public interface PipelineLogger extends Generator {
> > public void startPipeline();
> > public void endPipeline();
> > public void trace(Component origin, String message);
> > public void error(Component origin, String message, Exception e);
> > ...
> > }
> >
> > This doesn't change the shape of the pipeline, but since PipelineLogger
> > extends Generator, it is possible to use the "tracing" results of a
> > pipeline, XML-ize them and feed them thru another pipeline for
> > presentation.
> >
> > This solves the issue of error handling with multiple user agents. The
> > pipeline as a whole becomes a generator for another pipeline.
>
> THANK YOU!!!
> I knew it would come to you sooner or later...
Hey, how unfair, I'm not that slow... :)
> 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.
> Tough questions indeed, and I will twist my head some, and see what comes
> about later today.
ok
> > Resource views
> > --------------
> >
> > Well, with a particular request parameter
> >
> > http://myhost/myURI/resource?cocoon:view="xxx"
> >
> > where all "cocoon:*" names are reserved for future use. It's an XML-ish
> > hack. but it works and it's easy to parse and easy to read and easy to
> > edit by hand.
>
> 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?
> > So, for example a pipeline like
> >
> > g -> f1 -> f2 -> f3 -> s
> >
> > can be refactored as
> >
> > [ g ] [ f1 , f2 , f3 , s ]
> > [ g , f1 ] [ f2 , f3 , s ]
> > [ g , f1 , f2 ] [ f3 , s ]
> > [ g , f1 , f2 , f3 ] [ s ]
> >
> > Sort of pipeline diagonalization.
> >
> > Why this? well, mainly to reduce verbosity, the components of a view
> > might change, but the component of a viewer might not.
>
> And sorry for being an idiot,
You're no idiot.
> If I have a resource;
> /abc/def/ghi
> and you say that it can be viewed in many ways, how is that different from
> 'extending' the resource itself;
> /abc/def/ghi/complex-semantic
> (other than syntactically in the URI)
Hu, great point, didn't think of this one... see below...
> 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.
> I must be missing something big here, since I don't think you have
> overlooked this.
No, of course not. I wanted this to remain the very last thing to define
exactly because its redundant... i wanted to see if it was necessary.
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.
Best solution would be to introduce the "view" notion in HTTP (sort of
what WebDAV does), but it would require you to write a special client to
browse the pages.
So we have to "hardcode it" into the URI.
Say you have
http://host/path/resource
and you want to access its "tracing" view to find out how much it took
to generate it or what did the XSLT stylesheet tell you.
The HTTP request is
GET HTTP/1.0 /path/resource
the best solution would be
GET HTTP/1.2 tracing /path/resource
but the mountain is _way_ too hard to climb in that direction.
So, given HTTP, we have to modify the URI. A URI is composed by
http://host:port/path/resource?query
Let's try to modify all of them:
1) host
www.myhost.org -> normal view
tracing.myhost.org -> tracing view
2) port
host:80 -> normal view
host:10000 -> tracing view
3) resource (what Niclas proposes)
path/resource -> normal view
path/resource/tracing -> tracing view
4) query (what I proposed)
path/resource -> normal view
path/resource?cocoon-view="tracing" -> tracing view
the first 2 are not directly controllable by Cocoon.
So the choice is between 3 and 4.
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.
Hmmm, I would like to know your comments on this before stating my vote.
>(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? :)
--
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
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> Pipeline revised
> ----------------
>
> I recently came to the conclusion our pipe model must be enhanced. The
> pipe currently passes SAX events. These are data events.
>
> I want to add a metaevents pipeline, sort of a logging/tracing pipeline
> where the components throw everything that is related to event
> generation and not event payload.
>
> Example of this are:
>
> - pipeline tracing (knowing what's going on, XSLT messages, FOP page
> generation output, pipeline timings, etc...)
>
> - error reporting (xml non-wellformed, exception inside a component,
> exception inside a server page)
>
> So, every component is given access to the stream of events of the next
> component, plus the orthogonal stream of pipeline metaevents. The
> implementation of this metaevent stream is not semantic abstract like
> SAX but its semantic specific (like any logging class).
>
> Something like
>
> public interface PipelineLogger extends Generator {
> public void startPipeline();
> public void endPipeline();
> public void trace(Component origin, String message);
> public void error(Component origin, String message, Exception e);
> ...
> }
>
> This doesn't change the shape of the pipeline, but since PipelineLogger
> extends Generator, it is possible to use the "tracing" results of a
> pipeline, XML-ize them and feed them thru another pipeline for
> presentation.
>
> This solves the issue of error handling with multiple user agents. The
> pipeline as a whole becomes a generator for another pipeline.
THANK YOU!!!
I knew it would come to you sooner or later...
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??
Tough questions indeed, and I will twist my head some, and see what comes
about later today.
> Resource views
> --------------
>
> Well, with a particular request parameter
>
> http://myhost/myURI/resource?cocoon:view="xxx"
>
> where all "cocoon:*" names are reserved for future use. It's an XML-ish
> hack. but it works and it's easy to parse and easy to read and easy to
> edit by hand.
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".
> So, for example a pipeline like
>
> g -> f1 -> f2 -> f3 -> s
>
> can be refactored as
>
> [ g ] [ f1 , f2 , f3 , s ]
> [ g , f1 ] [ f2 , f3 , s ]
> [ g , f1 , f2 ] [ f3 , s ]
> [ g , f1 , f2 , f3 ] [ s ]
>
> Sort of pipeline diagonalization.
>
> Why this? well, mainly to reduce verbosity, the components of a view
> might change, but the component of a viewer might not.
And sorry for being an idiot,
If I have a resource;
/abc/def/ghi
and you say that it can be viewed in many ways, how is that different from
'extending' the resource itself;
/abc/def/ghi/complex-semantic
(other than syntactically in the URI)
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.
I must be missing something big here, since I don't think you have
overlooked this. (Stefano is not Mohammed - Why go to the mountain, when
you can turn it... :o)
Niclas