Follow-up Comment #3, bug #68668 (group groff): The original submission makes sense to me. "Embedding hyperlinks in documents intended to be typeset or electronically formatted" is a reasonable semantic purpose. The basic design of the man(7) .UR/.UE macro also makes sense. I did not review the details of the macro design at this point, but even if there should be minor design defects (i'm neither saying there are nor there aren't), uniformity of design across macro languages is also of value because it helps users more easily learn different macro languages, so it may or may not make sense to copy specific minor design defects from one language to another.
However, i object to almost all the rest of comments #1 and #2.
The concept of a URI as defined in RFC 3986 ("A Uniform Resource Identifier is
a compact sequence of characters that identifies an abstract or physical
resource.") is so broad that it is essentially unusable in the present
context. That concept is obviously not useful for semantic purposes because
it lumps together vastly different classes of things and concepts under a
single term. It might arguably be useful for purely technical purposes (as
opposed to semantic purposes), most notably to establish common parsing rules
for a wide range of very different classes of things and concept - except that
RFC 3986 is an abject failure even in that purely technical respect because it
delegates parsing rules to scheme-specific sub-standards. So, in a nutshell,
RFC 3986 neither has a clear purpose nor does it establish a formal handling
of that essentially undefined purpose.
The concept of a URL as defined in https://url.spec.whatwg.org/ suffers from
essentially the same ailments, in some ways in an even worse manner. While
RFC 3986 at least tries - but essentially fails - to define its purpose (see
above), the URL living standard does not even _attempt_ to specify what the
purpose of a URL is, see the introductory paragraph "Goals" which is
exclusively concerned with parsing technicalities, not saying anything about
semantics. Traditionally, the term "URL" was thought to be narrower than,
designating a subset of, the term "URI"; the living standard appears to intend
to reverse that relationship: while RFC 3986 at least gives a definition at
all - even though an absurdly broad one - the living standard places no
limitation whatsoever on what a URL might be, arguably making it even broader,
but certainly making it somewhere between ill-defined and undefined. Note
that the living standard is intended to supplant the existing RFCs as a whole,
and for that purpose, it would have to define the terms and purposes now
defined in the RFCs, but it doesn't.
I regard the approach "groff should handle URIs and URLs in a uniform way" and
then rushing to implementation proposals without even considering questions of
language design as utterly misguided and short-sighted. Which kinds of
resources need to be semantically represented in which macro languages? Is
the set of useful resource classes the same for all macro languages, or are
there any language-dependent distinctions? Which kinds of resources can
usefully be represented in different output modes? Are there any
language-specific considerations in the latter respect?
Given the failure of RFC 3986 to usefully delimit its own scope, i see a need
to define the semantic scope of what the to-be-designed trans-language groff
macros - possibly including .UR - are supposed to cover. The word "hyperlink"
in the title of this ticket might be a (half-conscious?) attempt at doing
that. However, the term "hyperlink" seems to need clarification in the
present context. Which kinds of hyperlinks are useful for typesetting and
electronic text formatting, and why? For example, we might adopt a naïve
definition of the term, for example similar to what Wikipedia currently says:
"In computing, a hyperlink, or simply a link, is a digital reference providing
direct access to data by a user's clicking or tapping." That would seem like
a useful choice to me, but in that case, mailto: URIs fall outside the scope
by a wide margin. We might also adopt a more formal definition, for example
from RFC 8288 ("This specification defines a model for the relationships
between resources on the Web ('links')"), again putting mailto: URIs firmly
out of scope - besides, i deem RFC 8288 too formal and complicated for our
purposes. So, what are we actually talking about, and what should we be
talking about?
Let me try to approach the topic from the opposite side, from specifics rather
than from generalities. Whatever we do, it seems clear to me URIs in the
http:// and https:// schemes need to be covered (at least simple ones - some
http[s]:// URIs can be so complicated that their usefulness in typesetting
becomes dubious at best). It is also clear that some macro languages can
usefully provide markup for email adresses. The man(7) and mdoc(7) languages
are example of languages already providing such semantic markup. However, i
will argue that using URIs syntax for email adresses does not make sense, in
particular not in a typesetting and text formatting context, and in particular
not in the way it is officially defined by RFC 6068 which is complicated to
the point of absurdity and feels like it is designed almost exclusively with
the intent of facilitating social engineering and phishing attacks. On to of
that, the dominant practical use case of mailto: URIs, unless i'mmissing
something, is embedding email addresses in web pages typically served via
HTTP[s], with the intent that users can click on such mailto: URIs in order to
send email. I very strongly disagree with that use case for multiple reasons.
Just as one example, while it is technically possible to instruct web
browsers to invoke (some) external email programs, the practice encourages
users to send and receive email in a web browser, which is utter madness and
about the worst security nightmare imaginable.
So there are very good reasons of both semantic and technical nature to *not*
handle email addresses with the same machinery as web hyperlinks:
semantically, they are not hyperlinks because they cannot be used to retrieve
data, and technically, they are best handled with entirely different programs
and protocols. I see no reasonable motivation whatsoever to handle web
hyperlinks and email addresses in any similar way. That some people defined
excessively generic terms so broad that they can subsume everything and the
kitchen sink is not a reasonable motivation to wish for a uniform handling of
apples and oranges.
Branden's complication of proposing a proposing an additional
"suppress-scheme" flag is purely due to starting from an excessively
complicated framework that isn't adapted to the specific tasks at hand and
then piling afterthoughts on top trying to resolve the artificial
complications caused by the wrong approach to the task.
So, let's step from the unhelpful concept of URIs or URLs and instead ask:
What exactly is the task we are tying to solve here? Web hyperlinks? Email
addresses? Anything else - if so, what specifically?
If it turns out there is a list of five things we want to do, then *maybe*
they can usefully be unified to some degree, or maybe not, depending on the
details.
I'm pretty sure that arguing about URIs or URLs in the abstract can only cause
confusion and complication and won't help at all.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68668>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
