Okay, now I get it; I had misread your message the first time through.
Re-reading it, I believe I get your gist.
It's a *very* cool idea in concept, and I rather like it -- I agree with
the comments that this is quite analagous to the HTML logical operators
(actually, a rather closer analogy than my idea). And it's almost
certainly complementary to my idea; the two seem likely to work quite
well together.
A possible refinement -- I think you've really got two different kinds
of entities here, which you're using the same node type for. I'm not
sure that that's ideal, either from the viewpoint of the Browser or
for human comprehension. On the one hand, you've got the "container"
objects, the groups that you give hints for like "standard-type wall".
On the other hand, you've got "contained" objects, which can be
essentially any object, and for which you've got hints like "place
upper-right".
Of course, an object can be both a container and contained. But it
isn't clear to me that using a single node type for both is ideal;
it might be clearer to separate these, since I *suspect* that in
most cases you're going to have a simple one-level container-contained
relationship. (And for most contained objects, there's no particular
reason for the hints node to be an SoGroup.) I'd bet that the extra
clarity would be worth the occasional need to put a "container" node
inside a "contained" node.
Actually, if we implemented both this and my scheme simultaneously,
the two might synergize well. One thing that my keyword-based lookup
scheme requires is a way to associate a keyword with any arbitrary
node. We might find it convenient to merge my "keywords" with your
"hints", into a single mechanism; it bears some thought.
I still worry about a possible explosion of hint types. However, that
might be approachable as a sort of evolving standard -- we could
start out by defining a small set of containers and ways that things
could be put into them, then let that gradually expand. The biggest
trick would be defining everything in such a way that it's downward-
compatible -- so that, if a browser hit a kind of container or
contained hint that it didn't understand, it had some sensible and
reasonably consistent way of dealing with that. This isn't a trivial
problem, but is probably tractable.
All in all -- an intriguing notion, worth hashing out in more detail
for the second or third round of enhancements, I suspect...
-- Justin
Random Quote du Jour:
"Staying with you requires a degree of stupidity of which I no longer
feel capable."
"Now you're just being modest."
-- Avon & Blake