Hi,
DJ Chase wrote on Sat, Aug 13, 2022 at 05:27:34PM +0000:
> Have we ever considered a de jure *roff standard?
No, i think that would be pure madness given the amount of working
time available in any of the roff projects.
I expect the amount of effort required to be significantly larger
than the amount of effort that would be required for rewriting
the entire groff documentation from scratch because:
1. You would have to study all features of all the major roff
implementations (groff, Heirloom, neatroff, Plan 9, and possibly
some others, maybe even historical ones) and compare the features.
For every difference (i.e. typically multiple times for almost every
feature), you would have to descide which behaviour to standardize
and what to leave unspecified.
2. Discussions of the kind mentioned in item 1 are typically
lengthy and often heated. If you don't believe me, just buy
several pounds of popcorn and watch the Austin list, where
maintenance of the POSIX standard is being discussed.
Even discussions of the most minute details tend to be
complicated and extended.
3. Even after deciding what you want to specify, looking at the
manuals typically provides very little help because a
standard document requires a completely different style.
User and even reference documentation is optimized for clarity,
comprehensibility, and usefulness in practice; a standard document
needs to be optimized for formal precision, whereas
comprehensibility and conciseness matters much less.
4. Even when you have the text - almost certainly after many years
of work by many people - be prepared for huge amounts of red
tape, like dealing with elected decision-making bodies of
professional associations, for example the IEEE. Be prepared
for having to know things like what technical societies,
technical councils, and technical committees are, and how to
deal with each of them. You are certainly in for a lot of
committee work, and i would count you lucky if you got away
without having to deal with lawyers, paying membership fees,
buying expensive standard documents you need for your work,
and so on and so forth. Even when you submit a technically
perfect proposal, it will typically be rejected without even
being considered until you secure the official sponsorship
of at least one of the following: the IEEE, the Open Group,
or ISO/IEC JTC 1/SC 22. Of course, your milage may vary
depending on what exactly you want to standardize and how,
but since roff(1) is arguably the most famous UNIX program,
i wouldn't be surprised if you were if for an uanbridged
POSIX-style Odyssey.
5. The above is not helped by standards committee work being
typically conducted in ways that are technically ridiculously
outdated, and i'm saying that as an avid user of cvs(1) who
somewhat dislikes git(1) as overengineered and very strongly
detests GitHub. Take the Austin groups as an example. Most of
its work is changing the content of technical documents,
but the group *never* uses diff(1), never uses patch(1), and
never makes diffs available even after they have been approved.
They are very firmly stuck in the 1980ies regarding the technolgies
they are using and missed even most of the 1990ies innovations.
They do have some kind of version control system internally, but
no web interface of such version control ins publicly available,
nor any other public read-only access to that version control.
Even the source code of the finished version of the standard
is typically not made available to the public (at least not
without forcing people to jump through hoops).
> A standard could lead to more implementations because
> developers would not have to be intimately familiar with the
> {groff,heirloom,neatroff} toolchain before implementing a
> *roff toolchain themselves.
That's not even wishful thinking. Better maintenance of the
existing implementations would be so much more useful than yet
another implementation.
> It could also lead to more users & use cases because existing
> users could count on systems supporting certain features, so
> they could use *roff in more situations, which would lead to
> more exposure.
You appear to massively overrate the importance end-users
typically attribute to standardization. Even people *implementing*
a system rarely put such an emphasis on standardization.
> It’s ridiculous that *roff isn’t part of POSIX when it was Unix’s
> killer feature.
You are welcome to spend the many years required to change that.
But be aware that some standardization efforts that are part of
POSIX resulted in parts of the standard that are barely useable
for practical work. One famous example is make(1).
Don't get me wrong: i think standardization is very nice to have,
should be taken very seriously when available, and provides some
value even when the standardization effort mostly failed, like in
the case of make(1). But standardization is absolutely not cheap.
To the contrary, it is usually significantly more expensive than
implementation and documentation.
Yours,
Ingo
