cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Sitemap Draft comments
Date Thu, 22 Jun 2000 11:43:38 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message