cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Washeim <esa...@canuck.com>
Subject Re: XML Query language
Date Thu, 17 Feb 2000 21:45:00 GMT
on 17/2/2000 15.14, Darren Scott at dscott@bluecheese.co.uk wrote:

> 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.
> 

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
> approach.
> 

I hate what apache's httpd.conf file looks like when you have dozen's of
Location and Directory directives accross Virtual Domains. In fact I went
back to a pre 1.3 approach to the conf files (that is, extracted Modules,
srm, access) to clean it up. It was a nightmare to maintain. And directory
directives are actually quite XML like.


>>>> 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.
> 

Ditto!


>>> 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:
> 
> <snip>
>> 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.
> </snip>
> 
> 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
> 
> http://localhost/~dscott/reports/quarterly.xml
> 
> 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
> idealist...
> 
> <snip>

My main concern is that users all of a sudden need a site-map FOR the
site-map. They can no longer tell where the data is. Of course, one could
derive all possible interfaces and make a page displaying that. But for
content AUTHORS?


>>> 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
> </snip>
> 
> 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.
> 

Ditto! Though, I may be a bumbling idiot :) With the power to pay bonuses :)

>> 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.

Ditto. My problem space. I admit stefano DID say that cocoon is not an
entire Information Management System. Ok. More later.


-- 
Mark (Poetaster) Washeim

'In Xanadu did Kublai Khan
 A stately pleasure dome decree . . .'

 



Mime
View raw message