[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: nested templates?

Subject: RE: nested templates?
From: "Chris Bayes" <Chris@xxxxxxxxxxx>
Date: Thu, 17 May 2001 00:03:07 +0100
nesting templates
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:  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:  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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.