<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/14/2015 08:55 AM, Gabriel Riba
wrote:<br>
</div>
<blockquote cite="mid:me1b47$ds3$1@ger.gmane.org" type="cite">El
13/03/15 a les 18:07, Adam Chlipala ha escrit:
<br>
<blockquote type="cite">
<blockquote type="cite">Specially the type constructor "tag" it
is confound with the value
<br>
"tag" (that builds up xml subtrees with specific tag) but the
<br>
different parameters they take augments the confusion.
<br>
</blockquote>
<br>
The idea of separate namespaces for types and values is pretty
common;
<br>
Ur/Web inherits it from SML. You see the same thing with, e.g.,
class
<br>
constructors in C++. I don't think it's inherently confusing,
and
<br>
usually it even improves understanding, by avoiding the need to
add some
<br>
extra nonsense prefix or suffix to an identifier for
disambiguation.
<br>
<br>
</blockquote>
<br>
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.
<br>
<br>
Namespaces are not mentioned in the manual.<br>
</blockquote>
<br>
Scope resolution rules <i>may</i> 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 <i>real</i> 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. >:)<br>
<br>
<blockquote cite="mid:me1b47$ds3$1@ger.gmane.org" type="cite">
<blockquote type="cite">
One easy-to-implement workaround is to use a /separate tag/ for
nested
<br>
SVG, with a different name. Then modify src/monoize.sml to add
a
<br>
special case renaming that tag to <svg> in compiled code,
for instance
<br>
by copying the code in the place that maps "tabl" to "table"
right now.
<br>
<br>
</blockquote>
<br>
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.
<br>
<br>
I propose <SVGML> for the main SVG container (since SVGIMG
or SVGOBJ may suggest other tags attributes)
<br>
</blockquote>
<br>
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.<br>
</body>
</html>