New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What to call 'URI serialization' #74
Comments
I strongly agree with this, and intend to incorporate "URIwashing" into my vocabulary. |
"introduction by serialized reference" is what I suggested in #29
|
or "squatting". It's an anti-pattern documented as far back as 2005: UriSpaceSquatting |
I see... the document has a section 'URI serialization' which is correctly named... it's in a section called 'Node locator' which includes various serializations. To be compulsively parallel the larger section might be called "Locator serializations". As suggested I'll close this as a dup of #29 |
Dup of #29 |
A comment on #73 (locators spec draft):
I would still prefer that all mentions of 'URI' be removed from the document, even if the syntax of that form satisfies the generic URI syntax. Later, if someone can come up with a good reason for these things being URIs (not just syntactically; and I requested a use case a while ago and no one came forward with one), then there must be some kind of commitment to push an 'ocapn' scheme registration through IETF. And I warn you, that might not be easy - I've been lurking on the uri-review list and submissions routinely get trashed.
We could say 'the string serialization' or 'the ad hoc serialization' or 'the linear serialization' or something like that instead of 'URI serialization'.
A cautionary tale: the LSID spec said that LSIDs were supposed to be URNs, but its URN subscheme (:lsid:) was never even written up, much less registered with IETF. I consider this behavior to be terribly antisocial since it breaks the social contract of the URI and URN specs. Someone coming across an LSID could with reason look up urn: in the URI scheme registry and find the URN spec, then go to the URN subscheme registry (referenced in the URN spec) to find LSID, and they wouldn't find it, endangering their faith in the whole system and reinforcing the idea that it's a free for all (which it is to some extent but only for spec violators).
If :lsid: had been submitted to IETF for review it would have been rejected because there is no way to write a conforming URN registration for it that's consistent with the LSID spec. This is not how things are supposed to work. You might call it 'URIwashing'.
The text was updated successfully, but these errors were encountered: