Web devel with python: Best route? XML to HTML translation!

[Alex Martelli]

<rturpin at my-deja.com> wrote in message news:93vnlv$2qq$1 at nnrp1.deja.com...
> In article <93hfp1013sm at news2.newsguy.com>,
>   "Alex Martelli" <aleaxit at yahoo.com> wrote:
> > All the presentation logic goes into the template, all of
> > the computation into the Python CGI script, and my little
> > yaptu.py (yet another python template utility, of course)
> > bridges the gap ..
>
> That's pretty good. It seems to me there is a better way.
> (1) The server scripts in Python generate XML. This is
> pretty easy to do with xmlpickle. (2) Use an XML to HTML
> filter to generate the HTML. Let the repitition of
> values in XML guide the repitition of the relevant
> sections of HTML. The advantage to this is that the
> same server side scripts can be used to generate XML
> (for downstream processing by another script) or HTML
> (for presentation in browsers).

I can do that -- just by using an XML template rather
than an HTML one, still with yaptu:-).  Yeah, yeah, I
know, that's cheating.  But, who'll write the appropriate
'XML to HTML filters' that output the same contents in
English, Italian, French, etc?  To write (and, more
relevantly, natural-language-translate) the HTML yaptu
templates, there are a zillion free or cheap HTML editors
which authors/translators can use.

XML may well be the best way to present complex data
that are being output, and it has the advantage that
any programming language whatsoever might be used to
produce it -- a big plus for some applications, no
doubt (as for my own needs, I've already indicated I
don't especially need portability along this axis --
Python will do, and it will handle any other language
that may be involved).  But merging the data with
presentation-specific material (which will include
natural-language choice, as well as style and layout
issues) is still a hefty job; for most of the kinds
of applications I've written, I think I'd _still_ like
some very simple templating utility at the server's
back-end, rather than doing (e.g.) localization to
specific natural languages in XSLT (XSLT is great for
'normalizing' stuff that follows different XML schemas
or DTD's to one standardized XML form -- but you still
have to provide for presentation-specific processing
of that 'one XML form', and I don't think XSLT is how
you ideally want to do this last optional step).


Alex