[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Re: XSLT-driven syntax highlighting for XPath 2.0, XSLT 2.0 and XSD 1.1

Subject: Re: [xsl] Re: XSLT-driven syntax highlighting for XPath 2.0, XSLT 2.0 and XSD 1.1
From: Philip Fearon <pgfearo@xxxxxxxxxxxxxx>
Date: Fri, 30 Nov 2012 13:57:27 +0000

On Fri, Nov 30, 2012 at 1:18 PM, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:

> I wonder if the XML parser has some limitations (such as processing
> DTD's or XML Schemas -- with all their features) on which the source
> XML document is based?

A small explanation: The XML 'Parser' for this purpose can be
extremely nieve because it assumes well-formedness.
This simplifies the code and removes the need to maintain state in a
highly recursive algorithm.
The span elements generated for output are all at the same level. It
doesn't parse DTD's unless they're internal -
because this is just a syntax highlighter. Entity references aren't
checked in any way - though a future improvement
would be to colorise them specially.

> I will need to spend some time to play eith this syntax hi-lighter
> (BTW, we need a better name for this kind of tools) but an apparent
> use-case I have is a special hi-lighting of variables/parameters.

Yes, some though required on the name selection - for the moment
syntax highlighter suffices - but this could evolve into something

> As
> we all too-well know one of the most frequent and most difficult to
> detect programming error is failing to precede a (what must be a)
> variable reference with the '$' character. I would like any such
> occurence to be hi-lighted in bold red, and in addition, even
> flashing. Just implementing this will save many hours of confusion to
> us all.

I agree this would be most useful as I often find I've omitted the '$' myself.
Though this would be a simplistic approach I guess the easiest thing
would be to just
have a key holding all the permitted element names (even ignoring namespaces)
and for each apparent element name found in the expression check for a match.

Also of interest, though too advanced for this implementation, one
thing I do in my own c# coded XSLT editors is verify that literal
result elements and attributes are arranged such that it is at least
possible for them to produce valid output (where an output schema is
selected from the editor) - otherwise the offending parts are
highlighted. This requires a form of 'interleaved validation' where
the XSLT elements are validated independently.For this, searches are
made of the Schema Object Model so there isn't too much of a
dependency on globally defined elements.

Thanks for this feedback,


Current Thread