Quantcast

Announcing Saxon-JS

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Announcing Saxon-JS

Michael Kay
We're delighted to announce the first public beta release of Saxon-JS. Details here:

http://www.saxonica.com/saxon-js/index.xml

Saxon-JS allows execution of XSLT 3.0 stylesheets in the browser. In due course (but not yet) it will also become available in other environments such as Node.js.

Saxon-JS is a run-time only product; you first need to compile the stylesheet using Saxon-EE (9.7.0.7 or later). The compiled form (called a "stylesheet export file") is an XML document in a Saxon-specific format, so you can prepare the stylesheet on a development workstation and then deploy it anywhere on the web.

Saxon-JS is planned as a replacement for Saxon-CE. It shares with Saxon-CE the ability to write interactive applications, where template rules with modes such as "ixsl:onclick" respond to user interaction. Unlike Saxon-CE, it's a new product written in pure Javascript (Saxon-CE was the Java product stripped down and cross-compiled using GWT), which makes it much smaller and more manageable.

Saxon-JS at its first release has almost complete coverage of XPath 3.1 (including maps, arrays, and JSON), plus support for many XSLT 3.0 features such as try/catch and text value templates. To keep it small, it omits most optional features including schema awareness, streaming, and higher order functions.

At this beta release we haven't attempted comprehensive testing on all browsers. Most of our development has been on Safari and Firefox. We know for sure that it doesn't yet work on Internet Explorer. Feedback on browser issues is particularly welcome.

The product documentation at http://www.saxonica.com/saxon-js/documentation/index.html is a Saxon-JS application, so if you can read the documentation, then Saxon-JS works on your brorwser.

There's a project set up on http://saxonica.plan.io/ for feedback. We're looking forward to your reactions.

Michael Kay
Saxonica

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Sewell, David R. (drs2n)
Michael,

Congratulations on the release! For clarification: I assume that anyone who
wants to develop a Saxon-JS application will need a standalone Saxon-EE license,
i.e. it will not be an option to use a packaged Saxon-EE such the one bundled
with oXygen XML? (which in any case doesn't yet include Saxon 9.7)

David

On Thu, 28 Jul 2016, Michael Kay wrote:

> We're delighted to announce the first public beta release of Saxon-JS. Details here:
>
> http://www.saxonica.com/saxon-js/index.xml
>
> Saxon-JS allows execution of XSLT 3.0 stylesheets in the browser. In due course (but not yet) it will also become available in other environments such as Node.js.
>
> Saxon-JS is a run-time only product; you first need to compile the stylesheet using Saxon-EE (9.7.0.7 or later). The compiled form (called a "stylesheet export file") is an XML document in a Saxon-specific format, so you can prepare the stylesheet on a development workstation and then deploy it anywhere on the web.
>
> Saxon-JS is planned as a replacement for Saxon-CE. It shares with Saxon-CE the ability to write interactive applications, where template rules with modes such as "ixsl:onclick" respond to user interaction. Unlike Saxon-CE, it's a new product written in pure Javascript (Saxon-CE was the Java product stripped down and cross-compiled using GWT), which makes it much smaller and more manageable.
>
> Saxon-JS at its first release has almost complete coverage of XPath 3.1 (including maps, arrays, and JSON), plus support for many XSLT 3.0 features such as try/catch and text value templates. To keep it small, it omits most optional features including schema awareness, streaming, and higher order functions.
>
> At this beta release we haven't attempted comprehensive testing on all browsers. Most of our development has been on Safari and Firefox. We know for sure that it doesn't yet work on Internet Explorer. Feedback on browser issues is particularly welcome.
>
> The product documentation at http://www.saxonica.com/saxon-js/documentation/index.html is a Saxon-JS application, so if you can read the documentation, then Saxon-JS works on your brorwser.
>
> There's a project set up on http://saxonica.plan.io/ for feedback. We're looking forward to your reactions.
>
> Michael Kay
> Saxonica
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

--
David Sewell
Manager of Digital Initiatives
The University of Virginia Press
Email: [hidden email]   Tel: +1 434 924 9973
Web: http://www.upress.virginia.edu/rotunda

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Michael Kay
David,

SyncroSoft's agreement with Saxonica allows them to ship this capability in their product if (and when) they choose to do so.

Michael Kay
Saxonica


> On 28 Jul 2016, at 16:33, Sewell, David R. (drs2n) <[hidden email]> wrote:
>
> Michael,
>
> Congratulations on the release! For clarification: I assume that anyone who
> wants to develop a Saxon-JS application will need a standalone Saxon-EE license,
> i.e. it will not be an option to use a packaged Saxon-EE such the one bundled
> with oXygen XML? (which in any case doesn't yet include Saxon 9.7)
>
> David
>
> On Thu, 28 Jul 2016, Michael Kay wrote:
>
>> We're delighted to announce the first public beta release of Saxon-JS. Details here:
>>
>> http://www.saxonica.com/saxon-js/index.xml
>>
>> Saxon-JS allows execution of XSLT 3.0 stylesheets in the browser. In due course (but not yet) it will also become available in other environments such as Node.js.
>>
>> Saxon-JS is a run-time only product; you first need to compile the stylesheet using Saxon-EE (9.7.0.7 or later). The compiled form (called a "stylesheet export file") is an XML document in a Saxon-specific format, so you can prepare the stylesheet on a development workstation and then deploy it anywhere on the web.
>>
>> Saxon-JS is planned as a replacement for Saxon-CE. It shares with Saxon-CE the ability to write interactive applications, where template rules with modes such as "ixsl:onclick" respond to user interaction. Unlike Saxon-CE, it's a new product written in pure Javascript (Saxon-CE was the Java product stripped down and cross-compiled using GWT), which makes it much smaller and more manageable.
>>
>> Saxon-JS at its first release has almost complete coverage of XPath 3.1 (including maps, arrays, and JSON), plus support for many XSLT 3.0 features such as try/catch and text value templates. To keep it small, it omits most optional features including schema awareness, streaming, and higher order functions.
>>
>> At this beta release we haven't attempted comprehensive testing on all browsers. Most of our development has been on Safari and Firefox. We know for sure that it doesn't yet work on Internet Explorer. Feedback on browser issues is particularly welcome.
>>
>> The product documentation at http://www.saxonica.com/saxon-js/documentation/index.html is a Saxon-JS application, so if you can read the documentation, then Saxon-JS works on your brorwser.
>>
>> There's a project set up on http://saxonica.plan.io/ for feedback. We're looking forward to your reactions.
>>
>> Michael Kay
>> Saxonica
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>
> --
> David Sewell
> Manager of Digital Initiatives
> The University of Virginia Press
> Email: [hidden email]   Tel: +1 434 924 9973
> Web: http://www.upress.virginia.edu/rotunda
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 



------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Martynas Jusevičius
In reply to this post by Michael Kay
Would it be possible to plug a custom URIResolver into Saxon-JS?

Old question: https://sourceforge.net/p/saxon/mailman/message/31568980/

On Thu, Jul 28, 2016 at 4:41 PM, Michael Kay <[hidden email]> wrote:

> We're delighted to announce the first public beta release of Saxon-JS. Details here:
>
> http://www.saxonica.com/saxon-js/index.xml
>
> Saxon-JS allows execution of XSLT 3.0 stylesheets in the browser. In due course (but not yet) it will also become available in other environments such as Node.js.
>
> Saxon-JS is a run-time only product; you first need to compile the stylesheet using Saxon-EE (9.7.0.7 or later). The compiled form (called a "stylesheet export file") is an XML document in a Saxon-specific format, so you can prepare the stylesheet on a development workstation and then deploy it anywhere on the web.
>
> Saxon-JS is planned as a replacement for Saxon-CE. It shares with Saxon-CE the ability to write interactive applications, where template rules with modes such as "ixsl:onclick" respond to user interaction. Unlike Saxon-CE, it's a new product written in pure Javascript (Saxon-CE was the Java product stripped down and cross-compiled using GWT), which makes it much smaller and more manageable.
>
> Saxon-JS at its first release has almost complete coverage of XPath 3.1 (including maps, arrays, and JSON), plus support for many XSLT 3.0 features such as try/catch and text value templates. To keep it small, it omits most optional features including schema awareness, streaming, and higher order functions.
>
> At this beta release we haven't attempted comprehensive testing on all browsers. Most of our development has been on Safari and Firefox. We know for sure that it doesn't yet work on Internet Explorer. Feedback on browser issues is particularly welcome.
>
> The product documentation at http://www.saxonica.com/saxon-js/documentation/index.html is a Saxon-JS application, so if you can read the documentation, then Saxon-JS works on your brorwser.
>
> There's a project set up on http://saxonica.plan.io/ for feedback. We're looking forward to your reactions.
>
> Michael Kay
> Saxonica
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Michael Kay
First let's recognise that the "URIResolver" we are familiar with in the Java world does not resolve URIs, it dereferences them (well actually, it does a bit of each and as a result it's pretty badly defined). So we need to be clear about what the requirement is here, and preferably not define it in terms of a Java feature which is badly thought out.

Resolving relative URIs involves questions about base URI, and there are a lot of questions about the base URI of a compiled stylesheet that we haven't fully thought through yet. The XSLT 3.0 spec rocognizes the problem and gives us some room for manoevre, but it doesn't give us all the answers. But the traditional model where the base URI is the location of the stylesheet source code is clearly wrong: the stylesheet source code is probably on some developer's laptop.

Dereferencing absolute URIs to get a resource is a different question, and in many ways more straightforward, and there's certainly scope to include a user-supplied callback here. It can probably be done in Saxon-JS today by reassigning the relevant internal Saxon functions, but we should (and probably will) do it more cleanly as a well-defined and supported API. The tricky bits of the design are (a) whether the design should be specific to particular media types, and (b) how best to handle asyncronous access.

Michael Kay
Saxonica




------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Martynas Jusevičius
Our use case is actually more about dereferencing than resolving, as
the URIs being resolved are usually already absolute.

On the server-side, we are using URIResolver to map vocabulary
namespace URIs to cached copies of them, to avoid HTTP latency/errors
and improve performance. E.g. instead of looking up
"http://purl.org/dc/terms/" online, we read it as Source from a local
file such as dcterms.rdf.

The URIResolver:
https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/org/graphity/client/util/DataManager.java#L157
The namespace mapping:
https://github.com/AtomGraph/Web-Client/blob/master/src/main/resources/prefix-mapping.n3

Having a similar mechanism on the client-side to intercept document()
calls, we could make the stylesheets much more portable.
If you have some API in mind, I would be happy to provide feedback.
Re. media type, I think the most flexible way would be to allow
control of the HTTP Accept header.

It might involve caching documents using JS. Is there a way to put
them directly into Saxon's document cache?

On Fri, Aug 5, 2016 at 1:25 AM, Michael Kay <[hidden email]> wrote:

> First let's recognise that the "URIResolver" we are familiar with in the Java world does not resolve URIs, it dereferences them (well actually, it does a bit of each and as a result it's pretty badly defined). So we need to be clear about what the requirement is here, and preferably not define it in terms of a Java feature which is badly thought out.
>
> Resolving relative URIs involves questions about base URI, and there are a lot of questions about the base URI of a compiled stylesheet that we haven't fully thought through yet. The XSLT 3.0 spec rocognizes the problem and gives us some room for manoevre, but it doesn't give us all the answers. But the traditional model where the base URI is the location of the stylesheet source code is clearly wrong: the stylesheet source code is probably on some developer's laptop.
>
> Dereferencing absolute URIs to get a resource is a different question, and in many ways more straightforward, and there's certainly scope to include a user-supplied callback here. It can probably be done in Saxon-JS today by reassigning the relevant internal Saxon functions, but we should (and probably will) do it more cleanly as a well-defined and supported API. The tricky bits of the design are (a) whether the design should be specific to particular media types, and (b) how best to handle asyncronous access.
>
> Michael Kay
> Saxonica
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Imsieke, Gerrit, le-tex
Hi Martynas,

Maybe XML Catalogs and our XSLT-based catalog resolver are of any use to
you?

A Saxon CE demo of a previous version is here:
https://subversion.le-tex.de/common/letex-util/xslt-based-catalog-resolver/interactive.html

The most recent version is now hosted on github:
https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/README.md

Gerrit


On 05.08.2016 10:47, Martynas Jusevičius wrote:

> Our use case is actually more about dereferencing than resolving, as
> the URIs being resolved are usually already absolute.
>
> On the server-side, we are using URIResolver to map vocabulary
> namespace URIs to cached copies of them, to avoid HTTP latency/errors
> and improve performance. E.g. instead of looking up
> "http://purl.org/dc/terms/" online, we read it as Source from a local
> file such as dcterms.rdf.
>
> The URIResolver:
> https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/org/graphity/client/util/DataManager.java#L157
> The namespace mapping:
> https://github.com/AtomGraph/Web-Client/blob/master/src/main/resources/prefix-mapping.n3
>
> Having a similar mechanism on the client-side to intercept document()
> calls, we could make the stylesheets much more portable.
> If you have some API in mind, I would be happy to provide feedback.
> Re. media type, I think the most flexible way would be to allow
> control of the HTTP Accept header.
>
> It might involve caching documents using JS. Is there a way to put
> them directly into Saxon's document cache?
>
> On Fri, Aug 5, 2016 at 1:25 AM, Michael Kay <[hidden email]> wrote:
>> First let's recognise that the "URIResolver" we are familiar with in the Java world does not resolve URIs, it dereferences them (well actually, it does a bit of each and as a result it's pretty badly defined). So we need to be clear about what the requirement is here, and preferably not define it in terms of a Java feature which is badly thought out.
>>
>> Resolving relative URIs involves questions about base URI, and there are a lot of questions about the base URI of a compiled stylesheet that we haven't fully thought through yet. The XSLT 3.0 spec rocognizes the problem and gives us some room for manoevre, but it doesn't give us all the answers. But the traditional model where the base URI is the location of the stylesheet source code is clearly wrong: the stylesheet source code is probably on some developer's laptop.
>>
>> Dereferencing absolute URIs to get a resource is a different question, and in many ways more straightforward, and there's certainly scope to include a user-supplied callback here. It can probably be done in Saxon-JS today by reassigning the relevant internal Saxon functions, but we should (and probably will) do it more cleanly as a well-defined and supported API. The tricky bits of the design are (a) whether the design should be specific to particular media types, and (b) how best to handle asyncronous access.
>>
>> Michael Kay
>> Saxonica
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Michael Kay
In reply to this post by Martynas Jusevičius

>
> It might involve caching documents using JS. Is there a way to put
> them directly into Saxon's document cache?
>

Yes, as an interim solution that would work quite well. I think (without testing) you should be able to do

SaxonJS.U.context.fixed.documentPool[key] = content;

where key is the absolute URI and content is the XML document node; the next call on doc() should simply pick the document up from this documentPool.

The ".U." signals interfaces that may change over time...

Michael Kay
Saxonica



------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Martynas Jusevičius
In reply to this post by Imsieke, Gerrit, le-tex
Gerrit,

we would prefer a format-agnostic mechanism rather than an
XML-specific one. Our data is RDF, not XML as such. RDF/XML only
serves as an on-the-fly bridge for XSLT transformations, because the
input data (such as RDF vocabularies online) can be in any RDF syntax,
e.g. Turtle which is not XML.

On Fri, Aug 5, 2016 at 11:33 AM, Imsieke, Gerrit, le-tex
<[hidden email]> wrote:

> Hi Martynas,
>
> Maybe XML Catalogs and our XSLT-based catalog resolver are of any use to
> you?
>
> A Saxon CE demo of a previous version is here:
> https://subversion.le-tex.de/common/letex-util/xslt-based-catalog-resolver/interactive.html
>
> The most recent version is now hosted on github:
> https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/README.md
>
> Gerrit
>
>
> On 05.08.2016 10:47, Martynas Jusevičius wrote:
>> Our use case is actually more about dereferencing than resolving, as
>> the URIs being resolved are usually already absolute.
>>
>> On the server-side, we are using URIResolver to map vocabulary
>> namespace URIs to cached copies of them, to avoid HTTP latency/errors
>> and improve performance. E.g. instead of looking up
>> "http://purl.org/dc/terms/" online, we read it as Source from a local
>> file such as dcterms.rdf.
>>
>> The URIResolver:
>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/org/graphity/client/util/DataManager.java#L157
>> The namespace mapping:
>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/resources/prefix-mapping.n3
>>
>> Having a similar mechanism on the client-side to intercept document()
>> calls, we could make the stylesheets much more portable.
>> If you have some API in mind, I would be happy to provide feedback.
>> Re. media type, I think the most flexible way would be to allow
>> control of the HTTP Accept header.
>>
>> It might involve caching documents using JS. Is there a way to put
>> them directly into Saxon's document cache?
>>
>> On Fri, Aug 5, 2016 at 1:25 AM, Michael Kay <[hidden email]> wrote:
>>> First let's recognise that the "URIResolver" we are familiar with in the Java world does not resolve URIs, it dereferences them (well actually, it does a bit of each and as a result it's pretty badly defined). So we need to be clear about what the requirement is here, and preferably not define it in terms of a Java feature which is badly thought out.
>>>
>>> Resolving relative URIs involves questions about base URI, and there are a lot of questions about the base URI of a compiled stylesheet that we haven't fully thought through yet. The XSLT 3.0 spec rocognizes the problem and gives us some room for manoevre, but it doesn't give us all the answers. But the traditional model where the base URI is the location of the stylesheet source code is clearly wrong: the stylesheet source code is probably on some developer's laptop.
>>>
>>> Dereferencing absolute URIs to get a resource is a different question, and in many ways more straightforward, and there's certainly scope to include a user-supplied callback here. It can probably be done in Saxon-JS today by reassigning the relevant internal Saxon functions, but we should (and probably will) do it more cleanly as a well-defined and supported API. The tricky bits of the design are (a) whether the design should be specific to particular media types, and (b) how best to handle asyncronous access.
>>>
>>> Michael Kay
>>> Saxonica
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>
> --
> Gerrit Imsieke
> Geschäftsführer / Managing Director
> le-tex publishing services GmbH
> Weissenfelser Str. 84, 04229 Leipzig, Germany
> Phone +49 341 355356 110, Fax +49 341 355356 510
> [hidden email], http://www.le-tex.de
>
> Registergericht / Commercial Register: Amtsgericht Leipzig
> Registernummer / Registration Number: HRB 24930
>
> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
> Thomas Schmidt, Dr. Reinhard Vöckler
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Imsieke, Gerrit, le-tex
Hi Martynas,

Just to clarify: The XSLT-based resolver just translates URIs to URIs
(for ex., canonical URIs to relative URIs of cached copies). It uses XML
catalogs for the translation rule configuration. The resources behind
these URIs don’t have to be XML documents, as in typical XML catalog
resolvers.

On area where we use it is to translate this CSS
@font-face { font-family: 'Charis'; font-style: normal; font-weight:
normal;
src:url('http://transpect.le-tex.de/fontlib/charis/regular/CharisSIL-R.ttf'); 
}
to this:
@font-face { font-family: 'Charis'; font-style: normal; font-weight:
normal;
src:url('file:/my/working/copy/fontlib/charis/regular/CharisSIL-R.ttf'); }

CSS, TTF – no XML files involved!

Gerrit

On 05.08.2016 13:32, Martynas Jusevičius wrote:

> Gerrit,
>
> we would prefer a format-agnostic mechanism rather than an
> XML-specific one. Our data is RDF, not XML as such. RDF/XML only
> serves as an on-the-fly bridge for XSLT transformations, because the
> input data (such as RDF vocabularies online) can be in any RDF syntax,
> e.g. Turtle which is not XML.
>
> On Fri, Aug 5, 2016 at 11:33 AM, Imsieke, Gerrit, le-tex
> <[hidden email]> wrote:
>> Hi Martynas,
>>
>> Maybe XML Catalogs and our XSLT-based catalog resolver are of any use to
>> you?
>>
>> A Saxon CE demo of a previous version is here:
>> https://subversion.le-tex.de/common/letex-util/xslt-based-catalog-resolver/interactive.html
>>
>> The most recent version is now hosted on github:
>> https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/README.md
>>
>> Gerrit
>>
>>
>> On 05.08.2016 10:47, Martynas Jusevičius wrote:
>>> Our use case is actually more about dereferencing than resolving, as
>>> the URIs being resolved are usually already absolute.
>>>
>>> On the server-side, we are using URIResolver to map vocabulary
>>> namespace URIs to cached copies of them, to avoid HTTP latency/errors
>>> and improve performance. E.g. instead of looking up
>>> "http://purl.org/dc/terms/" online, we read it as Source from a local
>>> file such as dcterms.rdf.
>>>
>>> The URIResolver:
>>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/org/graphity/client/util/DataManager.java#L157
>>> The namespace mapping:
>>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/resources/prefix-mapping.n3
>>>
>>> Having a similar mechanism on the client-side to intercept document()
>>> calls, we could make the stylesheets much more portable.
>>> If you have some API in mind, I would be happy to provide feedback.
>>> Re. media type, I think the most flexible way would be to allow
>>> control of the HTTP Accept header.
>>>
>>> It might involve caching documents using JS. Is there a way to put
>>> them directly into Saxon's document cache?
>>>
>>> On Fri, Aug 5, 2016 at 1:25 AM, Michael Kay <[hidden email]> wrote:
>>>> First let's recognise that the "URIResolver" we are familiar with in the Java world does not resolve URIs, it dereferences them (well actually, it does a bit of each and as a result it's pretty badly defined). So we need to be clear about what the requirement is here, and preferably not define it in terms of a Java feature which is badly thought out.
>>>>
>>>> Resolving relative URIs involves questions about base URI, and there are a lot of questions about the base URI of a compiled stylesheet that we haven't fully thought through yet. The XSLT 3.0 spec rocognizes the problem and gives us some room for manoevre, but it doesn't give us all the answers. But the traditional model where the base URI is the location of the stylesheet source code is clearly wrong: the stylesheet source code is probably on some developer's laptop.
>>>>
>>>> Dereferencing absolute URIs to get a resource is a different question, and in many ways more straightforward, and there's certainly scope to include a user-supplied callback here. It can probably be done in Saxon-JS today by reassigning the relevant internal Saxon functions, but we should (and probably will) do it more cleanly as a well-defined and supported API. The tricky bits of the design are (a) whether the design should be specific to particular media types, and (b) how best to handle asyncronous access.
>>>>
>>>> Michael Kay
>>>> Saxonica
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>
>>
>> --
>> Gerrit Imsieke
>> Geschäftsführer / Managing Director
>> le-tex publishing services GmbH
>> Weissenfelser Str. 84, 04229 Leipzig, Germany
>> Phone +49 341 355356 110, Fax +49 341 355356 510
>> [hidden email], http://www.le-tex.de
>>
>> Registergericht / Commercial Register: Amtsgericht Leipzig
>> Registernummer / Registration Number: HRB 24930
>>
>> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
>> Thomas Schmidt, Dr. Reinhard Vöckler
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Martynas Jusevičius
OK, I get a better picture now :)

But is it using the standard document() or some custom function on
lookup? I was hoping to reuse document() just like we do on the
server-side.

On Fri, Aug 5, 2016 at 1:51 PM, Imsieke, Gerrit, le-tex
<[hidden email]> wrote:

> Hi Martynas,
>
> Just to clarify: The XSLT-based resolver just translates URIs to URIs
> (for ex., canonical URIs to relative URIs of cached copies). It uses XML
> catalogs for the translation rule configuration. The resources behind
> these URIs don’t have to be XML documents, as in typical XML catalog
> resolvers.
>
> On area where we use it is to translate this CSS
> @font-face { font-family: 'Charis'; font-style: normal; font-weight:
> normal;
> src:url('http://transpect.le-tex.de/fontlib/charis/regular/CharisSIL-R.ttf');
> }
> to this:
> @font-face { font-family: 'Charis'; font-style: normal; font-weight:
> normal;
> src:url('file:/my/working/copy/fontlib/charis/regular/CharisSIL-R.ttf'); }
>
> CSS, TTF – no XML files involved!
>
> Gerrit
>
> On 05.08.2016 13:32, Martynas Jusevičius wrote:
>> Gerrit,
>>
>> we would prefer a format-agnostic mechanism rather than an
>> XML-specific one. Our data is RDF, not XML as such. RDF/XML only
>> serves as an on-the-fly bridge for XSLT transformations, because the
>> input data (such as RDF vocabularies online) can be in any RDF syntax,
>> e.g. Turtle which is not XML.
>>
>> On Fri, Aug 5, 2016 at 11:33 AM, Imsieke, Gerrit, le-tex
>> <[hidden email]> wrote:
>>> Hi Martynas,
>>>
>>> Maybe XML Catalogs and our XSLT-based catalog resolver are of any use to
>>> you?
>>>
>>> A Saxon CE demo of a previous version is here:
>>> https://subversion.le-tex.de/common/letex-util/xslt-based-catalog-resolver/interactive.html
>>>
>>> The most recent version is now hosted on github:
>>> https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/README.md
>>>
>>> Gerrit
>>>
>>>
>>> On 05.08.2016 10:47, Martynas Jusevičius wrote:
>>>> Our use case is actually more about dereferencing than resolving, as
>>>> the URIs being resolved are usually already absolute.
>>>>
>>>> On the server-side, we are using URIResolver to map vocabulary
>>>> namespace URIs to cached copies of them, to avoid HTTP latency/errors
>>>> and improve performance. E.g. instead of looking up
>>>> "http://purl.org/dc/terms/" online, we read it as Source from a local
>>>> file such as dcterms.rdf.
>>>>
>>>> The URIResolver:
>>>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/org/graphity/client/util/DataManager.java#L157
>>>> The namespace mapping:
>>>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/resources/prefix-mapping.n3
>>>>
>>>> Having a similar mechanism on the client-side to intercept document()
>>>> calls, we could make the stylesheets much more portable.
>>>> If you have some API in mind, I would be happy to provide feedback.
>>>> Re. media type, I think the most flexible way would be to allow
>>>> control of the HTTP Accept header.
>>>>
>>>> It might involve caching documents using JS. Is there a way to put
>>>> them directly into Saxon's document cache?
>>>>
>>>> On Fri, Aug 5, 2016 at 1:25 AM, Michael Kay <[hidden email]> wrote:
>>>>> First let's recognise that the "URIResolver" we are familiar with in the Java world does not resolve URIs, it dereferences them (well actually, it does a bit of each and as a result it's pretty badly defined). So we need to be clear about what the requirement is here, and preferably not define it in terms of a Java feature which is badly thought out.
>>>>>
>>>>> Resolving relative URIs involves questions about base URI, and there are a lot of questions about the base URI of a compiled stylesheet that we haven't fully thought through yet. The XSLT 3.0 spec rocognizes the problem and gives us some room for manoevre, but it doesn't give us all the answers. But the traditional model where the base URI is the location of the stylesheet source code is clearly wrong: the stylesheet source code is probably on some developer's laptop.
>>>>>
>>>>> Dereferencing absolute URIs to get a resource is a different question, and in many ways more straightforward, and there's certainly scope to include a user-supplied callback here. It can probably be done in Saxon-JS today by reassigning the relevant internal Saxon functions, but we should (and probably will) do it more cleanly as a well-defined and supported API. The tricky bits of the design are (a) whether the design should be specific to particular media types, and (b) how best to handle asyncronous access.
>>>>>
>>>>> Michael Kay
>>>>> Saxonica
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>>
>>>
>>> --
>>> Gerrit Imsieke
>>> Geschäftsführer / Managing Director
>>> le-tex publishing services GmbH
>>> Weissenfelser Str. 84, 04229 Leipzig, Germany
>>> Phone +49 341 355356 110, Fax +49 341 355356 510
>>> [hidden email], http://www.le-tex.de
>>>
>>> Registergericht / Commercial Register: Amtsgericht Leipzig
>>> Registernummer / Registration Number: HRB 24930
>>>
>>> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
>>> Thomas Schmidt, Dr. Reinhard Vöckler
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>
> --
> Gerrit Imsieke
> Geschäftsführer / Managing Director
> le-tex publishing services GmbH
> Weissenfelser Str. 84, 04229 Leipzig, Germany
> Phone +49 341 355356 110, Fax +49 341 355356 510
> [hidden email], http://www.le-tex.de
>
> Registergericht / Commercial Register: Amtsgericht Leipzig
> Registernummer / Registration Number: HRB 24930
>
> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
> Thomas Schmidt, Dr. Reinhard Vöckler
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Imsieke, Gerrit, le-tex
But document() is for XML resources only, isn’t it?

You’d use it like document(tr:resolve-uri-by-catalog($uri-in,
$catalog)), see
https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/xsl/resolve-uri-by-catalog.xsl#L64

On 05.08.2016 14:01, Martynas Jusevičius wrote:

> OK, I get a better picture now :)
>
> But is it using the standard document() or some custom function on
> lookup? I was hoping to reuse document() just like we do on the
> server-side.
>
> On Fri, Aug 5, 2016 at 1:51 PM, Imsieke, Gerrit, le-tex
> <[hidden email]> wrote:
>> Hi Martynas,
>>
>> Just to clarify: The XSLT-based resolver just translates URIs to URIs
>> (for ex., canonical URIs to relative URIs of cached copies). It uses XML
>> catalogs for the translation rule configuration. The resources behind
>> these URIs don’t have to be XML documents, as in typical XML catalog
>> resolvers.
>>
>> On area where we use it is to translate this CSS
>> @font-face { font-family: 'Charis'; font-style: normal; font-weight:
>> normal;
>> src:url('http://transpect.le-tex.de/fontlib/charis/regular/CharisSIL-R.ttf');
>> }
>> to this:
>> @font-face { font-family: 'Charis'; font-style: normal; font-weight:
>> normal;
>> src:url('file:/my/working/copy/fontlib/charis/regular/CharisSIL-R.ttf'); }
>>
>> CSS, TTF – no XML files involved!
>>
>> Gerrit
>>
>> On 05.08.2016 13:32, Martynas Jusevičius wrote:
>>> Gerrit,
>>>
>>> we would prefer a format-agnostic mechanism rather than an
>>> XML-specific one. Our data is RDF, not XML as such. RDF/XML only
>>> serves as an on-the-fly bridge for XSLT transformations, because the
>>> input data (such as RDF vocabularies online) can be in any RDF syntax,
>>> e.g. Turtle which is not XML.
>>>
>>> On Fri, Aug 5, 2016 at 11:33 AM, Imsieke, Gerrit, le-tex
>>> <[hidden email]> wrote:
>>>> Hi Martynas,
>>>>
>>>> Maybe XML Catalogs and our XSLT-based catalog resolver are of any use to
>>>> you?
>>>>
>>>> A Saxon CE demo of a previous version is here:
>>>> https://subversion.le-tex.de/common/letex-util/xslt-based-catalog-resolver/interactive.html
>>>>
>>>> The most recent version is now hosted on github:
>>>> https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/README.md
>>>>
>>>> Gerrit
>>>>
>>>>
>>>> On 05.08.2016 10:47, Martynas Jusevičius wrote:
>>>>> Our use case is actually more about dereferencing than resolving, as
>>>>> the URIs being resolved are usually already absolute.
>>>>>
>>>>> On the server-side, we are using URIResolver to map vocabulary
>>>>> namespace URIs to cached copies of them, to avoid HTTP latency/errors
>>>>> and improve performance. E.g. instead of looking up
>>>>> "http://purl.org/dc/terms/" online, we read it as Source from a local
>>>>> file such as dcterms.rdf.
>>>>>
>>>>> The URIResolver:
>>>>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/org/graphity/client/util/DataManager.java#L157
>>>>> The namespace mapping:
>>>>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/resources/prefix-mapping.n3
>>>>>
>>>>> Having a similar mechanism on the client-side to intercept document()
>>>>> calls, we could make the stylesheets much more portable.
>>>>> If you have some API in mind, I would be happy to provide feedback.
>>>>> Re. media type, I think the most flexible way would be to allow
>>>>> control of the HTTP Accept header.
>>>>>
>>>>> It might involve caching documents using JS. Is there a way to put
>>>>> them directly into Saxon's document cache?
>>>>>
>>>>> On Fri, Aug 5, 2016 at 1:25 AM, Michael Kay <[hidden email]> wrote:
>>>>>> First let's recognise that the "URIResolver" we are familiar with in the Java world does not resolve URIs, it dereferences them (well actually, it does a bit of each and as a result it's pretty badly defined). So we need to be clear about what the requirement is here, and preferably not define it in terms of a Java feature which is badly thought out.
>>>>>>
>>>>>> Resolving relative URIs involves questions about base URI, and there are a lot of questions about the base URI of a compiled stylesheet that we haven't fully thought through yet. The XSLT 3.0 spec rocognizes the problem and gives us some room for manoevre, but it doesn't give us all the answers. But the traditional model where the base URI is the location of the stylesheet source code is clearly wrong: the stylesheet source code is probably on some developer's laptop.
>>>>>>
>>>>>> Dereferencing absolute URIs to get a resource is a different question, and in many ways more straightforward, and there's certainly scope to include a user-supplied callback here. It can probably be done in Saxon-JS today by reassigning the relevant internal Saxon functions, but we should (and probably will) do it more cleanly as a well-defined and supported API. The tricky bits of the design are (a) whether the design should be specific to particular media types, and (b) how best to handle asyncronous access.
>>>>>>
>>>>>> Michael Kay
>>>>>> Saxonica
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>>>
>>>>
>>>> --
>>>> Gerrit Imsieke
>>>> Geschäftsführer / Managing Director
>>>> le-tex publishing services GmbH
>>>> Weissenfelser Str. 84, 04229 Leipzig, Germany
>>>> Phone +49 341 355356 110, Fax +49 341 355356 510
>>>> [hidden email], http://www.le-tex.de
>>>>
>>>> Registergericht / Commercial Register: Amtsgericht Leipzig
>>>> Registernummer / Registration Number: HRB 24930
>>>>
>>>> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
>>>> Thomas Schmidt, Dr. Reinhard Vöckler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>
>>
>> --
>> Gerrit Imsieke
>> Geschäftsführer / Managing Director
>> le-tex publishing services GmbH
>> Weissenfelser Str. 84, 04229 Leipzig, Germany
>> Phone +49 341 355356 110, Fax +49 341 355356 510
>> [hidden email], http://www.le-tex.de
>>
>> Registergericht / Commercial Register: Amtsgericht Leipzig
>> Registernummer / Registration Number: HRB 24930
>>
>> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
>> Thomas Schmidt, Dr. Reinhard Vöckler
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Martynas Jusevičius
Well, XML on the output side does not mean XML on the input side :)

When dereferencing vocabulary URI, RDF format is not important as it
can be content-negotiated. Whatever the syntax, it is parsed into an
RDF model. Then, for document() access, the model is always serialized
as RDF/XML.



On Fri, Aug 5, 2016 at 2:20 PM, Imsieke, Gerrit, le-tex
<[hidden email]> wrote:

> But document() is for XML resources only, isn’t it?
>
> You’d use it like document(tr:resolve-uri-by-catalog($uri-in,
> $catalog)), see
> https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/xsl/resolve-uri-by-catalog.xsl#L64
>
> On 05.08.2016 14:01, Martynas Jusevičius wrote:
>> OK, I get a better picture now :)
>>
>> But is it using the standard document() or some custom function on
>> lookup? I was hoping to reuse document() just like we do on the
>> server-side.
>>
>> On Fri, Aug 5, 2016 at 1:51 PM, Imsieke, Gerrit, le-tex
>> <[hidden email]> wrote:
>>> Hi Martynas,
>>>
>>> Just to clarify: The XSLT-based resolver just translates URIs to URIs
>>> (for ex., canonical URIs to relative URIs of cached copies). It uses XML
>>> catalogs for the translation rule configuration. The resources behind
>>> these URIs don’t have to be XML documents, as in typical XML catalog
>>> resolvers.
>>>
>>> On area where we use it is to translate this CSS
>>> @font-face { font-family: 'Charis'; font-style: normal; font-weight:
>>> normal;
>>> src:url('http://transpect.le-tex.de/fontlib/charis/regular/CharisSIL-R.ttf');
>>> }
>>> to this:
>>> @font-face { font-family: 'Charis'; font-style: normal; font-weight:
>>> normal;
>>> src:url('file:/my/working/copy/fontlib/charis/regular/CharisSIL-R.ttf'); }
>>>
>>> CSS, TTF – no XML files involved!
>>>
>>> Gerrit
>>>
>>> On 05.08.2016 13:32, Martynas Jusevičius wrote:
>>>> Gerrit,
>>>>
>>>> we would prefer a format-agnostic mechanism rather than an
>>>> XML-specific one. Our data is RDF, not XML as such. RDF/XML only
>>>> serves as an on-the-fly bridge for XSLT transformations, because the
>>>> input data (such as RDF vocabularies online) can be in any RDF syntax,
>>>> e.g. Turtle which is not XML.
>>>>
>>>> On Fri, Aug 5, 2016 at 11:33 AM, Imsieke, Gerrit, le-tex
>>>> <[hidden email]> wrote:
>>>>> Hi Martynas,
>>>>>
>>>>> Maybe XML Catalogs and our XSLT-based catalog resolver are of any use to
>>>>> you?
>>>>>
>>>>> A Saxon CE demo of a previous version is here:
>>>>> https://subversion.le-tex.de/common/letex-util/xslt-based-catalog-resolver/interactive.html
>>>>>
>>>>> The most recent version is now hosted on github:
>>>>> https://github.com/transpect/xslt-util/blob/master/xslt-based-catalog-resolver/README.md
>>>>>
>>>>> Gerrit
>>>>>
>>>>>
>>>>> On 05.08.2016 10:47, Martynas Jusevičius wrote:
>>>>>> Our use case is actually more about dereferencing than resolving, as
>>>>>> the URIs being resolved are usually already absolute.
>>>>>>
>>>>>> On the server-side, we are using URIResolver to map vocabulary
>>>>>> namespace URIs to cached copies of them, to avoid HTTP latency/errors
>>>>>> and improve performance. E.g. instead of looking up
>>>>>> "http://purl.org/dc/terms/" online, we read it as Source from a local
>>>>>> file such as dcterms.rdf.
>>>>>>
>>>>>> The URIResolver:
>>>>>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/org/graphity/client/util/DataManager.java#L157
>>>>>> The namespace mapping:
>>>>>> https://github.com/AtomGraph/Web-Client/blob/master/src/main/resources/prefix-mapping.n3
>>>>>>
>>>>>> Having a similar mechanism on the client-side to intercept document()
>>>>>> calls, we could make the stylesheets much more portable.
>>>>>> If you have some API in mind, I would be happy to provide feedback.
>>>>>> Re. media type, I think the most flexible way would be to allow
>>>>>> control of the HTTP Accept header.
>>>>>>
>>>>>> It might involve caching documents using JS. Is there a way to put
>>>>>> them directly into Saxon's document cache?
>>>>>>
>>>>>> On Fri, Aug 5, 2016 at 1:25 AM, Michael Kay <[hidden email]> wrote:
>>>>>>> First let's recognise that the "URIResolver" we are familiar with in the Java world does not resolve URIs, it dereferences them (well actually, it does a bit of each and as a result it's pretty badly defined). So we need to be clear about what the requirement is here, and preferably not define it in terms of a Java feature which is badly thought out.
>>>>>>>
>>>>>>> Resolving relative URIs involves questions about base URI, and there are a lot of questions about the base URI of a compiled stylesheet that we haven't fully thought through yet. The XSLT 3.0 spec rocognizes the problem and gives us some room for manoevre, but it doesn't give us all the answers. But the traditional model where the base URI is the location of the stylesheet source code is clearly wrong: the stylesheet source code is probably on some developer's laptop.
>>>>>>>
>>>>>>> Dereferencing absolute URIs to get a resource is a different question, and in many ways more straightforward, and there's certainly scope to include a user-supplied callback here. It can probably be done in Saxon-JS today by reassigning the relevant internal Saxon functions, but we should (and probably will) do it more cleanly as a well-defined and supported API. The tricky bits of the design are (a) whether the design should be specific to particular media types, and (b) how best to handle asyncronous access.
>>>>>>>
>>>>>>> Michael Kay
>>>>>>> Saxonica
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>>>>
>>>>>
>>>>> --
>>>>> Gerrit Imsieke
>>>>> Geschäftsführer / Managing Director
>>>>> le-tex publishing services GmbH
>>>>> Weissenfelser Str. 84, 04229 Leipzig, Germany
>>>>> Phone +49 341 355356 110, Fax +49 341 355356 510
>>>>> [hidden email], http://www.le-tex.de
>>>>>
>>>>> Registergericht / Commercial Register: Amtsgericht Leipzig
>>>>> Registernummer / Registration Number: HRB 24930
>>>>>
>>>>> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
>>>>> Thomas Schmidt, Dr. Reinhard Vöckler
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>>>
>>>
>>> --
>>> Gerrit Imsieke
>>> Geschäftsführer / Managing Director
>>> le-tex publishing services GmbH
>>> Weissenfelser Str. 84, 04229 Leipzig, Germany
>>> Phone +49 341 355356 110, Fax +49 341 355356 510
>>> [hidden email], http://www.le-tex.de
>>>
>>> Registergericht / Commercial Register: Amtsgericht Leipzig
>>> Registernummer / Registration Number: HRB 24930
>>>
>>> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
>>> Thomas Schmidt, Dr. Reinhard Vöckler
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>>
>
> --
> Gerrit Imsieke
> Geschäftsführer / Managing Director
> le-tex publishing services GmbH
> Weissenfelser Str. 84, 04229 Leipzig, Germany
> Phone +49 341 355356 110, Fax +49 341 355356 510
> [hidden email], http://www.le-tex.de
>
> Registergericht / Commercial Register: Amtsgericht Leipzig
> Registernummer / Registration Number: HRB 24930
>
> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
> Thomas Schmidt, Dr. Reinhard Vöckler
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Martynas Jusevičius
In reply to this post by Michael Kay
Michael,

but the documentPool would have to be initiated per-request, right?

In that case, it is not really a viable option, because we need to
cache like 10 document nodes. They should persist between requests,
otherwise the performance would be to poor.

Have you considered Web Storage API for document caching? It provides
sessionStorage and localStorage, and looks like a possible solution in
our case.
https://www.w3.org/TR/webstorage/

On Fri, Aug 5, 2016 at 11:55 AM, Michael Kay <[hidden email]> wrote:

>
>>
>> It might involve caching documents using JS. Is there a way to put
>> them directly into Saxon's document cache?
>>
>
> Yes, as an interim solution that would work quite well. I think (without testing) you should be able to do
>
> SaxonJS.U.context.fixed.documentPool[key] = content;
>
> where key is the absolute URI and content is the XML document node; the next call on doc() should simply pick the document up from this documentPool.
>
> The ".U." signals interfaces that may change over time...
>
> Michael Kay
> Saxonica
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Martynas Jusevičius
Any thoughts about Web Storage?

On Wed, Aug 17, 2016 at 5:55 PM, Martynas Jusevičius
<[hidden email]> wrote:

> Michael,
>
> but the documentPool would have to be initiated per-request, right?
>
> In that case, it is not really a viable option, because we need to
> cache like 10 document nodes. They should persist between requests,
> otherwise the performance would be to poor.
>
> Have you considered Web Storage API for document caching? It provides
> sessionStorage and localStorage, and looks like a possible solution in
> our case.
> https://www.w3.org/TR/webstorage/
>
> On Fri, Aug 5, 2016 at 11:55 AM, Michael Kay <[hidden email]> wrote:
>>
>>>
>>> It might involve caching documents using JS. Is there a way to put
>>> them directly into Saxon's document cache?
>>>
>>
>> Yes, as an interim solution that would work quite well. I think (without testing) you should be able to do
>>
>> SaxonJS.U.context.fixed.documentPool[key] = content;
>>
>> where key is the absolute URI and content is the XML document node; the next call on doc() should simply pick the document up from this documentPool.
>>
>> The ".U." signals interfaces that may change over time...
>>
>> Michael Kay
>> Saxonica
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> saxon-help mailing list archived at http://saxon.markmail.org/
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/saxon-help

------------------------------------------------------------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Announcing Saxon-JS

Michael Kay

> On 23 Aug 2016, at 23:04, Martynas Jusevičius <[hidden email]> wrote:
>
> Any thoughts about Web Storage?

We've talked and thought about it. No decisions yet, but thanks for the feedback.

Michael Kay

>
> On Wed, Aug 17, 2016 at 5:55 PM, Martynas Jusevičius
> <[hidden email]> wrote:
>> Michael,
>>
>> but the documentPool would have to be initiated per-request, right?
>>
>> In that case, it is not really a viable option, because we need to
>> cache like 10 document nodes. They should persist between requests,
>> otherwise the performance would be to poor.
>>
>> Have you considered Web Storage API for document caching? It provides
>> sessionStorage and localStorage, and looks like a possible solution in
>> our case.
>> https://www.w3.org/TR/webstorage/
>>
>> On Fri, Aug 5, 2016 at 11:55 AM, Michael Kay <[hidden email]> wrote:
>>>
>>>>
>>>> It might involve caching documents using JS. Is there a way to put
>>>> them directly into Saxon's document cache?
>>>>
>>>
>>> Yes, as an interim solution that would work quite well. I think (without testing) you should be able to do
>>>
>>> SaxonJS.U.context.fixed.documentPool[key] = content;
>>>
>>> where key is the absolute URI and content is the XML document node; the next call on doc() should simply pick the document up from this documentPool.
>>>
>>> The ".U." signals interfaces that may change over time...
>>>
>>> Michael Kay
>>> Saxonica
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> saxon-help mailing list archived at http://saxon.markmail.org/
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
> ------------------------------------------------------------------------------
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help



------------------------------------------------------------------------------
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Loading...