RE: [xsl] Apply-templates - how to omit top level element tags?

["Mike Schinkel" <mikes@xxxxxxxxx>]

>> nodes in the input are explict.

Yes.  GLOBALLY explicit.  That's the problem; it requires one to
consider the entirety of the XSL for every change made.  What's worse,
it takes a long time to learn exactly what an XSL construct will do, so
it is easy to make a global change and have no idea that it will affect
something else.

>> Processing flow is controlled _by the document_ not by the
stylesheet.

Which works great, when the input follows the structure of the output.
Often it doesn't, or can't (if content needs to be output multiple ways
in the same document.)

>> It sounds like you'd rather have a language in which the document was
essentially input data not the main process control, and that process
flow was under the control of the stylesheet, so you can see what is
called when by looking at calls in the stylesheet rather than by looking
at the document.

In portions of the stylesheet, yes.  In others, no.

>> That's fine XSLT can support that style as well, just don't use
xsl:apply-templates,

I need both, but want it to be robust.   Would it help to actually see
my XSL and one of my XML files? (I'd have to email off-list, I assume.)
I'm not asking for your help, but instead thought if you saw them you
might be better able to see my concerns?  FYI, here is one of the output
documents from my XML & XSL process:
http://www.howtoselectguides.com/dotnet/visualstudio2005/


-Mike


-----Original Message-----
From: David Carlisle [mailto:davidc@xxxxxxxxx]
Sent: Friday, September 09, 2005 7:26 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Apply-templates - how to omit top level element tags?


> Yes, but in C, calls to functions are explicit; in XSLT, calls to
> templates are implicit.  That makes all the difference.

nodes in the input are explict. Having a node <foo/> in the input causes
a template matching foo to be invoked. If more than one template matches
there is a resolution mechanism but it's not much less explicit than
similar constructs in other languages.

what you call fragility is in fact the main design feature of xslt (and
most other document-oriented processing languages that came before it,
dsssl, omnimark, latex, ....) It's what allows you to write code that
can simply process natural language markup in which essentially
arbitrary structures appear in arbitrary order. Processing flow is
controlled _by the document_ not by the stylesheet.

XSLT2 adds a lot more strict typing controls than xslt1 but this basic
procesing model is still there.

It sounds like you'd rather have a language in which the document was
essentially input data not the main process control, and that process
flow was under the control of the stylesheet, so you can see what is
called when by looking at calls in the stylesheet rather than by looking
at the document. That's fine XSLT can support that style as well, just
don't use xsl:apply-templates, just named templates and call-template
(and xsl:for-each. This works well for regularly structured input such
as an xml view of a database, and is more or less (baring surface
syntax) the definition of Xquery, for exanple. It would make converting
(say) docbook to html much much more difficult.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. For more information on a proactive anti-virus
service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________