These glossary values are canonical for the Local Names Namespace Description Specification version 1.2.
A blank line is a line in a namespace description that is either empty, or consists entirely of whitespace characters.
"column" refers to a logical column in a record.
The first column is always the record type.
The meanings of the second and third depending on the record type: LN, NS, PATTERN, or X.
A column value cannot have any white space in it, unless it is surrounded by quotations marks. Within quotation marks, a quotation marks can be expressed with slash-quote (\"). you, Unfortunately, this means you have to use slash-slash (\\) to express an actual slash.
If any column has a dot in it, then that means: "Use the column value used here in the previous record."
A comment line is a line in a namespace description that is there for people to read, but has no meaning to the namespace interpreter.
Every comment line begins with hash ("#") and is ignored by the namespace interpreter.
Example:
# This line is ignored.
# So is this line
LN "some line" "This line is not a comment line, it is a record."
"extension data'""" is data that is extra information attached to a namespace. This is so you attach extra information to a namespace, that does not itself define a local name, pattern, or namespace link.
Extension data is defined by X records within a namespace description.
The data is indexed by extension key, and consists of a list of extension values. X records with the same extension key add additional items to the list of extension values.
The Local Names Namespace Description Specification version 1.2 defines several extension keys, including the required "VERSION," as well as the recommended "AUTHOR," "AUTHOR-FOAF," "LAST-CHANGED," "PREFERRED-NAME," and "FINAL."
"extension key" refers to the string identifying a part of the extension data in a namespace. The extension key is associated with a list of extension values.
For example, if you have a record:
X "foo" "bar"
...then the extension key is "foo," and we are appending "bar" to the list of extension values.
"extension values" refers to the list of strings associated with an extension key as part of the extension data found in a namespaces.
For example, if you have the following X records defining an extension key "foo":
X "foo" "bar"
X "foo" "baz"
... then the extension values are: "bar" and "baz," in that order.
"line" refers to a line in a namespace description.
Lines are one of three types:
Record lines consist of three columns, the first being the record type, the meaning of the second and third depending on the rcord type.
"link key," refers to the string identifying a namespace link, that has been bound to a URL.
For example, if you have a line:
NS "foo" "namespace_bar.txt"
...then the link key is "foo," and it is bound to the relative URL "namespace_bar.txt."
An LN record is a record found in a namespace description that binds a name to a URL or relative URL, forming a local name.
An example:
LN "foo" "bar"This creates a local name with the name "foo" bound to the relative URL "bar."
Another example:
LN "foo" "http://example.net/"This creates a local name with the name "foo" bound to the URL "http://example.net/".
A local name is a binding between a single name and a URL found within a namespace.
Local names are defined by LN records in a namespace description.
" Local Names," written with capital letters and always plural, refers to the complete Local Names system.
Local Names, written with capital first letters, like in a title, refers to the Local Names system. It's the whole collection of interfaces, specifications, servers, perhaps even all the namespaces and the Local Names project itself. The whole system, everything having to do with local names, all in one bundle.
The idea of a local name, a single binding between name and URL, is all lower case.
The Local Names project refers to the people and the effort to construct the Local Names system.
A Local Names server is a server that implements a Local Names interface.
It's a server that performs web browser redirection.
We use it to make someone's web browser go to a page named with a local name.
Basically, someone asks the server for a page "foo," the server finds out where "foo" is on the Internet, and then returns the URL.
A Local Names Web Browser Redirection Server ("Redirect Server" for short,) redirects a user's web browser in response to a name-resolution request.
A Local Names Web Browser Redirection Server is a web server that uses Location: in an HTTP response to redirect a web browser.
An XML-RPC interface that is accessed to retrieve information from a Local Names Query Server that supports the interface.
A particular LNXRQueryI is represented with a URL.
For example:
Both of these, (if they are working right now,) are LNXRQueryI.
The interface is fully specified in the Local Names XML-RPC Query Interface Specification.
The interface supports the following:
An XML-RPC interface that is accessed to store information in a Local Names Store Server that supports the interface.
(TODO)
(TODO)
"name," refers to the string identifying a local name, that has been bound to a URL.
For example, if you have a line:
LN "foo" "bar"
...then the name is "foo," and it is bound to the relative URL "bar."
"name" is used specificly to talk about a local name. Do not confuse it with a pattern key, link key, or extension key.
A "namespace link" is a link between one namespace (the "source namespace") and another namespace (the "target namespace").
Namespace links are defined by NS records within a namespace description- the namespace description for the source namespace.
Namespace links are always named, and the name is called the " link key."
Namespace links are unidirectional: If you link a namespace to another namespace, it is not necessarily the case that the target namespace will link back to the source namespace.
An NS record is a record found in a namespace description that binds a link key to a URL or relative URL, forming a namespace link.
An example:
NS "foo" "localnames.txt"This creates a namespace link with the link key "foo" bound to the namespace description found at relative URL "localnames.txt".
Another example:
NS "foo" "http://example.net/localnames.txt"This creates a namespace link with the link key "foo" bound to the namespace description found at URL "http://example.net/localnames.txt".
History lesson:
In late 1994, Lion Kimbro wrote a Local Names Query Server based on an even older version. It had two interfaces, XML-RPC and REST. It's still in use today, June 2005. That said, there were a few problems with it:
Lion decided to focus on specifications instead of implementations, which led to the creation of the Local Names interfaces, which he is much happier with.
Before the Old Style Local Names Query Server, that was an even older server, the original query server. It was horrible. The API was terribly inconsistent. And it's still in use today, because MooKitty wrote a Local Names WordPress plugin that became indispensible to Lion, and that was written to the original query server.
The Old Style Local Names Query Server doesn't exist anymore.
Use the current one, which works by the Local Names XML-RPC Query Interface.
There are presently two Local Names interfaces:
The query interface gives programs a way to ask a server to resolve names. It is comparable to a BIND server in the Domain Name System. The query interface is specified in the Local Names XML-RPC Query Interface specification.
The store interface gives programs a way to tell a server to bind a name to a URL, in some namespace. The store interface is specified in the Local Names XML-RPC Store Interface specification.
A given Local Names server can implement multiple interfaces; It doesn't have to be one or the other.
Local Names Wrap refers to specific server software. The software wraps up existing wiki, providing namespace descriptions for them.
(TODO)
A namespace is a space that contains local names.
Namespaces are defined by text files called namespaces descriptions.
A namespace can point to other namespaces with NS records in the namespace's description.
A namespace description is text file defining a namespace.
The file consists of lines. Each line is either a blank line, a comment line, or a record.
Records consist of 3 columns, the first of which tells the record type, and the meaning of the second and third columns dependent on the record type.
A "pattern" is a named substitution pattern. It emulates a namespace with infinite local names: Every name is bound to a URL calculated by substituting the name into a URL template.
Patterns are defined by PATTERN records within a namespace description.
In the order of resolution, patterns apply before namespace links. That is, a pattern can conceal a namespace link. (This is to preserve expressive power. Namespace links provide a dual purpose: They can be either explicitly traversed, or implicitly traversed. You can cover up a namespace link with a pattern, and it won't be usable by explicit traversal, but it will still be implicitly traversed. Having namespace links conceal patterns would reduce expressive power.)
Patterns are always named, and the name of a pattern is called it's " pattern key."
"pattern key" refers to the string identifying a pattern, that has been bound to a URL template.
For example, if you have a line:
PATTERN "foo" "bar/$NAME"
...then the pattern key is "foo," and it is bound to the relative URL template "bar/$NAME".
A PATTERN record is a record found in a namespace description that binds a pattern key to a URL template or relative URL template, forming a pattern.
An example:
PATTERN "foo" "bar/$NAME"This creates a pattern with the pattern key "foo" bound to the relative URL template "bar/$NAME".
Another example:
PATTERN "foo" "http://example.net/$NAME"This creates a pattern with the pattern key "foo" bound to the URL template "http://example.net/$NAME".
Read the glossary entry on pattern for information on how patterns are used.
(TODO)
A record is a line in a namespace description that tells something about the namespace that the namespace description is defining.
Every record has three columns. "extension values" refers to the list of strings associated with an extension key as part of the extension data found in a namespaces.
For example, if you have the following X records defining an extension key "foo":
X "foo" "bar"
X "foo" "baz"
... then the extension values are: "bar" and "baz," in that order.
A namespace description is made of lines, and each non-blank non-comment line defines a record. Each record has a type, called the record type.
The record type can be one of four things:
(This is new in version 1.2 of the Local Names Namespace Description Specification.)
Wherever you can put a URL, you can also put a relative URL. The URL is specified relative to the last URL path element leading to the namespace description itself.
For example, if the URL to get the namespace description were "http://example.com/localnames.txt", and the relative URL read "foo.html", then the resulting URL would be "http://example.com/foo.html".
For another example, if the URL to get the namespace description read "file:///C:Documents and Settings/foo/My Documents/localnames.txt", and the relative URL read "bar.html", then the resulting URL would be "file:///C:Documents and Settings/foo/My Documents/bar.html".
The Local Names Namespace Description Specification is mute on how an API returns relative URLs. However, the Local Names XML-RPC Query Interface specification will describe how URLs are returned when using it.
Uniform Resource Locator.
"Local Names binds names to URLs."
Technically, however, they are URIs.
The difference between a URL and an URI? A "URI," or "Uniform Resource Identifier," can be either an URL or an URN. Almost all URI's that you find in the world are URLs, but a handful are URNs, or "Uniform Resource Names." You can read more about them on Wikipedia.
Since most people are comfortable with "URLs," we just say "URL" in our documentation, rather than "URI."
But, technically speaking, you can bind any local name to any URI. That is, you can bind any local name to a URL or an URN.
Skirting the rules a little, you can bind to any arbitrary string. However, this may confuse the query server, which has no way of knowing whether it is the string, or a relative URL.
If you want to bind keys to strings in the namespace, it's probably best to use X records.
A URI template is a URI that can have a name (or several names) substituted into it, before it is evalutated.
Any occurances of "$NAME" in the URI template are replaced with a given name. For multiple pattern arguments, you can use "$ARGn", where "n" is a number, starting counting from 1.
Suppose the URI template were "http://example.com/$NAME", and the name was "foo", then the resulting URI would be "http://example.com/foo".
Web Browser Redirection is a technique used by a Redirection Server to send a user's web browser to the URL bound to a particular local name.
It works like so:
In this way, the user can jump to web pages by local name.
You can try it out, using a functioning redirect server:
Note the following parts in this use:
Here's another, that performs some hops:
The colon (:) tells it to hop through the namespace. This one starts by looking for namespace "S" (short for "services"), then for "WP" (short for "Wikipedia"), then looks up "robot" in that space.
An X record is a record found in a namespace description that appends an extension value to the list of extension values associated with an extension key.
An example:
X "foo" "bar" X "foo" "baz"These two lines add to the extension data identified by extension key "foo." After these two lines are processed, "foo" is bound to whatever it was bound to before, as well as the extension values "bar" and "baz."