Community
Participate
Working Groups
Need the ability for as you type xsl validation. This should check constraints that are beyond just the grammar constraints. Ideally this will compile the stylesheet and leverage the error reporting from a particular parser for XPath compliation and validation of those xpaths that use variables and parameters. It would be nice as well to have the various error conditions configurable so that the user can set the error level information.
Doug, assigning this one to you since you are working on the XSL Source validator for the editor. Please track progress here.
I've checked in the beginnings of a validator that checks that called templates exist and parameters being passed in are present and correct. The validator builds a model that can be obtained via XSLCore (like JDTCore for Java). I'm going to work on it further, but first I need to know how to validate referenced files. For example, if a stylesheet is changed it will be validated. But if that stylesheet is included in another stylesheet, then I need to re-validate that stylesheet too, and that doesn't happen automatically. I've found an extension point called org.eclipse.wst.validation.referencialFileValidator that looks promising, but it doesn't seem to get invoked. Is there anyone with some validator expertise that can help out?
Open!
Doug, I'm adding Gary Karasiuk to this bug report, as he developed the new new Validation framework so should be able to answer your questions. One other thing, are you going to use Xalan to basically pre-compile the stylesheets and then catch any errors returned and set markers appropriately?
I haven't used Xalan for validation. I'm building the model by running XPaths against the DOM document (which is already in memory) created by the XML validator. Then I run a few selected checks against the model (idea being to eventually make 'compile' errors/warnings user configurable via preferences as for Java).
A suggestion would be to allow the user to specify an available processor to be used for the validation. The reason I suggest this is, that if you turn the work over to the processors like Xalan, and potentially any other XSLT processor that an adopter chooses to use the framework to implement, you aren't reimplementing what the XSLT processors/compilers have already implemented. I believe this is what the XML Validators and XSD Validators due and hook into the error reporting ability of each of these. Most of these should be handled by SAX parser events (I believ through the JAXP interface or better, hooking into the specific parsers directly). Otherwise, processor specific features for items like exslt and processor specific extensions are going to be more difficult to implement and validate against. The existing XML editors only handle the items that are specific to source editing, but leave the rest of the verification of the XML and XSD validation of the particular source to the parsers that are designed to handle that.
(In reply to comment #4) The framework that I'm working on is for build based validation. There is a different (but related) framework for as-you-type validation. The as-you-type framework is part of SSE. For the build based validation there is a dependency mechanism, where you can assert what resources that you are dependent on, and then if they change, you will be called so that you have a chance to revalidate. The two classes to look at are: org.eclipse.wst.validation.ValidationResult and org.eclipse.wst.validation.AbstractValidator
(In reply to comment #6) > A suggestion would be to allow the user to specify an available processor to be > used for the validation. The reason I suggest this is, that if you turn the > work over to the processors like Xalan, and potentially any other XSLT > processor that an adopter chooses to use the framework to implement, you aren't > reimplementing what the XSLT processors/compilers have already implemented. I'd argue that we already doing that more or less for content assist and whatnot... In fact, we could possibly take advantage the the XSLCore model in the content assist, too, for tracking things like the names of templates in included files. > The existing XML editors only handle the items that are specific to source > editing, but leave the rest of the verification of the XML and XSD validation > of the particular source to the parsers that are designed to handle that. True, BUT as-you-type validation is going to be very slow and CPU intensive if we rely on existing validator.
Always open to looking at better ways to work with the xsl content assistance, so if there is a better way to look up this information, we should pursue it. There are certain parts of validation and compilation that we are going to have to look at once we get more users. I definitely don't want to slow things down, but also I don't necessarily want to re-invent and implement code where it may not be needed. Again, I'm always open to looking at different ways to do things.
Doug, the xsl validator code is looking good. A thing to keep in mind for the XSL Core model for the templates is that xsl:template and xsl:apply have another attribute called mode, which needs to be kept track of as well. This is important to keep track of during duplicate template name checking, as it is valid for templates to have the same match/name values as long as they have different mode attribute values. The docbook xsl stylsheets make extensive use of the mode attribute to help control when a particular template is called, and I use it pretty heavily during my own xsl development.
One other thing on duplicates as well, is that it is perfectly valid to have templates from xsl:imports can be overriden by the stylesheet that is doing the importing. XSL Included templates have the same priority as the templates that are in the stylsheet that are including them. Just thought I'd put that here as well to keep track of it and make sure it's unit tested (this portion really needs some unit tests to make sure we are getting it right and don't break anything later).
I still need some help with SSE validation. The validation I have put into XSLCore is stuff I originally wrote for X-Assist, but for that I was using a custom project builder rather than SSE. The advantage of the builder was that I would get notice of all resource deltas, so if for example a stylesheet included in an XSL file is deleted from the file system I could trap that and create problem marker. But with SSE validation, I'm not sure where I can get them from within the SSE validation framework?
(In reply to comment #12) > I still need some help with SSE validation. > > The validation I have put into XSLCore is stuff I originally wrote for > X-Assist, but for that I was using a custom project builder rather than SSE. > > The advantage of the builder was that I would get notice of all resource > deltas, so if for example a stylesheet included in an XSL file is deleted from > the file system I could trap that and create problem marker. > > But with SSE validation, I'm not sure where I can get them from within the SSE > validation framework? > Doug, I think we are mixing two validation methods here. WST validators have two different types of validation that occurs depending on where it is kicked off. 1. Are the Source Editor validators (org.eclipse.wst.xml.internal.validation.MarkupValidator) which act directly on the Document that is in the source editor. 2. Are the Source Validators which act on the files on the file system. Some of what I think you are implementing for the real time validation, should go into similar code that is in the Source Editor Validator. I'm taking a look at your existing implementation, and may have a few suggestions. If so, I'll attach anything I come up with to this bug for you to review. The Source Validators are Gary's expertise since he helped rewrite that framework (IValidatorV2 i bleive), so should be able to tell you about incremental validation or dependent files.
(In reply to comment #13) > Doug, I think we are mixing two validation methods here. WST validators have > two different types of validation that occurs depending on where it is kicked > off. > > 1. Are the Source Editor validators > (org.eclipse.wst.xml.internal.validation.MarkupValidator) which act directly on > the Document that is in the source editor. And it could use any bookkeeping information about its dependencies, if these are recorded (so we wouldn't have to reparse everything) > 2. Are the Source Validators which act on the files on the file system. Some > of what I think you are implementing for the real time validation, should go > into similar code that is in the Source Editor Validator. Yes, I think it could use the same code, just a different route into the validator (1 is partial, 2 is total) > The Source Validators are Gary's expertise since he helped rewrite that > framework (IValidatorV2 i bleive), so should be able to tell you about > incremental validation or dependent files. I looked into this quite a bit, it is pretty nifty. You should call org.eclipse.wst.validation.ValidationResult.setDependsOn during the validation for resources which have been included (such as external XML entities). If validate an included stylesheet, you can set it in a call to setValidated. Check out the javadocs, they are informative. The framework is your friend.
Created attachment 93033 [details] Re-Adds As you type validation for the markup. This patch re-adds the ability to have as you type validation on the element names and attributes. It extends the MarkupValidator that is in the org.eclipse.wst.xml.ui.internal.validation package. It could be extended to provide additional checks that are specific to XSL validation including XPath compilations and error checks for the attributes.
adding noteworthy keyword so we know to write up something about this.
Moved to Incubator
Don't forget to attach some screen shots for this for the 0.5M6 release that is scheduled for April 7th. Those items should be attached for 0.5M6. If you can please close out this particular bug for 0.5M6 and open an new one for the continuation of the validation framework for 0.5M7, it looks like you have a pretty good start, and we can continue configuring as we go. One other option to think about and I did a bit of playing around with it this weekend, is that we may want to consider using EMF for the XSL data model. It's not overly difficult to generate the emf model from the XSD for xslt 1.0 or xslt 2.0. Just something to think about.
screen shots should be attached to bug 223719 along with a brief description.
Closing this bug as we have delivered basic editor validation for 05.M6. Bug 225421 will be for the source validation for ongoing development.
Mass Migration to wtp.inc.xsl
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
