Linking to the POSIX standard text (about editions and HTML fragments)

Question

When linking to the POSIX standard document one may link to a specific edition (as I did here), or to the latest (undated) edition.

Linking to a specific edition may be preferable when linking to a HTML fragment, such as, for example, the text on Tilde Expansion (the URL has #tag_18_06_01 at the end signifying a HTML fragment which in this case refers to the section on Tilde Expansion in a longer document), as advocated by Stéphane Chazelas in a comment to me regarding this:

Something to be aware of: when linking to POSIX with HTML fragments, it's better to specify the exact edition (like pubs.opengroup.org/onlinepubs/9699919799.2016edition) as fragments have been known to change between editions of a same revision of the spec (a lot of links in answers on this site including of mine are now wrong as the fragments point in the wrong place after the 2016 edition has been released).

At the same time, I can see schily's point in another more recent comment thread, where he advocates linking to the most recent (undated) edition of the standard, simply because it's the current standard:

[...] if you remove the year substring in the POSIX URL, you would always get the latest documents under this URL.

How do I resolve these two standpoints? For example,

• do I not link to HTML fragment at all and always use the undated edition (forcing the user to search through the page for the relevant information), or
• do I link to a specific edition when referring to a HTML fragment, but to the undated edition when not (which is being inconsistent in behaviour and which I would probably forget to do properly after a time), or
• do I continue linking to a specific edition for everything (my answers would be correct for the linked edition, but may eventually be outdated when compared to the most recent edition), or
• do I use the undated edition for everything (links to HTML fragments may die after some time)?

I'm asking because it obviously matters to people enough to comment on it, and it would be nice to be able to "do the right thing" (if at all possible), and also because I tend to link to the POSIX documents quite often.

Answer 1

I don't think it's automatically a bad thing to use a link with the explicit date (as long as it's current at the time!). The answer written here will probably be based on that particular version anyway, and if the standard changes, the answer itself is going to be wrong too, not just the link.

Other than noting any changes, and updating the answers, there's no workaround for this: we can't know in 2018 what a 2023 standard will say.

If the standard changes in a backward-incompatible way, someone will get confused, but not just because we used a particular link. That may manifest in new questions asking "Why does X work in A but not in B (even though [high-rep user] said it's standard)?". That's not an invalid question in those circumstances.

And, you get the blame for the wrong link only if the standard changes in the particular subject you're linking to. Linking to the newest version with an anchor runs the risk of breaking the link if anything changes in the same document before the part you link to.

...

On the other hand, linking to, say some part of the Shell Command Language page without an intra-page anchor would just seem... impolite, so I'm going to go on including them, but will try to use the links with the explicit dates from now on.

Answer 2

This is the difference between bare unadorned URLs and proper citations.

Bare URLs suffer from link rot, are often undecipherable from the actual URL path once rotten, and are of no Earthly use to (say) people who actually own a copy of the standard on DVD.

Proper citations do not suffer from these problems. A reader should be able to discount the hyperlink entirely and still be able to find the cited doco, from the name of the work, the author, the date, and any necessary chapter and section.

And this is not just true for the SUS.

Examples

From https://unix.stackexchange.com/a/347927/5132:

• "Utilities: join". Shell Command Language. Single UNIX Specification. Issue 7. IEEE 1003.1. 2016. The Open Group.

From https://unix.stackexchange.com/a/413225/5132:

• "pwd". The Open Group Base Specifications Issue 7. IEEE 1003.1:2008. The Open Group. 2016.
• "Pathname Resolution". The Open Group Base Specifications Issue 7. IEEE 1003.1:2008. The Open Group. 2016.

From https://unix.stackexchange.com/a/441817/5132:

• Jonathan de Boyne Pollard (2018). The Unix login database. Frequently Given Answers.
• pututxline. Base Specifications. IEEE 1003.1:2017. The Open Group.

From https://unix.stackexchange.com/a/426870/5132:

• "ustar header block". pax. Single Unix Specification. IEEE 1003.1-2008:2016.
• Tim Kientzle (2016-12-27). tar. § 5. FreeBSD File Formats Manual.

From https://unix.stackexchange.com/a/405780/5132:

• George V. Neville-Neil, Marshall Kirk McKusick, and Robert N.M. Watson (2014-09-25). "Process Management". The Design and Implementation of the FreeBSD Operating System. Addison-Wesley Professional. ISBN 9780133761832.
• Donald Lewine (1991). "Terminal I/O". POSIX Programmers Guide. O'Reilly Media, Inc. ISBN 9780937175736.
• Daniel P. Bovet and Marco Cesati (2005). "Processes". Understanding the Linux Kernel: From I/O Ports to Process Management. 3rd edition. O'Reilly Media, Inc. ISBN 9780596554910.
• "Definitions". The Open Group Base Specifications. Issue 7. 2016. IEEE 1003.1:2008.
• "General Terminal Interface". The Open Group Base Specifications. Issue 7. 2016. IEEE 1003.1:2008.

Answer 3

I support using the undated link with a fragment identifier, and using the section heading plus number where possible as the link text or title,

• unless talking about a specific edition (for example, discussing changes or addressing a historical situation),
• while trying to keep the quoted text and links updated on a best-effort basis as a community effort.

Consider a visitor who reads your answer, which contains such a link and some quoted text. If they follow the link and see something different, they can immediately see that the answer was outdated. Then they may alert you to the fact or even update the answer themselves.

Now, all other options add a barrier to the user realising that the answer is outdated. A year-specific link may have an obsolescence notice on top, but it may not be conspicuous and additionally the user would have to find the current latest and check to see if anything changed. A link without a fragment id is just an annoying thing, period.

Answer 4

First an important note: http://pubs.opengroup.org/onlinepubs/9699919799/ is the link to ISSUE 7 of the standard. ISSUE 6 is e.g. here: http://pubs.opengroup.org/onlinepubs/007904975/

If there will be a future standard, this will get a new URL. So there is no reason to assume the content will be changed so that the URL will point to claims that do not match the answer it should backup.

What on the other side happens with the generic URL is that bugs in the text are fixed in a way that keeps the section numbers. So there is no reason to assume that a specific section might point to something completely different in the future.

A known bug that has been fixed is e.g. the information about the waitid() call. In 1995, the exit() description correctly mentioned that the exit parameter is the exit code. In the 1997 (ISSUE 2) edition, a bug has been introduced that claimed that only the low 8 bits of the exit code are propagated. The 2016 edition of ISSUE 7 fixed this bug and correctly mentions that wait() and waitpid() limit the available bits from the exit code, but not waitid().

This definitely was not a change in the standard but a fix of a textual bug in the standard.

We have many real changes that have already been agreed on but these changes are delayed until we publish ISSUE 8 that will then be available under a different base URL.

Since there has been a change in numbering in the past, it seems to be a bad idea to post URLs to section numbers. URLs like this: http://pubs.opengroup.org/onlinepubs/9699919799/functions/_exit.html are still OK as they have a fixed text and a unique content. Posting the URL http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/functions/_exit.html on the other side keeps the buggy text for _exit().