From cocoon-dev-return-35173-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Tue Jan 14 23:30:40 2003
Return-Path:
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 17897 invoked by uid 500); 14 Jan 2003 23:30:39 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
list-post:
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 17885 invoked from network); 14 Jan 2003 23:30:38 -0000
Message-ID: <3E249D74.4060504@nada.kth.se>
Date: Wed, 15 Jan 2003 00:29:56 +0100
From: Daniel Fagerstrom
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Input Pipelines: Storage and Selection (was Re: [RT] Input
Pipelines (long))
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
Stefano Mazzocchi wrote:
> Sorry for taking me so long.
I should be more sorry ;) If I could learn to write shorter RT:s it
would take less time booth to answer them and to answer the answers,
anyway, I'm always happy when you, (and other people) give feedback on
my thoughts.
> Daniel Fagerstrom wrote:
> Once the Cocoon Environment is more balanced toward input, you can
> have a uber-payload-generator that does everything and brews beer, or
> you can have your own small personal generator that does what you want.
Agreed.
>>
>>
>> The idea is that if no src attribute is given the sitemap interpreter
>> automatically connect the generator to the input stream of the
>> environment (the input stream from the http request in the servlet
>> case, in other cases it is more unclear). This behavior was inspired
>> by the handling of std input in unix pipelines.
>
>
> Hmmm, interesting concept indeed, but I wonder if it's really
> meaninful in our context. I mean, maybe there are generators that
> don't need src and don't rely on input. But an idiotic TimeGenerator
> is the only one I can think of... and that really doesn't stand up as
> an argument, does it?
The TimeGenerator could just ignore the input stream, as many unix
programs ignores std input. But if the input stream is a multipart mime,
it is unclear if we should feed the whole multipart mime or just a part
of it (this has been discussed in the "StreamGenerator depends on
Servlets!!!" thread and I stated my current opinion on the subject in
the "[RT] Better Environment Abstraction" thread). So IMO the idea
doesn't stand the test against reality, we need something more explicit.
> Nicola Ken proposed:
>
>>
>>
>>
>> I prefer this solution compared to mine as it doesn't require any
>> change of the sitemap interpreter, I also believe that it it easier
>> to understand as it is more explicit. It also (as Nicola Ken has
>> explained) gives a good SoC, the uri in the src attribute describes
>> where to read the resource from, e.g. input stream, file, cvs, http,
>> ftp, etc and the generator is responsible for how to parse the
>> resource. If we develop a input stream protocol, all the work
>> invested in the existing generators, can immediately be reused in web
>> services.
>
>
> It is true that reduces the number of required generators. But there
> is something about this that disturbs me even if I can't really tell
> you what it is rationally... hmmm...
Ok, we discuss this later, or hope that the disturbing feeling just
fades away, and disapears completely ;)
Interesting discussion about validation, scheemes etc
> > Should validation be part of the generator or a transform step? I
> don't know.
> Transformation, for the simple reason that you might need to validate
> a pipeline more than once.
I'm totally convinced :)
More interesting discussion about validation
>> Mixing data and state information was considered to be a bad practice
>> in the discussion about pipe-aware selection (se references in [3]),
>> that rules out using only augmentation of the xml document as error
>> reporting mechanism. Throwing an exeption would AFAIU lead to
>> difficulties in giving customized error reports. So I believe it
>> would be best to put some kind of state describing object in the
>> environment and possibly combine this whith augmentation of the xml
>> document.
>
>
> Yes, that would be my assumption too. And in case there is the need to
> incorporate those validation mistakes back into the content, a
> transformer (maybe even an XSLT stylesheet) can do that.
>
> This seems the cleanest solution to me.
Good.
> we are reaching the point where pipeline selection cannot be
> processed "a-priori" but must include
> information on the run-time environment.
> As much as I didn't like pipe-aware selection, I do agree that
> validation-aware selection is a special pipe-aware selection but it
> *IS* very important and must be taken in to consideration.
>
> Hmmm, this kinda shades a totally different light on the concept of
> selection. (which has an interesting side effect in making selectors
> and matchers even more different than they are today).
>
>> An alternative and more explicit way to describe the pipeline state
>> dependent selection above, is:
>>
>> ...
>>
>>
>>
>>
>>
>>
>>