cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: [RT] Views for readers
Date Thu, 14 Aug 2003 21:05:37 GMT
Sylvain Wallez wrote:

> Miles Elam wrote:
>> In other words, the pipeline is full of side effects and dependant 
>> upon things happening behind the curtain (to use a Wizard of Oz 
>> reference).  You'd be right in that it adds to the confusion.  I 
>> agree with Vadim.  This is obfuscation in exchange for two lines of 
>> verboseness.
> Just some additional precisions, "mon frère" ! 

I hope it wasn't taken the wrong way.  I did not intend any offense.

> Yes, the pipeline is full of side effects, which can break pipelines 
> at any point an continue somewhere else without this being explicitely 
> visible in the pipeline construction statements.
> These side effects are called "views", and the way to define views is 
> through labels. 

Don't get me wrong.  I see clearly the reason why views exist.  I see 
clearly why reader views are wanted.  When working with XML data -- not 
just text, but structured text -- getting at that data before it is 
processed into a presentation format (such as viewing source, getting a 
true content view, etc.) can prove invaluable.

> And even worse : labels can be placed on component definitions, 
> meaning a clean pipeline with no label attribute at all is full of 
> these side effects.
> So what you call obfuscation has been there *for years*. And 
> everybody's happy with it. 

When grabbing from the presentation format as a source, you are 
comparing apples and oranges.  Not only are there innumerable binary 
formats out there being squeezed into a few reader implementations, but 
they are not all desirable data.  While you may want the data from a PDF 
file, you may not bother with a PNG image because it may index "Created 
with The Gimp" over and over.

Since putting in all binary format-to-generator mapping info seems out 
of the question, all of the pipeline path must be specified in the 
matcher -- hence the discussion surrounding readers and generators in 
the same matcher.  If everything is specified in the same matcher and 
not truly orthogonal, as is the case for views currently, why add the 
extra syntax for what amounts to a non-orthogonal if-else clause?

if (!content-view)

as opposed to

   +---------- view-short-curcuit! --+-> transform-x
transform-1                          +-> serialize

There is a discontinuity there that makes me uncomfortable.  This is not 
an overt attachment to symmetry.  This is seeing the same tool applied 
to two (in my opinion) very different tasks.  I am not a committer and 
can't vote.  But these are my thoughts on the matter.  Take with as many 
grains of salt as are necessary.

- Miles Elam

View raw message