cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Wagner" <>
Subject RE: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Tue, 30 May 2000 21:29:49 GMT
Stefano Mazzocchi []
<snip scope="ManyGoodComments"/>
> > Also (a personal observation), a frightening large
> > number of web publishers have no inclination to learn any kind of
> > structured techniques, be they programming or markup languages.
> This is _very_ likely to change once you show them the abilities you
> obtain by doing so. Also, XML defines validation and bases most of
> power on this.
We can only hope...  I'm still waiting for it down here in the

> We never tried to hide that Cocoon-based systems have a much steeper
> learning curve.
> But we say the plateaux is almost flat when you reach the top of the
> curve :)

> 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.
I think it was around then I also proposed using XML for content
authoring with the plan being to publish a series of CDs (the project
at hand) in the browser flavor of the month.  (Shot down: no time
right now for the front end work; we need content NOW even if the
whole project takes longer and costs more.)  I am a big fan of thin
(even emaciated) clients and efficiency.  Even passing all the content
component options to the client (as SMIL does) can become a big chunk
of bandwidth itself.  (Imagine delivering a page with all the
possibilities for each image in a typical navbar: #links x 3(states) x
(SVG + PNGlowres + PNGhires + GIFlowres + GIFhires + HTML4/CSS + HTML
2 + WML + ...).  I would rather not need clients to be half of a
supercomputer with a T1 connection just so people can read Alice in
Wonderland, or whatever.
> > Ah, but to answer your question, it could be either,
> depending on the
> > type of document delivered;
> Right. The question remains: how do you know? special extended-XSLT
> stylesheets with hooks to the request parameters? Sorry, but I don't
> think this is the path to simplicity.
<snip scope="myRamblings"/>
> 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.
This is the same logic needed by Cocoon2 to transform source content
into delivered streams.  In any case, the server, the client, and user
preferences must somehow determine the content, delivery media, and
presentation style desired.  XLink may simply be used in an RDF
linkbase to locate the source content components, define component
interrelations, and tie the content into meaningful clusters.  I am
still thinking the simpliest solution inolves XML-izing these
parameters and transforming the lot.  (Your conditional model is a
gorgeous insight into this; I was looking at the model SMIL uses to do
the same on the client side.)

> > I am considering how to use xinclude for resource inclusion in
> > delivered markup  to allow SVG and MathML to be
> (optionally) included
> > directly in the delivered document.  Why optional?  There's
> no need to
> > waste bandwidth including your stunning SVG logo on every
> > page when it can be embedded and cached in your client's computer
> > mystunninglogo.svg.
> Right. This is why URIs were created in the first place. And
> why Cocoon
> reacts on URIs.
Does this include fragments so I may reuse the parts of 'complete'
source documents in others?
<xinclude:include href='logo.svg#xpointer(id("ravenhead"))'/>
<img src='logo.svg#xpointer(id("ravenhead"))'/>
> > (Suggestions:
> > i18n,
> already implemented in Cocoon2

> > WAI Triple-A,
> what's this?
The Web Accessibility Initiative [].  Cocoon
would qualify as an authoring tool, I think, since it has the ability
to generate documents.  It's a darn good idea to think of the basics
early, since many of the commonsense recommendations of the WAI define
application behavior defaults.  The basic idea seems to be that Cocoon
should generate accessible content by default, though it may allow
document authors to override this good behavior.  The Cocoon home page
[], for example, has many errors (mostly
missing alt attribute and invalid P placement) and does not validate
as HTML 4 Transitional.  For WAI compliance (there are three levels
from A to Triple-A), Cocoon should generate only valid markup, and use
the accessibility options built into delivered markup languages fully
unless each is explicitly overridden by document authors.

> > 100% open standards
> are you kidding? do you see any proprietary standard around?
Well, umm...  Just the XML document standards y'all are writing.
(XSP, sitemap, ...)  100% open is probably not reachable, but I'd like
to minimize that learning curve for simple web apps.

<snip scope="MoreGoodComments"/>
P.S. I need to take your email, "Pipeline conditional model," home for
analysis.  It looks like it may, if generalized a bit, be a good
suggestion for the XML and XHTML W3C working groups.  Many XML DTDs
define conditional markup (XSL and SMIL come to mind immediately), and
a general means to do so may be a valuable addition to the standards.

View raw message