Authors: Mitra, Chris Marrin, and members of the VRML-UMEL Working Group.
Note: This proposal is based on an earlier document
that describes the use of URNs in relation to VRML. Authored by Mitra, the
original URN work is referenced in the VRML specification and is available
URNs are ideal for naming elements of a library independent of their actual location. In fact, this is exactly what URNs were originally designed for, making them ideal for use with the Universal Media Element Library.
URN resolution (how a browser "resolves", or translates, a URN into a file) is the key issue addressed in this UMEL recommended practice proposal. While the Internet Engineering Task Force (IETF) has spent many years attempting to define how URNs should be resolved, an issue which remains outstanding, the lack of a standard solution for URN resolution does not preclude the use of URNs for our purposes. Since "url" fields in VRML are multi-value, unlike those in HTML (which are single-value), and will only resolve to a previously installed library, our use of URNs is not contingent on the network-wide resolution method currently being sought by the IETF.
This document specifies a resolution mechanism to be used when a browser encounters a URN in a multi-value url field.
|Is the defined prefix for all URNs.|
|Specifies that this is the VRML Consortium's namespace (i.e. a place where the VRML Consortium defines the rules on name allocation).|
|Is a string assigned by the VRML Consortium that specifies who is assigning names. In this case, it specifies that the names are being assigned by the Universal Medial Element Library working group. The the VRML Consortium could, for example, also allocate "lw" to Living Worlds defined names (for example Prototypes) or "pharmaceutical" to a working group assigning names to Pharmaceutically related media elements.|
|Is an example string assigned by the UMEL working group that is used to reference a specific media element, which is a texture in this case (note: the exact format of this string is still to be determined by that group).|
When the browser determines the location of the library, it will replace the initial sub-string of the URN with the location of the library, and find the file relative to that location. For instance, if the browser determines that the library "urn:vrml:umel:" is installed at "C:\vrml-libraries\umel\" then it will look for the file above at "C:\vrml-libraries\umel\texture\wood\oak001.gif". If it finds the library is at "http://vrml.org/libs/umel", it will then retrieve the file from "http://vrml.org/libs/umel/texture/wood/oak001.gif".
Note that on some platforms the character "/" in the URN will need to be replaced with the appropriate directory hierarchy separator character, for example "\" in DOS.
If the file is not found at the location specified, the browser will
then move to the next string in the url field. The next string in the
url field will typically be the location (URL) of the file,
although it might also be another URN.
HKEY_LOCAL_MACHINE\VRML\PROTOCOLS\urnwhere the key's name is derived from the URN, and the value gives the URL of the installed location of a specific library. This is a semi-colon separated list of alternative locations.
Continuing the example above, the key HKEY_LOCAL_MACHINE\VRML\PROTOCOLS\urn\vrml\umel would have a value "file:///C|/vrml-libraries/umel".
If the library might optionally be found on a CD, then it might also have a value of "file:C|/vrml-libraries/umel;D:"
urn:vrml:umel: file:///usr/local/lib/vrml-libraries/umelor for multiple entries, with one option available locally via HTTP:
urn:vrml:umel: file:///usr/local/lib/vrml-libraries/umel,http://myserver/vrml-libraries/umelwhere the part on the right is the initial sub-string being matched, and it is separated by white-space before the comma (and optionally white-space) separated locations of the libraries.
Continuation lines may be separated by white-space, so the above could be
urn:vrml:umel: file:///usr/local/lib/vrml-libraries/umel, http://myserver/vrml-libraries/umel
Note: The Preferences folder itself may need to be creating under
System 6.x and earlier if it doesn't already exist since these versions of the
Macintosh OS don't inherently support the notion of "Preferences" as System 7.x
and greater does.
UMEL versioning is an additive process. New and/or updated content is assigned a unique name and added alongside existing content. Existing UMEL content is never replaced with new or updated material; it is only added to over time. This approach applies to entire libraries as well as individual elements.
Specifically, UMEL versioning is handled on an element-by-element basis by the introduction of new files (images, audio clips and 3D objects) into the core set of libraries ("Textures", "Sounds" and "Objects"). Similarly UMEL accommodates versioning on a library-by-library basis by the introduction of entirely new libraries to the core system ("Textures2.0", "Sounds2.0" and "Objects2.0", for example, which will reside alongside the core libraries).
When a update to an existing library element is added to UMEL, it is given a unique file name to distinguish it from earlier versions of the element ("redbrick2.gif", for instance, would represent a new version of the "redbrick.gif" texture). Likewise, when a new version of the entire UMEL "Textures" library is introduced, it will be giving a unique name such as "Textures2.0" to distinguish it from the original "Textures" library.
This simple, elegant approach to versioning allows authors to specify precisely the media element they desire by name, without concern for changes or updates to UMEL. Since each new version of a library or element is assigned a unique name, authors can be certain that the elements they reference will never be replaced with an updated version. If they wish to take advantage of an updated library or element version, they do so by updating their VRML world's URN references accordingly.
Note: A directory named "version" (urn:vrml:umel:version) is reserved for
future use should the need to track version numbers arise (inside this directory
files related to library version numbers can be stored if needed).
World Wide Web Consortium Addressing: http://www.w3.org/Addressing/Addressing.html
"A URN Namespace for IETF Documents"
"URN Namespace Mechanisms"
"Persistent Document Identifiers"
"URI Resolution Services Necessary for URN Resolution"
"Functional Requirements for Uniform Resource Names"
Memo: RFC 1737
"Resolution of Uniform Resource Identifiers using the Domain Name