Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 122836 - xsd:include not properly resolved
xsd:include not properly resolved
Product: xml
Classification: Unclassified
Component: Schema Tools
All All
: P2 (vote)
Assigned To: Samaresh Panda
Depends on: 168376
  Show dependency treegraph
Reported: 2007-11-27 11:03 UTC by tkellerer
Modified: 2009-10-12 15:23 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT

Display of the OrderDetail node in NetBeans (ordermanagement.xsd) (29.21 KB, image/png)
2007-11-27 11:06 UTC, tkellerer
Expandable display of the same node in XMLPad (18.43 KB, image/png)
2007-11-27 11:07 UTC, tkellerer

Note You need to log in before you can comment on or make changes to this bug.
Description tkellerer 2007-11-27 11:03:04 UTC
When viewing XML schema that makes use of xsd:include the referenced types are not show properly in the schema editor. 

I'm using the XCBL schema

When opening the file ordermanagement.xsd and viewing the structure of the Order type, it is not possible to view the
details of the OrderDetail node which consists e.g. of an ListOfItemDetail node, that contains a list of ItemDetail
entries, but these cannot be expanded in NetBeans.

Screenshots showing the schema display in NetBeans and e.g. XMLPad are attached
Comment 1 tkellerer 2007-11-27 11:06:30 UTC
Created attachment 53534 [details]
Display of the OrderDetail node in NetBeans (ordermanagement.xsd)
Comment 2 tkellerer 2007-11-27 11:07:37 UTC
Created attachment 53535 [details]
Expandable display of the same node in XMLPad
Comment 3 Samaresh Panda 2007-11-28 22:29:33 UTC
Reason being, ordermanagement.xsd includes OrderType.xsd and uses OrderType from there. OrderType in turn uses
OrderDetailType defined in OrderDetailType.xsd, however, OrderType.xsd doesn't include OrderDetailType.xsd. If you
include OrderDetailType.xsd in OrderType.xsd, you'll be able to see that.

Ideally, it should just work, but doesn't because of the way we resolve types.
Comment 4 Sergey Lunegov 2008-05-30 09:15:38 UTC
Sam I raised the priority to P2 since it impacts BPEL mapper. It was discussion about Dean's case.
Comment 5 Samaresh Panda 2008-06-02 21:41:36 UTC
Comment 6 Kirill Sorokin 2008-06-03 06:24:59 UTC
I believe you meant 6.5M1 as the target milestone.
Comment 7 tonybeckham 2008-06-18 23:09:19 UTC
Fix Verified

Product Version: NetBeans IDE Dev (Build 200806181204)
Java: 1.6.0_05; Java HotSpot(TM) 64-Bit Server VM 1.6.0_05-b13-52
System: Mac OS X version 10.5.3 running on x86_64; MacRoman; en_US (nb)
Comment 8 Nikita Krjukov 2009-07-07 13:43:01 UTC
The applied solution can cause serious performance problems. It is based on analysis of all Include dependences between
all Schema models are loaded by NetBeans. Here is the code snippet, which illustrates it:

         for(SchemaModel m: SchemaModelFactory.getDefault().getModels()) {

Moreover, the result can depend on content of schema models cache. Models are loaded by request so at the beginning not
all models are loaded. It can come to impossibility to resolve some references. 

It is suggested to filter out only relevant schema models. Full set of schema models can be separated by projects. It
doesn't make sense to try comparing models from different projects. Having such subsets of schema models can
significantly improve performance in some cases. 

I reopened the issue and changed it to ENHANCEMENT. 
Comment 9 Nikita Krjukov 2009-07-13 16:21:49 UTC
The current solution allows resolving only simple situations: A includes B and C. Declarations from C aren't visible in
B. Any more complex cases, for example, with more deep inclusion, don't work. 
Comment 10 Nikita Krjukov 2009-07-13 17:25:38 UTC
Here is the new fix:

It resolves problem with "only one layer inclusion", so now it is possible to resolve complex inclusion. 
Corresponding test is added: SchemaModelTest.testResolve6()

Also the algorithm is partly optimized. But it still hasn't manage to restrict scope, in which models' inclusion is
analyzed. Fortunately it turned out that it works fast enough because of models' dependencies caching (issue #158236).
But it is still necessary to resolve issue #168376. 

I don't close the issue now because I'm going to try applying another one optimization. The use case is discussed in the
issue seems quite exotic. In most cases the schema files includes each other if they use each other. So the resolving
approach has to be used as a latest attempt and only once per a resolve call. It seems now it can be called several
times. It's necessary to check and improve. 
Comment 11 Quality Engineering 2009-07-14 06:25:42 UTC
Integrated into 'main-golden', will be available in build *200907140201* on (upload may still be in progress)
Log: #122836 - xsd:include not properly resolved
Comment 12 Nikita Krjukov 2009-07-23 19:47:50 UTC

I've replaced the schema resolution algorithm. It has become more complex but now the different resolution ways are 
prioritized and the mega-include is executed at the end of the queue. 

Also I've done refactoring of the schema resolving tests and added about 10 new tests. 
Comment 13 Quality Engineering 2009-07-24 05:42:18 UTC
Integrated into 'main-golden', will be available in build *200907240201* on (upload may still be in progress)
Log: #122836 - xsd:include not propertly resolved
Comment 14 Nikita Krjukov 2009-08-05 19:11:11 UTC
Verified with JUnit tests + verifying different BPEL projects
Comment 15 pgebauer 2009-10-06 11:58:43 UTC
The fix has been ported into the release67_fixes repository.
Comment 16 Sergey Lunegov 2009-10-12 15:23:49 UTC
Verified by Michael Nazarov.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo