The file extension for VRML files is .wrl
(for world).
The official MIME type for VRML files is defined
as:
model/vrml
where the MIME major type for 3D data descriptions
is model, and the minor type for VRML documents is vrml.
For compatibility with earlier versions of VRML,
the following MIME type shall also be supported:
x-world/x-vrml
where the MIME major type is x-world,
and the minor type for VRML documents is x-vrml.
See [MIME] for
details.
design note
MIME types do not encode file format version
information, so both the MIME type and the file extension were not
changed between VRML 1.0 and VRML 2.0. Changing the MIME type would
avoid cryptic error messages like "Not a VRML file" from
VRML 1.0 tools that do not understand VRML 2.0. However, this would
require that every Web server in the world be configured to support
the new file suffix. The most frequently encountered problem with
VRML 1.0 files is that Web servers are not configured to serve VRML
files. Therefore, changing the MIME type of the suffix would cause
more problems than it solved.
tip
Almost all VRML 1.0 files can be transparently
converted into VRML 2.0. There are VRML 1.0-to-2.0 file translators
available from both Silicon Graphics (http://vrml.sgi.com)
and Sony (http://vs.sony.co.jp/VS-E/vstop.html). Also, if
you are using VRML 1.0, it is recommended that you avoid MatrixTransform
and TransformSeparator since both of these nodes do not translate
into VRML 2.0 very well.
A URL (Uniform Resource Locator), described
in [URL], specifies a file located on a
particular server and accessed through a specified protocol (e.g., http).
The upper-case term URL refers to a Uniform Resource Locator, while
the italicized lower-case version url refers to a field which
may contain URLs, URNs, or in-line encoded data.
All url fields are of type MFString.
The strings in these fields indicate multiple locations to look for
data in decreasing order of preference. If the browser cannot locate
the data specified by the first location, it shall try the second and
subsequent locations in order. The url field entries are delimited
by double quotation marks " ". Due to the "2.5.4 Data Protocol" and the "2.5.5 Scripting Language Protocols" url
fields use a superset of the standard URL syntax (IETF RFC 1738). Details
on the string field are located in "4.9 SFString and MFString."
More general information on URLs is described
in [URL].
design note
Allowing multiple locations to be specified
wherever a VRML file refers to some other file adds some useful features:
- forward and backward compatibility between
browsers as new protocols are created and deployed across the Internet.
You can specify the new protocol as the first (most desirable) string
in the url field and specify a more standard protocol as a
backup in case the new protocol isn't understood by the browser. For
example:
url [ "new://www.vrml.org/foo.wrl"
"http://www.other.org/foo.wrl" ]
- "fault-tolerant" URLs. You can store
a file on several different servers around the Web, then have the
url field point to all of them. If one of the servers goes
down, the VRML browser will simply use one of the other servers. For
example:
url [ "http://server1.com/foo.wrl"
"http://server2.com/foo.wrl" ]
Relative URLs are handled as described in [RURL]. The base document for EXTERNPROTO statements
or Anchor, AudioClip, ImageTexture, Inline, MovieTexture, and Script
node statements is:
- The file in which the prototype is instantiated,
if the statement is part of a prototype definition.
- The file containing the script code, if the
statement is part of a string passed to the createVrmlFromURL() or
createVrmlFromString() browser calls in a Script node.
- Otherwise, the file from which the statement
is read, in which case the RURL information provides the data itself.
The IETF is in the process of standardizing
a "Data:" URL to be used for in-line inclusion of base64 encoded
data, such as JPEG images. This capability shall be supported as specified
in [DATA].
design note
The data: URL scheme is meant to be used for
small pieces of data when the overhead of establishing a network connection
is much greater than the time it takes to send the data. Some other
uses for data: URLs include
- low-resolution stand-ins. Using the multiple-strings
URL feature, specify the full-resolution URL first and give an inline
low-resolution version of the data as the second URL. Smart VRML browsers
can display the low-resolution version to the user while the full-resolution
version is being fetched across the network.
- stand-alone VRML files. Sometimes it is convenient
to bundle up a VRML world into one single file. This can be done by
recursively replacing any URLs in the main VRML file with inline data:
URLs. This is generally a bad idea if the VRML file will be delivered
by a network, since it is much better if the user doesn't have to
wait for a huge file to download before interacting with a world,
but it can be very convenient for moderate-size VRML worlds distributed
on (for example) CD-ROM.
The Script node's url field may also
support custom protocols for the various scripting languages. For example,
a script url prefixed with javascript: shall contain JavaScript
source, with line terminators allowed in the string. A script prefixed
with javabc: shall contain Java bytecodes using a base64 encoding.
The details of each language protocol are defined in the appendix for
each language. Browsers are not required to support any specific scripting
language. However, browsers shall adhere to the protocol for any scripting
language which is supported. The following example illustrates the use
of mixing custom protocols and standard protocols in a single url (order
of precedence determines priority):
#VRML V2.0 utf8
Script {
url [ "javascript: ...", # custom protocol
"http://bar.com/foo.js", # std protocol
"http://bar.com/foo.class" ] # std protocol
}
In the example above, the "..." represents
in-line JavaScript source code.
design note
These new VRML-specific "protocols"
were added to make it easier to create behaviors with a text editor
and they don't follow the strict URL syntax as specified by the IETF
(which requires certain common punctuation to be encoded, for example).
URNs are location-independent pointers to a
file or to different representations of the same content. In most ways,
URNs can be used like URLs except that, when fetched, a smart browser
should fetch them from the closest source. URN resolution over the Internet
has not yet been standardized. However, URNs may be used now as persistent
unique identifiers for referenced entities such as files, EXTERNPROTOs,
and textures. General information on URNs is available at [URN].
URNs may be assigned by anyone with a domain
name. For example, if the company Foo owns foo.com, it may allocate
URNs that begin with "urn:inet:foo.com:". An example of such
usage is "urn:inet:foo.com:texture:wood001". See the draft
specification referenced in [URN] for a
description of the legal URN syntax.
To reference a texture, EXTERNPROTO, or other
file by a URN, the URN is included in the url field of another
node. For example:
ImageTexture {
url [ "http://www.foo.com/textures/wood_floor.gif",
"urn:inet:foo.com:textures:wood001" ]
}
specifies a URL file as the first choice and
a URN as the second choice.
design note
It is hoped that eventually there will be a
standard set of VRML data files that will be widely distributed and
frequently used by world creators—a standard library of objects,
textures, sounds, and so forth. If a common set of resources are agreed
on, they could be distributed and loaded from a CD-ROM or hard disk
on a user's local machine, resulting in much faster load times. The
world creator would merely refer to things by their standard URN name.
The VRML browser will know the location of the "nearest"
copy, whether already loaded into memory, on a CD in the local CD-ROM
drive, or located somewhere on the network.
