[Doc-SIG] Alternative inline markup

Moore, Paul Paul.Moore@atosorigin.com
Thu, 8 Nov 2001 09:55:13 -0000

From: Alan Jaffray [mailto:jaffray@pobox.com]
> Ack, no!  I'm saying that in the existing construct ::
>     `content content content`__
> curly braces in the content would have to be escaped.  So if 
> the content was ``{'a':1, 'b':2}`` you'd have to write
> ``\{'a':1, 'b':2\}`` instead.

Question: precisely what markup are you referring to here? See the spec, but
we have::

    `xxxxx`_   -  named hyperlink reference (type 2)
    `xxxxx`__  -  anonymous hyperlink reference (type 2)
    _`xxxx`    -  inline hyperlink targets
    `/xxx/`    -  substitution reference
    `xxxxx`    -  interpreted text

(assuming we limit ourselves to markup which limits itself to using single
"`" characters). As you can see, there's a wealth of different possibilities

I'll assume you *really* mean that in **hyperlink references** (a specific
type of markup, as defined in the spec) that curly braces have special

That's fine - I'm not keen, as I see no value in this, but if that *is* what
you mean, you should say so. And you'll also have to *define* that meaning.
That's the hard bit.

You seem to be saying that, within a hyperlink reference, constructs with
start-string="{" and end-string="}_" should *also* be named hyperlink
references, and that constructs with start-string="{" and end-string="}__"
should be anonymous hyperlink references. Yes? No? But how can you word the
rationale for this ("because the normal \` character doesn't nest") in such
a way that it sounds reasonable in the context of the spec?

Once you put it in pseudo-legalese like this, the contradiction becomes
clear. You are proposing a second syntax for hyperlink references, which is
*only* valid within current-syntax hyperlink references, in order to get
over the fact that the existing syntax doesn't nest.

This is bogus. Either we should fix the nesting issue at the "top level", or
we should not make special-case changes.

The general feeling seems to be that nesting is *not* worth adding. It's
interesting to note that in HTML, <a> elements *don't* nest - so prior art
here says that nesting isn't useful for links.

Apologies if I've misinterpreted what you propose - hopefully, the
misinterpretation is valuable in pointing out where you are still not
getting your point across :-)