Hi all, I have two questions regarding XSD validation,
1. resolving paths while using imported XSDs 2. error reporting
1. resolving paths while using imported XSDs
consider this example
let $doc := <a /> let $schema := doc("../xsd/XDW.xsd") return validate:xsd($doc,$schema)
this returns an error "[BXVA0001] Validation failed: src-resolve: Cannot resolve the name 'cda:NullFlavor' to a(n) 'type definition' component.". This is because the XDW.xsd schema imports two more XSD's with the following import statements that uses relative paths to refer to schemas that reside in the same folder as the root XDW.xsd.
<xs:import namespace="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803" schemaLocation="ws-humantask-types.xsd"/> <xs:import namespace="urn:hl7-org:v3" schemaLocation="HW_POCD_MT000040.xsd"/>
The problem occurs with both file and http based uris. The only way I have to make validations through imported schemas to work is by using absolute paths in the import statements which is very annoying/limiting especially when handling multiple deployments. I just wanted to know whether this is the expected behaviour in which case it'll require us to take countermeasures at application deployment level.
2. Error reporting
Basex reports the first error while validating with xsd schema, while java uses to report the collection of errors that do not depend on each other. This latter beaviour allos a user to correct multiple bugs simultaneously befor redoing the validation. I understand that the choice to return an exception on validation failure complicates this but couldn't it be possible to return a more complex description of the validation result containing multiple error marks?
For information, we use Basex 7.5 on Ubuntu 12.04.
Thanks in advance, Seenivasan
Hi Seenivasan,
finally some feedback..
let $doc := <a /> let $schema := doc("../xsd/XDW.xsd") return validate:xsd($doc,$schema)
Yes, I see this is a problem, and I’ve encountered similar use cases, but I'm currently not sure how to fix this properly. The issue is that BaseX relies on external schema validation, so we don’t have direct access to the code executing the validation.
It could well be that Java’s validator interface provides some methods to set/modify the path to the current base uri. If you – or someone else – has time, ideas and/or experience how to fix this, suggestions and patches are welcome (see [1] for the source code).
Basex reports the first error while validating with xsd schema, while java uses to report the collection of errors that do not depend on each other.
A similar observation applies here: the error handling in the mentioned class could be revised in order to catch more than just the first error [2].
Feel free to ask if you have more questions, Christian
[1] https://github.com/BaseXdb/basex/blob/master/src/main/java/org/basex/query/func/FNValidate.java#L95 [2] https://github.com/BaseXdb/basex/blob/master/src/main/java/org/basex/query/func/FNValidate.java#L183
Hi Marco,
thanks again for sending me the patch for the Validation Module. After some thoughts, I’ve eventually decided to add two new functions dtd-info() and xsd-info(), which return all warnings and errors in a string sequence [1] – in contrast to the existing functions, which continue to either return an empty sequence or a simple error message.
Remarks are welcome, Christian
[1] http://docs.basex.org/wiki/Validation_Module ___________________________
On Tue, Jan 22, 2013 at 2:06 PM, Seenivasan Gunabalan < seenivasan.gunabalan@dedalus.eu> wrote:
Hi all, I have two questions regarding XSD validation,
resolving paths while using imported XSDs
error reporting
resolving paths while using imported XSDs
consider this example
let $doc := <a /> let $schema := doc("../xsd/XDW.xsd") return validate:xsd($doc,$schema)
this returns an error "[BXVA0001] Validation failed: src-resolve: Cannot resolve the name 'cda:NullFlavor' to a(n) 'type definition' component.". This is because the XDW.xsd schema imports two more XSD's with the following import statements that uses relative paths to refer to schemas that reside in the same folder as the root XDW.xsd.
<xs:import namespace="http://docs.oasis-**open.org/ns/bpel4people/ws-** humantask/types/200803<http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803>" schemaLocation="ws-humantask-**types.xsd"/> <xs:import namespace="urn:hl7-org:v3" schemaLocation="HW_POCD_** MT000040.xsd"/>
The problem occurs with both file and http based uris. The only way I have to make validations through imported schemas to work is by using absolute paths in the import statements which is very annoying/limiting especially when handling multiple deployments. I just wanted to know whether this is the expected behaviour in which case it'll require us to take countermeasures at application deployment level.
- Error reporting
Basex reports the first error while validating with xsd schema, while java uses to report the collection of errors that do not depend on each other. This latter beaviour allos a user to correct multiple bugs simultaneously befor redoing the validation. I understand that the choice to return an exception on validation failure complicates this but couldn't it be possible to return a more complex description of the validation result containing multiple error marks?
For information, we use Basex 7.5 on Ubuntu 12.04.
Thanks in advance, Seenivasan ______________________________**_________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-**konstanz.de <BaseX-Talk@mailman.uni-konstanz.de> https://mailman.uni-konstanz.**de/mailman/listinfo/basex-talk<https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk>
Nice to know, Chrisitan. Will take a note on this new feature. I was already thinking of introducing another signature because of the "explosions" of combinations with two optional parameters (4) but of course I deliberately left this "architectural" decision to you! :-D A sequence of strings as a return type is ok. I was thinking about an XML structure (similar to what schematron does with svrl) but your solution is much more lightweight I believe. Thanks again for introducing the feature and kind regards, M.
On 01/29/2013 11:34 PM, Christian Grün wrote:
Hi Marco,
thanks again for sending me the patch for the Validation Module. After some thoughts, I’ve eventually decided to add two new functions dtd-info() and xsd-info(), which return all warnings and errors in a string sequence [1] – in contrast to the existing functions, which continue to either return an empty sequence or a simple error message.
Remarks are welcome, Christian
[1] http://docs.basex.org/wiki/Validation_Module ___________________________
On Tue, Jan 22, 2013 at 2:06 PM, Seenivasan Gunabalan <seenivasan.gunabalan@dedalus.eu mailto:seenivasan.gunabalan@dedalus.eu> wrote:
Hi all, I have two questions regarding XSD validation, 1. resolving paths while using imported XSDs 2. error reporting 1. resolving paths while using imported XSDs consider this example let $doc := <a /> let $schema := doc("../xsd/XDW.xsd") return validate:xsd($doc,$schema) this returns an error "[BXVA0001] Validation failed: src-resolve: Cannot resolve the name 'cda:NullFlavor' to a(n) 'type definition' component.". This is because the XDW.xsd schema imports two more XSD's with the following import statements that uses relative paths to refer to schemas that reside in the same folder as the root XDW.xsd. <xs:import namespace="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803" schemaLocation="ws-humantask-types.xsd"/> <xs:import namespace="urn:hl7-org:v3" schemaLocation="HW_POCD_MT000040.xsd"/> The problem occurs with both file and http based uris. The only way I have to make validations through imported schemas to work is by using absolute paths in the import statements which is very annoying/limiting especially when handling multiple deployments. I just wanted to know whether this is the expected behaviour in which case it'll require us to take countermeasures at application deployment level. 2. Error reporting Basex reports the first error while validating with xsd schema, while java uses to report the collection of errors that do not depend on each other. This latter beaviour allos a user to correct multiple bugs simultaneously befor redoing the validation. I understand that the choice to return an exception on validation failure complicates this but couldn't it be possible to return a more complex description of the validation result containing multiple error marks? For information, we use Basex 7.5 on Ubuntu 12.04. Thanks in advance, Seenivasan _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de <mailto:BaseX-Talk@mailman.uni-konstanz.de> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Marco Lettere -
Seenivasan Gunabalan