RE: XSL controversy

[Sean Mc Grath <digitome@xxxxxx>]

>Sean Mc Grath writes:
> > I do electronic publishing with XML/SGML for a living and
> > in my experience "funky" transformations are the norm rather than the
> > exception. I can assure you that they are more than
> > just of academic interest.
>
[Sebastian Rahtz] 
>Care to give some examples of day-to-day transformations that are beyond the
>scope of `normal' XSL? I am not doubting you, I am just curious as to
>what sort of things you have in mind.
>

Sure. Six off the top of my head that would be non-trivial to implement
in any declarative syntax:

1) The Irish Parliamentary Debate record is 3.5 GB of XML. We publish
this to HTML and Folio Views. Part of the publishing process is to
take each speakers name, pass it through a normalizer and look up
the speakers C.V. in a MySQL database. The C.V. details become part
of the generated HTML/FOLIO. The original XML is never changes
because it is quasi-legal material.

2) The PricewaterhouseCoopers manual of accounting is approximately
15,000 interlinked HTML pages. Part of the down-translation from
XML is to create a "faked" collapsible table of contents to appear
in a HTML frame. This, combined with some dense Javascript creates
the "illusion" of a collapsible/expandable table of contents using
IE 4/5.

3) The Financial Information Database is 1.5 GB of XML published
to winhelp, mediaviews, folio 3, folio 4, HTML and Lotus Notes. Part
of the publishing process is to grab product details from the XML,
root around in the filesystem for an Installshield template,
modify the template, invoke Installshield and generate
distributable media for the product.

4) A pre-publishing QA suite performs "fake" transformations
on XML documents in batch mode. It examines the result for
anomalies and sends e-mail to the nominated person if anything
worrying turns up.

5) 0.5 GB of accounting rules and regulations marked up in
XML contain extensive cross-references to Irish and English
legislation. As part of the publishing process, a
database of known anchors is assembled as a first pass.
In the second publishing pass, non-resolvable links are removed.
The result is that for a client in the UK, the links
to UK legislation work and the links to Irish legislation
have disappeared. For a client in Ireland, the situation
is reversed.

6) An XML micro-document based publishing architecture
is based on a rack mounted network of pentium PCs
running Linux. Downtranslation of gigabytes of XML
from a shared network drive is distributed across all
processors based on configuration information stored
in a XML based publishing control system.[1]

I can see places in all six systems above where XTL
can save me time and money but it will never replace
Python (and I don't think the designers intended it to --
especially since a turing complete escape hatch in the
original XSL hit the showers a long time ago).

The things mentioned above are where the rubber hits the road
in electronic publishing in my opinion. There is nothing academically
challenging about them. A pure exercise in "systems programming"
for self confessed engineers like me. However, it is stuff like
this that differentiates products in the marketplace either in
terms of features or speed to market.

---------------
[1]
I have written this one and it works fine with a network
of desktop PCs but I am having trouble sourcing a rack at
the moment! Any pointers appreciated...
---------------

regards,


<Sean uri="http://www.digitome.com/sean.html";>
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</Sean>



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