You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Niclas Hedhman <ni...@localbar.com> on 2000/06/20 13:54:25 UTC
Sitemap Draft comments
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.
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.
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>. 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...
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().
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...
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?)
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>
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!!
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??
Well, I am sorry if I am rumbling about old news, but I am trying to
catch up real quick now.
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.
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.
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...
Niclas Hedhman
Re: Sitemap Draft comments
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
>
> Stefano Mazzocchi wrote:
>
> > 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.
>
> NO, I can make a serializer that don't bother a second about MimeType.
Sure, that's the thing. mime-type is _NOT_ an attribute for the
serializer, is a attribute for the pipeline that will call setMimeType()
before the serializer is executed.
> My
> case is not about DocType itself, but the fact that some parameters to the
> serializer is an attribute, the others are <param> tags. Inconsistent.
It's not. the serializer doesn't have access to that attribute.
> > > 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.
>
> Agree, just want to highlight a possible future misunderstanding, if kept in
> the final version as sample.
>
> > > c) <choose>/<when>
> > 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.
>
> Ok :o(
>
> > > 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.
>
> Again, just highlighting small issue, that easily are forgotten in future.
>
> > > g) The type="uri" is somewhat hardcoded in Cocoon??
> >
> > no
>
> There are no 'uri' chooser declared in the draft sample. That's why I asked.
>
> > > 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.
>
> I think you missed my point a bit. But since the URI matching is not native,
> and you have proposed the match/choose separation, which I promote stronger,
> this is now a non-issue.
>
> > > 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
> > sitemap?
> >
> > This would allow us to write
> >
> > <sitemap:generator ...>
> > <doctype>....</doctype>
> > </sitemap:generator>
> >
> > instead of
> >
> > <generator ...>
> > <param name="doctype">...</param>
> > </generator>
> >
> > without compromising readability as well as validability for XMLSchemas.
> >
> > Comments?
>
> Of course. By using the namespaces, you are keeping the long term door open
> for all kind of extensions. Especially stuff like, tool generation of
> sitemaps, dynamic sitemaps and so forth (not that I necessary believe it will
> happen or is recommended.)
I agree.
> > > 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.
>
> Of course, we shouldn't. I was saying, that a sitemap spec that fulfills
> nearly all needs is the target, and then one might consider a simpler version
> for the 50-80% cases, such as new sites. And that spec sould be designed with
> a XSL transform in mind...
Being completely XML compliant and having good namespace support, I
think we are future-XSLT-compatible in every sense. I might say this is
a real beauty of the XML model: if you play by the rules, you gain lots
of benefits just by doing so.
--
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: Sitemap Draft comments
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> 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.
NO, I can make a serializer that don't bother a second about MimeType. My
case is not about DocType itself, but the fact that some parameters to the
serializer is an attribute, the others are <param> tags. Inconsistent.
> > 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.
Agree, just want to highlight a possible future misunderstanding, if kept in
the final version as sample.
> > c) <choose>/<when>
> 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.
Ok :o(
> > 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.
Again, just highlighting small issue, that easily are forgotten in future.
> > g) The type="uri" is somewhat hardcoded in Cocoon??
>
> no
There are no 'uri' chooser declared in the draft sample. That's why I asked.
> > 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.
I think you missed my point a bit. But since the URI matching is not native,
and you have proposed the match/choose separation, which I promote stronger,
this is now a non-issue.
> > 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
> sitemap?
>
> This would allow us to write
>
> <sitemap:generator ...>
> <doctype>....</doctype>
> </sitemap:generator>
>
> instead of
>
> <generator ...>
> <param name="doctype">...</param>
> </generator>
>
> without compromising readability as well as validability for XMLSchemas.
>
> Comments?
Of course. By using the namespaces, you are keeping the long term door open
for all kind of extensions. Especially stuff like, tool generation of
sitemaps, dynamic sitemaps and so forth (not that I necessary believe it will
happen or is recommended.)
> > 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.
Of course, we shouldn't. I was saying, that a sitemap spec that fulfills
nearly all needs is the target, and then one might consider a simpler version
for the 50-80% cases, such as new sites. And that spec sould be designed with
a XSL transform in mind...
Niclas Hedhman
Re: Sitemap Draft comments
Posted by Stefano Mazzocchi <st...@apache.org>.
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??
no
> 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
sitemap?
This would allow us to write
<sitemap:generator ...>
<doctype>....</doctype>
</sitemap:generator>
instead of
<generator ...>
<param name="doctype">...</param>
</generator>
without compromising readability as well as validability for XMLSchemas.
Comments?
> 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
head...
--
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 ---------------------