Community
Participate
Working Groups
The W3C has a publicly available XSLT Schema for XSLT 1.0 at: http://www.w3.org/XML/2000/04schema-hacking/xslt.xsd It would be nice to have this built into the XML Catalog, so that it is automatically available to users. This would give the Eclipse Tools some basic built in support for editing XSLT style sheets.
XSLT 2.0 schema can be found here: http://www.w3.org/2005/02/schema-for-xslt20.xsd
I've submitted these schemas for Eclipse IP Legal review https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1748
I went to add the entries to the XML Catalog, and became confused (what's new :) As far as I can see, the entries should be <uri name="http://www.w3.org/1999/XSL/Transform" uri="xsd/xslt.xsd" /> <uri name="http://www.w3.org/1999/XSL/Transform" uri="xsd/schema-for-xslt20.xsd" /> But, doesn't the namespace have to be unique? What's up with that? I'm just looking at the namespace that's listed at the beginning of each of the files. One says <schema targetNamespace="http://www.w3.org/1999/XSL/Transform" elementFormDefault="qualified" version="April 15, 2000"> The other says <xs:schema targetNamespace="http://www.w3.org/1999/XSL/Transform" elementFormDefault="qualified"> If that don't have to be unique, then that's fine ... but, would appreciate it if one of you experts confirmed what the entries should be in the plugin.xml file that is in org.eclipse.wst.standard.schemas Thanks,
Oh, wait ... I think the browser's display was messing me up ... if I really look inside the file, the headers say <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3.org/1999/XSL/Transform" elementFormDefault="qualified" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> and <schema xmlns='http://www.w3.org/1999/XMLSchema' targetNamespace='http://www.w3.org/1999/XSL/Transform' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' elementFormDefault='qualified' version='April 15, 2000'> So, given that, I think the plugin.xml entries would be <uri name="http://www.w3.org/1999/XMLSchema" uri="xsd/xslt.xsd" /> <uri name="http://www.w3.org/2001/XMLSchema" uri="xsd/schema-for-xslt20.xsd" /> Feel free to correct me, or ... test out in a build in a few days! :) In other words, I'll release the files, and the plugin.xml and we can correct later, if it's wrong.
Marking as fixed, please verify in builds >= I20071104
David, unfortunately, this is one of those cases where the XMLCatalog isn't going to work. As the production XSLTs both use the same namespace. It's the target namespace http://www.w3.org/1999/XSL/Transform that is the important. Every XSLT will have a xmlns="http://www.w3.org/1999/XSL/Transform", and then it's up to an editor to check the version attribute to determine which schema to apply. The fix you suggested would require all XSLT 2.0 files, to use the http://www.w3.org/2001/XMLSchema as the namespace for XSLT 2.0 files, unfortunately this would break tool compatibility for XSLT 2.0 files. I think this bug is actually better attached to the XML Tools Development project as we will need to handle some of this programaticlly there based on some content-type extensions to the XML editor.
(In reply to comment #6) > David, unfortunately, this is one of those cases where the XMLCatalog isn't > going to work. As the production XSLTs both use the same namespace. It's > the target namespace http://www.w3.org/1999/XSL/Transform that is the > important. > > Every XSLT will have a xmlns="http://www.w3.org/1999/XSL/Transform", and then > it's up to an editor to check the version attribute to determine which schema > to apply. > > The fix you suggested would require all XSLT 2.0 files, to use the > http://www.w3.org/2001/XMLSchema as the namespace for XSLT 2.0 files, > unfortunately this would break tool compatibility for XSLT 2.0 files. > > I think this bug is actually better attached to the XML Tools Development > project as we will need to handle some of this programaticlly there based on > some content-type extensions to the XML editor. > Thanks for the reminders Dave. I'll clone a new bug to cover the content assist. So, we'll count this bug as simply putting them in the XML Catalog for other tools to use. I assume that's still desirable? Should I include a third catalog entry ... <uri name="http://www.w3.org/1999/XSL/Transform" uri="xsd/schema-for-xslt20.xsd" /> That would cover the version 2 case by default, or would that cause other confusion and problems?
At this point, having XSLT 1.0 support in the catalog would be desirable, and I think we can deal with not having XSLT 2.0 support. We can add XSLT 2.0 support once the XDT project is under way. It is deseriable though to have XSLT 1.0 support until that occurs.
(In reply to comment #4) > Oh, wait ... I think the browser's display was messing me up ... if I really > look inside the file, the headers say > > <xs:schema > xmlns:xs="http://www.w3.org/2001/XMLSchema" > targetNamespace="http://www.w3.org/1999/XSL/Transform" > elementFormDefault="qualified" > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> > > and > > <schema > xmlns='http://www.w3.org/1999/XMLSchema' > targetNamespace='http://www.w3.org/1999/XSL/Transform' > xmlns:xsl='http://www.w3.org/1999/XSL/Transform' > elementFormDefault='qualified' > version='April 15, 2000'> The targetNamespace is what you need to be concerned with. The XSLT folks when designing XSLT 2.0 did NOT change the namespace, which they probably should have but didn't. So, my recommendation right now is to only add in the XSLT 1.0 specification, and we'll handle XSLT 2.0 within the XDT project. I also think we need to find a newer XSLT 2.0 schema. I'll do some more searching. Dave
I've removed the schemas from wst.standard schemas, for now, since I didn't do it right, and still seems like some work is needed to know the "right" way to do it? Also, it was pointed out to me, that if it is needed/used by incubator project only, then it would be best not to "leak in" to WTP proper. For example, some adopters may provide their own, so we don't want to interfere with that, at least not until the time we can say positively how adopters should react. So, I'll leave this bug in 'reopen' state, for now.
Assigning to dave so this bug has a specific owner. Please re-assign if appropropriate.
The schema referenced in the original description text is obsolete, i.e. it's in the old (1999) schema grammar. I don't know how to transform it into a "modern" one, and doing it by hand is very error-prone. Do you (anyone, really!) have a stylesheet handy which can do this?
(In reply to comment #12) > The schema referenced in the original description text is obsolete, i.e. it's > in the old (1999) schema grammar. Jesper, the one in the first text seems to be accurate to XSLT 1.0, as XSLT 1.0 was approved as a recommendation in 16 November 1999. http://www.w3.org/TR/xslt > > I don't know how to transform it into a "modern" one, and doing it by hand is > very error-prone. Do you (anyone, really!) have a stylesheet handy which can do > this? If you can tell me what is wrong, I can correct it. These two schemas have passed IP review, just an fyi.
(In reply to comment #13) > (In reply to comment #12) > > The schema referenced in the original description text is obsolete, i.e. it's > > in the old (1999) schema grammar. > Jesper, never mind, I see what you mean, it's referring to the 1999 version of XSD. I can correct this. I work with XSDs on a daily basis, and this is one of the smaller ones I work with. I'll post the corrected version here.
(In reply to comment #14) > > Jesper, never mind, I see what you mean, it's referring to the 1999 version of > XSD. I can correct this. I work with XSDs on a daily basis, and this is one > of the smaller ones I work with. I'll post the corrected version here. > I didn't read this until I already started writing a small XSL transformation to handle this. So unless you've already done this, I can handle it. I just had hoped there'd be an easy way.
Actually, I've almost got this converted.
Re-Opening as XSD for XSLT 1.0 has been rewritten to use the correct schema language specification. Jesper this correctly validates in the XSD editor now, if you wouldn't mind helping me test it to make sure that it validates XSLTs correctly and provides the correct content assistance, I'd appreciate it. I'll correct any errors we find before we put it into the Incubator repository.
Created attachment 85881 [details] Corrects XSLT 1.0 xsd. This corrects the W3 version so that it uses the XML Schema 2001 1.0 specification instead of the draft 1999 specification.
one issue with the xsd, the substitutionGroups aren't working right for param and variables, and with-param items. I'm looking into it.
Created attachment 85884 [details] Modified version of XSLT 2.0 schema to implement XSLT 1.0 spec This replaces the original XSLT 1.0 schema. It is based off the XSLT 2.0 schema. There were numerous problems with the way the original XSLT 1.0 schema was structured. The XSLT 2.0 schema works and validates XSLT 2.0 files fine. It also validates XSLT 1.0 schemas, but would allow new elements in that aren't in the 1.0 specification. This version, strips out all the XSLT 2.0 enhancements and attributes, and leaves us with a working XSLT 1.0 schemas. One thing we should consider is adding in the appropriate annotation information so that documentation for an element is available with the content assistance. I have verified it against a 9000 line XSLT 1.0 stylesheet, that implements pretty much every feature of XSLT 1.0. The schema validated it correctly. Validation took less than a second.
Created attachment 85915 [details] Updated XSLT 1.0 xsd which contains documentation for attributes and elements. This is the update to the XSLT to include the following: 1. W3C Copyright statement 2. Eclipse EPL statement. 3. Date of Modification and reason for creating derrivate work. 4. All elements and attributes now have appropriate annotation/documenation information for each item. This will allows for the complete ability for Content Assist of XSLT, that also includes not only the content model, but any documentation for the particular elements and attributes available to be used at that particular point. This works with the existing XML Editor through the use of either a XML Catalog or schemalocation attribute. However, long term, the XSLT editor needs a way to specify the grammar to be used so that it may be applied. In the initial version we can support only XSLT 1.0 through the use of the XML Catalog grammar contribution mechanism, because XSLT 1.0 and 2.0 both use the same namespace. There is an open bug for an enhancement in 3.0 to allow the requested functionality required by an XSLT editor to contribute the grammar to be used for validation and content assistance. Jesper if you could take a look at this and do some verification on it that it is indeed working, I'd appreciate it. This will take care of many structural validations, but there are still a few dependency validations that will need to be handled by the XSLT interpretor when compiling the stylesheet. David, please review this to make sure that I've covered everything that is needed for any additional IP review we may need to have done. If it's okay, I'll get it attached to the appropriate CQ with an explanation of why we needed to update it.
(In reply to comment #21) > Created an attachment (id=85915) [details] > Updated XSLT 1.0 xsd which contains documentation for attributes and elements. > > David, please review this to make sure that I've covered everything that is > needed for any additional IP review we may need to have done. If it's okay, > I'll get it attached to the appropriate CQ with an explanation of why we needed > to update it. > Yes, looks fine to me. I would add an explicit encoding="UTF-8" to the XMLDecl, but looks like you have the IP stuff covered.
A patch in bug 157254 fixes an issue discovered with documentation and content assist that this particular schema brought forward. Bug 157254 needs to be fixed for this xsd to provide full functionality with annotations in content assist mode.
*** Bug 213854 has been marked as a duplicate of this bug. ***
This is implemented and targeted for M1. This currently only supports XSLT 1.0, but will support xslt 2.0 or 1.0 in the future.
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.
