-Re: Hierarchical Visibility Strings
Ed Kohlwey 2012-07-12, 10:35
Adding quotes would be a little heavyweight for my purposes, but that
sounds like a good idea.
I don't think that letting in . and / characters would have a significant
negative effect on the grammar flexibility, especially since the resulting
expressiveness would be less than URI's, which have pretty reduced
expressivity themselves, but other people might have some use cases in mind
where this could be a problem.
On a separate but related note, the docs seem to say : isn't valid (see
but the code does (see
on line 62
On Wed, Jul 11, 2012 at 4:56 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
> 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.
> 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
> > 62.
> > Any thoughts on pros/cons to doing so? Any interest in doing this in a
> > release?