[Ur] UrWeb SVG inclusion trial, needs revision

[Adam Chlipala]

On 03/14/2015 08:55 AM, Gabriel Riba wrote:
> El 13/03/15 a les 18:07, Adam Chlipala ha escrit:
>>> Specially the type constructor "tag" it is confound with the value
>>> "tag" (that builds up xml subtrees with specific tag) but the
>>> different parameters they take augments the confusion.
>>
>> The idea of separate namespaces for types and values is pretty common;
>> Ur/Web inherits it from SML.  You see the same thing with, e.g., class
>> constructors in C++.  I don't think it's inherently confusing, and
>> usually it even improves understanding, by avoiding the need to add some
>> extra nonsense prefix or suffix to an identifier for disambiguation.
>>
>
> I expressed my self wrongly. I just wanted to say that when things are 
> complex to understand, the eyes go from one definition to the other 
> incrementing mind boggling.
>
> Namespaces are not mentioned in the manual.

Scope resolution rules /may/ reasonably be considered to be implicit in 
the typing rules from the manual, but I recognize that most Ur/Web users 
won't be familiar with the notation used there. The /real/ reason I 
don't feel bad about not giving more explicit explanation in 
documentation is that various places warn that it would be good to know 
ML (OCaml, etc.) before starting with Ur/Web. >:)

>> One easy-to-implement workaround is to use a /separate tag/ for nested
>> SVG, with a different name.  Then modify src/monoize.sml to add a
>> special case renaming that tag to <svg> in compiled code, for instance
>> by copying the code in the place that maps "tabl" to "table" right now.
>>
>
> If we change the main container tag (which appears only once) instead 
> of the maybe many nested svg fragment tags, we will preserve fidelity 
> to the specification for the majority of the code.
>
> I propose <SVGML> for the main SVG container (since SVGIMG or SVGOBJ 
> may suggest other tags attributes)

Since there is no legacy code base to be broken by any reasonable 
proposal for SVG, I'd be happy to accept a patch going whichever way 
sounds best to you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150315/9641c233/attachment.html>