cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Scott <>
Subject Re: XML Query language
Date Thu, 17 Feb 2000 15:14:41 GMT
Hi all,

I didn't realize my honest request would spark off such a heated debate
whilst I was snug in bed last night. I've only just got the chance to
read through the exchanges:

> >> >If you think Cocoon is "too" powerful and "too" useful and "too"
> >> >expensive... well, nobody forces you to use it. ;)
> >>
> >> Stefano. This is a glib response and unfair.
> >
> >You're right. Sorry about that, you come to help us and I blame you for
> >that... what an idiot... sorry again :(
> Ok, thank you for being honest.

Thank you, although I was probably being a bit over-zealous. If I
offended you, it was not because I do not respect and admire the work
you have done on Cocoon - quite the opposite. Like Mark Washeim, I
*want* to use cocoon because I think it is the best attempt at a
solution for concerns that I share with you guys.

> I do think it's a well thought out, methodical approach. It's just a
> question of how the theoretical contracts you propose, namely
> Management - Content - Logic - Style, can be accounted for in real world
> terms.

Here here.

> Perhaps the site-map is the only solution and it will simply require that
> authoring tools account for it and allow/facilitate access to the site-map.

I happen to think the sitemap is a great idea. I've often felt that a
central document (or group of) for managing a site would be a good

> >> I'm sorry to bitch, but the reason I use apache and jserv are exactly
> >> because I do NOT need to bind myself to jserv when building servlets. In
> >> fact, we have a whole application 'framework' that we easily 'port' (ie
> >> install) with different web servers and servlet engines without ever
> >> changing a line of code.

I am in the same position here, and I would like to keep it that way -
not because I want to 'dump Cocoon' but because I believe that it is
good practice. It's why I stick to the w3c HTML DTD's and plain SQL-92,
for example.

> >I'd like to think at myself as a catalist, rather then a benevolent
> >dictator or anything like that. But one thing is for sure: I want others
> >to come and help. I want others to express their opinions and make
> >critical suggestions on how to improve the system. I want this project
> >to be succesful in any possible way.

OK. If I could just address a couple of earlier replies you sent to me:

>This is what I find wrong. If I have something like this
> http://localhost/~stefano/address-book
>what happens? what's referenced by that URL? it could be a search page,
>a PDF report, an image with the pictures of all my friends, a xml list,
>a VRML space where I navigate the people... you name it.
>If I do something like this
> http://localhost/~stefano/address-book.vrml
>the above still holds true: the browser should understand what this is
>_only_ depending on the MIME type of the response. Unfortunately this is
>not so with many browsers (first of all, M$ IE) and what happens if you
>get tired of VRML and want to use X3D (which is XML compliant, and for
>this reason, more cool)? you have to change the URL.

I agree that the mime-type should dictate how the browser deals with the
content. IE really shouldn't be making any guesses here. But, taking the
Cocoon 1* addressing space, lets say I have a URL


and I want to give users a choice between XHTML and PDF? (maybe users
with a workstation want to view it online but mobile users want a
print-quality version - whatever). I don't want to duplicate the
content, but the format required needs to be communicated somewhere. 

I can see that you are addressing this problem with the sitemap, but I'm
still concerned about portability issues. Not because I want to ditch
the publishing framework a.s.a.p but because, like you, I'm an

>> This can't be an unusual request. Not wanting to teach you to suck eggs
>> (a British phrase meaning to tell you what you already know), the Cocoon
>> deal is also about management. I want to avoid maintaining multiple
>> documents containing the same content in different languages - that's a
>> management issue, because I don't want to have to edit each document
>> every time there is a change in the content - just like I don't want to
>> edit every page on a site if there is a stylistic change.
>Sorry, I don't want to be hard on you, but the above makes no sense: why
>would Cocoon limit you from doing something like that? I mean: the
>sitemap will allow you to do something like this

I take offense to this. I'm not some bumbling idiot that you need to be
'soft on' and you're not the architect of the internet. Sure, you're
breaking ground. Sure your doing a damn good job of it. Well done! I
don't expect my every need to be pampered, but I do expect my point of
view to be taken seriously. I *know* that the sitemap will allow me to
do this. Maybe in the future I will be using the sitemap to do this -
but for now I would like to be able to start using the XSL/XML
capabilities of Cocoon to solve the real-world problems I have today,
because I *know* that it is rooted in open standards.

>not that I like something like this... IMO, two files with different
>languages are normally handled by different persons and should reside on
>different files to simplify management... unless you have an automatic
>translator then you do

Two files, same content - maybe. 4,5,6 files, same content - nah. That
doesn't simplify management. It quickly becomes a nightmare.


Darren Scott
Technical Director

View raw message