URI resolver when calling XSLT
Monday, 28 January 2013 · 7 messages · last reply 1 Feb 2013
WP
Wendell Piez28 Jan 2013 23:00 #
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
Quoted text · Christian Grün · 36 lines
On Fri, Jan 25, 2013 at 4:41 PM, Christian Grün <christian.gruen at 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 at 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_^
AH
Alexander Holupirek29 Jan 2013 09:29 #
Hi Wendell,
Quoted text · Wendell Piez · 1 line
> 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
Quoted text · Wendell Piez · 66 lines
On 28.01.2013, at 22:00, Wendell Piez <wapiez at 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 at 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 at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
ML
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.
Quoted text · Wendell Piez · 63 lines
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 at 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 at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
CG
Christian Grün29 Jan 2013 12:07 #
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/func/FNXslt.java#L150
Quoted text · Marco Lettere · 104 lines
On Tue, Jan 29, 2013 at 10:08 AM, Marco Lettere <marco.lettere at 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 at 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 at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >
CG
...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,
ChristianQuoted text · Wendell Piez · 39 lines
>> >> 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 at 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
ML
Marco Lettere1 Feb 2013 10:40 #
Yeah. It works with the schema passed in as URI string.
M.
Quoted text · Christian Grün · 59 lines
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 at 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 at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >
CG
Christian Grün1 Feb 2013 19:55 #
Hi Wendell, hi all,
path resolutions should now correctly work for both the XSLT and the Validation Module. You are invited to check out the latest stable snapshot [1].
Best,
Christian
[1] http://files.basex.org/releases/latest/
Quoted text · Wendell Piez · 96 lines
On Thu, Jan 31, 2013 at 10:20 PM, Wendell Piez <wapiez at wendellpiez.com> wrote: > Dear Christian, > > My problem is actually on the XSLT side, using xsl:import from a > stylesheet being processed by Saxon (using the xslt:transform() > function). I am only surmising they will (would) be resolved the same > way as calling modules of an XSD. Should I send you a demonstration > example? > > Cheers, > Wendell > > > On Thu, Jan 31, 2013 at 4:18 AM, Christian Grün > <christian.gruen at gmail.com> wrote: >> ..to simplify testing, could you send me some xml/xsd files your are >> working with? >> >> Thanks, >> Christian >> ___________________________ >> >> On Mon, Jan 28, 2013 at 10:00 PM, Wendell Piez <wapiez at 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 at 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 at 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 at 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_^
Written for BaseX 7.5. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery