Lists Home |
Date Index |
- To: Michael Kay <email@example.com>, 'Pete Cordell' <firstname.lastname@example.org>, email@example.com
- Subject: RE: [xml-dev] XSL for non-XML input (Was: Re: [xml-dev] XML Hangover)
- From: Mukul Gandhi <firstname.lastname@example.org>
- Date: Wed, 13 Jul 2005 02:01:32 -0700 (PDT)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jL35pNzw+GN4JRrGT4p6dkg1ky2QqB1gaXragXhc+dD9NLNeW+oMO1ZfOp2BIacnnUJkOxHhnBKvnXY+VUDiywZxyma6IQ9P/kzCAstTVDE4GdjeR0O4M6zpbKHERtkE37gkwWyog6OHuYx2colU0qUhUNI5H+fQa6sCuiDotaA= ;
I get error
HTTP 404 - File not found
--- Michael Kay <email@example.com> wrote:
> Michael Kay
> Going further, observing the idea of using out of
> band data (e.g. schema) to
> provide extra information to complete 'binary XML',
> could XSL (with suitable
> front ends) work on say an ASN.1 encoded X.509
> certificate (and ASN.1
> message definition) and produce, say, a PDF output?
> Not that I have a need to do that right now! I'm
> just interested to know
> whether XSL can be used as a kind of universal data
> Pete Cordell
> Tech-Know-Ware Ltd
> for XML to C++ data binding
> (or http://www.xml2cpp.com)
> ----- Original Message -----
> From: Michael Kay <mailto:firstname.lastname@example.org>
> To: 'Joe Schaffner' <mailto:email@example.com>
> Sent: Monday, July 11, 2005 9:00 PM
> Subject: RE: [xml-dev] XML Hangover
> I've been reading the XML litterature. It's great.
> Just a few comments:
> Welcome on board. It's refreshing to get thoughtful
> comments from someone
> who's new to the game.
> XSL - XML Stylesheets is divided into two parts,
> XSL-T and XSL-FO.
> The T part deals with templates and translation.
> Since HTML is valid XML, I
> guess I can parse my HTML using XSL-T to produce XML
> and vice versa. I don't
> understand why XSL-T refers to "nodes in an output
> tree". This suggests some
> kind of internal representation, but XML is
> perfectly good representation
> language. Don't <templates> merely write XML text to
> No, the result tree is completely abstract, there is
> no suggestion of an
> internal representation. In fact, for many XSLT
> processors, the "result
> tree" is represented internally as a stream of
> events, not as a linked
> collection of objects in memory. This concept of
> writing a tree, rather than
> writing text, however is extremely important.
> Firstly, it defines a
> separation of the information content of an XML
> document from the accidental
> aspects of its lexical representation - something
> that is sadly missing from
> the XML spec itself. In turn, this gives you a basis
> for defining a concise
> set of operators that are in some sense complete,
> composable and exhibit
> closure. In practical terms, it gives you the
> ability to write a series of
> transformations - a pipeline - in which the
> expensive steps of serializing
> and parsing intermediate results can be eliminated.
> Roughly, the process seems to work like this: the T
> processor does a
> recursive descent of the source XML. At each node it
> evaluates the set of
> templates. Those templates which match the name of
> the "current" tag are
> processed, in some order. The template writes text,
> that's why it's called a
> "template. The recursive descent is continued with
> an <apply-templates> tag
> inside the template. This allows you to balance
> It doesn't have to do a recursive descent of the
> source XML: that's up to
> the application, though a recursive descent is the
> most common design
> pattern. And it definitely doesn't write text:
> people who create a mental
> model of writing text eventually get a rude
> awakening, usually when they
> first try to tackle grouping problems.
> If no matches are found, the T processor continues
> the descent.
> There is a <template> tag (I forget what) which will
> select arbitrary paths
> in the souce tree, and there are tags which iterate
> through the result.
> Again, it's best to think of the stylesheet as
> containing nodes
> (representing instructions) rather than tags.
> <xsl:element name="x"><xsl:value-of
> There are three tags there, but four nodes, and only
> two instructions. The
> semantics of the language are described in terms of
> the two instructions,
> not the three tags.
> This will allow me to build up a result "tree"
> which is not a mirror image
> of the source, something I need to do if I'm
> rearranging sections of the
> input document. Rather than buffering intermediate
> structures, the T
> processor does multiple passes based on these tags,
> and creates the output
> on-the-fly. Cool.
> ... .
> I assume there is nothing stopping me from using
> XSL-T to transform my HTML
> to PDF, but it seems best to output XSL-FO then
> create a PDF using some kind
> of tool. What is that tool?
> It's an XSL-FO processor. Examples are FOP, RenderX,
> Antenna House.
> Are there FO plug-ins available for my browsers?
> No, people are by-and-large using (X)HTML/CSS for
> the browser, XSL-FO/PDF
> for the printed page.
> Does this technology work?
> Absolutely yes.
> Michael Kay
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around