Community
Participate
Working Groups
On code hinting from an XSD stylesheet - If the XSD stylesheet looks like this : <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <!-- some stuff here --> <xsd:complexType name="object"> <xsd:attribute ref="name" use="required"> <xsd:annotation><xsd:documentation> The name of this object, e.g. 'User' </xsd:documentation></xsd:annotation> </xsd:attribute> </xsd:complexType> <xsd:attribute name="name"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="[a-zA-Z0-9_]+"></xsd:pattern> </xsd:restriction> </xsd:simpleType> </xsd:attribute> </xsd:schema> When I display code hinting for the 'name' attribute when displaying an in an <object> element, the <xsd:documentation> block does not display, as the code hint looks to the <xsd:attribute name="name"> declaration. This should not be the case, as the attribute 'name' could have different meanings depending on what element it is applied to, and therefore the code hint should look to the documentation that is applied to the attribute as it is done above. (I hope that made sense)
Craig, is this an error in our namespace algorithms, or, Amy, do our "hint lookups" need a little more sophistication?
Let me clarify the bug report with some steps to reproduce (correct me if i'm wrong here)... - create an XML document that is an instance of XML Schema pasted above (you'll need to tweak this schema to add an element declaration in order to create a valid document) - position the cursor inside like this... <object |> ...and invoke content assist - the 'name' attribute is suggested which is good - the information in the description window for the 'name' suggestion is not what is expected (the content of the documentation element is not shown)
I'm guessing the issue here is that the XSD content model skips over the attribute reference to the actual attribute to get the documentation. We need to fix the XSD content model implementation to ensure it checks for documentation in the attribute ref first, before walking over the the attribute. Notice that if I put the documentation on the attribute declaration that the information window displays the expected content (see test.xml and test.xsd attached above).
Created attachment 50751 [details] instance document of 'tweaked' schema
Created attachment 50752 [details] 'tweaked' schema to demo a case where things work I've added attachment to demo the case where things work as expected. In this case the user will see "Here's some documentation!" but really what they want to see is "The name of this object, e.g. 'User'". So our fix for this bug should be to check the reference first and use it's doc if present... otherwise walk over to the definition and use it's doc. The same goes the various ref constructs in XML Schema though elements and attributes are the important ones that are likely to be exposed in content assist.
Valentin, can you review and commit this?
Hi Craig, I assume you meant I should fix this bug. I don't see any patch attached. Did you maybe forgot to attach it if you have one?
Version: 3.3.1.1 Build id: M20071023-1652 Web Tools 2.0.1. I'm experiencing this issue or a very similar one with xsd:elements that have a ref attribute. XSD snippet that exhibits the problem: <xs:element name="call-template" substitutionGroup="xsl:instruction"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xslt"> Specifies the name of a template to be called. A called template is only executed when it is called. It is not executed directly by an apply-templates command. </xs:documentation> </xs:annotation> <xs:complexType> <xs:complexContent> <xs:extension base="xsl:element-only-versioned-element-type"> <xs:sequence> <xs:element ref="xsl:with-param" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xsl:QName" use="required"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xslt"> Required. The name of the template to be called. </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="with-param"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xslt"> Defines the value of a parameter to be passed to a called template. </xs:documentation> </xs:annotation> <xs:complexType> <xs:complexContent mixed="true"> <xs:extension base="xsl:sequence-constructor"> <xs:attribute name="name" type="xsl:QName" use="required"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xslt"> Required. The name of the parameter to be set. This must exist in the template that is being called. </xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="select" type="xsl:expression"> <xs:annotation> <xs:documentation source="http://www.w3.org/TR/xslt"> Optional. An XPath expression that is used to set the value for the parameter being passed to a template. </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> The issue here is this...the element "with-param" doesn't display any annotation information when you hover over it. The global element with-param has annotation information attached to it. It appears that when the ContentModel is grabbing the annotation information, it is not going back to the referrenced element to get that information if none is attached directly to it. Regardless of whether an element or attribute is a referrence, the following order should be checked to see if there is annotation/documentation for the particular item: 1. Check the local definition of the element. If their is locally defined annotation/documentation then use that for that particular point. 2. Otherwise, go to the refferenced item and grab the annotation/documentation information and get it from there. This is important because there are many industry standard schemas out that make use of global elements to document a particular element, and the current implementation only looks for annotation information if it is locally defined. Now where it does work for globals, is when an item is being used as part of a substitution group. This issue only seems to appear when the element is refferenced from within a ComplexType, and not being used by a substitution group. This bug will affect the proposed use of the WTP Incubator xslt project's use of xsd schemas for XSLT 1.0 content assist.
changed to wst.xsd for component as that is where the bug resides. Attaching patch to fix the issue.
Created attachment 85917 [details] Patch to correctly get documentation from referrenced attributes and elements This patch will correctly get the documentation when an attribute or element is referrenced, and the local declaration does not contain any annotations. What it does first is check to see if there are no annotations for the local element. If there are none, then it gets the documentation from the global declaration of the element or attribute.
Created attachment 85919 [details] Tweaked Patch to handle situations were annotation has appinfo but no documentation elements This tweaks the patch to handle those situations where an attribute or element may have an xsd:annotation/xsd:appinfo combination but doesn't necessarily have an xsd:annotation/xsd:documentation combination. If this was not checked, it would not check to see if the referenced item contained the documentation. This should now handle all situations correctly for elements and attribute documentation.
Valentin, any update on this bug?
Hi David, it's on my todo list for M6. Any chance you have time to create a JUnit for the fix as part of org.eclipse.wst.xsd.core.tests?
(In reply to comment #13) > Hi David, it's on my todo list for M6. Any chance you have time to create a > JUnit for the fix as part of org.eclipse.wst.xsd.core.tests? > Sure. let me look into it today...should have something no later than Wednesday.
Created attachment 93281 [details] Unit Test for supplied patch This provides a unit test for the patch provided. It loads the provided schema in this patch file, and makes appropriate checks against the content model, to make sure that information that is expected to be returned is returned. If not it fails the test. The schema attached in this unit test patch is original, and available under the EPL. Appropriate header information included. I created this schema myself.
Dave, the unit test patch seems to be identical to the code patch. Perhaps you've attached the wrong file?
Yeah, it looks like I exported the wrong patch. I'll correct this in a few.
Created attachment 93405 [details] Corrected Unit Test Patch Attached the corrected patch.
Hi Dave, thanks for the patch and the test. I've given them a try and I think they are good but need a little bit more work. The issue is with the support for attribute refs documentation. The way the patch is written now, the code will always check the actual referenced attribute declaration and not the attribute ref. This is because XSDAttributUse#getAttributeDeclaration() will return the actual global attribute. If you want to get the attribute declaration representing the ref you could use something like this XSDAttributeDeclaration xsdAttributeDeclaration = xsdAttributeUse.getContent(); Your unit test could also be enhanced to test documentation for attribute declaration, which is the original intent of this bug. I hope this helps. Thank you again for your contribution.
Sorry, we're out of time for M6, moving to M7.
Keith, perhaps we can try this fix for RC1.
Created attachment 101564 [details] Updated patch
Created attachment 101565 [details] Test for attribute refs
Created attachment 101566 [details] Test attribute refs XSD file
I've attached an updated patch to fix the documentation for attribute refs. Dave, please retry. Also, if you agree with the fix, can you please update your unit test? Thanks.
(In reply to comment #25) > I've attached an updated patch to fix the documentation for attribute refs. > > Dave, please retry. Also, if you agree with the fix, can you please update > your unit test? Thanks. > Sure. I'll try and verify this, this evening, and provide an updated unit test.
Doesn't look like we'll be able to get this into RC2. Dave, do you think this fix can wait for 3.0.1? Or is it a must for 3.0? In that case, please make the argument accordingly to support the PMC approval.
(In reply to comment #27) > Doesn't look like we'll be able to get this into RC2. > > Dave, do you think this fix can wait for 3.0.1? Or is it a must for 3.0? In > that case, please make the argument accordingly to support the PMC approval. > I would prefer if we can get this in for 3.0. The reason being is that as it currently stands, none of the documentation appears for the elements that use a ref attribute and don't have local documentation. This makes it appears as there is no documentation at all. When would 3.0.1 be done, if it is going to be September, as I'm not releasing my latest version built on 3.0 until late October. But the sooner the better.
Created attachment 101669 [details] Global Element and Global Attribute documentation unit tests I've added the unit tests for the global attributes as well as testing the local elements. Keith, the XML file isn't needed for the unit tests, just your XSD file is needed to test the files. This patch contains the unit test and the source xsd files.
added contributed keyword.
Thanks Dave, I ran your junits with the patch and it works fine. Yes, agreed the XML file is not needed. I attached it so that you can readily test out content assist manually.
PMC Approval Info: * Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. Adopter wants this fix for the incubating XSLT project. * Is there a work-around? If so, why do you believe the work-around is insufficient? No workaround. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Dave Carver added a junit test. It works correctly with the patch applied...(and fails if the patch is not applied). I also tested the patch manually. * Give a brief technical overview. Who has reviewed this fix? The content model currently gets the documentation elements from the resolved attribute/element declaration when determining the text to display for content assist. However, this assumption does not work when dealing with references. The documentation element can be attached to the reference, which can lead to no content assist documention showing when there really should be. The fix is to 'enhance' the getDocumentation method for elements and attributes to check if the references have documentation. If so, present that to the user. If not, then use the resolved reference declaration's documentation. See patch. I've documented the changes for attributes. Dave Carver documented the changes for elements. * What is the risk associated with this fix? This is a safe fix. The change is isolated to getting the documentation for elements and attributes and their references.
Dave, Keith, the fix looks good and works fine. Thank you for the unit tests! One small suggestions would be to move the new test resources in the samples folder and double check to make sure the case of the file name is right to avoid any issues when running the tests under Linux.
PMC, please review and consider approving this fix for RC3. See comment #32 for details.
(In reply to comment #33) > Dave, Keith, the fix looks good and works fine. Thank you for the unit tests! > > One small suggestions would be to move the new test resources in the samples > folder and double check to make sure the case of the file name is right to > avoid any issues when running the tests under Linux. > My development environment is is Ubunutu Linux so I know the test cases work there as well. So there is no case sensitivity issue.
I'm fine with this. Seems important, since it's such an old bug.
Fix released for WTP 3.0 RC3. Map entry tag for xsd.core and xsd.core.tests should be >= v200805282012
The junits are successfully running in the S-3.0RC3-20080528220621 build
Thanks for getting this in.
verified in wtp3.0RC4 20080609110539 sdk that the original use case submitted by Mark works now. and based on comment #38, other use cases work too, so I'm closing this bug. Mark & Dave, please reopen asap if this is still an issue.
