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.
Related
when using content-security-policy-report-only report-uri, is it possible to have a fully-qualified absolute URL for the 'report-uri' value? All examples I see are relative values that go back to the application itself.
Yes, you can place a full URL in the report-uri directive.
I run an external reporting service at https://report-uri.com for doing exactly this!
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.)
Why does file: protocol has 3 (back)slashes in this URL?
file:///C:/Users
(C:/Users is the path name of this URL.)
How does an URL parser handle it?
I thought the last slash of these 3 slashes could mean 'path', I put a host name before declaring it, like
file://domainname.extension/C:/Users
but JavaScript's URL parser ignores this domain name.
To make things easier to understand, here file:// is the protocol and / is the root directory.
And later occurring terms are subdirectory, as in http://google.com: here http:// is the protocol and google.com is the root directory.
This is a URI scheme, typically used to retrieve files from within one's own computer.
For more details, see https://en.wikipedia.org/wiki/File_URI_scheme
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
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