Community
Participate
Working Groups
I took a look through the buglist and I don't see anything for this. I would really like an XSLT tool which "knows" the document I plan to process and gives me content assist when writing xpaths. Naturally if it can do content assist it should be able to highlight errors instead of waiting for errors at runtime. Ideally I would be able to specify a sample XML document (similar to what I might use if I was using the launcher or debugger) and a schema that goes along with it. Then in areas where xpaths are used such as select attributes the string I've typed would be executed against that document so I can see where in the document I currently am and which nodes are available for selection. I don't know whether it would be possible to instantiate one of the existing XSLT processors in the background and use it for this purpose or whether it would require a new xpath processor to be written. Some cases like templates with match attributes could be tricky in either case.
One approach would be to make use of the launch configurations. They specify a particular XML file for the transformation, and also have all the information you would need to run background as-you-type transformations. Since the mapping from XSL file to XML input files is one to many, you would need a way of displaying a list of launch configs to the user for them to choose, and whichever they choose tells you the XML file to use as the context in XPath expressions. But the problem with that approach is that you couldn't specify an XSD's for the input context, which would be a shame. So I suppose the alternative is just to allow the user to select either and XML file or an XSD for the context, and then automatically create a launch config for that that can be run in the background.
(In reply to comment #0) > I took a look through the buglist and I don't see anything for this. > > I would really like an XSLT tool which "knows" the document I plan to process > and gives me content assist when writing xpaths. Naturally if it can do content > assist it should be able to highlight errors instead of waiting for errors at > runtime. The XSLT editor is namespace aware, so if you have your input document defined as one of the namespace and it has a grammar with it, that content model is available to the editor. Currently during XPath content assistance the available items aren't currently added to the proposal list. So we could look as a start as adding these to the proposal list based off some prior information that has already occurred. > Ideally I would be able to specify a sample XML document (similar to what I > might use if I was using the launcher or debugger) and a schema that goes along > with it. Then in areas where xpaths are used such as select attributes the > string I've typed would be executed against that document so I can see where in > the document I currently am and which nodes are available for selection. If you open the XML Document, and have the XPath Navigator view open, you can type your XPaths in there and see the results in the document....if you have an XPath already...we might be able to limited testing by providing a Run->XPath option on the selection from within the document. Some of this though is better done using the XSLT Debugger. 1. Here you could have a Context View, that shows the current context Node, and possibly have a way to link this with the XML input document. 2. Have the debugger view, allow you to change xpath expression and update them in place (this may depend on each of the debuggers and what they can do). > > I don't know whether it would be possible to instantiate one of the existing > XSLT processors in the background and use it for this purpose or whether it > would require a new xpath processor to be written. Some cases like templates > with match attributes could be tricky in either case. I think a combination of the two approaches I mentioned above would work. We definitely could had some basic content assist for XPath creation based off the namespaces that have been defined with the document. For those that documents that don't have a grammar we might be able to provide an option to allow you to associate a document while editing so that an inferred grammar could be created and used.
(In reply to comment #1) > One approach would be to make use of the launch configurations. They specify a > particular XML file for the transformation, and also have all the information > you would need to run background as-you-type transformations. Since the mapping > from XSL file to XML input files is one to many, you would need a way of > displaying a list of launch configs to the user for them to choose, and > whichever they choose tells you the XML file to use as the context in XPath > expressions. What I was thinking was a little bit like this. It needs to be similar to the launch configuration although the configuration you provide needs to be more hierarchical - it's unlikely anyone wants to setup a unique configuration for every file but they might. They also might just want one configuration for everything. > But the problem with that approach is that you couldn't specify an XSD's for > the input context, which would be a shame. So I suppose the alternative is just > to allow the user to select either and XML file or an XSD for the context, and > then automatically create a launch config for that that can be run in the > background. The XSD issue is the thorniest. The use case for this is that a number of different industries provide fairly hefty standard XML schemas which everyone works to. Individual XML samples might only use a fraction of what's in the schema yet people still need to keep the entire schema in mind when writing xpaths.
(In reply to comment #2) > If you open the XML Document, and have the XPath Navigator view open, you can > type your XPaths in there and see the results in the document....if you have an > XPath already...we might be able to limited testing by providing a Run->XPath > option on the selection from within the document. Some of this though is > better done using the XSLT Debugger. The problem as I see it is this. In a complex stylesheet there'll likely be lots of different variables defined, for example $company might be //abc:Company[@name='MyCompany'], $year might be $company/abc:CoreData[abc:Year == '2005'] and $customer might be $year/abc:Customer[@name='MyCustomer']. Now when someone comes in to perform whatever task it is they have to reconstruct this xpath mentally and constantly refer back either to the schema or whatever XML file they might have to ensure what they're doing is valid. Odds are they'll have to run it a couple of times and examine a stack trace and/or get stuck figuring out why an xpath didn't match. Now being able to run an xpath interactively is one step forward but what I really want to do is tie it all together. If someone types "$year/" and hits content assist it would be really nice if "abc:Customer" and whatever else is available at that level appeared. I guess they could examine it in the debugger but then that was also always possible with Java, it's when it was brought into the toolset that people really sat up and took notice. > 1. Here you could have a Context View, that shows the current context Node, >and possibly have a way to link this with the XML input document. > 2. Have the debugger view, allow you to change xpath expression and update >them in place (this may depend on each of the debuggers and what they can do). I think the ideal situation would be that content assist in the editor helps you build the xpath so it shows you only node names,attributes, operators etc while the xpath view shows you the results of your xpath as currently applied to whatever sample xml you might have configured. When the project is being build would it be possible to run the debugger on each file and build a model of the needed information? If some debuggers are better than others maybe the editor could just whichever is the best - it might produce some divergent results from whatever parser the user intends to use but I think most people understand what they see in their editor may not be the same as at runtime.
(In reply to comment #4) > (In reply to comment #2) > > > If you open the XML Document, and have the XPath Navigator view open, you can > > type your XPaths in there and see the results in the document....if you have an > > XPath already...we might be able to limited testing by providing a Run->XPath > > option on the selection from within the document. Some of this though is > > better done using the XSLT Debugger. > > The problem as I see it is this. > > In a complex stylesheet there'll likely be lots of different variables defined, > for example $company might be //abc:Company[@name='MyCompany'], $year might be > $company/abc:CoreData[abc:Year == '2005'] and $customer might be > $year/abc:Customer[@name='MyCustomer']. > > Now when someone comes in to perform whatever task it is they have to > reconstruct this xpath mentally and constantly refer back either to the schema > or whatever XML file they might have to ensure what they're doing is valid. > Odds are they'll have to run it a couple of times and examine a stack trace > and/or get stuck figuring out why an xpath didn't match. > > Now being able to run an xpath interactively is one step forward but what I > really want to do is tie it all together. If someone types "$year/" and hits > content assist it would be really nice if "abc:Customer" and whatever else is > available at that level appeared. Correct, some of this could be done by assoicating a particular file with an XSL Stylesheet, and having the ability to change this. The content model, and the XML file together with a grammar can providce the additional information to the xsl tools processor. I've seen this done in other XSLT IDE's. The key is associting an XML file with the stylesheet. Launch configurations don't necessarily need to be done to do this...They can be leveraged though. The content assist could look up and see if there is an existing launch configuration, and grab the XML input file to be used. Again, I've seen this sort of configuration done in other XSLT IDEs. > > I guess they could examine it in the debugger but then that was also always > possible with Java, it's when it was brought into the toolset that people > really sat up and took notice. > > > 1. Here you could have a Context View, that shows the current context Node, >and possibly have a way to link this with the XML input document. > > > 2. Have the debugger view, allow you to change xpath expression and update >them in place (this may depend on each of the debuggers and what they can do). > > I think the ideal situation would be that content assist in the editor helps > you build the xpath so it shows you only node names,attributes, operators etc > while the xpath view shows you the results of your xpath as currently applied > to whatever sample xml you might have configured. Let me work on some implementation of this after the first of the year. I think there are several stories to go with this. 1. Provide content assistance for the XML grammars known when constructing an XPath. 2. Look for XSLT Launch configurations for the current process, and select one of the XML files that exists for possible content assistance input, and validation of the xpath expression. 2a. Make XPath evaluation and expression assistance user selectable. Some xpaths could be long running and return a huge number of node sets especially if they are error prone. 3. Further enhance the support so that it tries to expand the variables and populate them as necessary, so if a select statement is set up like $someVariable/ that someVariable is populated and it's childelements are avaiable for content assistance. Remember just because an XPath doesn't return any information doesn't necessarily mean that on another input document it won't return something.
(In reply to comment #5) The key is > associting an XML file with the stylesheet. Launch configurations don't > necessarily need to be done to do this...They can be leveraged though. The > content assist could look up and see if there is an existing launch > configuration, and grab the XML input file to be used. The reason I'm thinking of launch configurations is the next level up again is to also have declared helpers in the content assist. This would need a classpath declaration with jars so at that point you have something very similar to a launch configuration only it defines what's available in the editor. > Let me work on some implementation of this after the first of the year. When I'm finished with the build path and facet tasks I'm happy to contribute to this also if there's anything I can add. > 2a. Make XPath evaluation and expression assistance user selectable. Some > xpaths could be long running and return a huge number of node sets especially > if they are error prone. Yes I definitely don't think this stuff should be running if people don't want it. There could well be scenarios with small stylesheets running against very large input files. > 3. Further enhance the support so that it tries to expand the variables and > populate them as necessary, so if a select statement is set up like > $someVariable/ that someVariable is populated and it's childelements are > avaiable for content assistance. This is pretty much what I'm looking for - an easy way to see where you are in the document in the current scope without having to spend time looking through variables reconstructing the xpath. There's also the issue of match templates which I think is probably more complex. A template with "match="abc:Customer" is going to mean "." is the same as $year from an xpath perspective. > Remember just because an XPath doesn't return any information doesn't > necessarily mean that on another input document it won't return something. Yes exactly, which is why I'd also like to involve a schema and combine the content assist with the xpath view. This way you can clearly see your xpath is valid according to the provided schema but provides no results based on your sample xml.
I've targeted this for 1.0M5 to implement the basics.
I've added some preliminary support for the XML elements that are defined via the namespace declarations. If the namespace is loaded up by either a custom resolver, or the XML Catalog, it will provide all available elements that can be applied to that position. Currently it's not very smart as it just provides a list of all available elements and doesn't try to determine the scope. If there is any documentation with the elements it finds, it will provide that information in the AdditionalInfo box. I've got some unit testing to do with this and will expand on the functionality as we proceede forward. As of right now it only does elements, I'll probably add a different class to add support for Attribute proposals that are available as well. Look for the first cut of this after the first of the year.
Still not sure if I want to add validation of the XPath created beyond whether it's syntax is correct, which is what we currently do. I still think a combination of the XPath navigator View and the editor can provide some of what you want in the way of evaluation as that actually Executes the xpath against the currently opened document in a SSE editor.
The basic code for this is checked in along with a unit test example.
This code has been released to the latest I-Build. The very basics are there, but there is some more testing with the XPath parser that needs to occur. Patches and enhancements are welcome, don't know if I'll have time during January and February to do much more with it. If I don't I'll split this bug into a couple of different ones to address each of the remaining features and close this one out. But I'll wait to do that until after the holiday's are over.
Dave, I've grabbed the latest code and I'm taking a look at it now. As for the validation, the way I look at it is if the content assist is context sensitive and works then it should technically be also possible to validate the complete xpath not just for syntax for also for correctness against the schema. In the same way in the Java editor you can get context assistance for variable names but even if you don't use it and you mistype a name it'll be highlighted as an error. Now in this case the configuration/resources for validation would be extensive enough that it's probably not going to be on by default but if the functionality is there it seems reasonable to let people decide how they want to use it.
(In reply to comment #12) > Dave, I've grabbed the latest code and I'm taking a look at it now. > > As for the validation, the way I look at it is if the content assist is context > sensitive and works then it should technically be also possible to validate the > complete xpath not just for syntax for also for correctness against the schema. > In the same way in the Java editor you can get context assistance for variable > names but even if you don't use it and you mistype a name it'll be highlighted > as an error. > > Now in this case the configuration/resources for validation would be extensive > enough that it's probably not going to be on by default but if the > functionality is there it seems reasonable to let people decide how they want > to use it. Validation is going to be a tricky thing as you said. Pretty much every XSLT editor I've seen or used has only ever done XPath sytnax checking, and did validation during the debugging or executing of the schema. We can help make the content assistance even more aware by knowing what can go in there based off a Model. Rigt now there isn't really a model backing the parsing of the XPath. We are using the parser from the apache commons JXPath library to walk the AST and Tokens to determine where certain items start and end. It's pretty crude, but it works for fairly simple assistance. I looked at one time in trying to use EMF to build a model of an XPath expression, but my EMF foo is weak, so I went with the crude method we have now. Any help in this area would be appreciated.
One other thing, we need to make the assistance more intelligent than it currently is. It's basically allowing all global elements to be added, but it really needs to be based off of the prior node, and what elements are allowed under that node. So using xhtml as an example. <xsl:template match="xhtml:html"> <xsl:value-of select="xhtml: "/> </xsl:template> The valid values for xhtml: should only include those items that are childred of the xhtml:html element and the xhtml:html attributes. Right now it just shows everything that is a global element. The Model Query has to take a DOM Node (node, element, or attribute) for the query to get available items. So we have to parse to basically create the DOM tree for the xhtml XPath expression above, and then take the last node in the tree to see what items are available at that context. The code I have in place gives an idea of how it can be done, and it's pretty isolated. I did notice that I missed the test attribute for this completion so I'll be adding a test to check there. If you do provide some enhancements please also provide a patch for the unit tests as well, this way we can make sure we don't do any regressions.
Stuart just a follow up to see if you had a chance to test this implementation. I'm not going to have much time before the end of 1.0M5 to finish this entirely, but I will try to schedule some more time in 1.0M6 to clean up any remaining xpath content assistance bugs.
Dave, I'm actually having some trouble getting everything to build at the moment. When I updated everything today I was missing the dependency org.eclipse.osgi.util. I trued just checking that project out from the eclipse repository but it didn't seem to help. I then downloaded the latest Eclipse SDK eclipse-SDK-3.4.1-win32.zip and the latest WTP wtp-sdk-R-3.0.3-20081113203138.zip but I'm still missing the OSGI requirement and a bunch of other ones. I'm probably not this the best way by manually putting together all the dependencies, is there a guide somewhere on how to setup Eclipse for all this?
(In reply to comment #16) > Dave, > > I'm actually having some trouble getting everything to build at the moment. > > When I updated everything today I was missing the dependency > org.eclipse.osgi.util. I trued just checking that project out from the eclipse > repository but it didn't seem to help. > > I then downloaded the latest Eclipse SDK eclipse-SDK-3.4.1-win32.zip and the > latest WTP wtp-sdk-R-3.0.3-20081113203138.zip but I'm still missing the OSGI > requirement and a bunch of other ones. > > I'm probably not this the best way by manually putting together all the > dependencies, is there a guide somewhere on how to setup Eclipse for all this? > Best thing to do since XSL Tools is built currently on Eclipse 3.5, is to download the preqs listed here: http://build.eclipse.org/webtools/committers/xsl-R1.0-I/20090114231606/I-I20090114231606-20090114231606/ Dave
Aha! I accidentally followed the link for the latest WTP release build which is how I ended up with Eclipse 3.1. I'm playing around with the XPath view and I'm trying to figure out how to use it. I have a generated web.xml file open which looks like this <?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <display-name> Test</display-name> <welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> <welcome-file>default.html</welcome-file> <welcome-file>default.htm</welcome-file> <welcome-file>default.jsp</welcome-file> </welcome-file-list> </web-app> If I type "//" I see the entire DOM view appear which is what I expect but if I click on it then it just brings me to the editor. What I initially expected was for that part to get inserted into the xpath I was typing. If I type "//web-app/" I get the error "A location step was expected following the '/' or '//' token." Playing around a bit I noticed clicking on each element in the editor view shows the xpath in the xpath view which is really neat. I caught it by accident though and only because I'm looking at this specifically so lots of people might miss it. What is the area under the xpath input box supposed to show? I sort of expect it to show the result of applying the xpath but it seems to not work in the current version.
(In reply to comment #18) > Aha! I accidentally followed the link for the latest WTP release build which is > how I ended up with Eclipse 3.1. > > I'm playing around with the XPath view and I'm trying to figure out how to use > it. I have a generated web.xml file open which looks like this > > <?xml version="1.0" encoding="UTF-8"?> > <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> > <display-name> > Test</display-name> > <welcome-file-list> > <welcome-file>index.html</welcome-file> > <welcome-file>index.htm</welcome-file> > <welcome-file>index.jsp</welcome-file> > <welcome-file>default.html</welcome-file> > <welcome-file>default.htm</welcome-file> > <welcome-file>default.jsp</welcome-file> > </welcome-file-list> > </web-app> > > If I type "//" I see the entire DOM view appear which is what I expect but if I > click on it then it just brings me to the editor. What I initially expected was > for that part to get inserted into the xpath I was typing. > > If I type "//web-app/" I get the error "A location step was expected following > the '/' or '//' token." > > Playing around a bit I noticed clicking on each element in the editor view > shows the xpath in the xpath view which is really neat. I caught it by accident > though and only because I'm looking at this specifically so lots of people > might miss it. > > What is the area under the xpath input box supposed to show? I sort of expect > it to show the result of applying the xpath but it seems to not work in the > current version. You have to have open the XML editor. The results of the xpath you type into the xpath input box will be executed as you type. It will show the resulting DOM tree that is returned. I'll play around with your sample input file and see if I can reproduce the errors you are seeing. If you have any redesign ideas or anything, on how to make using the view easier and more intuititve for the user they would be appreciated. Currently you have to copy and paste the XPaths you enter into the view. It would be nice to do Drag and Drop into the editor. Again, you have to have the XML file editor active for the XPath's you are creating in order to see the tree view. There is another view, that isn't currently enabled called the XPath Navigator view, and it works a bit differently. Source for that view is available also in the org.eclipse.wst.xml.xpath.ui plugin.
> > > > <?xml version="1.0" encoding="UTF-8"?> > > <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> > > <display-name> > > Test</display-name> > > <welcome-file-list> > > <welcome-file>index.html</welcome-file> > > <welcome-file>index.htm</welcome-file> > > <welcome-file>index.jsp</welcome-file> > > <welcome-file>default.html</welcome-file> > > <welcome-file>default.htm</welcome-file> > > <welcome-file>default.jsp</welcome-file> > > </welcome-file-list> > > </web-app> > > > > If I type "//" I see the entire DOM view appear which is what I expect but if I > > click on it then it just brings me to the editor. What I initially expected was > > for that part to get inserted into the xpath I was typing. > > > > If I type "//web-app/" I get the error "A location step was expected following > > the '/' or '//' token." > > > > Playing around a bit I noticed clicking on each element in the editor view > > shows the xpath in the xpath view which is really neat. I caught it by accident > > though and only because I'm looking at this specifically so lots of people > > might miss it. > > > > > What is the area under the xpath input box supposed to show? I sort of expect > > it to show the result of applying the xpath but it seems to not work in the > > current version. I can repeat your situation under Eclipse 3.4.1 with XSL Tools installed. However, it works correctly under Eclipse 3.5M4 and XSL Tools 1.0M4. I don't do much testing on Eclipse 3.4, because XSL Tools 1.0 is targeted for Eclipse WTP 3.1 and Eclipse 3.5. With that said it is probably something simple to fix, but it will be a low priority unless you are having problems with it under 3.5 and wtp 3.1 with code from head.
I installed the requirements from the page you linked above, in the about box the version number is listed as "Version: 3.5.0 Build id: I20081211-1908" I am using a project that was created in an earlier version of Eclipse and then imported, I'll try creating one from scratch and see if it makes a difference.
(In reply to comment #21) > I installed the requirements from the page you linked above, in the about box > the version number is listed as > > "Version: 3.5.0 > Build id: I20081211-1908" > > I am using a project that was created in an earlier version of Eclipse and then > imported, I'll try creating one from scratch and see if it makes a difference. > Okay, I managed to repeat the xpath view issue on 1.0M4 as well. It is having problems with the namespaces. if you have an xml file with out the namespaces you'll get what you expect. I've opened bug 261428 to track this particular issue with the view. Will target it for fixing early in 1.0M6.
Yep it works a lot better without the namespace. Where does the content assist come into play?
(In reply to comment #23) > Yep it works a lot better without the namespace. > > Where does the content assist come into play? > Content assit for the namespace input XML file comes into play in the select, test, and match attributes in the XSLT. If you specify the namespace in the XSLT and give it a prefix...in your sample case, add the JavaEE namespace to the XSLT, make sure the entry is in the XML Catalog (I believe it is by default), and specify the namespace with a prefix (i.e. xmlns:web="http://....") then in your select, test, or match statement start typing something like: <xsl:template match="web:web-app"> <xsl:value-of select="web:" /> </xsl:tempalte> in the select="web: hit CTRL+Space and you should get a list of available elements to be inserted for the web: namespace. Again, it has to know what grammar to use...if you have the Inferer Grammar option turned on it may be able to get a listing of suggestions based on what was done prior in the xslt, but no guarantee. It works best with a grammar. It has some issues which need some unit tests for, specifically if you have something like the following: web:web-app/ And try to do CTRL+Space right after the / it doesn't provide any proposals. However if you put a space after it, it will work. So this is a general parsing issue within the parsing code I have implemented. Should be easy to fix, I just have to create the test cases and implement it. I also would like to implement Content Assistance in the XPath View itself.
Where do I specify grammar options? What I did was go to http://java.sun.com/xml/ns/j2ee/ and download web-jsptaglibrary_2_0.xsd. I added this to the XML catalog in preferences. I added a NS declaration to my stylesheet and tried web: with CTRL+Space but nothing happened.
(In reply to comment #25) > Where do I specify grammar options? > > What I did was go to http://java.sun.com/xml/ns/j2ee/ and download > web-jsptaglibrary_2_0.xsd. I added this to the XML catalog in preferences. > > I added a NS declaration to my stylesheet and tried web: with CTRL+Space but > nothing happened. > Make sure you add the Namespace to the XML Catalog, and then specify the XSD. In your xslt <xsl:stylesheet xmlns:web="http://java.sun.com/xml/ns/j2ee/".... Then follow what is described in this blog entry: http://intellectualcramps.blogspot.com/2008/12/basic-xml-aware-xpath-assistance.html The namespace should be defined already I would assume for the J2EE if you have the JavaEE plugins installed from WTP. This article will help with working with the XML Catalog: http://wiki.eclipse.org/index.php/Using_the_XML_Catalog You may have to do a Reload Grammars once you add the namespace, but the editor should automatically pick it up. You should also get content assistance for the new namespace within the templates as well where you enter any type of xml tag.
(In reply to comment #25) > Where do I specify grammar options? > > What I did was go to http://java.sun.com/xml/ns/j2ee/ and download > web-jsptaglibrary_2_0.xsd. I added this to the XML catalog in preferences. > > I added a NS declaration to my stylesheet and tried web: with CTRL+Space but > nothing happened. > There is a bug in the Xpath content assistance and it is related the : and /s try. The assistance without the : type: web CTRL+Space That should get it to come up. Again it's one of those issues that need to be worked on.
I've fixed up a few more issues with the XPath proposals. You can now get completion right after a /, :, (, ), [, or ]. There may still be one touchy issue with :: but I'll work on that later. This code is now in head.
I haven't updated from HEAD yet but I haven't had any luck getting this to work without the : or / Here's what I did: 1. Downloaded http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd and stored it on my local filesystem 2. Created a user defined XML Catalogue entry with location "C:\Users\Stuart Harper\Downloads\j2ee_1_4.xsd", keytype "Namespace Name" and key http://java.sun.com/xml/ns/j2ee 3. Created an XSL as follows: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:web="http://java.sun.com/xml/ns/j2ee" version="1.0"> <xsl:output method="text"/> <xsl:variable name="newline"> <xsl:text> </xsl:text> </xsl:variable> <xsl:template match="/"> <xsl:apply-templates select="/documentation/file/url"/> </xsl:template> <xsl:template match="/documentation/file/url"> <xsl:value-of select=""/> <xsl:value-of select="$newline"/> </xsl:template> <xsl:template name="otherTemplate"></xsl:template> </xsl:stylesheet> In the template that matches "/documentation/file/url" I'm trying to use the content assist in the value-of statement. web CTRL + SPACE shows no entries and blank CTRL + SPACE just shows the normal list.
I've got another set of patches and unit tests to upload tonight. I'll let you know when that is done. Is the XSD that you are using available somewhere? This way I can test with it as well.
Yep you can get it at http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd and it's linked from http://java.sun.com/xml/ns/j2ee/
I've released the fixes I talked about yesterday, to head today. I'll look at setting up a test for your particular use case tomorrow.
(In reply to comment #31) > Yep you can get it at http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd and it's > linked from http://java.sun.com/xml/ns/j2ee/ The reason that this isn't working is that there are no Global elements that can be used to reference a group element. All this file contains are groups and Complextype definitions. So with the current implementation it can't find a proposal.
I've released to head the latest changes...that should handle the various places where XPath content assistance can be invoked. For the XML namespace assistance within a file there must be some global elements. This needs to be enhance to help determine the content assistance based on the definitions of the prior element and the context of the transformation. This at best will be a best guess. Stuart, please try this assistance with a Grammar that contains some global element declarations, and you should see the results that were indicated in the blog entry. I've tried it with the schema for XSD, XHTML, and SOAP and these all provided proposals when their namespace was defined in the stylesheet.
Retargeting for 1.0M6 as awaiting final approval on the IP before adding the functionality to check XPath 2.0 statements with the new PsychoPath XPath 2.0 parser contribution.
Correction, this is going in for 1.0M5. This contains the basic functionality, but will need further enhancements in 1.0M6. I'll open separate bug reports for this to continue development of particular features.
Resolving this initial bug, additional enhancements will be added as new bug requests.
mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.
