[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: Mansour Al Akeel <mansour.alakeel@xxxxxxxxx> Date: Fri, 30 Nov 2012 11:38:53 -0500 |
There's source code highlighter for other languages, but didn't use it for xml http://sourceforge.net/apps/mediawiki/xslthl/index.php?title=Main_Page I am not sure if it handles xml properly. On Fri, Nov 30, 2012 at 8:57 AM, Philip Fearon <pgfearo@xxxxxxxxxxxxxx> wrote: > 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 > more. > >> 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, > > Phil
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Re: XSLT-driven syntax hi, Philip Fearon | Thread | Re: [xsl] Re: XSLT-driven syntax hi, Jirka Kosek |
Re: [xsl] Re: XSLT-driven syntax hi, Philip Fearon | Date | Re: [xsl] Re: XSLT-driven syntax hi, Jirka Kosek |
Month |