AW: [xsl] Function to resolve URNs?

Subject: AW: [xsl] Function to resolve URNs?
From: "Dr. Patrik Stellmann patrik.stellmann@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 13 Jun 2017 11:48:10 -0000
Thanks, for the explanation, Michael.
So I will stick to my base-uri(doc(b&)) for now. And if it should turn out to
be necessary I will call a static Java method to use the URI resolver from the
Saxon configuration.

Regards,
Patrik



------------------------------------------------------------------
Systemarchitektur & IT-Projekte
Tel: +49 40 33449-1142
Fax: +49 40 33449-1400
E-Mail: Patrik.Stellmann@xxxxxxxxx<mailto:Patrik.Stellmann@xxxxxxxxx>


Von: Michael Kay mike@xxxxxxxxxxxx
[mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx]
Gesendet: Dienstag, 13. Juni 2017 11:11
An: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Betreff: Re: [xsl] Function to resolve URNs?

Unfortunately terminology in this area is very confused and it's best to try
and distinguish:

- expanding a relative reference - this means taking what is popularly called
a relative URI and turning it into an absolute URI, for example index.html
becomes http://www.ibm.com/index.html. This is what the XPath resolve-uri()
function does

- dereferencing a URI - this means taking an absolute URI and fetching the
resource identified by this URI. This may involve

- redirecting a URI - this means taking a URI that doesn't directly identify a
location (for example, a URN) and mapping it to a URI that does identify a
location.

All of these operations, confusingly, are sometimes called "resolving".

If you're starting with a URN, then the first stage (resolving) is irrelevant,
but the "redirecting" stage becomes essential. To redirect a URN to a
dereferenceable URI, you need some kind of catalog that defines the mapping.
This will usually be an "OASIS catalog".

In the Java world, the mechanisms vary a bit depending which API you are
using. For parsers you use an EntityResolver, for transformations you use a
URIResolver, for schemas you might use an LSResourceResolver. There are
various implementations of these interfaces that make use of the data in an
OASIS catalog. This is all generally done outside the XSLT/XQuery code itself,
in the supporting Java (etc) framework.

Michael Kay
Saxonica


On 13 Jun 2017, at 09:02, Dr. Patrik Stellmann
patrik.stellmann@xxxxxxxxx<mailto:patrik.stellmann@xxxxxxxxx>
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx<mailto:xsl-list-service@xxxxxxxxxxxx
rytech.com>> wrote:

Hi,

I have files that reference other files and I need to get the URLs of the
files being referenced (e.g. an xsd file including or importing other xsd
files).

I tried to use resolve-uri(@schemaLocation) which works fine for relative URLs
but this does not resolve URNs (which are used in most of my use-cases).

Using base-uri(doc(resolve-uri(@schemaLocation))) works fine (and Ibm
processing the referenced files recursively anyway, so itbs OK for me).

But still Ibm wondering if there isnbt a direct way to resolve the URNs
without having to read the whole file (and also without Saxon-specific
extensions like calling java methods)!?

Thanks and regards,
Patrik
GDV Dienstleistungs-GmbH
GlockengieCerwall 1
D-20095 Hamburg
www.gdv-dl.de

Sitz und Registergericht: Hamburg
HRB 145291
USt.-IdNr : DE 205183123

GeschC$ftsfC<hrer:
Dr. Jens Bartenwerfer
Michael Bathke
Fred di Giuseppe Chiachiarella
Thomas Fischer

Aufsichtsratsvorsitzender: Werner Schmidt

------------------------------------------------------------------
Diese E-Mail und alle AnhC$nge enthalten vertrauliche und/oder rechtlich
geschC<tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtC<mlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die
unbefugte Weitergabe der E-Mail ist nicht gestattet.

This e-mail and any attached files may contain confidential and/or privileged
information. If you are not the intended recipient (or have received this
e-mail in error) please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

Current Thread