You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/06/30 19:18:33 UTC
[C2] (hopefully) last sitemap major changes
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Sun, Jul 02, 2000 at 03:22:41PM +0200, Stefano Mazzocchi wrote:
> Giacomo Pati wrote:
> >
> > Stefano Mazzocchi wrote:
> >
> > As one looks into the sitemap WD in the CVS it seems that the
> > <map:match> element is the top element of a resource pipe. I guess it's
> > still true that such a pipe can be formed as (even if it somehow doesn't
> > make sense):
> >
> > <map:choose type="ip-filter">
> > <map:when test="allowsAddress()">
> > <map:match pattern="cocoon/dist/*">
> > <map:redirect-to uri="dist/cocoon/{1}"/>
> > </map:match>
> > </map:when>
> > <map:otherwise>
> > <map:redirect-to resource="Access refused"/>
> > </map:otherwise>
> > </map:choose>
>
> Well, I think the <match> should be the only one allowed. It makes it
> more declarative... just like XSLT has only <template> to start from.
>
> To me, it doesn't make any sense to start a declaration with a "if it's
> this" without returning what it is.
>
> So, instead of
>
> <map:choose type="ip-filter">
>
> I would do
>
> <map:match type="ip" pattern="127.0.0.1|192.123.*.*|10.2.38.*">
>
> I could not find a place where <choose> could start a pipe.... but if
> you have any idea, I'm more than happy to change my mind.
No, I also think that having a <match> the only tag directly under <pipeline> is much cleaner. I've only wanted to make it clear for everybody.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: [C2] (hopefully) last sitemap major changes
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
>
> Stefano Mazzocchi wrote:
>
> As one looks into the sitemap WD in the CVS it seems that the
> <map:match> element is the top element of a resource pipe. I guess it's
> still true that such a pipe can be formed as (even if it somehow doesn't
> make sense):
>
> <map:choose type="ip-filter">
> <map:when test="allowsAddress()">
> <map:match pattern="cocoon/dist/*">
> <map:redirect-to uri="dist/cocoon/{1}"/>
> </map:match>
> </map:when>
> <map:otherwise>
> <map:redirect-to resource="Access refused"/>
> </map:otherwise>
> </map:choose>
Well, I think the <match> should be the only one allowed. It makes it
more declarative... just like XSLT has only <template> to start from.
To me, it doesn't make any sense to start a declaration with a "if it's
this" without returning what it is.
So, instead of
<map:choose type="ip-filter">
I would do
<map:match type="ip" pattern="127.0.0.1|192.123.*.*|10.2.38.*">
I could not find a place where <choose> could start a pipe.... but if
you have any idea, I'm more than happy to change my mind.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
As one looks into the sitemap WD in the CVS it seems that the
<map:match> element is the top element of a resource pipe. I guess it's
still true that such a pipe can be formed as (even if it somehow doesn't
make sense):
<map:choose type="ip-filter">
<map:when test="allowsAddress()">
<map:match pattern="cocoon/dist/*">
<map:redirect-to uri="dist/cocoon/{1}"/>
</map:match>
</map:when>
<map:otherwise>
<map:redirect-to resource="Access refused"/>
</map:otherwise>
</map:choose>
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: [C2] (hopefully) last sitemap major changes
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> Stefano Mazzocchi wrote:
>
> > 1) namespace:
> > to http://apache.org/cocoon/sitemap/1.0
>
> +1.
>
> > 2) filter becomes transformer
>
> A Transformer takes an input and Transforms it to an output. The process is
> called a Transformation.
> +1.
>
> > 3) increased redirection capabilities
> >
> > <map:redirect-to uri="..."/>
> > <map:redirect-to resource="..."/>
>
> Feels right.
> +1
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>
>
> +1 for the idea...
> BUT, is it possible to Reset the SAX stream, and start all over?? And what
> about the response object in case of Http? It would possibly already been
> sending some data back to the client, by the time the error occur, no?
> A bit uncertain of the possibilities and implications...
Oh gosh, you are totally right: I underestimated that problem.
This an intrinsic limitation of the HTTP model: once the header has been
sent, you're doomed, but it's the same problem for "any" web technology.
> > 6) added the notion of "views" and pipeline "labels".
>
> Don't grasp this... Your sample has too many "content", and hard to
> understand what belongs where.
> You have another example, perhaps in the CVS?
No, it's basically the same, but if you don't understand it there's
something wrong.
> > 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.
>
> <snip>
>
> > So, I consider it feature-frozen from now.
> >
> > Let's polish it and let's rock and roll implementing it :)
>
> What? We are only talking Sitemap here...
Yes, I know. But the sitemap is the skeleton of C2... you need a
skeleton to make you body stand up.
> Wait until things falls in place
> and the massive stream of requests and wishlist is pouring in from the
> crowd.
We'll see how the sitemap stands that tide ;-)
> Last question for the last WD - 1.1? or 1.2?
> No clue what the consensus was last time.
What's in CVS always reflects consensus... I make sure it does.
Anyway, if you don't like something or wish to change it, speak up
sooner rather than later!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> 1) namespace:
> to http://apache.org/cocoon/sitemap/1.0
+1.
> 2) filter becomes transformer
A Transformer takes an input and Transforms it to an output. The process is
called a Transformation.
+1.
> 3) increased redirection capabilities
>
> <map:redirect-to uri="..."/>
> <map:redirect-to resource="..."/>
Feels right.
+1
> 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>
+1 for the idea...
BUT, is it possible to Reset the SAX stream, and start all over?? And what
about the response object in case of Http? It would possibly already been
sending some data back to the client, by the time the error occur, no?
A bit uncertain of the possibilities and implications...
> 6) added the notion of "views" and pipeline "labels".
Don't grasp this... Your sample has too many "content", and hard to
understand what belongs where.
You have another example, perhaps in the CVS?
> 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.
<snip>
> So, I consider it feature-frozen from now.
>
> Let's polish it and let's rock and roll implementing it :)
What? We are only talking Sitemap here... Wait until things falls in place
and the massive stream of requests and wishlist is pouring in from the
crowd.
Last question for the last WD - 1.1? or 1.2?
No clue what the consensus was last time.
Niclas
Re: [C2] (hopefully) last sitemap major changes
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> > 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.
>
> We have still type= and name=. As there were no comments on it I thought
> you would make them consistent. But this didn't happend so I vote for
> using name= as IDs and type= as IDREFs.
Good point, I like the pattern. +1
> >
> > 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>
>
> First some glossary:
> - a pipeline is the block enclosed by <map:pipeline> and </map:pipeline>
> - a pipe is a assebled chain of a generator, transformers and a
> serializer choosen by matchers, choosers, mounts and/or resources.
>
> Do I understand it right, that the hole
> <map:handle-errors></map:handle-errors> block is a pipe for itself with
> the surrounding pipeline (excluding the handle-errors block) as its
> generator.
Yes, I don't like with your terminology entirely but I don't have better
names.
> Every component (including matchers, chooser, etc.) of the
> pipeline can fire event to that handle-error block and as soon as an
> (maybe special) Exception is thrown the handle-errors block becomes the
> active pipe which writes to the OutputStream instead of the failing
> pipe.
No, no. Each component has access to two event streams, one is the SAX
stream routed by the sitemap to the other component, the other one is
the tracing stream.
> There is a need to extend existing Interfaces or introduce new ones to
> have access to the ContentHandler of the handle-errors block.
Sure we have to extend existing interfaces since we must provide hooks
to send tracing metaevents to this pipe.
Now I wonder: should we have both
<pipeline>
...
<handle-errors>
</handle-errors>
<handle-traces>
</handle-traces>
</pipeline>
or we can keep this together?
NOTE: if we keep them together, we can use different namespaces to
indicate errors and traces, but maybe two different schemas are better?
What do you think?
> > 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]
>
> I see a lot of new Interfaces introduced getting that to work. And also
> some changes to the existing ones. You too?
Yes, the new interface is TraceHandler and must be made available to all
pipeline components.
> >
> > 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.
>
> I don't think I have that all grasped but my intuition says it will come
> on the right way.
Thanks for your trust :)
> > 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.
>
> <snip/>
>
> > So, I consider it feature-frozen from now.
> >
> > Let's polish it and let's rock and roll implementing it :)
>
> Uff, finaly. Now we can implement that monster leisurely :)
it shouldn't be that bad... we already thought about most of the problem
we could have come out with during implementation...
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> 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.
+1
> 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.
+1
> 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.
We have still type= and name=. As there were no comments on it I thought
you would make them consistent. But this didn't happend so I vote for
using name= as IDs and type= as IDREFs.
>
> 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>
First some glossary:
- a pipeline is the block enclosed by <map:pipeline> and </map:pipeline>
- a pipe is a assebled chain of a generator, transformers and a
serializer choosen by matchers, choosers, mounts and/or resources.
Do I understand it right, that the hole
<map:handle-errors></map:handle-errors> block is a pipe for itself with
the surrounding pipeline (excluding the handle-errors block) as its
generator. Every component (including matchers, chooser, etc.) of the
pipeline can fire event to that handle-error block and as soon as an
(maybe special) Exception is thrown the handle-errors block becomes the
active pipe which writes to the OutputStream instead of the failing
pipe.
There is a need to extend existing Interfaces or introduce new ones to
have access to the ContentHandler of the handle-errors block.
> 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]
I see a lot of new Interfaces introduced getting that to work. And also
some changes to the existing ones. You too?
>
> 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.
I don't think I have that all grasped but my intuition says it will come
on the right way.
> 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.
<snip/>
> So, I consider it feature-frozen from now.
>
> Let's polish it and let's rock and roll implementing it :)
Uff, finaly. Now we can implement that monster leisurely :)
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: [C2] (hopefully) last sitemap major changes
Posted by Stefano Mazzocchi <st...@apache.org>.
Jonathan Stimmel wrote:
>
> On Thu, Jul 06, 2000 at 12:09:42AM +0200, Stefano Mazzocchi wrote:
>
> > Sorry, I don't understand where the security hole is. Can you elaborate
> > more on this?
>
> Well, here are two chunks from the sitemap:
>
> <map:match pattern="dist/*">
> <map:mount src="./dist/{1}"/>
> </map:match>
>
> ...
>
> <map:match pattern="cocoon/dist/*">
> <map:choose type="ip-filter">
> <map:when test="allowsAddress()">
> <map:redirect-to uri="dist/cocoon/{1}"/>
> </map:when>
> ...
> </map:choose>
> </map:match>
>
> If I type "cocoon/dist/whatever", cocoon checks my address and then
> processes the request as if I had typed "dist/cocoon/whatever". However,
> there's nothing to prevent me from just typing "dist/cocoon/whatever",
> completely circumventing the authorisation test.
Oh, you are talking about the example, not the sitemap notion behind it.
I understand now.
> This isn't really something that can be "fixed", as it's a security
> hole due to poor configuration.
Right, you still have to _build_ your sitemap... we'll find out good or
bad "design patterns" after a while, for sure, not before users start
using it.
> It makes me wonder if the sitemap
> really should have a <redirect-to uri=""/> or whether that role
> should be left to the web server. Thinking about it some more, you
> can still have the same problem redirecting to resources:
>
> <map:match pattern="path/*">
> <map:redirect-to resource="sensitive"/>
> </map:match>
>
> <map:match pattern="path/*">
> <map:choose type="ip-filter">
> <map:when test="allowsAddress()">
> <map:redirect-to resource="sensitive"/>
> </map:when>
> ...
> </map:choose>
> </map:match>
> Resources are a Good Thing(tm), so we can't eliminate them, which
> means we need <redirect-to>. The only other options I see are
> (a) allow resources to include <map:choose> tags (I'm not sure
> if this is currently the case)
Sure, a resource is just another part of the pipe that you happen to use
often.
> or (b) make certain this case is
> documented (which I think it should be either way).
I agree.... well, redirection is possibly a problem but I guess all
sys-admin know this.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Jonathan Stimmel <jo...@stimmel.net>.
On Thu, Jul 06, 2000 at 12:09:42AM +0200, Stefano Mazzocchi wrote:
> Sorry, I don't understand where the security hole is. Can you elaborate
> more on this?
Well, here are two chunks from the sitemap:
<map:match pattern="dist/*">
<map:mount src="./dist/{1}"/>
</map:match>
...
<map:match pattern="cocoon/dist/*">
<map:choose type="ip-filter">
<map:when test="allowsAddress()">
<map:redirect-to uri="dist/cocoon/{1}"/>
</map:when>
...
</map:choose>
</map:match>
If I type "cocoon/dist/whatever", cocoon checks my address and then
processes the request as if I had typed "dist/cocoon/whatever". However,
there's nothing to prevent me from just typing "dist/cocoon/whatever",
completely circumventing the authorisation test.
This isn't really something that can be "fixed", as it's a security
hole due to poor configuration. It makes me wonder if the sitemap
really should have a <redirect-to uri=""/> or whether that role
should be left to the web server. Thinking about it some more, you
can still have the same problem redirecting to resources:
<map:match pattern="path/*">
<map:redirect-to resource="sensitive"/>
</map:match>
<map:match pattern="path/*">
<map:choose type="ip-filter">
<map:when test="allowsAddress()">
<map:redirect-to resource="sensitive"/>
</map:when>
...
</map:choose>
</map:match>
Resources are a Good Thing(tm), so we can't eliminate them, which
means we need <redirect-to>. The only other options I see are
(a) allow resources to include <map:choose> tags (I'm not sure
if this is currently the case) or (b) make certain this case is
documented (which I think it should be either way).
Re: [C2] (hopefully) last sitemap major changes
Posted by Stefano Mazzocchi <st...@apache.org>.
Jonathan Stimmel wrote:
>
> On Fri, Jun 30, 2000 at 07:18:33PM +0200, Stefano Mazzocchi wrote:
>
> > 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.
>
> Now *that's* a sitemap =)
Wow, seems it's gaining fans :)
> > 3) increased redirection capabilities
> >
> > <map:redirect-to uri="..."/>
> > <map:redirect-to resource="..."/>
>
> This has probably already been discussed, but are these done
> internally to cocoon, or by actually redirecting the browser?
internal.
External redirection is up to the logic in your components (you'll be
given the ability to add response parameters from all components... but
mostly you'd do from XSP.
> Imagine the following example (lifted from the draft) using
> client-side redirects:
> <map:match pattern="cocoon/dist/*">
> <map:choose type="ip-filter">
> <map:when test="allowsAddress()">
> <map:redirect-to uri="dist/cocoon/{1}"/>
> </map:when>
> <map:otherwise>
> <map:redirect-to resource="Access refused"/>
> </map:otherwise>
> </map:choose>
> </map:match>
> If the redirect is done client-side, then we have to insure that we
> perform the test a second time when the client returns for the
> new location, otherwise one person with access can distribute an
> unrestricted URL to the whole world.
>
> On further thought, I guess this is a problem in either case; the
> only secure way of doing this (without replicating tests) is
> to use the <map:redirect-to resource=""/> form. (It might be good
> to give this special mention in the redirect-to documentation; a
> novice (or even not-so novice) administrator could easily lull
> themself into a false sense of security...)
Sorry, I don't understand where the security hole is. Can you elaborate
more on this?
> > 6) added the notion of "views" and pipeline "labels".
>
> Hmmmm... I'm not certain I understand the intent here. It sounds
> almost like a mechanism to implicitly apply <map:choose> and
> <map:resources> (minus the generator) to pipelines. If this is
> accurate, do we necessarily need both views and resources?
No it's much more than this and yes, trust me, you'll need this _a_lot_
in the future.
I even venture to say that Cocoon views will make the XML successful,
otherwise, Cocoon will simply kill TBL ideas of a new web.
> > BIG NOTE: I believe this sitemap may result a little "pull" centric,
>
> True, but isn't that somewhat inherent to the HTTP protocol?
Great point (but it's not an excuse).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Jonathan Stimmel <jo...@stimmel.net>.
On Fri, Jun 30, 2000 at 07:18:33PM +0200, Stefano Mazzocchi wrote:
> 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.
Now *that's* a sitemap =)
> 3) increased redirection capabilities
>
> <map:redirect-to uri="..."/>
> <map:redirect-to resource="..."/>
This has probably already been discussed, but are these done
internally to cocoon, or by actually redirecting the browser?
Imagine the following example (lifted from the draft) using
client-side redirects:
<map:match pattern="cocoon/dist/*">
<map:choose type="ip-filter">
<map:when test="allowsAddress()">
<map:redirect-to uri="dist/cocoon/{1}"/>
</map:when>
<map:otherwise>
<map:redirect-to resource="Access refused"/>
</map:otherwise>
</map:choose>
</map:match>
If the redirect is done client-side, then we have to insure that we
perform the test a second time when the client returns for the
new location, otherwise one person with access can distribute an
unrestricted URL to the whole world.
On further thought, I guess this is a problem in either case; the
only secure way of doing this (without replicating tests) is
to use the <map:redirect-to resource=""/> form. (It might be good
to give this special mention in the redirect-to documentation; a
novice (or even not-so novice) administrator could easily lull
themself into a false sense of security...)
> 6) added the notion of "views" and pipeline "labels".
Hmmmm... I'm not certain I understand the intent here. It sounds
almost like a mechanism to implicitly apply <map:choose> and
<map:resources> (minus the generator) to pipelines. If this is
accurate, do we necessarily need both views and resources?
> BIG NOTE: I believe this sitemap may result a little "pull" centric,
True, but isn't that somewhat inherent to the HTTP protocol?
Re: [C2] (hopefully) last sitemap major changes
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> > > 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?
> >
> > I think the nearest we get in the first round is a FileAuthenticationChooser.
> > It will basically use a kind of .htaccess file in each directory, and then "grant access"
> > to that subpipe.
> >
> > I have also been lurking with the idea of a ResourceAuthenticationChooser, which would
> > work on the Resource abstraction in the sitemap.
>
> It would be great!
> In my point of view (correct me if 'm wrong) it is something like (not exact):
> classes : interfaces = file : recource
> So for resources:
> +2
hmmm, not really. It's more related to AOP than OOP.... but in general,
yes, the idea of a "resource" is more abstract than a "file".
> > Stefano/Giacomo, since I am looking into these Choosers at the moment, how do they get a
> > reference to the whole Cocoon context, and such thing as resource/path in process and so
> > forth.
> >
> > > > > 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?
> >
> > Site managers of course. Content creators and Style/Graphics people have no clue,
> > programmers never care, so...
> >
>
> Ok... mmm.
> Well, in an organization there are many different levels, and different
> people manage security for different contexts.
This is why the sitemap is cascaded.
> For example, there is a planning division, and the manager has the need of both
> authoring reports and setting access privileges for them. But he must not deal with
> security of other domains...
right.
> I guess that with your solution it could be ok:
> the site manager gives him access to only some directories, where he puts the
> files and the security files. Ok.
> But how about maintaining a security "database" that is dispersed in all the file system?
> I don't know the internals of .htaccess are but if they specify only the constraits (roles)
> needed as I think they do it could be ok.
Also keep in mind Cocoon is not a web server. You still have Apache up
higher if you need security in other locations of your URI space.
For the locations that are mapped to Cocoon, keep in mind you can have
different Cocoon instances mapped to different URI or virtual hosts.
Each one with different security capabilities due to Tomcat security
managers and custom classloaders.
Then, when you need to partition Cocoon behavior (sort of
security-views), you can do something like
<match type="uri" pattern="*">
<choose type="role">
<when test="administrator">
<mount src="file:///home/www/admin.xmap"/>
</when>
<when test="user">
<mount src="file:///home/www/user.xmap"/>
</when>
<otherwise>
<mount src="file:///home/www/guest.xmap"/>
</otherwise>
</choose>
</match>
with selective mounting, separating the working contexts from web
administrators with different skills.
> Then there is another point. (using the same example)
> Let's say that you need to limit portions of the report to users, and that this report is
> linked in another file: it would be nice that the link would not be shown if the privileges
> needed inside the file were not to be satisfied by the current user. It would need a special
> link tag that nows about other file restrictions.
No, you need to trigger a transformation in the sitemap based on
security parameters.
> Now I am duplicating the security info using my tablib security tag twice, but I have to
> keep both up to date.
Right. The sitemap should have control of all these things, demanding
complex logic to programmers.
> Any ideas?
> Today's innovation is tomorrows legacy. (just reminding myself of it)
No shit. This is why we want to get this sitemap thing right (or, at
least, best that we can) and make it simple but nor simpler.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Niclas Hedhman" <ni...@localbar.com>
> Nicola Ken Barozzi wrote:
>
> > > > 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?
>
> I think the nearest we get in the first round is a FileAuthenticationChooser.
> It will basically use a kind of .htaccess file in each directory, and then "grant access"
> to that subpipe.
>
> I have also been lurking with the idea of a ResourceAuthenticationChooser, which would
> work on the Resource abstraction in the sitemap.
It would be great!
In my point of view (correct me if 'm wrong) it is something like (not exact):
classes : interfaces = file : recource
So for resources:
+2
> Stefano/Giacomo, since I am looking into these Choosers at the moment, how do they get a
> reference to the whole Cocoon context, and such thing as resource/path in process and so
> forth.
>
> > > > 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?
>
> Site managers of course. Content creators and Style/Graphics people have no clue,
> programmers never care, so...
>
Ok... mmm.
Well, in an organization there are many different levels, and different
people manage security for different contexts.
For example, there is a planning division, and the manager has the need of both
authoring reports and setting access privileges for them. But he must not deal with
security of other domains...
I guess that with your solution it could be ok:
the site manager gives him access to only some directories, where he puts the
files and the security files. Ok.
But how about maintaining a security "database" that is dispersed in all the file system?
I don't know the internals of .htaccess are but if they specify only the constraits (roles)
needed as I think they do it could be ok.
Then there is another point. (using the same example)
Let's say that you need to limit portions of the report to users, and that this report is
linked in another file: it would be nice that the link would not be shown if the privileges
needed inside the file were not to be satisfied by the current user. It would need a special
link tag that nows about other file restrictions.
Now I am duplicating the security info using my tablib security tag twice, but I have to
keep both up to date.
Any ideas?
Today's innovation is tomorrows legacy. (just reminding myself of it)
Ken
Re: [C2] (hopefully) last sitemap major changes
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> Nicola Ken Barozzi wrote:
>
> > > > 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?
>
> I think the nearest we get in the first round is a FileAuthenticationChooser.
> It will basically use a kind of .htaccess file in each directory, and then "grant access"
> to that subpipe.
> I have also been lurking with the idea of a ResourceAuthenticationChooser, which would
> work on the Resource abstraction in the sitemap.
>
> Stefano/Giacomo, since I am looking into these Choosers at the moment, how do they get a
> reference to the whole Cocoon context, and such thing as resource/path in process and so
> forth.
This is the next thing we have to define after we are happy with the
sitemap.
Feel free to propose any addition/change to the Request/Response
interfaces we have.
> > > > 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?
>
> Site managers of course. Content creators and Style/Graphics people have no clue,
> programmers never care, so...
Right.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Giacomo Pati <Gi...@pwr.ch>.
Niclas Hedhman wrote:
>
> Nicola Ken Barozzi wrote:
>
> > > > 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?
>
> I think the nearest we get in the first round is a FileAuthenticationChooser.
> It will basically use a kind of .htaccess file in each directory, and then "grant access"
> to that subpipe.
> I have also been lurking with the idea of a ResourceAuthenticationChooser, which would
> work on the Resource abstraction in the sitemap.
>
> Stefano/Giacomo, since I am looking into these Choosers at the moment, how do they get a
> reference to the whole Cocoon context, and such thing as resource/path in process and so
> forth.
Maybe this can work: If a Chooser implements SitemapComponent it gets
called at request time with setup (request, response, source,
parameters). Can this help you? In the generated SitemapProcessor, I'm
working on, I've not decided to use a tree of Configuration objects to
serve the components (it derives directly from the sitemap.xmap). If
this is realy necessary I will first parse the sitemap.xmap file into a
tree of Configuration objects and afterwards generate the
SitemapProcessor from it.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: [C2] (hopefully) last sitemap major changes
Posted by Niclas Hedhman <ni...@localbar.com>.
Nicola Ken Barozzi wrote:
> > > 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?
I think the nearest we get in the first round is a FileAuthenticationChooser.
It will basically use a kind of .htaccess file in each directory, and then "grant access"
to that subpipe.
I have also been lurking with the idea of a ResourceAuthenticationChooser, which would
work on the Resource abstraction in the sitemap.
Stefano/Giacomo, since I am looking into these Choosers at the moment, how do they get a
reference to the whole Cocoon context, and such thing as resource/path in process and so
forth.
> > > 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?
Site managers of course. Content creators and Style/Graphics people have no clue,
programmers never care, so...
Niclas
Re: [C2] (hopefully) last sitemap major changes
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@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
Re: [C2] (hopefully) last sitemap major changes
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> This is the first time I am posting something on this list, so I would like
> to say hi to everyone. :-)
> Before I found out about Cocoon I was planning something similar...
> fortunately I found Cocoon before the code writing!
> Thanks to all the Cocoon developers!
Prego.
> ----- Original Message -----
> From: "Stefano Mazzocchi" <st...@apache.org>
>
> > 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.
>
> We will see how solid it is only after using it! ;-)
> Anyway you have your asbesto suit!
Nah, no need to wear asbesto suits around here.
> > 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.
> > 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.
>
> +1
>
> Imho one should use resources, it is easier when uris change, but this
> doesn't mean uris are not to be allowed.
right
> > 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.
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.
> Another thing is security.
yep, "another thing".
> Now I made my taglib for security but why not specify it in the sitemap?
For example?
> How does it relate to the contracts?
Which contracts? Sorry, I lost you here.
> 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?
> > 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...]
> > 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.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] (hopefully) last sitemap major changes
Posted by Donald Ball <ba...@webslingerZ.com>.
> I hope it doesn't get too complicated.
> 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.
holy ratatouille, batman! that's a hell of a chunk of XML there. you might
be interested in my castor logicsheet for doing database editing -
http://www.webslingerZ.com/balld/wz-castor-0.2.zip
- donald
Re: [C2] (hopefully) last sitemap major changes
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
This is the first time I am posting something on this list, so I would like
to say hi to everyone. :-)
Before I found out about Cocoon I was planning something similar...
fortunately I found Cocoon before the code writing!
Thanks to all the Cocoon developers!
------------------- initial compliments finished -------------------
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
> 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.
We will see how solid it is only after using it! ;-)
Anyway you have your asbesto suit!
> 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...
> 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.
+1
Imho one should use resources, it is easier when uris change, but this
doesn't mean uris are not to be allowed.
> 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?
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 >
Another thing is security.
Now I made my taglib for security but why not specify it in the sitemap?
How does it relate to the contracts?
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.
> 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...
> 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.
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.
> Let's polish it and let's rock and roll implementing it :)
Yeah! :-)
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)