The advantage is efficiency in the notations, the ability of
the domain experts (sound specialists) to evolve a notation
that is not compromised by concepts not applicable (light and
sound similar? Not at all.), and the ability to create
levels of detail based on relationships whose filtering does
not require parsing ALL of the notations to find out WHAT
gets filtered.
You will need a stronger location and addressing model
than either VRML or HTML provides. This is ( as I posted
before) because the notations must interoperate, that is,
communication across your "views". Sound needs geometry,
textual and directional information that VRML knows about,
but sound cares about such things as ADSR data
(attack, decay, sustain, release) and the routing
of the original signal through filters which can be
better modeled if they do not use the VRML notation.
A location model based on network domain addreses
(i.e., paths) is not adequate.
I suppose if you look around, you will find that a
vendor has already invented a notation for this.
You could do as you have done before and simply
adopt one. This approach is working well for VRML/SGI,
for Adobe/PDF, etc. It does mean that
that *Cyberspace* will inevitably become a FraggerSpace
in which multiple non-interoperable apps compete for
market share... Just like the rest of the markets.
Len Bullard
"I tip my hat to the new Constitution.
Take a bow for the New Revolution..
Smile and Grin at the Change_all_around
Pick Up My Guitar and Play.
Just Like Yesterday.
Then I get on my knees and pray...
We' Don't Get Fooled Again!!!"
"Won't Get Fooled Again" - Peter Townshend