Bugzilla – Full Text Bug Listing
| Summary: | XML Generation not picking up all available namespaces | ||
|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | David Carver <d_a_carver> |
| Component: | wst.xml | Assignee: | Gabriel Indik <gindik> |
| Status: | CLOSED DUPLICATE | QA Contact: | David Williams <david_williams> |
| Severity: | normal | ||
| Priority: | P3 | CC: | gindik |
| Version: | 1.5.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | DC - Created Proposed patch | ||
| Attachments: | |||
|
Description
David Carver
Created attachment 60283 [details]
Schemas that can be used to reproduce problem
Added sample schemas. Generate from the STAR/Rev/BODs/Developer version.
Also, when the namespace extra namespace is added, exraneous items are being added to the SchemaLocation, only the primary namespace should be added to the schemalocation.
This appears to happen when there are no Imports included in the XSD. However, the way the developer versions of the schema are constructed, this probably needs to look farther in to make sure there are no xsd:import statements in any of the included schemas to make sure it retrieves all possible namespaces. To see this in action, generate a XML that produces the expected namespaces, generate an instance using the Meta.xsd file in the STAR/Rev/Common/Components directory. This will populate 6 more namespaces due to the import statements appearing in this XSD. Gabriel, I believe you were looking at this functionality recently. I dug a bit further into the code and found in XSDImpl when it loads the resources a ResourceSet of all additional resources is created as well. However, the way the classes and code are currently constructed there is no simple way to get to the additional resources in the original set, because all the functionallity just works off the theXSDSchema. The getNamespaces method does not know or has access to the original ResourceSet that was loaded when the root schema was loaded. Use of the XSDSearchQueryTool util from the XSD library to find the additional includes seems to go into a recursive call loop as it's not detecting possible recursions that can happen with the xsd:include/imports. I checked, and this same issue currently exists in the HEAD code, as well as in the 1.5.x branch. The issue also existed in the 1.5.2 branch, I just didn't notice it until the 1.5.3 branch. Created attachment 60443 [details]
Code to get all xmlns that are defined in an XML document
The above code will retrieve the namespaces, but not the location. This needs to be added manually. In the getProperty() method in the XSDImpl, the following line would need to be added after the getImportedNamespaceInfo() method call (line 834).
getAllNamespacesInfo(xsdSchema, list);
This allows for the checking of the current XSDImport namespaces, and then getting any extra namespaces through the new method. The new method will not add a namespace if it has already been defined.
Only issue is that you can't delete the namespaces added through XSDImport or this new method, and you should be able to because not all namespaces are used in the instance, just by the XSD.
Created attachment 60445 [details]
Allow Namespaces to always be deleteable.
Created attachment 60446 [details]
Patch for XSDImpl, should be applied to 2.x as well.
Patch for XSDImpl to handle importing xmlns specified namespaces.
Dave, Thanks a lot for reporting the bug and for the proposed code and patch. This problem was actually detected in earlier tests and a patch for it has been under development. I wanted to take a look at yours but it seems there might have been code formatting applied to it making it hard to see the changes introduced. If you can, please re-submit the patch without the formatting change. Created attachment 60460 [details]
Reformatted patch, and cleaned up code.
Cleaned up and reformatted patch.
Dave, Thanks a lot for reformatting the patch. I went over it and noted you are collecting the namespaces throughout the top level schema contents. While this can help find more namespaces, it might not be enough to guarantee that the list of namespaces obtained is complete. This is because other required namespaces could be located in schemas being imported in other imported schemas, or in schemas imported in included schemas (or any combination of these). In order to ensure that all required namespaces have been collected it would be necessary to recursively explore all imports/includes. I recently posted a patch for this in bug 105128. If you can please give it a try to see if it correctly solves the problem. *** This bug has been marked as a duplicate of bug 105128 *** Yep, I realized this. Too me the best solution is the query and get the available imported schemas from the RecordSet that is created when the resource is loaded, but this currently would require some refactoring of the existing code, as this is lost once the resource is loaded. Unfortunately because this is not kept, it requires an addtional navigation step through the XSD model to get the imports, which isn't really necessary. Long term I would look at refactoring the XSDImpl to keep the recordset around and make it avaiable for getting these namespaces, or extract these namespaces and make them available for later processing. The resource.load will already handle the duplicate and circular includes/imports that could occur, so you are only left with the schemas and namespaces that are used. Closing as part of mass query to clean up old resolved bugs in untargetted milestones. |