Re: [wtp-incubator-dev] Dependency on Validator framework - optionsgoing

["Jesper Moller" <jesper@xxxxxxxxxxxxx>]

Inline...

David Carver wrote:
>One thing I do think is relevant for us, though is the ability to be
>able to choose what Grammar is used for validation for the XSL
>Editors.   To this affect I have opened a couple of bugs asking for a
>way for the editor to specify a grammar to be used so that we can get
>both syntax and structural validation provided by either a DTD or Schema.

Are you talking about validation of the XSLT itself or the output nodes being created by the XSLT - or both?

As for validating the XSLT itself, the validation will be tied to the parsing. Basically, I'm going to parse and index the XSLT in order to produce correct cross-file validation and context sensitive content assist (names of templates, parameters, etc).

The long term goal here is to also have XPath completion. For this we'd need to keep track of scopes, etc. So we need to pretty much hard-code the XSLT grammars into Java anyway (in an extensible fashion, of course!). I think that's acceptable, if that's the cost of exemplary XLST editing support.

>https://bugs.eclipse.org/bugs/show_bug.cgi?id=210413
>https://bugs.eclipse.org/bugs/show_bug.cgi?id=210416

I don't follow the full implications of these, but as I read it, it mostly concerns XML as such - see below.

>Jesper Steen Møller wrote:
>> About XSL validation. It seems there's a new proposal (bug 212196) to
>> look into overhauling the validation framework of WTP in general [1].
>> All idea, no code (?). I have no idea whether that is in scope for WTP
>> 3.0 or not, or whether we should be making any assumptions based on
>> that. Dave, I know your gripes with the validators go beyond XSL, what
>> do you make of it?
>All of the comments in that bug are valid, and need to be addressed,
>however, I wouldn't hold out hope for it being done in time for WTP
>3.0.

As you may have noticed, it turns out that this code is pretty much done already, and will be committed for M4 !!!! While this is not what I would call an open process, I think the outcome is as good as could be hoped for.

> Just my two cents.  Validation of any type of XML file is really
>topic we could spend a year itself working on.

Yes, and the guts of XML schema validation is something I'd leave up to the experts at Xerces, Saxon, etc.

>I don't think you can
>necessarily treat validation like you do compilation of Java source
>files.  Start getting a large number of XSDs, and validation will take a
>long time.  Get a large set of XSDs, HTML, and other validator type
>files mixed into a project and it will drive it to it's needs and drive
>end users away.

It looks like the new framework will do this like it's done for Java, i.e. using pre-determined dependency information so incremental changes are manageable.

>We have to be careful with the same thing with any type of XSL
>validation that we want to implement.    I don't know exactly what is
>going to be the correct method, because with XSL validation you will
>have a two pass approach more than likely.  A structural validation of
>the XSL file itself, and then a syntax/compilation stage.

Yes, that's the deal. One for parsing (reads resources, builds a list of XSL constructs with external references), one for validation (checks these constructs against the resolved references, maintains indexes). When a resource is saved, it will be re-parsed and it will be validated, and so will it's dependents. That should be pretty fast. When the resource is edited in a n SSE editor, it will be incrementally re-parsed and the file itself will be validated). This is just like it's done in Java.

The indexes are used for hover and content assist stuff.

Doug's X-Assist plugin does some of this already, although not with the incremental validation and XSL content assist.

>I'd almost prefer having an Ant Task created, so that users could decide
>themselves what gets validated and what doesn't when directory
>structures change.

I assume that we're talking XML validation as such, not XSL... XSL is easy to deal with at the structural level - although it gets hairy when moving into XPath.

>> But as I see it, we have three options for controlling the XSL
>> validation:
>>
>> A - Await and encourage a new framework in bug 212196 [1], and align
>> with this from the start.
>My opinion, this is the long term goal.

This just became the short term goal!

>> B - Use the validator framework in place, but also push for bug 102882
>> (include/exclude paths, [2]) or bug 208448 (validator prefs at folder
>> level) and/or bug 187193
>
>This again is a trickier thing to do, because you really can't treat
>validation the same as you do with compilation, especially if you are
>focused on pure XML Development.  Validation can be a very long running
>process.

>> C - Make XSL validation "something else" outside the scope of WTP
>> validation (as Dave has suggested), more like a builder, with explicit
>> and very visible UI.
>I'd go vote for this approach for the short term...if nothing else, do
>an Ant Task approach, and allow exporting of an Validation build file,
>or something along those lines that the use could hook into the build
>system.  It would at least give finer control.

With the new controls over what goes where and how/when stuff is validated, I don't see the need anymore.

>> At any rate, I'm looking into writing a fast and accurate validator in
>> line with the requirements from bug 208836 (XSL Validation, [3]),
>> which will work well with  dependency updates and "validate as you
>> type" functionality. I'm trying to make it independent of the choice
>> outlines above.
>I like this idea as well.

And from a cursory glance at the API they provide in bug 212196, it matches my plans very well.

-Jesper