Re: [xsl] nested templates?

Subject: Re: [xsl] nested templates?
From: "Kurt Cagle" <cagle@xxxxxxxxx>
Date: Wed, 16 May 2001 15:32:38 -0500
Alex,

I don't think that XSLT should be OO, but I argue in a book that I'm writing
that XSLT, in conjunction with Schema, XLink and RDF, works best when the
whole is considered as an OO system. XSLT serves as a mechanism for defining
methods on XML objects defined by schemas, schemas can be used as
constructors, inheritance is a natural consequence of the importing and
including mechanisms that XSLT has, and the stateless nature of XSLT
transformations makes concepts such as garbage collection pretty much moot.
The definition of encapsulation has to be stretched a bit, since you have
the multiple distinct conditions that XSLT makes it possible to create
methods that apply equally well to schemas that may have no particular
elements in common, but that are relationally similar.

-- Kurt


----- Original Message -----
From: "Alex Black" <enigma@xxxxxxxxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 16, 2001 4:54 PM
Subject: Re: [xsl] nested templates?


>
> hi tom,
>
> thanks - xsl:call-template is essentially what I was looking for re:
> "element handlers"
>
> I must disagree strongly with the idea that XSLT should be OO, it is
> specifically for building complex, nested _hierarchies_ - thus my post.
>
> Some examples from other posts: (as I have apparently started a fire)
>
>
> > Why not? A template matches a node, matching it by node type, by element
or
> > attribute type name, or by some other identifier such as an ID or key
> > value. It doesn't matter where in the source tree the node is, or how
deep;
> > once that node is picked up for processing (through an
xsl:apply-templates
> > instruction), the template applies. For a given type of node, you get a
>
> That's fine if you're dealing only with arbitrary nodes, which in _some_
> cases is exactly what I want to be able to do. xsl:call-template is
perfect
> for those cases, as far as I'm concerned.
>
> however, in many other cases I need to have a complete, editable picture
of
> the hierarchy of a document I'm creating.
>
> the lots-of-little-bits-way doesn't give me that. I've used nearly every
> kind of template system on earth, and I have found that I work much faster
> if I can mix "objects" (i.e. xsl:call-template  for a "bookmark" in the
> example I gave) and "documents" (large nested hierarchies, consisting
mostly
> of layout code)
>
> > given output. Why is this not useful? It seems particularly elegant and
> > powerful especially for the sort of semi-structured,
> > not-entirely-predictable, arbitrarily deep, hierarchical data sets
> > (documents) that are so common among markup applications. Many of us use
it
> > every day.
>
> Above, I have nothing against templates that do that, but I see no reason
to
> _prevent_ users from nesting templates.
>
> I'm not suggesting that you should _have_ to nest your templates, I think
it
> should be something that XSLT can do.
>
>
> > Since you used the magic word "goto", I think that the lack of structure
is
> > what is conceptually wrong with the original idea of "nested
templates(from
> > Alex Black) in the first place.  This is like the (legal) COBOL
structure
>
> This is confusing, as I am implying that I would like a more deeply nested
> structure that is currently doable with xslt.
>
> I want _more_ structure, not _less_ structure.
>
> > of PERFORM paragraphs A THRU K, and then having other places where you
just
> > PERFORM B (which was in the original sequence A THRU K).  This leads to
> > unmaintainable spagetti code in a big hurry.  I think this is why
Wendell
> > Piez and Tom Passin were urging the "lots of little bits" approach.  In
> > fact, Wendell was quite explicit about this (though he may not
appreciate
> > my "help" here).
>
> Right, which is why you should be able to do both, and mix them as you see
> fit.
>
> But I really can't come up with a good reason why it should be _illegal_
> syntax to nest <xsl:template> elements.
>
>
> _alex
>
>
> --
> alex black, ceo
> enigma@xxxxxxxxxxxxxxxx
>
> the turing studio, inc.
> http://www.turingstudio.com
>
> vox+510.666.0074
> fax+510.666.0093
>
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


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


Current Thread