cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Ulrich Niedermann <niederm...@isd.uni-stuttgart.de>
Subject Re: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Sat, 27 May 2000 01:56:05 GMT
Stefano Mazzocchi <stefano@apache.org> writes:

> David Wagner wrote:

> Well, XML started on the client side... it was my personal idea (back to
> December 1998) to move it on the server side to avoid waiting for
> browsers to support those very nice ideas.

[ ... ]

> > xlink:show defines where the resource is
> > to display on the user's system.  For XHTML, the server would create
> > the appropriate link to the resource such that it will display in the
> > client at the right place, say as an img element (causing the client
> > to generate a seperate request for the image itself).  For WML and PDF
> > versions, an embedded image would be encoded and delivered with the
> > document, as their standards specify.  XLINK defines
> > xlink:show="embed" as, "An application traversing to the ending
> > resource should load it for display in place of the starting
> > resource... ...embedding affects only the display of the relevant
> > resources; it does not dictate permanent transformation of the
> > starting resource." [http://www.w3.org/TR/xlink/#link-behaviors]
> 
> I know that, the problem is _how_ the server knows this for every
> possible format language supported on the client side. Sorry, but I
> think XLink is mainly useful on the client side.

Perhaps as long as Cocoon helps XML-unaware clients understand XML one
should draw the border between server and client somewhere within
Cocoon. I.e. the "client" consists of some XML->HTML transformation
powered by Cocoon and e.g. Netscape 4 displaying HTML.

These "client layers" of Cocoon could well have some use for XLink.

Uli

Mime
View raw message