cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [C2] (hopefully) last sitemap major changes
Date Fri, 30 Jun 2000 17:18:33 GMT
Ok, I spent the whole afternoon on this and I'm pretty happy with the
results. Please, throw rock at it and let's see how solid this is.

I made some substantial changes:

1) namespace:

from

 http://xml.apache.org/cocoon/sitemap/1.0

to
 
 http://apache.org/cocoon/sitemap/1.0

to avoid possible virtual-host collisions in the future since the ASF is
thinking about removing all apache virtual hosts or giving a different
virtual host for each project. The above is independent of the result of
such URI refactoring and is designed with forward compability in mind.

2) filter becomes transformer

One main reason for this: filter and its verbe are the same word in
English... this causes big troubles in sitemap validation, while
"transform" and "transformer" are different words and have different
semantics inside the sitemap.

3) increased redirection capabilities

 <map:redirect-to uri="..."/>
 <map:redirect-to resource="..."/>

a "resource" being a

 <map:resource name="...">

where the "name" attribute is the ID and "resource" is the IDREF.

4) fixed some typos here and there.

5) added the notion of "error handling" (which includes metaevents
handling) as such

 <map:pipeline>
  <map:match ...>
   ...
  </map:match>
  <map:handle-errors>
   <map:transform src="./style/error-page2html.xsl"/>
   <map:serialize/>  
  </map:handle-errors>
 </map:pipeline>

6) added the notion of "views" and pipeline "labels".

for example

 <map:view name="content" generate-from="content">
  <map:serialize type="xml"/>
 </map:view>

 <map:view name="schema" generate-from="content">
  <map:transformer type="schema"/>
  <map:serialize type="xml"/>
 </map:view>

 ....
 
  <map:label name="content">
   <map:generate src="./file/document.xml"/>
  </map:label>
  <map:transform src="./style/doc2html.xsl"/>
  <map:serialize/>
 
where it can be viewed as
 
 g -(content)-> t -> s   [normal view]
        +-----> t -> s   [schema view]
        +----------> s   [content view]

The sitemap allows each "producing" component (generators and
transformers) to attach "default labels" to these components so that 

  <map:label name="content">
   <map:generate src="./file/document.xml"/>
  </map:label>
  <map:transform src="./style/doc2html.xsl"/>
  <map:serialize/>

is totally equivalent to

  <map:generate src="./file/document.xml"/>
  <map:transform src="./style/doc2html.xsl"/>
  <map:serialize/>

if the "parser" generator (which here is default), has attached as
default label "content"... such as in

  <map:generators default="parser">
   <map:generator type="parser" src="..." label="content"/>
  </map:generators>

this should allow us to use sitemaps for simple views (such as content
or schema) without introducing too much sitemap-creation overhead and
reduce readability with a bunch of <label> tags.

Ok, people, this is it.

This is what my poor fried brain could come up with.

This, for me, it's the last working draft for Cocoon 2.0... it may not
be perfect, but it covers up everything I wanted to cover with this
release.

BIG NOTE: I believe this sitemap may result a little "pull" centric,
meaning that might not be perfect for writing very complex web
applications. While I want Cocoon to allow the creation of complex web
applications just as easily as complex web publishing systems, we need
to take one step at a time.

Note this "pull" centricity might reflect on content authoring, while I
believe that the notion of "edit views" might be powerful enough to
solve all needs. On the other hand, content authoring in the future will
have to deal with webDAV and being practially ignorant on the subject, I
don't want to dare going that far with this release.

So, XML editing and complex XML web applications were not indicated as
engineering constraints since we don't have enough information about
those problem spaces to create a decently-covering solution topology.
I'd go far enough to presume many of the sitemap topology can go far
enough to partially cover those problem spaces. The holes left in this
coverage, will be used to design next-next generation... unless the
sitemap results as a total failure and we'll restart from scratch.

Collaboration with the mod_dav and prowler project will give us the
feedback needed for content editing.

Collaboration with Turbine and Enhydra projects will give us the
feedback needed for XML web applications.

So, please, don't assume the sitemap will do _everything_ for you....
but I could not find any problem space that this sitemap solution space
cannot cover... and this after 18 months of feedback from thousands of
people.

This doesn't mean it's perfect, I'd presume from my past experience it's
not even close... but its a good step forward compared to C1 and it must
be judged for this only.

So, I consider it feature-frozen from now.

Let's polish it and let's rock and roll implementing it :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message