Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: niclas@envision.asiaconnect.com.my
Message-ID: <3951BB88.C10A9546@localbar.com>
Date: Thu, 22 Jun 2000 15:08:56 +0800
From: Niclas Hedhman <niclas@localbar.com>
Organization: Bali Automation Sdn Bhd
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Sitemap Draft comments
References: <394F5B71.B9454649@localbar.com> <39511224.83208615@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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