RE: [xsl] nested templates?

Subject: RE: [xsl] nested templates?
From: "Chris Bayes" <Chris@xxxxxxxxxxx>
Date: Thu, 17 May 2001 00:03:07 +0100
Kurt,
I wasn't suggesting that it should be. I was just comparing.
Like Rick just wrote me
we have flogged this dead horse
I agree. I was just kicking around some ideas.

How is the svg going?
Any good examples I can link to? (credits o'c')
This thing is blooming ;-))

Ciao Chris

XML/XSL Portal
http://www.bayes.co.uk/xml


>-----Original Message-----
>From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Kurt Cagle
>Sent: 16 May 2001 21:33
>To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>Subject: Re: [xsl] nested templates?
>
>
>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
>
>


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


Current Thread