This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: nested templates?
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] nested templates?
- From: Alex Black <enigma at turingstudio dot com>
- Date: Wed, 16 May 2001 15:52:04 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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.
I think that's a stretch.
I think this kind of code should be perceived the way it will exist in most
system: a goober-mix of procedural and OO.
pure oo is great for logic, but this stuff isn't really logic in the
traditional sense.
have a look at the millions of examples of markup embedded in classes, and
you'll see my point: the two concepts of building large trees of
hierarchically organization data with meta description is fundamentally
different from the ides of (ex.) a transaction manager, which has a nice
tightly defined set of methods.
anyway, I love these kinds of arguments so tell me when to shut up.
_alex
--
alex black, ceo
enigma@turingstudio.com
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