Mark writes (at the end of his keynote thingy):
>To construct a dictionary, we must be able to have a universal
>name space for objects, both within an instance of a VRML
>browser, but also, within the Web itself. It should not be necessary
>to give the canonical telephone as a WWWInline with some
>complex URL; rather, we should be able to say WWWInline
>"telephone", and let the rest take care of itself. (This assumes that
>the canonical telephone is being used.) There are proposals on the
>table for a universal naming mechanism (the Universal Resource
>Name) which spans the entire Web. Such a mechanism is an
>essential part of this extension to VRML. If a likely URN
>candidate does not exist by Midsummer, VRML designers will
>either have to halt further development on scalable worlds, or will
>have to use some other solution, such as ASN-1, to provide a
>universal name space.
Opinion: I'm not at all sure that, even when it's finished, URN's are
going to be the *right* mechanism for this.
To some degree, this may come down to a religious question: should
pages always be 100% unambiguous? That is, should it be the case that
two browsers will always wind up with exactly the same object set,
given the same page? Or should we have a concept of "generic" objects?
Mark gives the example of the "telephone", and assumes that we are
talking about a standard, canonical telephone. I don't necessarily buy
that assumption. I still say that there may be significant bandwidth
advantages to allowing pages to simply build in "generic" objects,
provided only if necessary. So, if a page specified just "telephone",
and didn't specify anything more detailed than that, and your local
site had a "telephone" object, your browser would just put that in,
figuring that it was close enough. If you did *not* have a "telephone"
locally, you could fetch it from the page's site.
(My full proposal, which I made here some months back, is rather more
detailed, and essentially allows WWWInline to define "keywords" which
would be matched with the objects on-hand; the browser would decide
based on that information whether the available objects were close
enough to the desired object. It's out there in the archives somewhere;
I can dig it out if there's significant interest. Suffice it to say, it's
sort of like Level-of-Detail, but on a much more conceptual level.)
Anyway, this is relevant because it's looking to me like URN's are
going to wind up slanted strongly towards the unambiguous. That's not
completely clear yet (the debates continue), but the general thinking
*seems* to be that a URN should identify a more-or-less distinct object.
Perhaps more importantly, all the URN schemes I've seen so far are
intrinsically lookup schemes. The URN isn't a simple word like
"telephone"; it's generally a path to a naming authority, which then
provides you with a URL for the object in question. Doing local
lookups (ie, given a URN, trying to find the named object on a local
CD-ROM, without spending time on the naming authority) may well go
against the spirit of URN's, I think. And it's looking quite clear to
me that URN's aren't going to be a lot clearer than URL's are -- I'm
really, really dubious that "telephone" is ever going to be a legal
URN. Even if the URN standard hardens, and even if we decide that we
need unambiguity, URN's still may not be great for our needs.
URC's (Uniform Resource Characteristics) *might* actually have some
promise for our purposes, but the discussion to date seems to have
mostly focussed on very different needs from ours. We'd need to do
some hard examination to decide if they will help.
(Something to consider, for those who have their heads into the URI
stuff: are our assumptions different from those that have come
before? The HTML side of the Web, which formed most of the assumptions
underlying URI's to date, has a subtle assumption that "standard"
objects are rare. Most URL's have completely different "code" from
each other, with little overlap. That indicates that the standards
should assume that we always need to fetch things, since there is
little common subsetting. But we are constructing an application
where we expect *massive* subsetting, where most worlds will probably
be largely constucted from similar objects, even the same objects.
Does this imply different appropriate mechanisms? It might...)
Anyway, we need to do some concrete thinking about these issues soon,
and start talking about them. We may well want to get some cross-
pollination between this list and the URI one, to try and make sure
that the URI standards are adequate for our needs...
-- Justin
Who has been lurking on the URI mailing list
for a couple of months now, trying to
grok how it's going to apply to our
needs...
Random Quote du Jour:
"On weekends, to let off steam, I participate in full-contact origami."
-- Hugh Gallagher