Compiler errors instead of Runtime errors

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiler errors instead of Runtime errors

Campbell, Lance

SAXON: 9.6.0.3

XSL: version 2.0

JAVA: 7.72

 

Issue:

Our XSLs are very complex.  There are many logical paths that can be traversed.  We are getting a lot of math Runtime errors because data is being seen as strings by the transformer factory.  To work around this issue we put the function number() around many of the values we are getting from the XML.  I would prefer to have compiler errors over runtime errors.  Runtime errors are very difficult to debug.

 

Solution:

When I call the method “newTemplates(xslSource)” on a transformation factory it normally gives me a Template back that represents generated byte code for the XSL.  I would suggest allowing us to also pass an XSD that represents the data being referred to within the XSL.  That way the transformation factory would know the types of data elements it is working with. 

 

Example:

<xsl:variable name=”sum” select=”/data/xyz/value + 10” />

 

Currently the above would cause a runtime error because the transformer factory does not know that /data/xyz/value resolves to an integer. 

 

To fix the issue today:

<xsl:variable name=”sum” select=””number(/data/xyz/value) + 10” />

 

If I could pass the XSD to the transformer factory then it would be able to generate byte code that would know that I defined “/data/xyz/value” as an integer.  This would allow for better type checking.  Compiler errors are much better than Runtime errors.

 

This feature may already be available.  I am just not aware of how to tell the transformer factory what XSD my XML is using.

 

Thanks.

 

 

Thanks,

 

Lance Campbell

Software Architect

Web Services at Public Affairs

217-333-0382

University of Illinois at Urbana-Champaign logo

 

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Compiler errors instead of Runtime errors

Michael Kay
Sure, this feature is called "schema-awareness" and it's a standard feature of Saxon-EE.

I wrote an overview of schema-awareness for the Stylus Studio web site many years ago, and it's still probably the best introduction there is. The focus is on XQuery rather than XSLT but the principles are the same:


Unfortunately it's not just a case of supplying the schema, because names such as "data" can refer to more than one element in the schema, or to elements in non-validated documents. But there's a new feature in XSLT 3.0 (not covered in that article)

<xsl:mode typed="strict"/>

which means that for all template rules in that mode, a match pattern like

<xsl:template match="invoice">

an element name like "invoice" should be interpreted as matching only elements that are valid against the element declaration "invoice" in the schema; you can also use typed="lax" which is a bit weaker; it means that if there is a global element for invoice, then the matching element must be a valid instance of this element.

Doing this enables Saxon to do further compile time checking, for example in the template rule

<xsl:template match="invoice">
  <xsl:value-of select="price"/>
</xsl:template>

you will get a compile-time error if the schema declaration for "invoice" does not allow a child element named price.

Michael Kay
Saxonica
+44 (0) 118 946 5893




On 1 Jan 2015, at 21:32, Campbell, Lance <[hidden email]> wrote:

SAXON: 9.6.0.3

XSL: version 2.0

JAVA: 7.72

 

Issue:

Our XSLs are very complex.  There are many logical paths that can be traversed.  We are getting a lot of math Runtime errors because data is being seen as strings by the transformer factory.  To work around this issue we put the function number() around many of the values we are getting from the XML.  I would prefer to have compiler errors over runtime errors.  Runtime errors are very difficult to debug.

 

Solution:

When I call the method “newTemplates(xslSource)” on a transformation factory it normally gives me a Template back that represents generated byte code for the XSL.  I would suggest allowing us to also pass an XSD that represents the data being referred to within the XSL.  That way the transformation factory would know the types of data elements it is working with. 

 

Example:

<xsl:variable name=”sum” select=”/data/xyz/value + 10” />

 

Currently the above would cause a runtime error because the transformer factory does not know that /data/xyz/value resolves to an integer. 

 

To fix the issue today:

<xsl:variable name=”sum” select=””number(/data/xyz/value) + 10” />

 

If I could pass the XSD to the transformer factory then it would be able to generate byte code that would know that I defined “/data/xyz/value” as an integer.  This would allow for better type checking.  Compiler errors are much better than Runtime errors.

 

This feature may already be available.  I am just not aware of how to tell the transformer factory what XSD my XML is using.

 

Thanks.

 

 

Thanks,

 

Lance Campbell

Software Architect

Web Services at Public Affairs

217-333-0382

<image001.png>

 

 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Compiler errors instead of Runtime errors

Campbell, Lance
Thanks so much for this information.  I implemented Java 1.7 code to get that to work.  But I ran into a related issue.

SAXON EE 9.6.0.3 is not able to find the file location for additional XSDs that are included and imported within my primary XSD.  

Actual examples:
<xsd:include schemaLocation="rss.xsd" />
<xsd:import namespace="edu.illinois.webservices.campus.bean" schemaLocation="file:/properties/campus/campus.xsd" />

The include file example above would be found within tomcat at:
{tomcat_location}/webapp/{app_name}/WEB-INF/classes/properties/rss.xsd

The import file example above is actually a file found within a jar file at the location:
/properties/campus/campus.xsd

Is there some way for me to tell SAXON where to get these files?  It seems like there should be a prefix I could use like "web-inf:" and "jar:" to tell SAXON where to look for the files.

Possible option for Include would be:
<xsd:include schemaLocation="web-inf:/properties/rss.xsd" />

Possible option for Import would be:
<xsd:import namespace="edu.illinois.webservices.campus.bean" schemaLocation="jar:somejarfile.jar:file:/properties/campus/campus.xsd" />

It appears that this is a common issue on the web.  I did find a reference to something called URIResolver .  Do I need to implement my own version of this class?  Also is there some way for me to tell the transformer factory, "if you see this URL, then actually go here on the file system to get the file".  That would work for my include but not for the import.

If it helps I generate my tomcat applications via eclipse.

Thanks.



Thanks,

Lance Campbell
Software Architect
Web Services at Public Affairs
217-333-0382



From: Michael Kay [mailto:[hidden email]]
Sent: Thursday, January 01, 2015 6:06 PM
To: Mailing list for the SAXON XSLT and XQuery processor
Subject: Re: [saxon] Compiler errors instead of Runtime errors

Sure, this feature is called "schema-awareness" and it's a standard feature of Saxon-EE.

I wrote an overview of schema-awareness for the Stylus Studio web site many years ago, and it's still probably the best introduction there is. The focus is on XQuery rather than XSLT but the principles are the same:

http://www.stylusstudio.com/schema_aware.html

Unfortunately it's not just a case of supplying the schema, because names such as "data" can refer to more than one element in the schema, or to elements in non-validated documents. But there's a new feature in XSLT 3.0 (not covered in that article)

<xsl:mode typed="strict"/>

which means that for all template rules in that mode, a match pattern like

<xsl:template match="invoice">

an element name like "invoice" should be interpreted as matching only elements that are valid against the element declaration "invoice" in the schema; you can also use typed="lax" which is a bit weaker; it means that if there is a global element for invoice, then the matching element must be a valid instance of this element.

Doing this enables Saxon to do further compile time checking, for example in the template rule

<xsl:template match="invoice">
  <xsl:value-of select="price"/>
</xsl:template>

you will get a compile-time error if the schema declaration for "invoice" does not allow a child element named price.

Michael Kay
Saxonica
[hidden email]
+44 (0) 118 946 5893



On 1 Jan 2015, at 21:32, Campbell, Lance <[hidden email]> wrote:


SAXON: 9.6.0.3
XSL: version 2.0
JAVA: 7.72
 
Issue:
Our XSLs are very complex.  There are many logical paths that can be traversed.  We are getting a lot of math Runtime errors because data is being seen as strings by the transformer factory.  To work around this issue we put the function number() around many of the values we are getting from the XML.  I would prefer to have compiler errors over runtime errors.  Runtime errors are very difficult to debug.
 
Solution:
When I call the method "newTemplates(xslSource)" on a transformation factory it normally gives me a Template back that represents generated byte code for the XSL.  I would suggest allowing us to also pass an XSD that represents the data being referred to within the XSL.  That way the transformation factory would know the types of data elements it is working with. 
 
Example:
<xsl:variable name="sum" select="/data/xyz/value + 10" />
 
Currently the above would cause a runtime error because the transformer factory does not know that /data/xyz/value resolves to an integer. 
 
To fix the issue today:
<xsl:variable name="sum" select=""number(/data/xyz/value) + 10" />
 
If I could pass the XSD to the transformer factory then it would be able to generate byte code that would know that I defined "/data/xyz/value" as an integer.  This would allow for better type checking.  Compiler errors are much better than Runtime errors.
 
This feature may already be available.  I am just not aware of how to tell the transformer factory what XSD my XML is using.
 
Thanks.
 
 
Thanks,
 
Lance Campbell
Software Architect
Web Services at Public Affairs
217-333-0382
<image001.png>
 
 
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Compiler errors instead of Runtime errors

Michael Kay
If the schemaLocation attribute in xsd:include or xsd:import isn't an ordinary relative URI (or if there isn't a schemaLocation at all), then you can supply a SchemaURIResolver which can locate the schema document any way it likes.

IIRC, for your xs:include, a relative URI in the form "/WEB-INF/classes/properties/rss.xsd" should work : at any rate, some relative URI starting in "/".

To access files within a jar or zip archive, Saxon supports the (Java-defined but non-standard) JAR URL scheme: see

http://docs.oracle.com/javase/7/docs/api/java/net/JarURLConnection.html

Michael Kay
Saxonica
[hidden email]
+44 (0) 118 946 5893




On 2 Jan 2015, at 06:02, Campbell, Lance <[hidden email]> wrote:

> Thanks so much for this information.  I implemented Java 1.7 code to get that to work.  But I ran into a related issue.
>
> SAXON EE 9.6.0.3 is not able to find the file location for additional XSDs that are included and imported within my primary XSD.  
>
> Actual examples:
> <xsd:include schemaLocation="rss.xsd" />
> <xsd:import namespace="edu.illinois.webservices.campus.bean" schemaLocation="file:/properties/campus/campus.xsd" />
>
> The include file example above would be found within tomcat at:
> {tomcat_location}/webapp/{app_name}/WEB-INF/classes/properties/rss.xsd
>
> The import file example above is actually a file found within a jar file at the location:
> /properties/campus/campus.xsd
>
> Is there some way for me to tell SAXON where to get these files?  It seems like there should be a prefix I could use like "web-inf:" and "jar:" to tell SAXON where to look for the files.
>
> Possible option for Include would be:
> <xsd:include schemaLocation="web-inf:/properties/rss.xsd" />
>
> Possible option for Import would be:
> <xsd:import namespace="edu.illinois.webservices.campus.bean" schemaLocation="jar:somejarfile.jar:file:/properties/campus/campus.xsd" />
>
> It appears that this is a common issue on the web.  I did find a reference to something called URIResolver .  Do I need to implement my own version of this class?  Also is there some way for me to tell the transformer factory, "if you see this URL, then actually go here on the file system to get the file".  That would work for my include but not for the import.
>
> If it helps I generate my tomcat applications via eclipse.
>
> Thanks.
>
>
>
> Thanks,
>
> Lance Campbell
> Software Architect
> Web Services at Public Affairs
> 217-333-0382
>
>
>
> From: Michael Kay [mailto:[hidden email]]
> Sent: Thursday, January 01, 2015 6:06 PM
> To: Mailing list for the SAXON XSLT and XQuery processor
> Subject: Re: [saxon] Compiler errors instead of Runtime errors
>
> Sure, this feature is called "schema-awareness" and it's a standard feature of Saxon-EE.
>
> I wrote an overview of schema-awareness for the Stylus Studio web site many years ago, and it's still probably the best introduction there is. The focus is on XQuery rather than XSLT but the principles are the same:
>
> http://www.stylusstudio.com/schema_aware.html
>
> Unfortunately it's not just a case of supplying the schema, because names such as "data" can refer to more than one element in the schema, or to elements in non-validated documents. But there's a new feature in XSLT 3.0 (not covered in that article)
>
> <xsl:mode typed="strict"/>
>
> which means that for all template rules in that mode, a match pattern like
>
> <xsl:template match="invoice">
>
> an element name like "invoice" should be interpreted as matching only elements that are valid against the element declaration "invoice" in the schema; you can also use typed="lax" which is a bit weaker; it means that if there is a global element for invoice, then the matching element must be a valid instance of this element.
>
> Doing this enables Saxon to do further compile time checking, for example in the template rule
>
> <xsl:template match="invoice">
>   <xsl:value-of select="price"/>
> </xsl:template>
>
> you will get a compile-time error if the schema declaration for "invoice" does not allow a child element named price.
>
> Michael Kay
> Saxonica
> [hidden email]
> +44 (0) 118 946 5893
>
>
>
> On 1 Jan 2015, at 21:32, Campbell, Lance <[hidden email]> wrote:
>
>
> SAXON: 9.6.0.3
> XSL: version 2.0
> JAVA: 7.72
>  
> Issue:
> Our XSLs are very complex.  There are many logical paths that can be traversed.  We are getting a lot of math Runtime errors because data is being seen as strings by the transformer factory.  To work around this issue we put the function number() around many of the values we are getting from the XML.  I would prefer to have compiler errors over runtime errors.  Runtime errors are very difficult to debug.
>  
> Solution:
> When I call the method "newTemplates(xslSource)" on a transformation factory it normally gives me a Template back that represents generated byte code for the XSL.  I would suggest allowing us to also pass an XSD that represents the data being referred to within the XSL.  That way the transformation factory would know the types of data elements it is working with.  
>  
> Example:
> <xsl:variable name="sum" select="/data/xyz/value + 10" />
>  
> Currently the above would cause a runtime error because the transformer factory does not know that /data/xyz/value resolves to an integer.  
>  
> To fix the issue today:
> <xsl:variable name="sum" select=""number(/data/xyz/value) + 10" />
>  
> If I could pass the XSD to the transformer factory then it would be able to generate byte code that would know that I defined "/data/xyz/value" as an integer.  This would allow for better type checking.  Compiler errors are much better than Runtime errors.
>  
> This feature may already be available.  I am just not aware of how to tell the transformer factory what XSD my XML is using.
>  
> Thanks.
>  
>  
> Thanks,
>  
> Lance Campbell
> Software Architect
> Web Services at Public Affairs
> 217-333-0382
> <image001.png>
>  
>  
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Compiler errors instead of Runtime errors

Campbell, Lance
I looked up information on SchemaURIResolver.  I have discovered it is an interface net.sf.saxon.lib.SchemaURIResolver .

How do I set my  implementation of this interface in Java?  

I tried doing:
com.saxonica.config.EnterpriseTransformerFactory etf = new com.saxonica.config.EnterpriseTransformerFactory();
Configuration configuration = etf.getConfiguration();

There is no method for setting a SchemaURIResolver.  There is a method for setting a URIResolver.  Is that the same thing?

configuration.setURIResolver(resolver);



Thanks,

Lance Campbell
Software Architect
Web Services at Public Affairs
217-333-0382



-----Original Message-----
From: Michael Kay [mailto:[hidden email]]
Sent: Friday, January 02, 2015 5:32 AM
To: Mailing list for the SAXON XSLT and XQuery processor
Subject: Re: [saxon] Compiler errors instead of Runtime errors

If the schemaLocation attribute in xsd:include or xsd:import isn't an ordinary relative URI (or if there isn't a schemaLocation at all), then you can supply a SchemaURIResolver which can locate the schema document any way it likes.

IIRC, for your xs:include, a relative URI in the form "/WEB-INF/classes/properties/rss.xsd" should work : at any rate, some relative URI starting in "/".

To access files within a jar or zip archive, Saxon supports the (Java-defined but non-standard) JAR URL scheme: see

http://docs.oracle.com/javase/7/docs/api/java/net/JarURLConnection.html

Michael Kay
Saxonica
[hidden email]
+44 (0) 118 946 5893




On 2 Jan 2015, at 06:02, Campbell, Lance <[hidden email]> wrote:

> Thanks so much for this information.  I implemented Java 1.7 code to get that to work.  But I ran into a related issue.
>
> SAXON EE 9.6.0.3 is not able to find the file location for additional XSDs that are included and imported within my primary XSD.  
>
> Actual examples:
> <xsd:include schemaLocation="rss.xsd" /> <xsd:import
> namespace="edu.illinois.webservices.campus.bean"
> schemaLocation="file:/properties/campus/campus.xsd" />
>
> The include file example above would be found within tomcat at:
> {tomcat_location}/webapp/{app_name}/WEB-INF/classes/properties/rss.xsd
>
> The import file example above is actually a file found within a jar file at the location:
> /properties/campus/campus.xsd
>
> Is there some way for me to tell SAXON where to get these files?  It seems like there should be a prefix I could use like "web-inf:" and "jar:" to tell SAXON where to look for the files.
>
> Possible option for Include would be:
> <xsd:include schemaLocation="web-inf:/properties/rss.xsd" />
>
> Possible option for Import would be:
> <xsd:import namespace="edu.illinois.webservices.campus.bean"
> schemaLocation="jar:somejarfile.jar:file:/properties/campus/campus.xsd
> " />
>
> It appears that this is a common issue on the web.  I did find a reference to something called URIResolver .  Do I need to implement my own version of this class?  Also is there some way for me to tell the transformer factory, "if you see this URL, then actually go here on the file system to get the file".  That would work for my include but not for the import.
>
> If it helps I generate my tomcat applications via eclipse.
>
> Thanks.
>
>
>
> Thanks,
>
> Lance Campbell
> Software Architect
> Web Services at Public Affairs
> 217-333-0382
>
>
>
> From: Michael Kay [mailto:[hidden email]]
> Sent: Thursday, January 01, 2015 6:06 PM
> To: Mailing list for the SAXON XSLT and XQuery processor
> Subject: Re: [saxon] Compiler errors instead of Runtime errors
>
> Sure, this feature is called "schema-awareness" and it's a standard feature of Saxon-EE.
>
> I wrote an overview of schema-awareness for the Stylus Studio web site many years ago, and it's still probably the best introduction there is. The focus is on XQuery rather than XSLT but the principles are the same:
>
> http://www.stylusstudio.com/schema_aware.html
>
> Unfortunately it's not just a case of supplying the schema, because
> names such as "data" can refer to more than one element in the schema,
> or to elements in non-validated documents. But there's a new feature
> in XSLT 3.0 (not covered in that article)
>
> <xsl:mode typed="strict"/>
>
> which means that for all template rules in that mode, a match pattern
> like
>
> <xsl:template match="invoice">
>
> an element name like "invoice" should be interpreted as matching only elements that are valid against the element declaration "invoice" in the schema; you can also use typed="lax" which is a bit weaker; it means that if there is a global element for invoice, then the matching element must be a valid instance of this element.
>
> Doing this enables Saxon to do further compile time checking, for
> example in the template rule
>
> <xsl:template match="invoice">
>   <xsl:value-of select="price"/>
> </xsl:template>
>
> you will get a compile-time error if the schema declaration for "invoice" does not allow a child element named price.
>
> Michael Kay
> Saxonica
> [hidden email]
> +44 (0) 118 946 5893
>
>
>
> On 1 Jan 2015, at 21:32, Campbell, Lance <[hidden email]> wrote:
>
>
> SAXON: 9.6.0.3
> XSL: version 2.0
> JAVA: 7.72
>  
> Issue:
> Our XSLs are very complex.  There are many logical paths that can be traversed.  We are getting a lot of math Runtime errors because data is being seen as strings by the transformer factory.  To work around this issue we put the function number() around many of the values we are getting from the XML.  I would prefer to have compiler errors over runtime errors.  Runtime errors are very difficult to debug.
>  
> Solution:
> When I call the method "newTemplates(xslSource)" on a transformation factory it normally gives me a Template back that represents generated byte code for the XSL.  I would suggest allowing us to also pass an XSD that represents the data being referred to within the XSL.  That way the transformation factory would know the types of data elements it is working with.  
>  
> Example:
> <xsl:variable name="sum" select="/data/xyz/value + 10" />
>  
> Currently the above would cause a runtime error because the transformer factory does not know that /data/xyz/value resolves to an integer.  
>  
> To fix the issue today:
> <xsl:variable name="sum" select=""number(/data/xyz/value) + 10" />
>  
> If I could pass the XSD to the transformer factory then it would be able to generate byte code that would know that I defined "/data/xyz/value" as an integer.  This would allow for better type checking.  Compiler errors are much better than Runtime errors.
>  
> This feature may already be available.  I am just not aware of how to tell the transformer factory what XSD my XML is using.
>  
> Thanks.
>  
>  
> Thanks,
>  
> Lance Campbell
> Software Architect
> Web Services at Public Affairs
> 217-333-0382
> <image001.png>
>  
>  
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net_____________________________________
> __________ saxon-help mailing list archived at
> http://saxon.markmail.org/ [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net 
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/ 
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/ [hidden email] https://lists.sourceforge.net/lists/listinfo/saxon-help 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Compiler errors instead of Runtime errors

Michael Kay
The Configuration returned by EnterpriseTranstormerFactory.getConfiguration() will generally be an EnterpriseConfiguration, and this has a method setSchemaURIResolver(). So you just need

> ((EnterpriseConfiguration)configuration).setSchemaURIResolver(resolver);

You can also set most configuration properties using methods such as

factory.setAttribute(FeatureKeys.SCHEMA_URI_RESOLVER, resolver);

Michael Kay
Saxonica
[hidden email]
+44 (0) 118 946 5893




On 2 Jan 2015, at 16:10, Campbell, Lance <[hidden email]> wrote:

> I looked up information on SchemaURIResolver.  I have discovered it is an interface net.sf.saxon.lib.SchemaURIResolver .
>
> How do I set my  implementation of this interface in Java?  
>
> I tried doing:
> com.saxonica.config.EnterpriseTransformerFactory etf = new com.saxonica.config.EnterpriseTransformerFactory();
> Configuration configuration = etf.getConfiguration();
>
> There is no method for setting a SchemaURIResolver.  There is a method for setting a URIResolver.  Is that the same thing?
>
> configuration.setURIResolver(resolver);
>
>
>
> Thanks,
>
> Lance Campbell
> Software Architect
> Web Services at Public Affairs
> 217-333-0382
>
>
>
> -----Original Message-----
> From: Michael Kay [mailto:[hidden email]]
> Sent: Friday, January 02, 2015 5:32 AM
> To: Mailing list for the SAXON XSLT and XQuery processor
> Subject: Re: [saxon] Compiler errors instead of Runtime errors
>
> If the schemaLocation attribute in xsd:include or xsd:import isn't an ordinary relative URI (or if there isn't a schemaLocation at all), then you can supply a SchemaURIResolver which can locate the schema document any way it likes.
>
> IIRC, for your xs:include, a relative URI in the form "/WEB-INF/classes/properties/rss.xsd" should work : at any rate, some relative URI starting in "/".
>
> To access files within a jar or zip archive, Saxon supports the (Java-defined but non-standard) JAR URL scheme: see
>
> http://docs.oracle.com/javase/7/docs/api/java/net/JarURLConnection.html
>
> Michael Kay
> Saxonica
> [hidden email]
> +44 (0) 118 946 5893
>
>
>
>
> On 2 Jan 2015, at 06:02, Campbell, Lance <[hidden email]> wrote:
>
>> Thanks so much for this information.  I implemented Java 1.7 code to get that to work.  But I ran into a related issue.
>>
>> SAXON EE 9.6.0.3 is not able to find the file location for additional XSDs that are included and imported within my primary XSD.  
>>
>> Actual examples:
>> <xsd:include schemaLocation="rss.xsd" /> <xsd:import
>> namespace="edu.illinois.webservices.campus.bean"
>> schemaLocation="file:/properties/campus/campus.xsd" />
>>
>> The include file example above would be found within tomcat at:
>> {tomcat_location}/webapp/{app_name}/WEB-INF/classes/properties/rss.xsd
>>
>> The import file example above is actually a file found within a jar file at the location:
>> /properties/campus/campus.xsd
>>
>> Is there some way for me to tell SAXON where to get these files?  It seems like there should be a prefix I could use like "web-inf:" and "jar:" to tell SAXON where to look for the files.
>>
>> Possible option for Include would be:
>> <xsd:include schemaLocation="web-inf:/properties/rss.xsd" />
>>
>> Possible option for Import would be:
>> <xsd:import namespace="edu.illinois.webservices.campus.bean"
>> schemaLocation="jar:somejarfile.jar:file:/properties/campus/campus.xsd
>> " />
>>
>> It appears that this is a common issue on the web.  I did find a reference to something called URIResolver .  Do I need to implement my own version of this class?  Also is there some way for me to tell the transformer factory, "if you see this URL, then actually go here on the file system to get the file".  That would work for my include but not for the import.
>>
>> If it helps I generate my tomcat applications via eclipse.
>>
>> Thanks.
>>
>>
>>
>> Thanks,
>>
>> Lance Campbell
>> Software Architect
>> Web Services at Public Affairs
>> 217-333-0382
>>
>>
>>
>> From: Michael Kay [mailto:[hidden email]]
>> Sent: Thursday, January 01, 2015 6:06 PM
>> To: Mailing list for the SAXON XSLT and XQuery processor
>> Subject: Re: [saxon] Compiler errors instead of Runtime errors
>>
>> Sure, this feature is called "schema-awareness" and it's a standard feature of Saxon-EE.
>>
>> I wrote an overview of schema-awareness for the Stylus Studio web site many years ago, and it's still probably the best introduction there is. The focus is on XQuery rather than XSLT but the principles are the same:
>>
>> http://www.stylusstudio.com/schema_aware.html
>>
>> Unfortunately it's not just a case of supplying the schema, because
>> names such as "data" can refer to more than one element in the schema,
>> or to elements in non-validated documents. But there's a new feature
>> in XSLT 3.0 (not covered in that article)
>>
>> <xsl:mode typed="strict"/>
>>
>> which means that for all template rules in that mode, a match pattern
>> like
>>
>> <xsl:template match="invoice">
>>
>> an element name like "invoice" should be interpreted as matching only elements that are valid against the element declaration "invoice" in the schema; you can also use typed="lax" which is a bit weaker; it means that if there is a global element for invoice, then the matching element must be a valid instance of this element.
>>
>> Doing this enables Saxon to do further compile time checking, for
>> example in the template rule
>>
>> <xsl:template match="invoice">
>>  <xsl:value-of select="price"/>
>> </xsl:template>
>>
>> you will get a compile-time error if the schema declaration for "invoice" does not allow a child element named price.
>>
>> Michael Kay
>> Saxonica
>> [hidden email]
>> +44 (0) 118 946 5893
>>
>>
>>
>> On 1 Jan 2015, at 21:32, Campbell, Lance <[hidden email]> wrote:
>>
>>
>> SAXON: 9.6.0.3
>> XSL: version 2.0
>> JAVA: 7.72
>>
>> Issue:
>> Our XSLs are very complex.  There are many logical paths that can be traversed.  We are getting a lot of math Runtime errors because data is being seen as strings by the transformer factory.  To work around this issue we put the function number() around many of the values we are getting from the XML.  I would prefer to have compiler errors over runtime errors.  Runtime errors are very difficult to debug.
>>
>> Solution:
>> When I call the method "newTemplates(xslSource)" on a transformation factory it normally gives me a Template back that represents generated byte code for the XSL.  I would suggest allowing us to also pass an XSD that represents the data being referred to within the XSL.  That way the transformation factory would know the types of data elements it is working with.  
>>
>> Example:
>> <xsl:variable name="sum" select="/data/xyz/value + 10" />
>>
>> Currently the above would cause a runtime error because the transformer factory does not know that /data/xyz/value resolves to an integer.  
>>
>> To fix the issue today:
>> <xsl:variable name="sum" select=""number(/data/xyz/value) + 10" />
>>
>> If I could pass the XSD to the transformer factory then it would be able to generate byte code that would know that I defined "/data/xyz/value" as an integer.  This would allow for better type checking.  Compiler errors are much better than Runtime errors.
>>
>> This feature may already be available.  I am just not aware of how to tell the transformer factory what XSD my XML is using.
>>
>> Thanks.
>>
>>
>> Thanks,
>>
>> Lance Campbell
>> Software Architect
>> Web Services at Public Affairs
>> 217-333-0382
>> <image001.png>
>>
>>
>> ----------------------------------------------------------------------
>> -------- Dive into the World of Parallel Programming! The Go Parallel
>> Website, sponsored by Intel and developed in partnership with Slashdot
>> Media, is your hub for all things parallel software development, from
>> weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now.
>> http://goparallel.sourceforge.net_____________________________________
>> __________ saxon-help mailing list archived at
>> http://saxon.markmail.org/ [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>>
>> ----------------------------------------------------------------------
>> -------- Dive into the World of Parallel Programming! The Go Parallel
>> Website, sponsored by Intel and developed in partnership with Slashdot
>> Media, is your hub for all things parallel software development, from
>> weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now.
>> http://goparallel.sourceforge.net 
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/ 
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/ [hidden email] https://lists.sourceforge.net/lists/listinfo/saxon-help 
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Compiler errors instead of Runtime errors

Campbell, Lance
Wow.  Thanks so much for all of your help.  One final question on this topic.

Is there a way to see the Java source code for the default implementation of SchemaURIResolver for Saxon EE.  I had a thought on a modification.  I wanted to send the code I implement back for consideration of being added to the product.

Lance

Sent from my iPhone

> On Jan 2, 2015, at 10:20 AM, Michael Kay <[hidden email]> wrote:
>
> The Configuration returned by EnterpriseTranstormerFactory.getConfiguration() will generally be an EnterpriseConfiguration, and this has a method setSchemaURIResolver(). So you just need
>
>> ((EnterpriseConfiguration)configuration).setSchemaURIResolver(resolver);
>
> You can also set most configuration properties using methods such as
>
> factory.setAttribute(FeatureKeys.SCHEMA_URI_RESOLVER, resolver);
>
> Michael Kay
> Saxonica
> [hidden email]
> +44 (0) 118 946 5893
>
>
>
>
>> On 2 Jan 2015, at 16:10, Campbell, Lance <[hidden email]> wrote:
>>
>> I looked up information on SchemaURIResolver.  I have discovered it is an interface net.sf.saxon.lib.SchemaURIResolver .
>>
>> How do I set my  implementation of this interface in Java?  
>>
>> I tried doing:
>> com.saxonica.config.EnterpriseTransformerFactory etf = new com.saxonica.config.EnterpriseTransformerFactory();
>> Configuration configuration = etf.getConfiguration();
>>
>> There is no method for setting a SchemaURIResolver.  There is a method for setting a URIResolver.  Is that the same thing?
>>
>> configuration.setURIResolver(resolver);
>>
>>
>>
>> Thanks,
>>
>> Lance Campbell
>> Software Architect
>> Web Services at Public Affairs
>> 217-333-0382
>>
>>
>>
>> -----Original Message-----
>> From: Michael Kay [mailto:[hidden email]]
>> Sent: Friday, January 02, 2015 5:32 AM
>> To: Mailing list for the SAXON XSLT and XQuery processor
>> Subject: Re: [saxon] Compiler errors instead of Runtime errors
>>
>> If the schemaLocation attribute in xsd:include or xsd:import isn't an ordinary relative URI (or if there isn't a schemaLocation at all), then you can supply a SchemaURIResolver which can locate the schema document any way it likes.
>>
>> IIRC, for your xs:include, a relative URI in the form "/WEB-INF/classes/properties/rss.xsd" should work : at any rate, some relative URI starting in "/".
>>
>> To access files within a jar or zip archive, Saxon supports the (Java-defined but non-standard) JAR URL scheme: see
>>
>> http://docs.oracle.com/javase/7/docs/api/java/net/JarURLConnection.html
>>
>> Michael Kay
>> Saxonica
>> [hidden email]
>> +44 (0) 118 946 5893
>>
>>
>>
>>
>>> On 2 Jan 2015, at 06:02, Campbell, Lance <[hidden email]> wrote:
>>>
>>> Thanks so much for this information.  I implemented Java 1.7 code to get that to work.  But I ran into a related issue.
>>>
>>> SAXON EE 9.6.0.3 is not able to find the file location for additional XSDs that are included and imported within my primary XSD.  
>>>
>>> Actual examples:
>>> <xsd:include schemaLocation="rss.xsd" /> <xsd:import
>>> namespace="edu.illinois.webservices.campus.bean"
>>> schemaLocation="file:/properties/campus/campus.xsd" />
>>>
>>> The include file example above would be found within tomcat at:
>>> {tomcat_location}/webapp/{app_name}/WEB-INF/classes/properties/rss.xsd
>>>
>>> The import file example above is actually a file found within a jar file at the location:
>>> /properties/campus/campus.xsd
>>>
>>> Is there some way for me to tell SAXON where to get these files?  It seems like there should be a prefix I could use like "web-inf:" and "jar:" to tell SAXON where to look for the files.
>>>
>>> Possible option for Include would be:
>>> <xsd:include schemaLocation="web-inf:/properties/rss.xsd" />
>>>
>>> Possible option for Import would be:
>>> <xsd:import namespace="edu.illinois.webservices.campus.bean"
>>> schemaLocation="jar:somejarfile.jar:file:/properties/campus/campus.xsd
>>> " />
>>>
>>> It appears that this is a common issue on the web.  I did find a reference to something called URIResolver .  Do I need to implement my own version of this class?  Also is there some way for me to tell the transformer factory, "if you see this URL, then actually go here on the file system to get the file".  That would work for my include but not for the import.
>>>
>>> If it helps I generate my tomcat applications via eclipse.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Lance Campbell
>>> Software Architect
>>> Web Services at Public Affairs
>>> 217-333-0382
>>>
>>>
>>>
>>> From: Michael Kay [mailto:[hidden email]]
>>> Sent: Thursday, January 01, 2015 6:06 PM
>>> To: Mailing list for the SAXON XSLT and XQuery processor
>>> Subject: Re: [saxon] Compiler errors instead of Runtime errors
>>>
>>> Sure, this feature is called "schema-awareness" and it's a standard feature of Saxon-EE.
>>>
>>> I wrote an overview of schema-awareness for the Stylus Studio web site many years ago, and it's still probably the best introduction there is. The focus is on XQuery rather than XSLT but the principles are the same:
>>>
>>> http://www.stylusstudio.com/schema_aware.html
>>>
>>> Unfortunately it's not just a case of supplying the schema, because
>>> names such as "data" can refer to more than one element in the schema,
>>> or to elements in non-validated documents. But there's a new feature
>>> in XSLT 3.0 (not covered in that article)
>>>
>>> <xsl:mode typed="strict"/>
>>>
>>> which means that for all template rules in that mode, a match pattern
>>> like
>>>
>>> <xsl:template match="invoice">
>>>
>>> an element name like "invoice" should be interpreted as matching only elements that are valid against the element declaration "invoice" in the schema; you can also use typed="lax" which is a bit weaker; it means that if there is a global element for invoice, then the matching element must be a valid instance of this element.
>>>
>>> Doing this enables Saxon to do further compile time checking, for
>>> example in the template rule
>>>
>>> <xsl:template match="invoice">
>>> <xsl:value-of select="price"/>
>>> </xsl:template>
>>>
>>> you will get a compile-time error if the schema declaration for "invoice" does not allow a child element named price.
>>>
>>> Michael Kay
>>> Saxonica
>>> [hidden email]
>>> +44 (0) 118 946 5893
>>>
>>>
>>>
>>> On 1 Jan 2015, at 21:32, Campbell, Lance <[hidden email]> wrote:
>>>
>>>
>>> SAXON: 9.6.0.3
>>> XSL: version 2.0
>>> JAVA: 7.72
>>>
>>> Issue:
>>> Our XSLs are very complex.  There are many logical paths that can be traversed.  We are getting a lot of math Runtime errors because data is being seen as strings by the transformer factory.  To work around this issue we put the function number() around many of the values we are getting from the XML.  I would prefer to have compiler errors over runtime errors.  Runtime errors are very difficult to debug.
>>>
>>> Solution:
>>> When I call the method "newTemplates(xslSource)" on a transformation factory it normally gives me a Template back that represents generated byte code for the XSL.  I would suggest allowing us to also pass an XSD that represents the data being referred to within the XSL.  That way the transformation factory would know the types of data elements it is working with.  
>>>
>>> Example:
>>> <xsl:variable name="sum" select="/data/xyz/value + 10" />
>>>
>>> Currently the above would cause a runtime error because the transformer factory does not know that /data/xyz/value resolves to an integer.  
>>>
>>> To fix the issue today:
>>> <xsl:variable name="sum" select=""number(/data/xyz/value) + 10" />
>>>
>>> If I could pass the XSD to the transformer factory then it would be able to generate byte code that would know that I defined "/data/xyz/value" as an integer.  This would allow for better type checking.  Compiler errors are much better than Runtime errors.
>>>
>>> This feature may already be available.  I am just not aware of how to tell the transformer factory what XSD my XML is using.
>>>
>>> Thanks.
>>>
>>>
>>> Thanks,
>>>
>>> Lance Campbell
>>> Software Architect
>>> Web Services at Public Affairs
>>> 217-333-0382
>>> <image001.png>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> -------- Dive into the World of Parallel Programming! The Go Parallel
>>> Website, sponsored by Intel and developed in partnership with Slashdot
>>> Media, is your hub for all things parallel software development, from
>>> weekly thought leadership blogs to news, videos, case studies,
>>> tutorials and more. Take a look and join the conversation now.
>>> http://goparallel.sourceforge.net_____________________________________
>>> __________ saxon-help mailing list archived at
>>> http://saxon.markmail.org/ [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>
>>>
>>> ----------------------------------------------------------------------
>>> -------- Dive into the World of Parallel Programming! The Go Parallel
>>> Website, sponsored by Intel and developed in partnership with Slashdot
>>> Media, is your hub for all things parallel software development, from
>>> weekly thought leadership blogs to news, videos, case studies,
>>> tutorials and more. Take a look and join the conversation now.
>>> http://goparallel.sourceforge.net 
>>> _______________________________________________
>>> saxon-help mailing list archived at http://saxon.markmail.org/ 
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/ [hidden email] https://lists.sourceforge.net/lists/listinfo/saxon-help 
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Compiler errors instead of Runtime errors

Michael Kay
>
> Is there a way to see the Java source code for the default implementation of SchemaURIResolver for Saxon EE.

I wish it were possible to let people see the source code for educational purposes without risking IP leaks. But in this case, the essence of it is:

public Source[] resolve(String targetNamespace, String baseURI, String[] locations) throws XPathException {
    if (config == null) {
        throw new NullPointerException("No configuration supplied to schema URI resolver");
    }
    try {
        if (config.isSchemaAvailable(targetNamespace) && !(Boolean)config.getConfigurationProperty(FeatureKeys.MULTIPLE_SCHEMA_IMPORTS)) {
            return EMPTY_SOURCE_ARRAY;
        }
        URIResolver uriResolver = config.getURIResolver();
        Source[] sources = new Source[locations.length];
        for (int i=0; i<locations.length; i++) {
            // Now try a JAXP URIResolver if available

            if (uriResolver != null) {
                sources[i] = uriResolver.resolve(locations[i], baseURI);
            }

            // if a user URI resolver returns null, try the standard one
            // (Note, the standard URI resolver never returns null)
            if (sources[i] == null) {
                sources[i] = config.getSystemURIResolver().resolve(locations[i], baseURI);
            }
        }
        return sources;
    } catch (TransformerException e) {
        throw XPathException.makeXPathException(e);
    }
}

Michael Kay
Saxonica
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help