cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Sitemap Draft comments
Date Wed, 21 Jun 2000 19:06:12 GMT
Niclas Hedhman wrote:
> These things might have been discussed, and if so, ignore...
> a) What is the difference between the parameter "mimetype" and the
> parameter "doctype"?? They are both an input to the serializer, and it
> is up to the serializer to figure out what to do with them. But still
> "mimetype" is an attribute, and the others are <param> tags. Not
> consistent.

I believe it is: while "doctype" can only be used for SGML-aware
serializers, the MIME-type is general for _every_ serializer... also, it
is a REQUIRED field.
> b) Using "Access Refused" as a sample of resources is possibly a bad
> idea. It will generate a lot of overhead, since the browser sends a
> request, Cocoon will generate the reponse 401, then the browser will
> request the user/pass, and resend the request. Only if the user press
> escape, this page will be shown. I see further down, that the resource
> is used for excluding hosts, in which case a 401 should not be sent at
> all, but a 200.

Well, it's there to show the possibility, not to enforce usability
design patterns... these are separate things if they don't impact on the
sitemap schema.

> c) <choose>/<when> is a weird name pair in my ears. Both for programmers
> and non-programmers I think this feels wrong. <when> indicates a point
> in time, but it is a boolean test that is performed, in which case we
> normally use the notion <if>.

This is what XSLT uses and I never heard complains about it... in fact,
while <if> is more procedural, <choose><when> is much more declarative
and the sitemap wants to be declarative.

> We could also be a bit more specific
> (although increasing verbosity) by <when-true> or <if-true>, which also
> invites for a <if/when-false>. <choose> for me is also a bit odd, hard
> to explain. <use> (<proceed>) is my suggestion(s) (slightly depending on
> if more than one <when/if> section can be used/chosen). <use>/<if-true>
> is a lot more intuitive to me.
> That leaves the <chooser> hanging out dry. <selector> ??? I don't
> know...

I admittedly don't like "chooser" myself, but we didn't want to reinvent
the wheel and decided to stick with the XSLT schema for the boolean
conditional model.
> d) I saw some Email that the "test" attribute is executed in Java, and
> I assume the method is called on the "type" object. But the greaterThen
> (line 415) is bad Java naming convention and wrong spelling, should be
> verb, isGreaterThan().

this is none of sitemap concerns. It's another design level and it's
left to the component implementation.

> e) <default> is probably too programatic for most normal people. Default
> for other people is "unable to perform", such as "defaulted your mortage
> payments" (who hasn't?). See below...

You are right, in fact it should be <otherwise> like for XSLT (my
mistake, sorry).
> f)  I am still unable to figure out if all <when> sections, that tests
> true are executed, or only the first one found. And whether <default> is
> excuted if nothing else is executed or always. I would say that there is
> perhaps a need for both. And then we would be talking of a <otherwise>
> and an <also> or <always>. (Howcome all my suggested changes starts with
> a vowel?)

this is why I proposed both <match> and <choose> to increase the sitemap
declarativity... today it seems just a bunch of if/then and we all know
how painful those things are to maintain... expecially if you didn't
write them.

> g) The type="uri" is somewhat hardcoded in Cocoon??


> But what if I want
> an tricky match, which is easier expressed in Java? Couldn't that all be
> solved with the use of different attributes, instead of the same name
> for both, such as
> <choose type="uri">
>   <when match="niclas/*">
>   </when>
>   <when test="isRestricted()">
>   </when>
> </choose>

no, you are using two different choosers here.

> But this then implies that there is an object instantiated for the URI
> selection, and that this can be extended with my own type.
> SM mention that URI matching is native to Cocoon engine and is handled
> internally. Is there 'actually' a need for that?? I doubt that there are
> any performance benefits of burying this natively. Put it up front!!

the uri matching was previously hardcoded as a specific sitemap
functionality... this is not the case anymore.
> h) The Serializers have a src: attribute to instantiate an object, and a
> handful of <param> tags. I take it that they are passed to the created
> object as configuration parameters. Are we still in the Map idea of
> config parameters, or could there be an arbitrary structure passed to
> other classes upon instantiation?? In that case, is the <param>
> well-designed for the classes in the draft??

This brings another question: should we do use namespaces for the

This would allow us to write

 <sitemap:generator ...>

instead of 

 <generator ...>
  <param name="doctype">...</param>

without compromising readability as well as validability for XMLSchemas.


> Well, I am sorry if I am rumbling about old news, but I am trying to
> catch up real quick now.

no problem at all... it's always great to have more eyes on the problem.

> Generally speaking, I am rather pleased with the SiteMap now. A bit
> surprised that Stefano hasn't shouted FS all over the place. Not yet.

Not yet? you should see my whiteboard :)

> But I have a feeling it is way too complicated in large URI spaces,
> support for many browsers and many languages... On the other hand, it
> would be possible to design a SiteMap Lite, and with XSL transform it to
> the actual one. Interesting thought.

Yes, but this is a dangerous approach to base our reasonings on.
> Tracing what is happening will be an essential administrator tool, and
> must be considered initially. Just think about trying to figure out what
> is going on with multiple level cascades...

I agree... but, you know the old Perl tune: easy things should be easy,
complex things should be possible.

And Cocoon2 will make possible things that are too complex to be
possible today.

And keep this in mind: there will be Cocoon3 at some point :) Or maybe a
totally different project that will kick our ass on this... for now,
this is the best I could think off... next year, I'm sure we'll have
tons of things to say about this, but today this is what makes sense.

Even if I still have tons of questions unresolved in the back of my

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

View raw message