Message-ID: <010001be14ac$5d040eb0$0200a8c0@mdaxke.mediacity.com>
From: "Mark D. Anderson" <mda@discerning.com>
To: <new-httpd@apache.org>
Subject: Re: Templates and XML - Provoking to get Help !
Date: Fri, 20 Nov 1998 09:36:53 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

>The 'solution' seems to build a content structure (with a lot of variant
>fields where needed) and pass that to a template engine. Which has some
>discreation in which templates to pull in:
>
>cgi/mod_perl -> content-structure -> template engine -> html -> client
>                      ||                   |||
> XML or in 'perl'           |||
>                                         /  |  \
> templates, recursive and in
> different flavours; depeding
> on browser agent and accept language

Ok, you provoked me :).

As long as we are talking futures, the emerging "standard" pipeline
seems to be that of xml for data and xsl for transformation and style:
   data-in-xml -----------> xsl processor -> html
   style-sheet-in-xml -|

Until the browsers get better (and in many cases even after), all but
the html sits on the server.

in the simplest case, there is just one data file, and it has no i18n-able
strings, and no code. There is a set of style sheets with just
one set of static strings and no code.

Regarding i18n, it will be desirable for both the dynamic data file(s) and
for xsl files to be able to inline alternative language variants for strings --
or for them to indicate just a string id which can be looked up in a separate
external string-only resource file, using the appropriate lang context (so that
localization can be separated). You can find some discussion of this
on the xml-dev mailing list (ic.ac.uk) under the topic "XML and Internationalization..."
from a few weeks ago. With such an infrastructure, the selection of
appropriate strings can be done entirely at the level of the xml parser
and/or xsl processor.

Regarding multiple files, there needs to be a way for the processor to
involve multiple data files and multiple style sheets. In fact, while
style and content may be separated, style data may also be dynamically
generated (for personalization), or at least some of it might be.
These can all be brought together for example via a single meta xml
document that uses XLink, although the semantics of XLink for xsl and xml
is not yet fully fleshed out.

Regarding code, in general that might appear either in the "data" file
or in the style files, although of course one would usually prefer that to be
in style. Some of that code can be encapsulated in "behavior sheets"
(microsoft's proposal) or "action sheets" (netscape's), whereby one
declares event handlers for particular tags (this is a gross simplification).
There will also be a need for an arbitrary code escape; there has been
extended debate about the advisability of an "<xsl:eval>" tag which
could allow an arbitrary suitably capable scripting language to be
used which could reference the current processing context as well as
the DOM.

Regarding Perl specifically, there has been considerable work already
producing modules that fit in with just about every paradigm you might
want to use (closures, OO, procedural, etc.). Examples are XML::Grove,
XML::Parser, and XML::DOM. This is all discussed on the perl-xml
mailing list (activestate).

None of this is necessarily meant to dissuade you from you current approach,
which may be sufficient for your needs, and will work independently of the
speed of approach of new standards.

-mda