cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <>
Subject Re: [RT] [OT] Content_negotiation++;
Date Fri, 26 May 2000 22:40:29 GMT
Hi all,

Sorry I've been so quiet. Bit of work and computer madness going
down (didn't help that I broke Xwindows this morning. whoops).

On Thu, May 25, 2000 at 02:16:15PM +0200, Stefano Mazzocchi wrote:
> Paul Russell wrote:
> > I hope I'm not infringing an unwritten copyright of Stefano's
> > here, 
> No, not at all. I'd love to have a collection of random thoughts from
> everybody on this list, it would make it easier to create a coherent
> model that fits all needs. The power of open source is that is also open
> developped. I wish more things were open developped.

Glad you think that way, same here.

> What you are talking about was already discussed previously and named
> "namespace reaction", this means that you indicate what transformations
> to apply when a namespace is found.

Ahhh. Does this have anything to do with the 'reactor' model
I remember reading about on the website?

> We'll see the problems this reasoning has.

Heh. okay.

> > Real Soon Now, we'll be able to use something called
> > 'content negotiation' to work out what format browers
> > would prefer without having to inferr it from the URL
> > or User Agent.
> I would say: as soon as the sitemap matchers are implemented.

The only problem with this is that currently, browsers have
a habit of not really putting much thought into their accept
headers. I was working with a site which had macromedia flash
content (anyone written a serializer for it yet? <g>), and I
didn't want to do any of the kludgy client side plugin detec-
tion stuff that people recommed. I wrote myself a little web-
server in perl (using LWP, which rocks for that kind of thing)
to see what the clients were doing. From what I can remember,
both netscape had a habit of sending

   Accept: text/html text/plain image/gif image/jpeg */*

... or something similar, regardless of plugins etc. All in all,
about as useful as a chocolate fireguard ;)

> Apache is very good at this, even if most people don't know it. The
> problem is that it's very good on static content only.

Yep, indeed it is. Apache's got a disturbing habit of being
good at everything, well, everything static, anyway.

> > All XML documents have a 'namespace'. 
> First problem:a  general well-formed XML document has "no" namespace.
> But I agree that every "good-behaving" XML document should indicate its
> namespace, just like any "good-behaving" document should use xlink for
> links and RDF for metadata.


> > [... 'translation map' ...]
> Ok, I see.
> What you are writing is a "translation map", instructions for what
> transformations to apply to come from one namespace to another. This is
> why I call it "namespace reaction": you feed the processing engine with
> instructions to allow it to understand, reacting on the namespace found,
> what transformation to apply.

Indeed. Look the final target up in the connected graph
(mentioned below), and traverse towards your destination.

> Second problem: there are _infinite_ ways to move from one namespace to
> another.
> This is called _styling_ :-)
> What you are proposing is a single-style, hardwired path between
> namespaces, which is good only if there is one and only one
> transformation style applied to move from namespace A to namespace B.

Yep. True.

> you are confusing MIME-types for namespaces. It is very likely that more
> than one namespace partecipate directly in the creation of one single
> MIME type (fo + svg -> pdf)

Again. True. Sigh.

> > When the source XML is parsed/generated, we discover
> > its namespace from the root element, and go find
> > ourselves that node in the graph. 
> AHHHHH! no way! the root element has nothing to do with the namespaces
> that can be found inside the document. You are confusing namespaces with
> SGML-like doctypes, which, in a true XML world make very little sense.

Yeah, you're right, I'm misunderstanding namespaces. I was think-
ing of <docroot xmlns="foo"> meaning that 'foo' was the doctype,
whereas actually it's just the default namespace.

> But I'm wide open to suggestions to integrate namespace reaction in the
> sitemap if you find this simplifies your life in situations I can't
> think of.

Nahh. As I said, I don't really thing this is an idea that ties
with Cocoon. The origional idea came about in relation to large
scale distributed application servers (don't panic, I'm not talk-
ing about making Cocoon distributed - that's a really *really*
bad idea). What I was considering, essentially was how to take
arbitary data from persistant objects and display it to a user
in some format. I'm still thinking about how to do this side of

> > [... stuff about 'packaging' filters so that staff ]
> > [ don't have to worry about sitemap configuration. ]
> Yes, this is clearly the idea scenario. I believe, on the other hand,
> that the real scalability power is done with cascading sitemaps. Of
> course, if namespace reaction is included in the sitemap, the cascading
> capabilitiy will inherited, so this is not a clear argument against
> namespace reaction.

Yeah, I agree. The new sitemap ideas rock, although I've
been a bit buried, and so haven't had a chance to pull
them to pieces yet. Tell you what, starting a company
certainly eats vast amounts of time ;). Rest assured I'll
try and find myself a few hours to play over the next
couple of days (between exams and meetings ;)

> Like I said, suggestions for integration are welcome.

Heh. As I said, I don't really think this is something
that we should be adding to Cocoon2 unless someone can
come up with a groundbreaking way of doing it. I think
it would muddy the waters too much, and detract from
the simplicity of Cocoon. I'm (obviously) going to
continue banging the idea around, so if I come up with
anything dramatic that means that it might be a benifit
to cocoon, then obviously I'll let you all know!

Paul Russell                               <>
Technical Director,         
Luminas Ltd.

View raw message