Re: [xsl] Avoiding boneheaded mistakes in XSLT?

Subject: Re: [xsl] Avoiding boneheaded mistakes in XSLT?
From: Dave Pawson <davep@xxxxxxxxxxxxx>
Date: Wed, 29 Dec 2010 15:29:19 +0000
On Wed, 29 Dec 2010 15:20:35 +0000
David Carlisle <davidc@xxxxxxxxx> wrote:

> On 29/12/2010 14:39, Dave Pawson wrote:
> > Even without schema awareness/context, surely the processor can
> > tell when an xpath expression will result in zero match?
> >
> some things, like /.. but not things like the example at the start of 
> the thread where you go foo/node instead of foo/node()
> and most instances of /.. even though it can never select anything
> are not an error, as it was a common xslt 1 idiom for an empty node
> set equivalent to xpath2's () and it is often still used now, out of
> habit, or copying old tutorials.

Agreed if it is an idiomatic use (way down in the 20%) then it
may be misleading. I'd suggest if that is the case then the author
(probably) knows what he/she is doing and needs less help?

> something like schematron relies on you being able to match things
> that should not be there, so it can report when they are there.

Sneeky one but yes, I'd agree there. 

> the html schema will tell you you can't have two <body> children of 
> <html> but that doesn't tell you that html/body[2] will not select 
> anything unless your processing environment ensures that all input is 
> validated, and not passed to xslt if it is not valid. that is not the 
> most common xslt processing model.

So my use of html/body[2] could be reported to me as a warning,
again assuming that the xml instance being processed has no such
  And assuming no schema is in use.

My suggestion here is based on an instance and stylesheet, no more
input. Possibly there's no need for it if a schema aware processor
is being used with a schema. 



Dave Pawson

Current Thread