Hi,
I've run into a similar problem to the one described (I think) below: I can invoke XSLT in BaseX (fantastic) but I get compiler errors if the stylesheet relies on xsl:import or xsl:include (not so good).
As I understand it, the JAXP interface (supported by Saxon and Xalan) allows you to provide your own URIResolver class, which is (I imagine) the way to fix this. But I'm no Java programmer.
It would be very (very) nice to be able to do this right.
My apologies if this post is no help but only a "me too". :-)
Cheers, Wendell
On Fri, Jan 25, 2013 at 4:41 PM, Christian Grün christian.gruen@gmail.com wrote:
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 _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^
Hi Wendell,
My apologies if this post is no help but only a "me too". :-)
no need for excuses. You mentioned that you have similar problems, proposed a hint on how that could be resolved and in general showed, that this is an issue of importance for you.
We, the BaseX community, definitely want BaseX users to tell us, the BaseX community, about their problems, ideas and use cases. This is what basex-talk is about. Talk about BaseX, XQuery, BaseX, XML, other XML processing systems. So feel invited to share ;-)
BTW, if traffic would grow we surely would have the possibility to set up basex-talk (for broader discussions) and, say, basex-tech (for implementation issues).
All the best, Alex
On 28.01.2013, at 22:00, Wendell Piez wapiez@wendellpiez.com wrote:
Hi,
I've run into a similar problem to the one described (I think) below: I can invoke XSLT in BaseX (fantastic) but I get compiler errors if the stylesheet relies on xsl:import or xsl:include (not so good).
As I understand it, the JAXP interface (supported by Saxon and Xalan) allows you to provide your own URIResolver class, which is (I imagine) the way to fix this. But I'm no Java programmer.
It would be very (very) nice to be able to do this right.
My apologies if this post is no help but only a "me too". :-)
Cheers, Wendell
On Fri, Jan 25, 2013 at 4:41 PM, Christian Grün christian.gruen@gmail.com wrote:
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 _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^ _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
I feel the problem is the same. The issue is just that the resolver for imports and includes (both XSD and XSL) in BaseX seems not being able to resolve relative uris. We fixed temporarely by creating a folder with all schemas and stylesheets locally to the BazeX dist folder and transforming all imports/include uris to absolute. This is quite annoying and it becomes difficult when dealing with multiple deployment sites and we try to come around with entity references but anyway in my op it's not safe to fiddle on xsd, wsdls and xslt that come with they'r own (relative uri based) linking architecture. Actually the resolver seems to work with relative uris only if they are "file:" uris and expressed relatively to the folder from where you launched BaseX itself. Saxon and JAXP reference impl do it right I can validate from Java (or Linux command line) even with XSDs that are downloaded from the net and link other files relatively to the remote URIs. As a final remark if I ask for the explicit resolution with *resolve-uri("importedfile.xsd", base-uri(doc(importingfile.xsd)))* the returned URI is correct. I get the proper absolute URI of the imported schema file. So it really looks like in the backoffice of validate/transform functions the resolver is mismatching something. Hope that my two cents can help out. Greetings, M.
On 01/28/2013 10:00 PM, Wendell Piez wrote:
Hi,
I've run into a similar problem to the one described (I think) below: I can invoke XSLT in BaseX (fantastic) but I get compiler errors if the stylesheet relies on xsl:import or xsl:include (not so good).
As I understand it, the JAXP interface (supported by Saxon and Xalan) allows you to provide your own URIResolver class, which is (I imagine) the way to fix this. But I'm no Java programmer.
It would be very (very) nice to be able to do this right.
My apologies if this post is no help but only a "me too". :-)
Cheers, Wendell
On Fri, Jan 25, 2013 at 4:41 PM, Christian Grün christian.gruen@gmail.com wrote:
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 _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^ _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Marco, hi Seenivasan, hi Wendell,
thanks for your comments; I’ve added a GitHub entry for that issue [1].
The original BaseX code is found at [2]. It gives some insight into how the XSLT processor is triggered via TransformerFactory.newInstance() etc., so if you should manage to get these few lines working in an external example and relative URIs, it should be easily embeddable in BaseX. Would one of you be interested in having a look at it?
Best, Christian
[1] https://github.com/BaseXdb/basex/issues/630 [2] https://github.com/BaseXdb/basex/blob/master/src/main/java/org/basex/query/f... ___________________________
On Tue, Jan 29, 2013 at 10:08 AM, Marco Lettere marco.lettere@dedalus.eu wrote:
I feel the problem is the same. The issue is just that the resolver for imports and includes (both XSD and XSL) in BaseX seems not being able to resolve relative uris. We fixed temporarely by creating a folder with all schemas and stylesheets locally to the BazeX dist folder and transforming all imports/include uris to absolute. This is quite annoying and it becomes difficult when dealing with multiple deployment sites and we try to come around with entity references but anyway in my op it's not safe to fiddle on xsd, wsdls and xslt that come with they'r own (relative uri based) linking architecture. Actually the resolver seems to work with relative uris only if they are "file:" uris and expressed relatively to the folder from where you launched BaseX itself. Saxon and JAXP reference impl do it right I can validate from Java (or Linux command line) even with XSDs that are downloaded from the net and link other files relatively to the remote URIs. As a final remark if I ask for the explicit resolution with resolve-uri("importedfile.xsd", base-uri(doc(importingfile.xsd))) the returned URI is correct. I get the proper absolute URI of the imported schema file. So it really looks like in the backoffice of validate/transform functions the resolver is mismatching something. Hope that my two cents can help out. Greetings, M.
On 01/28/2013 10:00 PM, Wendell Piez wrote:
Hi,
I've run into a similar problem to the one described (I think) below: I can invoke XSLT in BaseX (fantastic) but I get compiler errors if the stylesheet relies on xsl:import or xsl:include (not so good).
As I understand it, the JAXP interface (supported by Saxon and Xalan) allows you to provide your own URIResolver class, which is (I imagine) the way to fix this. But I'm no Java programmer.
It would be very (very) nice to be able to do this right.
My apologies if this post is no help but only a "me too". :-)
Cheers, Wendell
On Fri, Jan 25, 2013 at 4:41 PM, Christian Grün christian.gruen@gmail.com wrote:
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 _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^ _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
...some quick feedback regarding the relative path issues: the doc(...) function in the schema declaration can be skipped and replaced by a simple path string. This could already resolve the path discussed issues:
Old: validate:xsd(<a />, doc("../xsd/XDW.xsd")
New: validate:xsd(<a />, "../xsd/XDW.xsd"
Could you give it a try and give some feedback?
Thanks, Christian ___________________________
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 _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^ _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Yeah. It works with the schema passed in as URI string. M.
On 01/31/2013 09:02 PM, Christian Grün wrote:
...some quick feedback regarding the relative path issues: the doc(...) function in the schema declaration can be skipped and replaced by a simple path string. This could already resolve the path discussed issues:
Old: validate:xsd(<a />, doc("../xsd/XDW.xsd")
New: validate:xsd(<a />, "../xsd/XDW.xsd"
Could you give it a try and give some feedback?
Thanks, Christian ___________________________
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 _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^ _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
basex-talk@mailman.uni-konstanz.de
-
Alexander Holupirek -
Christian Grün -
Marco Lettere -
Wendell Piez