Re: XML+XSL to HTML strategies advice needed please!

[Paul Tchistopolskii <paul@xxxxxxx>]

From: Dylan Parker

> Here is some things we would like to do :
>
> - JSP->XML->XSLT->(HTML | WML | ...?) (all done on serverside)
> - Localization (all text, images, prompts etc, would be in a specified language)
> - Strong separate of content/presentation.
>
> What I am curious about is different approaches and strategies for transforming
> XML to HTML with XSLT.
>
> For instance :
>
> Is it advised that there be a separate XML structure (DTD) for each page? Yes
> they will contain different information... and of course will be made as modular
> as possible to promote structure re-use..
>
> Is it advised to have different XSL files for each page?

> Since all text and images will be localized for a specific (choosable)
> language... how can one cleanly pass through things like link HREFs and and
> image SRC-URLs etc..

>From your explanation I think that you have  ( simplified )
1 source ( content ) -> multiple media ( HTML | WML )

Also in some cases we have to consider 'localized  for a
choosable language' do be  'one more media'. ( Especially
if you can not tolerate the possible lost of quality making
'brutal'  localization. For high-quality layouts, different
languages could get a bit different formatting ( the length
of some Japaneese sentence could be significantly different
comparing to the 'same' sentence in English and things
like that ).

>From my point of view you have 2 'general' ways here.

1. 'Standard way'.

Devote 'entire server to one media'. 2 media = 2 webservers
( one on port 80, another on port 81. Or use virtual hosting
e t.c. )

There is .xml part common to every server, but .xsl part
is different. This means that when binding some.xml
to some.xsl, for the server running on port 80 you
will invoke one stylehseet, but for the server running
on port 81 another stylehseet will be invoked
( even the rest will be the same. I mean  if you'l be
binding some.xml to some.xsl with PI
( standard way ) - the PI could be simply
hardcoded in some.xml )).

With this ( standard ) scenario you'l have "different xsl files for
each page" .

The drawback is that you'l have to cut&paste some code,
and / or do some not obvious <xsl:include / <xsl:import

2. 'Unix way'.

Compose each page that you have as a superposition
of transformations :

cat some.xml | aggregate.xsl | resolve-widgets.xsl | tune-for-language.xsl |
tune-for-media.xsl

This is not standard, but it works ( latest version of Ux ( http://www.pault.com/Ux/ ) )
shows how to use such view.

It is possible to do almost the same thing using xsl:import / include,
but what you *really* do will be translation of the pipe written above into
xsl:import / include constructions ;-)

> I have looked at many examples and tutorials but they all seem to think that
> everyone just wants to format a listing of books within an unordered list. I'm
> more looking for complete site strategies and approaches... methods of re-use
> and modularization across pages... templates and methodologies for reusing image
> template and anchor templates etc...

I suggest to "think pipes" and then implement the desired pipes using
any tool you like to use. Almost any existing XSLT engine allows
passing result of Transformation 1 to Transformation 2 ,
accumulating result of Transfromation 1 into variable and
then applying Transformation 2 to that variable
( of course, node-set() conversion is needed, but every reasonable
XSLT engine supports this conversion. ) Well, Ux
also allows document( "/! some | trasformation | here" ) - this
allows easy writing of 'aggregation stylehseets' , but I don't think
this feature is more critical than any other feature. 'Thinking
pipes' is critical, I think.

>
> Is anyone else doing this? I would be interested in what people have to say in
> this regard,

I think the problem is to get a nice set of 'universal formatting objects'
together with 'set of common transformations', then adjust some
of existing tools to 'Unix way'. Sometimes XML repository is
a missing link. Depends on the task.

To the best of my knowledge nobody has reasonable
plug & play solution.

AxKit ( perl  ) Gaucho ( Java ) could be used, but I don't feel  they're
'finished' tools, I think they are work in progress.

Ah - there is also Cocoon. I don't like it for many reasons, but I
remember that Cocoon was constantly promoted to be a
solution for your problem.

Rgds.Paul.




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list