Aw: Re: Re: [EXTERNAL] Re: External Link Symbol

[Asmus Freytag]

This spells out what I tried to imply by warning against 
overinterpreting this example. However, whether something is a normative 
specification, and the limits of its normative scope is always only one 
aspect. Another aspect is whether it represents a record of somebody's 
explicit convention for what to do for a given feature, such as "anchor" 
links in the current example.

Having a written convention that documents intent is preferable over 
relying on mere observation, for example, noticing that certain 
documents or certain platforms just happen to behave in a certain way. 
But, on it's own, just because something is written down is certainly 
not enough to suggest that the convention is common, let alone universal.

 From Unicode's perspective, a convention does not have to be normative 
for general purpose documents to be taken into account in making 
informed encoding decisions. The degree to which it is followed in 
practice (both in its original domain as well as in analogous cases) is 
usually more important.

If I were a submitter, I would treat something like the citation of 
RFC7992 then not as something that "settles" an encoding question, but 
one that calls for further research to see whether that particular 
convention is found in (enough) other places to help reach a decision. 
Alternatively, it might serve as a data point for the conclusion that 
there's no single convention (with further research needed to find out 
whether this represents a case of a small number of alternate coexisting 
conventions, or the case of something where the real world hasn't 
settled on anything).

A./

On 4/17/2024 5:32 PM, Peter Constable wrote:
>
> Let’s be clear: all that RFC 7992 is doing is documenting the 
> conventions used in the non-canonical HTML versions of IETF RFCs. 
> Unless in some other context there is a specification that normatively 
> references RFC 7992, it has no real import beyond the HTML versions of 
> IETF RFCs.
>
> Peter
>
> *From:*Unicode <unicode-bounces at corp.unicode.org> *On Behalf Of *Asmus 
> Freytag via Unicode
> *Sent:* Monday, April 15, 2024 7:35 AM
> *To:* Marius Spix <marius.spix at web.de>
> *Cc:* unicode at corp.unicode.org
> *Subject:* Re: Aw: Re: Re: [EXTERNAL] Re: External Link Symbol
>
> On 4/15/2024 6:55 AM, Marius Spix wrote:
>
>     The pilcrow sign is offically mentioned in RFC 7992. See section
>     5.2. So I would consider it the conventional representation for
>     anchor links.
>
> I would agree that it is "a convention" for representation of anchor 
> links. It happens to work for English, as the pilcrow sign 
> conventionally means "paragraph" and the intent in RFC7992 is to 
> provide links to all paragraphs.
>
> However, the formatting of RFCs provided as HTML is a different beast 
> from generic prescription for formatting all HTML documents. So this 
> should not be over interpreted.
>
> A./
>
>     *Gesendet:* Freitag, 12. April 2024 um 18:46 Uhr
>     *Von:* "Asmus Freytag via Unicode" <unicode at corp.unicode.org>
>     <mailto:unicode at corp.unicode.org>
>     *An:* unicode at corp.unicode.org
>     *Betreff:* Re: Aw: Re: [EXTERNAL] Re: External Link Symbol
>
>     The first and last choice are arguably not the most conventional
>     representations for these. They are, at best, fallbacks.
>
>     A./
>
>     On 4/12/2024 12:31 AM, Marius Spix via Unicode wrote:
>
>         For all these types of links existing characters can be used:
>
>         anchor links: U+00B6 ¶ PILCROW SIGN
>
>         local links: U+1F517 🔗LINK SYMBOL
>
>         broken links (also known as red-links): U+26D3 U+200D U+1F4A5
>         CHAINS + ‍ZERO WIDTH JOINER + COLLISION SYMBOL
>
>         external links: U+2192 →RIGHTWARDS ARROW
>
>         *Gesendet:* Donnerstag, 11. April 2024 um 21:05 Uhr
>         *Von:* "Asmus Freytag via Unicode" <unicode at corp.unicode.org>
>         <mailto:unicode at corp.unicode.org>
>         *An:* "Tom Moore" <tom.moore at microsoft.com>
>         <mailto:tom.moore at microsoft.com>, "Sławomir Osipiuk"
>         <sosipiuk at gmail.com> <mailto:sosipiuk at gmail.com>, "Asmus
>         Freytag via Unicode" <unicode at corp.unicode.org>
>         <mailto:unicode at corp.unicode.org>
>         *Betreff:* Re: [EXTERNAL] Re: External Link Symbol
>
>         On 4/11/2024 11:47 AM, Tom Moore wrote:
>         > Then multiply that by 2, for links that navigate current tab
>         vs. request to open a new tab.
>
>         Is there a link to samples for all of these as used in
>         practice, or is
>         this just a theoretical distinction?
>
>         A./
>
>         >
>         > -----Original Message-----
>         > From: Unicode <unicode-bounces at corp.unicode.org>
>         <mailto:unicode-bounces at corp.unicode.org> On Behalf Of
>         Slawomir Osipiuk via Unicode
>         > Sent: Thursday, April 11, 2024 9:28 AM
>         > To: asmusf <asmusf at ix.netcom.com>
>         <mailto:asmusf at ix.netcom.com>; Asmus Freytag via Unicode
>         <unicode at corp.unicode.org> <mailto:unicode at corp.unicode.org>
>         > Subject: [EXTERNAL] Re: External Link Symbol
>         >
>         > There are actually three kinds of links that are
>         distinguishable from each
>         > other:
>         >
>         > - A link to a different location in the current document
>         (anchor link/jump
>         > link)
>         > - A link to a resource on the same network/domain as the
>         current document (local link/relative link)
>         > - A link to a resource on a different network (external link)
>         >
>         > All those can appear as symbols, used contrastively, within
>         a run of text.
>         > I'm very surprised these haven't already been encoded and
>         that there is any controversy. The consortium doesn't care
>         much for precendent, but come on, we have "play"and "eject"
>         symbols encoded!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20240417/1021d58b/attachment.htm>