Ed, Seems like a good, standard way to avoid name collisions. I do not think 1.4 is right place, 1.4.X release should mainly be bug fixes.
At some point we had a detailed discussion about allowing more characters in the labels. The con is that it takes away from future flexibility of the language. I was advocating for supporting quoting and escaping labels instead taking away reserved chars. So support expressions like : 'vis://A/B' & 'vis://A/C' where you can put any char between the quotes as long as quotes are properly escaped. There are a few standard escaping mechanisms we could choose from. Adding quoting should be done in a backwards compatible way. Keith On Wed, Jul 11, 2012 at 3:59 PM, Ed Kohlwey <[email protected]> wrote: > It would be nice to support hierarchical visibility strings, so that an > application could use a URI to delegate control of a certain set of > visibilities to a particular organization that you'd like to have control > those visibilities. Ex: visibility://some.org/some-dept/visibility > > You COULD use the existing characters to construct a hierarchical scheme, > but it would be more terse than a restricted URI and you'd have to get > pretty creative with your encoding. > > It looks like you could add slash and period to the allowed characters > pretty easily by adding a new statement in Authorizations.class around line > 62. > > Any thoughts on pros/cons to doing so? Any interest in doing this in a 1.4 > release?
