[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] Dependency on Validator framework - options going forward?
|
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.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=210413
https://bugs.eclipse.org/bugs/show_bug.cgi?id=210416
Jesper Steen Møller wrote:
Hi guys,
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. Just my two cents. Validation of any type of XML file is really
topic we could spend a year itself working on. 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.
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.
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.
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.
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.
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.
Dave
