Return-Path: 
 <cocoon-dev-return-29247-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 70480 invoked by uid 500); 8 Jul 2002 20:33:59 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 70467 invoked from network); 8 Jul 2002 20:33:58 -0000
Message-ID: <3D29F77B.8050807@yahoo.de>
Date: Mon, 08 Jul 2002 22:35:07 +0200
From: "J.Pietschmann" <j3322ptm@yahoo.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] reconsidering pipeline semantics
References: <3D21A28D.213AC669@apache.org> <3D22173D.4060208@yahoo.de>
 <3D22BB9F.2BA79B9C@apache.org> <3D261668.4000405@yahoo.de>
 <3D26BD67.2C27B703@apache.org> <3D26F358.7020801@yahoo.de>
 <3D2856C6.9022ED8D@apache.org>
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:
> Right now, the note proposed by Eve Maler and Norm Walsh (long time
> contributors of the document-centric XML/SGML world) is a sort of 'ant
> build file for xml processing'. Indeed powerful, but limited in scope
> and many believe too document-oriented.
> 
> I wouldn't personally wait for such a standard to emerge soon. And even
> if it does, I wouldn't bet it would allow us to replace our sitemap with
> it.

I don't think it would replace Cocoons sitemap, nor should it.
The sitemap does, in short, three different things
- declare component classes
- declare pipelines, and fill them with components
- declare mappings from URLs to pipelines (or, in general, to
   a processor for the request)
Admittedly, the sitemap maps also parameter values, cookie values
and everythig else to pipelines, whether this is a good idea or
not.

General pipelining will only deal with the second, and will
only use a very simplified form of the first, if at all.


Well, switch back to the thread topic (pipeline semantics)
Start with an analogy: You have a set of related XML
documents which contains a lot of certain personal data.
You have several choices to deal with this:
- Extreme 1: Expand all the personal dataa whereever it is
   used, for  examaple "contact: J.R.Hacker, Phone 1234567
   and D.A. User, Email dau@fubar.org"
   (use markup as needed)
   Obvious advantage: easy editing of all the docs
   Obvious disadvantage: redundancy, maintenance problems lurking
- Extreme 2: Have one document as a central repository which
   contains all of the personal data and reference them, for
   example:
     <person id="jrh0001">
       <name>
          <cn>J.R.Hacker</cn>
          <firstname>J.</firstname>
          <initial>R.</initial>
          <sn>Hacker</sn>
       </name>
       <contact>
         <phone type="home">1234567</phone>
         <phone type="mobile">99887766</phone>
       </contact>
    </person>
    <person id="dau0231">
       <name>
          <cn>D.A.User</cn>
     ...
   <!-- other doc --> "contact: <personref idref="jrh0001"/> and
    <personref idref="dau0231"/>"
   Obvious advantage: No redundancy, easier maintenance:
   Obvious disadvantage: needs discipline for data entry, needs
   tools to avoid dangling references.
- Middle ground: Use a person element which can contain either a
   full definition or a reference to a full definition:
   "contact: <person><personref idref="jrh0001"/></person> and
    <person><persondef><name><cn>D.A.User</cn></name>
      <contact><email type="unspecified">dau@fubar.org</email></contact>
    </person>"
   Advantages: Documents can be edited with full definitions if
   necessary. Definitions can be moved automatically from documents
   to the  repository and replaced by references, and vice-versa,
   as needed.
   Disadvantages: Needs tool support. <insert more here>.

Apply the principles above to pipelines. A simple pipeline is
an instance of the pipeline component, filled with other component
instances. Let's say the instances could be declared in place, or
referenced (note: no matchers or actions, only processors allowed)
  <!-- declare a few processors -->
  <processordef id="foogenerator" role="filegenerator"
    src="/foo/bar/{name}.xml>
    <param name="name"/>
  </processordef>
  <processordef id="aggregate-and-make-html" role="pipeline">
    <param name="name"/>
    <processorref idref="foogenerator">
      <with-param name="name" value="{name}"/>
    </processorref>
    <processordef role="xslt" src="ref-to-xinclude"/>
    <processorref idref="generic-xinclude"/>
    <processordef idref="doc-to-html"/>
    <processordef role="serializer">
  </processordef>
  <!-- map a URL to a processor -->
  <map match="foo/*.html">
    <processorref idref="aggregate-and-make-html">
      <with-param name="name" value="{1}"/>
    </processorref>
  </map>
  <!-- map another URL to a processor -->
  <map match="download/*.tar.gz">
    <processordef role="pipeline>
      <param name="name" value="{1}"/>
      <processordef role="targenerator" src="/path/to/dnld/{name}">
        <param name="name" value="{name}"/>
      </processorref>
      <processordef role="gzip">
        <param name="method" value="nocompress"/>
      </processorref>
    </processordef>
  </map>
Well, parametrization probably needs some work. I left out
the <processor> around the defs and refs inside the pipeline,
as this seems to be too verbose.
You can replace "ref" by "call" or whatever if you want to.

Well, enough for today
J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org