This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 203793 - Schema-aware code completion does not work with abstract elements
Summary: Schema-aware code completion does not work with abstract elements
Status: VERIFIED FIXED
Alias: None
Product: xml
Classification: Unclassified
Component: Schema Tools (show other bugs)
Version: 7.1
Hardware: Macintosh Mac OS X
: P2 normal (vote)
Assignee: Svata Dedic
URL:
Keywords: API, API_REVIEW_FAST
: 161436 194299 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-10-17 04:50 UTC by dbell
Modified: 2011-12-06 08:54 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
A set of XML schemas that demonstrate the issue, and an XML document indicating the code completion context (Parental.xml). (9.70 KB, application/x-gzip)
2011-10-17 04:55 UTC, dbell
Details
Tests for the issue (99.03 KB, patch)
2011-10-17 06:10 UTC, dbell
Details | Diff
Excludes abstract elements from code completion suggestions, and adds all subtitutions for elements valid in completion context. (34.79 KB, application/octet-stream)
2011-10-19 12:21 UTC, dbell
Details
Aggregated diff (148.01 KB, patch)
2011-10-26 14:37 UTC, Jesse Glick
Details | Diff
Diff with review suggestions addressed (54.80 KB, patch)
2011-10-27 15:32 UTC, dbell
Details | Diff
Diff with more feedback addressed (54.21 KB, patch)
2011-10-28 05:55 UTC, dbell
Details | Diff
Diff with Svata's feedback addressed (53.00 KB, patch)
2011-11-07 07:20 UTC, dbell
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description dbell 2011-10-17 04:50:27 UTC
[ BUILD # : 201110140600 ]
[ JDK VERSION : 1.6.26 ]

Expected behaviour:
When an XML schema declares an abstract element (e.g. <xs:element
name="my-element" abstract="true"/>), schema-aware code completion should
suggest all available subtypes of the element.

Actual behaviour:
Schema-aware code completion makes two mistakes in this respect:
1) the abstract element itself is suggested (in the correct context, but
inappropriately because the XML document cannot actually contain the abstract
element: it can only contain _subtypes_)
2) the available subtypes are not suggested

Workaround:
None
Comment 1 dbell 2011-10-17 04:55:16 UTC
Created attachment 112108 [details]
A set of XML schemas that demonstrate the issue, and an XML document indicating the code completion context (Parental.xml).

Uploaded set of schemas demonstrating the issue. To replicate the issue, extract the schemas to a directory, open the XML document in the editor, and invoke code completion (Ctrl-Space).
Comment 2 dbell 2011-10-17 06:10:39 UTC
Created attachment 112109 [details]
Tests for the issue
Comment 3 Svata Dedic 2011-10-17 09:35:03 UTC
Correct, completion support should expand the substitution groups whenever it encounters a completion item, which is a head of a substitution group. Might be even non-abstract element.

Support for tracking subst groups is not present at all at the moment, because schemas may import each other namespaces, we cannot make backward references and model the substitution in the schema model - the expansion must probably happen in the completion code.
Comment 4 Svata Dedic 2011-10-17 09:41:42 UTC
*** Bug 161436 has been marked as a duplicate of this bug. ***
Comment 5 dbell 2011-10-19 12:21:36 UTC
Created attachment 112220 [details]
Excludes abstract elements from code completion suggestions, and adds all subtitutions for elements valid in completion context.
Comment 6 dbell 2011-10-19 12:23:15 UTC
Svata, please review.
Comment 7 Jesse Glick 2011-10-26 14:37:12 UTC
Created attachment 112461 [details]
Aggregated diff

The previously attached bundle cannot be used since some csets use a username @gmail.com which is forbidden and cannot be pushed. Anyway a number of changes remove largish files added in earlier changes, etc. For API reviews, or other cases where you reasonably expect to be heavily revising your changes and want to see what the final effect would be, http://wiki.netbeans.org/HgHowTos#Develop_API_review_patches_using_MQ is recommended.

Please consider whether xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/XMLSchema.xsd really needs to be there; three copies are already present in the source tree, including one in xml.schema.completion/src!

Also avoid adding *.zip files to sources. A unit test needing test data should ideally minimize it to the point that it can be comfortably committed directly (or even generated from the JUnit-based source code), which also compresses better in the Hg repo and permits subsequent test updates to be reviewable as patches.
Comment 8 Jesse Glick 2011-10-26 14:43:49 UTC
Note that since this applies to a public package, it should be API_REVIEW_FAST [1] (assuming it can be fixed to be compatible [2]) and should include changes to OpenIDE-Module-Specification-Version (or spec.version.base [3]), apichanges.xml, @since.

[1] http://wiki.netbeans.org/Review_Steps
[2] http://wiki.netbeans.org/API_Design
[3] http://wiki.netbeans.org/DevFaqImplementationDependency
Comment 9 dbell 2011-10-27 15:32:04 UTC
Created attachment 112507 [details]
Diff with review suggestions addressed
Comment 10 dbell 2011-10-27 15:41:57 UTC
Addressed the following suggestions:
sdedic:
1) Removed method renaming from AXIComponentFactory
2) Removed method addition from SchemaModel/SchemaModelImpl
3) Renamed lookup() method to avoid confusion

jglick:
1) Switched to aggregated diff
2) Removed excess XMLSchema.xsd instances
3) Removed zip from test resources
4) Bumped spec.version.base (and dependency from xml.schema.completion > xml.schema.model)
5) Updated JavaDocs with @since
6) Created apichanges.xml and documented API change
Comment 11 dbell 2011-10-27 15:53:10 UTC
Please review
Comment 12 Jesse Glick 2011-10-27 22:58:02 UTC
I do not know much about the domain so I hope sdedic can comment on the meat of the change. As to form:


Diff to SchemaModelImpl.java does not appear to do anything at all, should probably be reverted.


FindSubstitutionsVisitor does not look to be used except for its static methods, meaning that to minimize API surface the actual visitor should be hidden:

public class FindSubstitutions {
  public static Set<GlobalElement> resolveSubstitutions(SchemaModel model, String namespaceUri, String localName) {...}
  public static Set<GlobalElement> resolveSubstitutions(SchemaModel model, GlobalElement substitutionGroupHead) {...}
  private FindSubstitutions() {/* unused */}
  private static class FSVisitor extends DeepSchemaVisitor {...}
}

For that matter, only the rS method taking two String's seems to be used externally; the one taking GlobalElement could be left package private for the unit test (could always be made public later if it is needed).
Comment 13 dbell 2011-10-27 23:50:29 UTC
(In reply to comment #12)
Thanks for the feedback.

> Diff to SchemaModelImpl.java does not appear to do anything at all, should
> probably be reverted.
Agreed: it probably only has space added or something at the moment. I'll revert it properly.

> FindSubstitutionsVisitor does not look to be used except for its static
> methods, meaning that to minimize API surface the actual visitor should be
> hidden:
> 
> public class FindSubstitutions {
>   public static Set<GlobalElement> resolveSubstitutions(SchemaModel model,
> String namespaceUri, String localName) {...}
>   public static Set<GlobalElement> resolveSubstitutions(SchemaModel model,
> GlobalElement substitutionGroupHead) {...}
>   private FindSubstitutions() {/* unused */}
>   private static class FSVisitor extends DeepSchemaVisitor {...}
> }
This is essentially what I had at first, living in the resolvers (non-public) package. The reason I exposed the visitor was for consistency with the rest of the visitors package classes (it didn't seem to belong in the model package). Do you have a suggestion for where the above utility class should live? Actually, I just noticed that I forgot to hide the constructor and expose the substitution result set. Given that doing those things (hiding the constructor and adding an accessor for the result set) would reduce the API surface, does that sound like a reasonable compromise? 

> For that matter, only the rS method taking two String's seems to be used
> externally; the one taking GlobalElement could be left package private for the
> unit test (could always be made public later if it is needed).
That makes sense. Will do.
Comment 14 Jesse Glick 2011-10-28 00:12:17 UTC
(In reply to comment #13)
> The reason I exposed the visitor was for consistency with the rest of
> the visitors package classes

Then there may have been a sloppy API to start with. Someone knowledgeable about the details of the module should comment.
Comment 15 dbell 2011-10-28 05:55:46 UTC
Created attachment 112522 [details]
Diff with more feedback addressed

Feedback addressed:
jglick:
> Diff to SchemaModelImpl.java does not appear to do anything at all, should
> probably be reverted.
Done (also reverted SchemaModel.java for the same reason)

> FindSubstitutionsVisitor does not look to be used except for its static
> methods
Hid constructor, exposed result set. Awaiting feedback (perhaps from Svata?) on leaving visitor exposed to maintain consistency with existing visitors API.

> For that matter, only the rS method taking two String's seems to be used
> externally; the one taking GlobalElement could be left package private for the
> unit test (could always be made public later if it is needed).
Done
Comment 16 Svata Dedic 2011-11-01 12:38:50 UTC
*** Bug 194299 has been marked as a duplicate of this bug. ***
Comment 17 dbell 2011-11-02 08:17:37 UTC
Svata, have you had a chance to look into this?
Comment 18 Svata Dedic 2011-11-03 09:30:34 UTC
[SD4] getAllConnectedSchemas should use Set + check for duplicities, to avoid circular import references.

[SD5] resolveSubstitution should not log unresolved substitution at all, or with e.g. FINEST level - the situation is fairly common if the inspected schema is not interested in the nsUri:localName at all

[SD6] note that the client is responsible for traversing import/include schemas in the javadoc of forSubstitutionGroup(). I would even recommend to remove this method from public API, as a resolve() method exists already.

Sorry for not catching them during the 1st run

[SD6] apichanges.xml - at the end, please fill the placeholders in htmlcontents

re. visitors in general: I would actually prefer to hide the visitor classes behind one utility class; they are quite single-purpose to be classes.
Comment 19 dbell 2011-11-07 07:20:51 UTC
Created attachment 112890 [details]
Diff with Svata's feedback addressed
Comment 20 dbell 2011-11-07 07:27:20 UTC
(In reply to comment #18)
> [SD4] getAllConnectedSchemas should use Set + check for duplicities, to avoid
> circular import references.
done: recursed into referenced schemas and switched to use a Set

> [SD5] resolveSubstitution should not log unresolved substitution at all, or
> with e.g. FINEST level - the situation is fairly common if the inspected schema
> is not interested in the nsUri:localName at all
done: removed log.

> [SD6] note that the client is responsible for traversing import/include schemas
> in the javadoc of forSubstitutionGroup(). I would even recommend to remove this
> method from public API, as a resolve() method exists already.
I'm not sure which method you mean. I can't find one called forSubstitutionGroup(). If this method was present in an earlier patch, it might have been removed.

> Sorry for not catching them during the 1st run
No worries: thanks for looking into it.

> [SD6] apichanges.xml - at the end, please fill the placeholders in htmlcontents
done. 

> re. visitors in general: I would actually prefer to hide the visitor classes
> behind one utility class; they are quite single-purpose to be classes.
done: hid the visitor, but left the utility class in the visitors package. Is that ok?
Comment 21 Svata Dedic 2011-11-14 08:38:06 UTC
(In reply to comment #20)
> (In reply to comment #18)
> > [SD4] getAllConnectedSchemas should use Set + check for duplicities, to avoid
> > circular import references.
> done: recursed into referenced schemas and switched to use a Set
ok.

> > [SD6] note that the client is responsible for traversing import/include > I'm not sure which method you mean. I can't find one called
> forSubstitutionGroup(). If this method was present in an earlier patch, it
> might have been removed.
> 
OK.

> done: hid the visitor, but left the utility class in the visitors package. Is
> that ok?
OK.
Comment 22 dbell 2011-11-14 09:11:27 UTC
(In reply to comment #21)
Thanks Svata. Is this able to be pushed now?
Comment 23 Quality Engineering 2011-11-17 07:27:31 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/4967cd723300
User: Svata Dedic <sdedic@netbeans.org>
Log: #203793: Adds substitution group members to code completion
Comment 24 Jesse Glick 2011-11-17 15:28:56 UTC
Please do not forget the Target Milestone. Also check ide.branding/release-toplevel/CREDITS.html if you have not done so already.