From nicolaken@supereva.it  Sun Jul  2 16:15:36 2000
Return-Path: <nicolaken@supereva.it>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 45262 invoked from network); 2 Jul 2000 16:15:36 -0000
Received: from adamo4.supereva.it (HELO mail.supereva.it) (195.110.96.107)
  by locus.apache.org with SMTP; 2 Jul 2000 16:15:36 -0000
Received: (qmail 12830 invoked from network); 2 Jul 2000 16:15:12 -0000
Received: from unknown (HELO ARES) (151.35.2.194)
  by mail.supereva.it with SMTP; 2 Jul 2000 16:15:12 -0000
Message-ID: <00b101bfe440$c9d088b0$c2022397@ARES>
Reply-To: "Nicola Ken Barozzi" <nicolaken@supereva.it>
From: "Nicola Ken Barozzi" <nicolaken@supereva.it>
To: <cocoon-dev@xml.apache.org>
References: <395CD669.DEC70286@apache.org> <00ef01bfe343$360a6c70$30022397@ARES> <395F412B.ABE5B76D@apache.org>
Subject: Re: [C2] (hopefully) last sitemap major changes
Date: Sun, 2 Jul 2000 17:49:02 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

----- Original Message ----- 
From: "Stefano Mazzocchi" <stefano@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Sunday, July 02, 2000 3:18 PM
Subject: Re: [C2] (hopefully) last sitemap major changes


  
> > > 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.
> > 
> > transformer reminds me of small robot toys...
> 
> So? my brother had a bunch of them :) I thought they were pretty cool.

Pretty cool?!? They were GREAT! :-)
  
> > > 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>
> > 
> > I am using Cocoon for two projects and one is an intranet.
> > Here security and error handling are not an option.
> > When I first saw the sitemap proposal I thought it was a good idea (I still
> > think it is), but error handling was not in it.
> > Now it is... but why don't we define a standard DTD for notifications and
> > standard XLST for main browsers?
> 
> Oh, sure, this is the idea, in fact. But nothing the sitemap should be
> aware of.
> > Something like (mixed notation)
> > 
> > <notify type="information|warning|exception|error|fatal">
> >   <title>foo_title</title>
> >   <description>foo_description</description>
> >   <message>foo_message</message>
> >   <stacktrace>foo.stacktrace</stacktrace>
> > </notify >
> 
> This is exactly the plan, but the sitemap is completely independent on
> this.... and while error handling doesn't give you control on how this
> schema is created (the pipeline metaevents will be serialized with
> something like this), it does allow you to control how to process this
> further.

Ok, just saying that the DTD is useful for me; I use Cocoon to serve 
XML to a Visual Basic client and he is not very happy to receive HTML or
HTTP errors...

> Many people expressed the need for having some users diplayed errors in
> some ways and some users (mainly developers or internal people) having
> access on more detailed transcritps of what's going on.
> 
> The error handling pipeline will give you the ability to implement
> whatever you want with the pipeline meta-information just like it was
> another generator. Thus reusing the good concept of pipeline components
> and MDSC.

Can't wait!

> > Another thing is security.
> 
> yep, "another thing".
> 
> > Now I made my taglib for security but why not specify it in the sitemap?
> 
> For example?

The web.xml in J2EE is similar in some ways to the sitemap; in it you can specify
security constraints for web resource collections.

    <security-constraint>
      <web-resource-collection>
         <web-resource-name>Protected Area</web-resource-name>
  <!-- Define the context-relative URL(s) to be protected -->
         <url-pattern>/restricted/*</url-pattern>
  <!-- If you list http methods, only those methods are protected 
  <http-method>DELETE</http-method>
         <http-method>GET</http-method>
         <http-method>POST</http-method>
  <http-method>PUT</http-method> --> 
      </web-resource-collection>

Here you limit HTTP methods in a url pattern.
In C2 you could limit views.

Anyway security is much bigger than something to put in the sitemap.
I am still confused on how it could implemented.
Are there any ideas on how C2 must deal with security issues anyone?

> > How does it relate to the contracts?
> 
> Which contracts? Sorry, I lost you here.

The contracts between programmers, content creators, etc.
Who should be in charge of security?
Is there another figure that has been missing?

> > This is what I am using now:
> > 
> >   <xsl:template match="security:require-role">
> >      <xsp:logic>
> >       if (request.isUserInRole("<xsl:value-of select="@role"/>"))
> >        {
> >           <xsl:apply-templates/>
> >        }
> > 
> >       </xsp:logic>
> >   </xsl:template>


> > OFF TOPIC: By the way, I went crazy trying to make security work in Tomcat;
> > in the documentation they say they tested it but it doesn't work! In fact it
> > is bugged, they froze the wrong code, so to make it work you have to change
> > three lines of code and recompile, then all works ok.
> 
> I'm sure the Tomcat people will be very happy to know this. Did you tell
> them?
>  

They know well, I found the answer on their mailing list archive (not easilly, really).
The fact is that Bugzilla is down and the don't explain this issue on their web page.

> > > 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.
> > 
> > +2
> > I think it could be used to add some sort of skinning... just associate
> > users with different views with a taglib...
> 
> No, that's not the notion of view I'm talking about.
> 
> Sure, the "view" concept is general enough to incorporate site skins,
> but the views the sitemap adds semantics for are "functional views" that
> can reuse the same pipe termination for a great number of resources and
> must be directly requested for in non-standard concerns.
> 
> For example, you could have
> 
>  http://host/path/resource?cocoon-view="purple-with-flowers"
> 
> while you should write instead
> 
>  http://host/path/resource/purple-with-flowers
> 
> or, even better,
> 
>  http://host/path/resource
> 
> and have the sitemap match depending on session/cookie parameters,
> instead of hardcoding this into the URI.
> 
> The "cocoon-view" parameter should indicate special functional views of
> the resource that is a standard way to access the internal of a
> resource, not a way to wrap it differently.
> 
> I hope this is clear because this notion if of extreme importance.
> 
> [which reminds me: the use of URI spaces as file system one-to-one maps
> destoyed the notion of "URI space design patterns".... we must create a
> collection of those in the future or poeple will have to write a couple
> of sites before understanding what is right to do and what not...]
>  

Thank you for the explanation.
Anyway I'm afraid that skinning or the more general concept of presentation
personalization are what many will do with this. Just an opinion.

> > > So, please, don't assume the sitemap will do _everything_ for you....
> > 
> > no coffee!?!!!!!
> > 
> > > 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.
> > 
> > I hope it doesn't get too complicated.
> 
> We all hope this.
> 
> > Before I found Cocoon was thinking of creating a servlet for report
> > generation and database insertions and transactions in the intranet. The XML
> > i was creating was beginning to become a monster.
> > This is one of the first versions (the text is in Italian):
> > 
> > <?xml version="1.0"?>
> > <!DOCTYPE SQLQuerySetDB SYSTEM "SQLQuerySetDB.dtd">
> > <SQLQuerySetDB>
> >    <DBIds>
> >       <DBId DBref="OreLavorateDB" DBdriver="sun.jdbc.odbc.JdbcOdbcDriver"
> > DBname="jdbc:odbc:OreLavorate" userId="admin" userPass="admin"/>
> >       <DBId DBref="KeyDB" DBdriver="sun.jdbc.odbc.JdbcOdbcDriver"
> > DBname="jdbc:odbc:KeyDB" userId="admin" userPass="admin"/>
> >    </DBIds>
> >    <SQLQuerySet name="TestQuerySet" stylesheet="testsheet.xsl">
> >       <SQLQuery name="TestQuery" DB="OreLavorate" type="SELECT">
> >          <SQLQueryString>SELECT ? from contatti</SQLQueryString>
> >          <SQLQueryParameters>
> >             <form name="firstform" stylesheet="testsheet.xsl">
> >                <select name="C1" default="0">
> >                   <caption>Scegli un choice:</caption>
> >                   <choices>
> >                      <choice value="1">choice 1</choice>
> >                      <choice value="2">choice 2</choice>
> >                   </choices>
> >                </select>
> >                <input name="I1" default="0">
> >                   <caption>Inserisci:</caption>
> >                </input>
> >                <hidden name="H1" default="defaulthiddenvalue"/>
> >                <select name="SQLS1" default="0">
> >                   <caption>Scegli un choice SQL:</caption>
> >                   <choices>
> >                      <SQLQuery name="TestQuery2" DB="OreLavorate"
> > type="SELECT">
> >                         <SQLQueryString>SELECT "Gino" from
> > contatti</SQLQueryString>
> >                      </SQLQuery>
> >                   </choices>
> >                </select>
> >             </form>
> >          </SQLQueryParameters>
> >       </SQLQuery>
> >    </SQLQuerySet>
> > </SQLQuerySetDB>
> > 
> > I was creating a tree containing all transaction info, starting fron the
> > result wanted (report in this case).
> > It was getting too big and to make decision branching possible I thought of
> > putting forward and backward branches: A NIGHTMARE!
> > So +100 to the idea of keeping it simple.
> 
> Oh, you'll find lots of friend in this list then :-)
>  
> > > Let's polish it and let's rock and roll implementing it :)
> > 
> > Yeah! :-)
> 
> Thanks for the feedback Ken (Shiro?) :-) Very appreciated.

Shiro? Kind of. My father worked for 22 years in Japan, I lived there for 5, and
Ken is a Japanese name that means "man who respects the law".
As for the feedback... it was due! :-)

Ken

Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica