Fix broken links to design principles document

[JohnOnGH]

Looks like there are two versions of the hyperlink being used in the document to the Design Principles PDF.

A broken version uses: "https://www.trustoverip.org/wp-content/uploads/Design-Principles-for-the-ToIP-Stack-V1.0-2022-01-17.pdf" - this results in a 404 Page error.

Whereas "https://trustoverip.org/wp-content/uploads/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf" works.

It looks like the error is in the date (2022-11-17 works, 2022-01-17 doesn't).

The quick fix would be a "find and replace" of the hyperlink, a better fix would be to make these links less fragile, perhaps by not referring to release dates, version numbers or other dynamic elements in the URL? A DID perhaps? ;-)

[wenjing]

Indeed, the PDF file was probably updated some time between those two dates without our knowledge - there shouldn't be any content change, at least not I am aware of. I would love to see DIDs.

[talltree]

@JohnOnGH, oh, the irony. While the broken link you found is simply an error we can easily fix, that error revealed another deeper error. To explain: the ToIP Foundation adopted a permalink policy last year specifically so we could have long-lived URLs for ToIP deliverables UNTIL we could start using DIDs for them. The permalink construction algorithm is documented here:

https://wiki.trustoverip.org/display/HOME/File+Names+and+Permalinks

Note that we made an explicit decision to include BOTH the version number AND the official Steering Committee approval date of the deliverable in each permalink. This was based on my experience with permalinks at other standards development orgs like W3C and OASIS, and still I believe it is the right design (until we can start using DIDs).

We followed that algorithm for our first set of deliverables beginning on November 17, 2021. But it turns out we made a simple human transcription error in the date of several of the first set of deliverables to which we assigned permalinks. To be specific, following is the list of the first five filenames for these deliverables (all of which are prefixed by https://trustoverip.org/permalink/ in order to become fully qualified permalinks):

• Introduction-to-ToIP-V2.0-2021-11-17.pdf
• Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf
• ToIP-Governance-Architecture-Specification-V1.0-2022-12-21.pdf
• ToIP-Governance-Metamodel-Specification-V1.0-2022-12-21.pdf
• ToIP-Governance-Metamodel-Specification-Companion-Guide-V1.0-2022-12-21.pdf

I was the one who created that list, and I missed the fact that only the first one had the correct year — 2021. All the rest were also supposed to be 2021, but mistakenly said 2022 instead.

But since that was the authoritative list, the ToIP webmaster faithfully created all of those permalinks with the dates as given.

Note that all of this has nothing to do with the broken link you found, because the current active permalink for the Design Principles for the ToIP Stack V1.0 is indeed:

https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf

It's just that having the wrong year number in the permalink is totally confusing to anyone using that link, because it says right on the title page of the deliverable that the correct is 2021-11-17.

I am taking the action item to fix this by having a new set of correctly-dated permalinks assigned to the four deliverables that currently have the wrong date. But — because the existing permalinks are permalinks — they will continue to work as well.

Thanks for pointing this out to us.

[JohnOnGH]

Crikey, I didn't think the loose link thread would be connected to a whole bunch of other stuff! Thanks for explanation, appreciated. I'm sure we've all realised belatedly that the fiendishly clever thing we've designed could be have been more simple.

“I would not give a fig for the simplicity this side of complexity; but I would give my life for the simplicity the other side of complexity.” – Oliver Wendell Holmes

[talltree]

@JohnOnGH I love that Oliver Wendell Holmes quote and use it frequently. I could not agree more.