in reply to XML documentation formatting and transformations


Some flamage (start of message) and one advice (end of the message).

This is my anecdotical, highly opinionated take on XSLT:

ME : "Looks we have to adjust this another bit..."
Coworker: "Do you think we can get this to work before XML falls out of fashion?"

Basically, it looks like every time I fish out my XSLT, the task at hand is either:

  1. Nothing a good CSS could not handle


  2. Nothing I would not rather do with a glue language directly from the DOM.
And my question would be, why do we need a highly idiosyncrasiac, verbose, devious programming language for transformations? How is it superior to direct interaction with the DOM?
Besides it appears to have a slew of limitations - just by looking at the mailing list, it appears that every tiny departure from the text book examples require some extension (Saxon is often mentioned).
So I have long ceased to try to wrestle with XSLT. When CSS is not up to snuff I usually do (on Win32):
use Win32::OLE; my $parser=Win32::OLE->new('msxml.DOMdocument'); my stuff
On linux, you can get something similar from either the perl XML modules OR the Xerces-C module.

AxKit has a thing that is called (I think) XpathScript, which does much what XSLT promises to do, but with much saner syntax and looks (IMHO). I have never used it, but it would probably be my choice after going straight to the DOM.

You can't have everything: where would you put it?

Replies are listed 'Best First'.
Re: Re: XML documentation formatting and transformations
by John M. Dlugosz (Monsignor) on Nov 01, 2001 at 23:44 UTC
    Yea, it means learning another language. I could do it using Perl and the DOM now and it's fairly obvious just how to do it.

    If XSLT can't do what I want, I wouldn't even try, but go right to the Perl program.

    What does CSS do with XML? I know how to use Cascading Style Sheets level 1 for my HTML, but I've never heard of it transforming XML into HTML or otherwise enableing a browser like IE to present it nicely. Can you elaborate on that?


      I do this kind of stuff occasionally, so I am of little use without a reference (which I do not have by now) however: say

      <foo>this is your tag</foo>

      then you can style it in a CSS2 stylesheet like this:
      foo { display:block; color:red; }
      Which tells the formatter you have got a block level element, and to color it in red...

      See for instance:

      You can't have everything: where would you put it?

        Yes, that got me going. The following:
        class { display: block; font-size: xx-large;   }
        signature { display: block; font-size: large; margin-top: 1em }
        P { display: block;  font-size: medium; font-family: georgia, bookman, serif; margin-top: 1em }
        was enough to get readable output in a browser from my posted XML file.

        It seems that IE doesn't handle the :before pseudo-tag.

Re: Re: XML documentation formatting and transformations
by John M. Dlugosz (Monsignor) on Nov 04, 2001 at 05:13 UTC
    On Win32, you say you use Win32::OLE->new('msxml.DOMdocument');.

    Why do you use that instead of the various Perl modules? My first impression, formed by experience with DBI vs. ODB etc. and using Word and VSS from Perl, is that the OLE interface is clunky compared to a module designed with Perl in mind.

    So, does msxml do something that the CPAN modules don't? Or is there some specific advantage to using it?



      I should perhaps have told that my XML parsing needs do not have a very high byte count - so I am not very concerned about efficiency at this point.

      So the main reason for using the msxml COM engine is the same as for climbing mount Everest: it's there.

      I do not need to install anything ,and I get an alternate drop-inimplementation from Xerces COM interface (that I do have to install - check's site for xerces-c, not the like named java implementation).

      I could (but have not done it) get the native perl/xerces interface, whose performance should be comparable to xerces.

      As for perl's XML:: hierarchy, I do not know. I was never able to get a clean windoze install, from CPAN or otherwise though things hav eprobably improved since my last attempt. I heard people that went through it and were much less then awed by the performance level. (And truly, a large DOM tree made entirely of perl objects must be an unwieldy beast..)

      --<br: You can't have everything: where would you put it?

        Yea, it was an effort to install XML::Twig, since it doesn't have a PPM. I posted a new thread on that and windows installing in general.

        What good is half a gigabyte of RAM if not to support the occasional unwieldly beast <g>. I'll keep an eye on the performance issue. I can process a twig at a time on input, and I think I can render the twig into a text string and store it that way, even though I have to wait 'till I have them all so I can print the final file in sorted order. But that doesn't mean I have to keep a fully-parsed representation around!