Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Reply-To: <dwagner@sa.kevric.com>
From: "David Wagner" <dwagner@sa.kevric.com>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date: Fri, 26 May 2000 11:44:37 -0500
Message-ID: <C9B23C6D1899D21188F600C00D009F8606EEA2@KEVRICSA1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-reply-to: <C9B23C6D1899D21188F600C00D009F8622FC03@KEVRICSA1>
Importance: Normal

> David Wagner wrote:
> > Ah, but I consider dynamically generated content as part of the
> > content layer, encoded in the RDF as is any another resource.
>
To which Stefano Mazzocchi Replied
> Ok, I understand.
>
> > The
> > programming needed extracts the current value of the resource and
> > presents it as any other resource request would.  How this
happens,
> > whether we call it a dynamic database request or a static
> page request
> > is irrelevant.
>
> Well, it's irrelevant to you that never wrote web-applications :)
> Anyway, I understand your point.
>
Which illustrates the design difference (not a flaw at all, perhaps
just a different target user of these systems) I was getting at.
Though I have written some fairly involved web applications, most web
publishers (as far as I can tell) have not, nor do they know this is
what they are doing when tossing a bunch of stuff on a server and
saying, "Hey!  Let's just put this stuff in a database and make all
the pages come out in a standard template!"

I am trying to consider what the user of Cocoon2 or another publishing
system is likely to do with it, regardless of what the package is
actually capable of doing.  For the most part (and this is what I
_think_ is a reasonable assumption), most of what publishers want to
do is publish stuff.  Every once in a while someone will think of
something truly new to add to a site (a new kind of resource needing
high-level programming), but for the most part publishers mix, match,
and customize a set of fairly common components along fairly stable
layout lines.  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.  "Cut
and paste until it works in IE4.01 and NN4.06," seems to be the
programming 'style' of all of those I have worked with in the US
Government and in small to middlin' business.  (For business there is
a strong incentive for a _lack_ of forward-compatibility: planned
obsolescence; the same business is likely to get the contract to
rewrite the same site over and over for every major browser release.)

> This is another way of expressing a sitemap, right into the
document,
> unfortunately, this requires client side operation, it has
> nothing to do
> with server side: what does it mean to "embed" a Gif image into a
> document on the server side? write the <img src=""> tag? include the
> binary as CDATA?
>
Client side operation?  I never considered running anything client
side...  Hmmm... That's an interesting idea...

Ah, but to answer your question, it could be either, depending on the
type of document delivered; 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 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 delivered
page when it can be embedded and cached in your client's computer as
mystunninglogo.svg.

> well, I'm not so sure you fully understand the paradigm shift
between
> server side and client side.... If we had a perfectly capable XML
> browser with all xml, xslt, xslt-extentions, xlink, RDF, SVG
> and XSL:FO
> in place, there will be very little need for Cocoon or anything like
> that.
>
OOooh...  Hmmm...  (btw: all my recent work has been on server-side
apps, except the client-side search page I needed to write for a CD
distribution of the contents of a web site; I am quite familiar with
the difference. :)  Interesting idea, but I disagree with your
conclusion.  IMHO, there would be even _more_ need for publication
site management tools, though such tools will need to be scalable both
UP to the international organization and DOWN to the individual user.
Anyone thinking about Cocoon3 yet?  (Suggestions: i18n, WAI Triple-A,
100% open standards, stunning front-end, name: Mothra ;)

> The problem is we _don't_ have these clients and we must _fake_ them
> using server side operation. Unfortunately, things work kind of
> different when distributed in client/server enviornment.
<snip/>
> This is highly subjective and clearly dependent on your programming
> background and mindset. Anyway, XSP and XSLT-extentions are
completely
> equivalent in functionality, this has already been analyzed, but
they
> represent orthogonal views of the same world.
<snip/>
> Totally. But, sorry, I still don't understand where is the design
flaw
> you underlined in your first email.
>
Ah, well, I think these systems have much more in common than
different, and I haven't found any design flaws, just a few
differences probably related to my timeline being set to incorporate
W3C X-standards as they stabilize to minimize the faking needed, and
to the intended users of these systems.  I am designing so even small
organizations (think individual activists) can get the good content
they have on the web and available to the greatest number of people
efficiently and effectively.

Thank you muchly for your thoughtful and considered responses to my
lengthy queries and explanations.  You have greatly increased my
understanding of this project, and of my project as well.  It will
help when writing and editing the documents y'all need.  I continue to
look forward to working with you and this fantastic team.

-David