Consider:
<xsl:result-document
href="{string-join(
($scripts-offset, $metadata-directory, $redirect-file),
'/'
)}"
format="text">
in which the net effect of the string-join is "../resources/foo.txt".
What is this supposed to be relative to? The style sheet? The input document?
EDIT
Cher answerers: after posing this question, I had a burst of energy and coffee and read the spec for xs:result-document carefully, and I also read the implementation of Saxon-B. The spec calls for the href to be relative to the 'primary output document'. Depending on how you call Saxon, it might set that up correctly from the File object you supply it as a target ... or it might require you to make an extra call to set it up. So upvotes all around, and sorry for all the trouble.
This is implementation defined.
From http://www.w3.org/TR/xslt20/#creating-result-trees
The href attribute is optional. The
default value is the zero-length
string. The effective value of the
attribute must be a URI Reference,
which may be absolute or relative.
There may be implementation-defined
restrictions on the form of absolute
URI that may be used, but the
implementation is not required to
enforce any restrictions. Any legal
relative URI must be accepted. Note
that the zero-length string is a legal
relative URI.
The base URI of the document node at
the root of the final result tree is
based on the effective value of the
href attribute. If the effective value
is a relative URI, then it is resolved
relative to the base output URI. If
the implementation provides an API to
access final result trees, then it
must allow a final result tree to be
identified by means of this base URI.
And from http://www.w3.org/TR/xslt20/#dt-base-output-uri
This document does not specify any
application programming interfaces or
other interfaces for initiating a
transformation. This section, however,
describes the information that is
supplied when a transformation is
initiated. Except where otherwise
indicated, the information is
required.
A base output URI. [Definition: The base output URI is a URI to
be used as the base URI when resolving a relative URI allocated to a final
result tree. If the transformation generates more than one final result tree, then typically each one will be allocated a URI relative to this base
URI. ] The way in which a base output URI is established is implementation-defined.
But more important, think about this note:
Note:
The base URI of the final result tree
is not necessarily the same thing as
the URI of its serialized
representation on disk, if any. For
example, a server (or browser client)
might store final result trees only in
memory, or in an internal disk cache.
As long as the processor satisfies
requests for those URIs, it is
irrelevant where they are actually
written on disk, if at all.
In Saxon and AltovaXML it's relative to path from XSLT processor were called. For example:
cd somePath
java -classpath lib\saxon9he.jar net.sf.saxon.Transform -o:output.xml xml\input.xml xsl\stylesheet.xsl
"C:\Program Files (x86)\Altova\AltovaXML2011\AltovaXML.exe" -xslt2 xsl\stylesheet.xsl -in xml\input.xml -out output.xml
In your case it would be:
somePath\..\resources\foo.txt
Related
After upgrading to eXist-db 4.7.0, we have now Jetty 404 errors for filenames with UFT-8 accented or Chinese characters.
Any idea if there is a config file to manage that?
For eg.:
HTTP ERROR 404
Problem accessing /.../dicoEnviro-fr/humanit%C3%A9.xml.
Reason: Document /.../dicoEnviro-fr/humanité.xml not found
Powered by Jetty:// 9.4.14.v20181114
Use Jetty 9.4.20.v20190813 (there are updates to UTF-8 handling of resources on java.nio.file.FileSystem present since 9.4.16.v20190411 that you need)
Since I don't know what eXist-db does to start Jetty, I'm going to assume it's embedded, and answer based on that assumption.
Make sure your ServletContextHandler or WebAppContext is declared to use a Base Resource that is defined as a PathResource object pointing to your directory location defined as a java.nio.file.Path object.
Advice about Base Resource declaration:
Do not use a String to define it, that winds up being a URLResource which works with URL references, not file system paths, and you'll have the problem you are experiencing.
Do not use a File to define it, as that winds up being a FileResource which is deprecated functionality, and known to have problems with UTF-8 references.
Ensure your java.nio.file.Path is an absolute path. (no relative paths)
Ensure your java.nio.file.Path is normalized. (no "//" or "/../" segments)
When using relative URLs and want to address a file in the same folder we have two options:
Just type a file name:
image1.png
Or this:
./image1.png
I tried these and encountered the same results.
What's the difference between these two? Although the result is the same, is one preferred to another one?
Essentially: there is none.
Both are relative to "the current context", called the base URI in the specification. (With ./ it's explicitly relative to the current context, without it, it's implicitly relative to the current context.) With links in both forms, the browser will perform relative resolution to determine the actual URL to navigate to.
Inclusion of such a prefix is essentially meaningless noise, given the implicit behaviour is explicitly documented, and the explicit form is optional. (It's not wrong, it's just not the optimal—most compact—form.)
This should be pretty simple I need know what dots mean in a url such as "../../../Program Files (x86)/Filed/examples/tmw_desert_spacing.png"
I'm assuming this is some kind of shorthand that means "the same as the current directory"/etc/folder/file.png a link to an article that explains this would be nice too, my google search turned up nothing since im not even sure this is called a url. thanks
more info: the program im writing won't except this as the file name, I need to konw what need to change to become acceptable.
According to RFC 3986:
The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy. They
are intended for use at the beginning of a relative-path reference
(Section 4.2) to indicate relative position within the hierarchical
tree of names.
The takeaway is that they have the same meaning as in paths on a linux or windows system - single dot means "the directory specified by the preceding part of the path", two dots mean "the parent directory of the directory specified by the preceding part of
Out of curiosity and the need to name a configuration setting properly: What do you call an URL that is an absolute path reference but without a domain?
http://www.domain.com/path/to/myfile is an absolute, full URL.
../to/myfile is a relative path.
What would you call /path/to/myfile?
Is there a convention? Am I just daftly overlooking the obvious? "absolute path" would work in a file system context, but in a URL context I fear confusion with the full URL.
RFC 3986 terms it as absolute-path reference:
A
relative reference that begins with a single slash character is
termed an absolute-path reference.
But you can say just absolute path or absolute URL/URI path.
It probably depends on the context, that's called path-absolute in the grammar of RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax). I think most people would call this an absolute path: that's also the terminology used by RFC 1808 (obsoleted by RFC 3986).
Speaking in terms of URI as per RFC 2396, this just is a path, among scheme (http), authority, query and fragment (none in your case).
A Virtual Path? Physical Path would be more accurate I guess.
I have a file that describes input data, which is split into several other files. In my descriptor file, I first give the path A that tells where all the other files are found.
The originator may set either a relative (to location of the descriptor file) or absolute path.
When my program is called, the user gives the name of the descriptor file. It may not be in the current working directory, so the filename B given may also contain directories.
For my program to always find the input files at the right places, I need to combine this information. If the path A given is absolute, I need to just that one. If it is relative, I need to concatenate it to the path B (i.e. directory portion of the filename).
I thought boost::filesystem::complete may do the job for me. Unfortunately, it seems it is not. I also did not understand how to test wether a path given is absolute or not.
Any ideas?
Actually I was quite misguided first but now found the solution myself. When "base" holds the path A, and filename holds B:
boost::filesystem::path basepath(base), filepath(filename);
if (!basepath.is_complete())
basepath = filepath.remove_leaf() /= basepath;
base = basepath.string();
It works with Linux at least (where it would be very easy to do without boost, but oh well..), still have to test with Windows.