In VOS it in fact would be easy to build a little tree of the types with 
different names to make them easier for people to work with, while 
keeping their real names hidden.

So you can make an object like "/t" and select out the specific top 
level versions used from the containers ("namespaces"?) with the big ids.


/t/vos -> /vos:0011223344556677889900aabbccddee/vos
   ...Has various children for core types...
/t/a3dl -> /vos:0011223344556677889900aabbccddef/a3dl
   ...Has various children for 3d types...
/t/mytypes -> /vos:992288337744beffc38aa3712cdd219a8e/mytypes
   ...Has various children for custom types...

/foo type="/t/mytypes/foo"
/bar type="/t/a3dl/object3d"

Maybe we even enshrine a container like /t or /_types as standard place 
to put the "working set" of types, as a convention that all user 
interfaces use, and so when they are telling a user what the type of a 
vobject is, they can just strip off the prefix, or when preseting the 
user with a list of possible types, just provide a listing (or tree 
view) of the children of /t, etc.

Or a UI can just look at the type definition to get a user friendly type 

But OK, in the general case, we need to come up with ways like this to 
help users navigate vobjects, whether in a particular application or in 
VOS stuff like this, without having to put a lot of special stuff in the 
user interface clients.


vos-d mailing list

Reply via email to