Proposal: change Grob.id to Grob.output-properties

[Paul]

Hi all,  I'd like to improve on the "id" grob property but I wanted to 
ask about the best way to migrate users if/when we made the change I'm 
thinking of.

The "id" property was introduced [0] in January 2012 by commit:
  ad3a9e6531e32c4403f1bdc6d203d3c94c6d411e

  Adds an ID property to grobs.

  This property is intended to group visual elements of a grob in a given
  backend into a container that has `id' as its id.  Currently, it is only
  implemented for svg, where grobs are wrapped in a <g> tag with its `id'
  attribute set to `id.'

As far as I can tell that's still all it does.  I'd like to change its 
type from a string to an alist (well, "list?") and change its name to 
something like "output-properties".  And make it so users could do 
things like:

  \override NoteHead.output-properties =
    #'((id . 324) (class . "bar") (data-custom-prop . "foo"))

Which would produce in the SVG output:

  <g id="324" class="bar" data-custom-prop="foo"> ... </g>

(The SVG spec allows arbitrary custom properties that start with "data-".)

Looking at the code, the changes seem pretty straightforward to do.  
Assuming we agree this is a good improvement to make, the question I 
have is about migrating existing user files to the new property.  
Literal strings are easy enough to handle with convert-ly:  = "abc"  
converts to  = #'((id . "abc"))

The problem is when users have assigned a procedure (that returns a 
string) to this property, which is surely a common use case.  I don't 
see a reasonable way to handle that with convert-ly.  Maybe it is 
possible but seems like it would get ugly.

So we could make the new property's type be "string-or-list?". (We'd 
have to define that predicate.)  Then for strings, output a deprecation 
warning, but go ahead and handle the string as the user expects.  That 
would give users time to rewrite their code and then at some future 
point we change the type to just "list?" and only support alist values.

Is anyone opposed to this migration strategy?  Any better options I'm 
missing?

The motivation for the change is that lilypond-html-live-score[1] is 
overloading the id string with multiple properties and then 
post-processing that string (in the SVG output file) with python to 
expand it into different properties.  But I see no reason why LilyPond 
shouldn't be able to do this directly, saving the post-processing step.  
And it would generally increase the possible uses for SVG output.

(I considered introducing a separate property, but especially after 
looking at the code, it seems best to redefine the current one.)

(I suppose another option would be to just allow string values (which 
would be output as the id) in addition to alist values, but I'm not sure 
whether that would be best in the long run.)

Thanks,
-Paul

[0] 
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=ad3a9e6531e32c4403f1bdc6d203d3c94c6d411e
[1] https://gitlab.com/sigmate/lilypond-html-live-score