> Al suggests the WWWlogical node, and a concept of "hints" combined with
> comparatively vague object definitions, sort of as a corresponding
> concept to the way HTML does business.
>
> It's not a bad idea, although I think that turning it into reality may
> prove tricky -- you may well find that the growth of kinds of "hints"
> quickly turns explosive when you try to apply it generally. (I'm not
> sure of this; it's just a hunch.) I think I'd need to see some more
> truly concrete examples...
It IS a bad idea, because it mixes levels of abstraction. VRML 1.0 is
very concrete (like, say, PDF). Mixing logical things into the same
format would make it one of those weird hybrids like RTF. People would
tend not to see the difference between concrete and logical object
specification unless something like the one WWWlogical node was done--
but in that case, it would be a better idea to say one is explicitly
embedding another specification language, which if you analyze the
WWWLogical node is what's really happening (and hence the likely
proliferation of hint types).
> For a possible alternative, consider one thought that I've been
> playing with for some time (I proposed it here a long time ago) --
> keyword-selected objects. In this scheme, you can provide keywords as
> an alternative to the URL for an object; if the local system has an
> object that fits those keywords, then it just uses that instead of
> loading the URL across the Net. As a possible refinement, you can
> define "mandatory" keywords (which a prospective object must match)
> and "optional" keywords (which may be matched or not, at the discretion
> of the browser).
I think this would probably be a job for a type of URN; then all the web
formats could use it, not just VRML.
> I still think it's an interesting idea, and may well push for it again
> one of these days. In the first go-round, several people opined that
> the URL working groups should be dealing with these local-cache issues;
> I'm not sure I really believe that they'll get a good solution, but I'm
> willing to give it some time. Besides, this is *definitely* a second (or
> third) cut issue...
It's not really entirely a 'local-cache' issue--this can already be
solved by browser writers. It's more an issue of 'how close does it
need to be to be the same thing'--and there are very good reasons to have
this specified in the URI rather than as fluff around it, such as
portability and keeping browsers and the formats that use URIs simpler.
-- James Deikun (University of Pittsburgh) #include <std_disclaimer.h> deconstruct (vt)- to disassemble into small pieces and reassemble incorrectly