Double plus good. Two more things that should be worked in somehow:
1) the ability to express preferences as relative values, like "q"
values on Accept: headers in HTTP. That way, a client can express how badly
they want to see the canonical, exact, but slow, representation of a scene,
and an author can express how closely a particular object matches their ideal
rendering of this world. In a way it becomes a "cyberspace volume control" -
i.e., if my "volume control knob" is set to 1.0, then the client knows to
always get the highest representation. However if I set it to .2, I'm
telling my browser I'm happy with the lowest-common-denominator settings,
fetching the most commen articles. The lowest q value would be always cast
to 0, and the "name" element would always be presumed to be 1.0.
Example:
WWWInline {
name "http://obscure.com/realcoolteapot.wrl"
default "http://vrml.org/generic/fancyteapot.wrl" q=0.7
default "http://vrml.org/generic/teapot.wrl" q=0.2
}
means if I have my "volume control" set to 0.3, then
http://vrml.org/generic/teapot.wrl is fetched (presumed to be common,
fast, etc), but if I set it to 1.0, then I get
http://obscure.com/realcoolteapot.wrl". If I set it to 0.1, I still get
http://vrml.org/generic/teapot.wrl since that's the lowest. This might
get around the requirement that these fields be ordered.
2) The author needs some way to contort the various common objects
into their system separately. http://vrml.org/generic/teapot.wrl and
http://vrml.org/generic/fancyteapot.wrl are going to be colored
differently, have different sizes and orientations, etc. However, it
might just be sufficient to express color and size preferences on the
whole WWWInline node.... thoughts?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
[email protected] [email protected] http://www.[hyperreal,organic].com/