Community
Participate
Working Groups
Consider this very simple schema: <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.org/Test" elementFormDefault="qualified" xmlns:tns="http://www.example.org/Test" xmlns:test="http://www.example.org/MissingImport"> <xsd:element name="test" type="test:importedType" /> </xsd:schema> If one runs this schema through the Xerces grammar parser, the diagnostic message looks like this: src-resolve.4.2: Error resolving component 'test:importedType'. It was detected that 'test:importedType' is in namespace 'http://www.example.org/MissingImport', but components from this namespace are not referenceable from schema document 'file:///D:/workspaces/WTP3.2-target/QName/Test.xsd'. If this is the incorrect namespace, perhaps the prefix of 'test:importedType' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:///D:/workspaces/WTP3.2-target/QName/Test.xsd'. The Xerces message is a tad long winded, but it eventually explains the problem and how it can be overcome. If one validates this schema with the XML Schema Infoset model validation code, the diagnostic message looks like this: XSD: Type reference 'http://www.example.org/MissingImport#importedType' is unresolved While the message is quite clear, it does not help differentiate between the case when the QName namespace is available (either the targetNamespace or through an import), and there's not much guidance about what to do to fix the problem. In theory, an external consumer could use the existing diagnostic substitution (the QName in the form namespaceURI#localName) to find the namespace, then look it up in the declared namespaces map and imports, I am thinking that it may be more object oriented/encapsulated/reusable/valuable to enhance the model validation code. To this effect, I was wondering if you'd accept a contribution to either: - enhance the existing diagnostic message for this scenario or - create a new diagnostic with a separate key I think the second approach is preferred because it allows for easy programmatic distinction between the two cases, enabling for example specialized quick fixes in the editor (add component vs. add import vs edit prefix). Similar enhancements would be needed for all other QName reference validation rules (ref).
Ed, 2.6 is the best target but there was no 2.6 target in bugzilla so I picked 2.5.
So there'd be a new message explaining it's because the namespace isn't imported while the old message might be enhanced to explain that there's no component with that name in the namespace (although the namespace itself is visible)? Sounds useful.
Yep. We'll get started with a patch and attach when ready.
Created attachment 164438 [details] Partial patch Hi Ed, I've finally found some time to work on this. Here's a partial patch that only addresses the element declaration -> type definition reference scenario. I've placed the code that determines the namespace availability in XSDNamedComponentImpl with the intent of reusing it for the other checks that will have to be changed (attribute declaration, simple and complex types, refs, etc). Please have a look and let me know if I'm on the right track.
Created attachment 164789 [details] Enhanced patch This patch contains changes to all classes I thought needed to change (basically did a search for _UI_Unresolved). While working on element and attribute refs I noted that the new method that determines the namespace availability was failing. That seemed to be because the target namespace of these local components was null. I changed the code to check the target namespace of the enclosing schema instead. I'm not yet 100% happy: the new messages duplicate a part of the existing messages and that seems redundant and the new message IDs are a tad verbose. I'll take another pass at this tomorrow morning. Suggestions are welcome.
Created attachment 164791 [details] Test schemas Here are the test schemas I used for unit testing.
Created attachment 164918 [details] Patch Hello Ed, here's the latest patch. It mainly corrects some formatting errors compared with the previous patch. I decided to keep the new diagnostic messages and their ID as in the previous patch. Let me know if you'd like them changed to something else or if you have any other suggestions. The attached sample schemas should hopefully provide a good manual test set (unfortunately I didn't have time to write the customary JUnit :-( ). One additional thing I noticed when comparing the XSD infoset model validation code with Xerces is that, for the case when a QName prefix points to an undeclared namespace Xerces produces something like this: s4s-att-invalid-value: Invalid attribute value for 'ref' in element 'attributeGroup'. Recorded reason: UndeclaredPrefix: Cannot resolve 'test:NewAttributeGroup' as a QName: the prefix 'test' is not declared. For now, the XSD model will just put out the new kind of unresolved reference message saying that the referenced namespace cannot be resolved. The synthetic component URI in such a case is of the form prefix#localName, instead of namespaceURI#localName. Perhaps we can address this with an extra validation rule sometime in the future (I'll make a mental note).
