3 ms·

> If W3C actually cared about links continuing to work, they would fix it at the technical level by promoting content-addressable links [...] Now, while I very

> If W3C actually cared about links continuing to work, they would fix it at the technical level by promoting content-addressable links [...] Now, while I very much like the idea of content-addressable systems, that is not the solution to this problem. Addresses/names often are used to identify more abstract things than "this sequence of bytes". For example, company A's current list of prices is not a fixed sequence of bytes, but rather an abstract concept that refers to information that varies over time. The purpose of a name in this case is that it allows you to obtain an up-to-date version of some information. A name that is derived from the content that you want to obtain cannot possibly do that job. Only names maintained by people who understand the continuity of those varying byte sequences can do that.

seagreen 10y ago
Heh, you got me:) I agree the situation is more complicated than I described. My main response to this is: just because we can't always use content-addressable links doesn't mean we shouldn't use them where we can. I'm sure you see where I'm going with this. When pirate movie websites have a 1000x more rock-solid way of identifying content than the NY Times we have a problem. But even in the most inhospitable situations like the one you describe we can still do better. Content-addressability won't help, agreed. How about promoting UUID style non-human readable paths instead? One of the reasons links change is that the content changes slightly and the name goes out of date. Perhaps in your case legal says "these prices may be up to ten minutes out of date, we can no longer call that path /prices/current/feed". If the path was /3824-3822-4864 this wouldn't be a problem. Information about what that endpoint returns can be placed in a description field or in the docs where it can be kept up-to-date without breaking links.
- zAy0LfpBZLC8mAC 10y ago
  I don't think that would make any real difference. Links break because people switch to new software that has different URIs for the content and they don't see the problem, or due to software that has stupid mechanisms for generating URIs, that's it. URIs changing due to a concious decision to change the URI are the rare exception, it's mostly just a side effect that noone cares about. Also, in your specific example, it would still be possible to replace the old content with a document explaining the change and linking to the new URI, or possibly even an HTTP redirect. Plus, a semantically meaningless name might still not prevent the problem, as there just as well could be legal consequences if you have communicated before that this URI provides "current prices" via some other means than the URI itself.

seagreen 10y ago

Heh, you got me:) I agree the situation is more complicated than I described. My main response to this is: just because we can't always use content-addressable links doesn't mean we shouldn't use them where we can. I'm sure you see where I'm going with this. When pirate movie websites have a 1000x more rock-solid way of identifying content than the NY Times we have a problem. But even in the most inhospitable situations like the one you describe we can still do better. Content-addressability won't help, agreed. How about promoting UUID style non-human readable paths instead? One of the reasons links change is that the content changes slightly and the name goes out of date. Perhaps in your case legal says "these prices may be up to ten minutes out of date, we can no longer call that path /prices/current/feed". If the path was /3824-3822-4864 this wouldn't be a problem. Information about what that endpoint returns can be placed in a description field or in the docs where it can be kept up-to-date without breaking links.

zAy0LfpBZLC8mAC 10y ago
I don't think that would make any real difference. Links break because people switch to new software that has different URIs for the content and they don't see the problem, or due to software that has stupid mechanisms for generating URIs, that's it. URIs changing due to a concious decision to change the URI are the rare exception, it's mostly just a side effect that noone cares about. Also, in your specific example, it would still be possible to replace the old content with a document explaining the change and linking to the new URI, or possibly even an HTTP redirect. Plus, a semantically meaningless name might still not prevent the problem, as there just as well could be legal consequences if you have communicated before that this URI provides "current prices" via some other means than the URI itself.