[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