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 [EMAIL PROTECTED]"
(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">[EMAIL PROTECTED]</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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
