Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 134861 - Schema unable to show structure of included type
Schema unable to show structure of included type
Product: xml
Classification: Unclassified
Component: Schema Model
All All
: P1 (vote)
: 6.x
Assigned To: Samaresh Panda
: 134860 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2008-05-12 14:16 UTC by Nikita Krjukov
Modified: 2008-05-16 12:40 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

test project (7.57 KB, application/octet-stream)
2008-05-12 14:18 UTC, Nikita Krjukov
schema model (576.19 KB, application/octet-stream)
2008-05-15 06:21 UTC, Samaresh Panda

Note You need to log in before you can comment on or make changes to this bug.
Description Nikita Krjukov 2008-05-12 14:16:46 UTC
See the attached project below. The project is cut version of a real project. 

Open the project and BSF.xsd schema inside. 
There is the only complex type BDSMeterDataNotification and its structure 
isn't shown in the Schema view. I can see only Transaction as a leaf element. 
But it has not a simple type. Validation doesn't indicate any errors. 

I think it's a problem of Schema model because the same problem appears 
in the BPEL mapper, which uses the model directly to show the structure.
Comment 1 Nikita Krjukov 2008-05-12 14:18:48 UTC
Created attachment 61260 [details]
test project
Comment 2 Sergey Lunegov 2008-05-12 15:00:39 UTC
Sam, would you please provide quick analysis what is the root cause of the problem. This is request from one of our
potential customers and quick evaluation is very nice to have.
Comment 3 Samaresh Panda 2008-05-12 20:54:34 UTC
*** Issue 134860 has been marked as a duplicate of this issue. ***
Comment 4 Samaresh Panda 2008-05-13 00:00:35 UTC
I do see the issue, however, I do not agree with the priority (read guidelines). The workaround is to declare components
inside aseXML_r17.xsd. I'm not sure whether the schema model doesn't resolve recursively or this particular use-case is

I'm working on it and will get back.
Comment 5 Kirill Sorokin 2008-05-13 08:30:24 UTC
Samaresh, unfortunately, the suggested workaround is not applicable for us. Most of our customers work with
industry-defined standard XML schemes which, obviously, are created elsewhere and should be used "as is". 

Pumping up back to P1.
Comment 6 Samaresh Panda 2008-05-13 18:55:59 UTC
ksorokin, you made it a P1, but didn't justify why though? Clearly from priority stand-point, this is not a P1. I'll
leave it to the i-team to decide.
Comment 7 Kirill Sorokin 2008-05-13 19:47:51 UTC
Errr.. I thought that stating that the suggested workaround is not applicable, is a good enough justification. :) Sorry
if it is not. What else would you like to see? Yes, this is a critical issue for most corporate/enterprise users of SOA
functionality in NetBeans.
Comment 8 Samaresh Panda 2008-05-15 05:37:53 UTC
There is a recursive algorithm in schema model that resolves external components. See SchemaModelImpl::resolve(). The
algorithm resolves components recursively for "include"s but for "import"s it stops at the first import, which is good,
except this use-case. In fact I'm not sure what should be the correct behavior. I'll have to investigate further. Please
stay tuned.
Comment 9 Samaresh Panda 2008-05-15 06:18:22 UTC
I have a fix that might work, but am cautious about it. There could be some implications to it, I'll review it with
former owners before committing. In the mean while, you may want to use the jar.
Comment 10 Samaresh Panda 2008-05-15 06:21:05 UTC
Created attachment 61418 [details]
schema model
Comment 11 Samaresh Panda 2008-05-16 00:21:57 UTC
Fix integrated:
Comment 12 Nikita Krjukov 2008-05-16 12:40:19 UTC
It works! 

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