-
Notifications
You must be signed in to change notification settings - Fork 280
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
Specification proposal: Use IRIs instead of URLs #543
Comments
Hi @simonsolnes and welcome! |
I'm against this proposal. GBFS is primarily made for machines, not humans. Depending on the consumer implementation URL parsing might fail, so this is a breaking change. If there would actually be the need to display any URL to the user, it’s easy to convert the URL-encoded characters back to display characters. |
I think one could argue that not using IRIs leads to unintuitive behaviour for developers implementing GBFS, given that –even though this is technically inaccurate/wrong – most devs nowadays assume Unicode support when hearing the term "URL". But I think @futuretap makes a very valid point about the proposed switch to IRIs being a breaking change! |
Tagging recent contributors for visibility: @cmonagle @viestat @ArashMansouri @AntoineAugusti @ezmckinn @fbouchPBSC @Carl-NM @bdferris-v2 @kulovan @gajayraghav @testower @hynick4 @PierrickP @tdelmas @tobsesHub @tstrubel @HannesOlszewski @leonardehrenfried |
I support this proposal, largely in the interest of keeping the standard legible for humans. As a Product Manager sharing URLs with other humans, I value having something easy to read and explain — and to the extent we think of GBFS as an "open data" standard, it's worthwhile to keep it user-friendly for developers who use any alphabet. If I particular publisher of GBFS feeds wants to use IRIs, the standard should not forbid it. IRIs may prove unpopular among aggregators who want to ingest that standard — but in that case, either the publisher of IRIs can revert to URLs or the aggregator can choose to support IRIs. The free market of publishers and aggregators will convene around the optimal solution. The role of GBFS is to support interoperability, so a change that better supports languages besides English seems aligned with the mission (and the platforms who don't want to use IRIs, don't have to). |
Agree with @futuretap . I'm against this change
|
I'm against this change. GBFS is primarily made for machines, not humans.
|
Thank you for providing your feedback, although I disagree with some arguments, we are all working together to make GBFS better. I'd like to address some arguments Argument for: Developer assumptionI think @derhuerst has a strong point that many developers do subconsciously assume URLs to be IRIs
IRIs has silently replaced URLs overall in APIs, websites and the like Argument against: Machine readableIRIs are specifically made for machines just like URLs, so I don't understand this argument. Arugment against: GBFS endpoints are in English
Argument against: The specification is already technical with JSON, APIs etc
|
I don't think this is worth it due to lack of (computer) language support. Java does not support it which leads to having to use plain Strings and adding custom validation for it. I imagine it will be similar in other languages. |
@testower So what's the status quo for existing GBFS tools? Process the URLs as URLs, even though some people may expect them to be IRIs – "This field likely works like the address bar in the browser." –, and therefore allow subtle bugs with non-ASCII IRIs? |
I can only speak for the tools I use myself. Even though the "iri" format exists in json schema draft-07, the pojo generator maps this to String type in java, whereas it maps "uri" to java.net.URI. There is a IRI type in Java, so the first hurdle for me would be to get the pojo generator (which I don't maintain) to map iri format to IRI type. What other complications await further down the line and in other languages is hard to predict. So what I'm saying is that it's probably not impossible to get done, but I don't really see it as important enough to be worth the hassle. |
Swift Wherever URLs are displayed to the user, they could of course be displayed as IRIs. That's what browsers do since ages. |
This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions. |
still relevant |
This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions. |
still relevant |
Please create a PR and ask for a vote. Just defending staleness by posting "still relevant" doesn't help anyone. I'm against this, as written above, but let the community decide! |
@richfab I'll let you handle this one. |
When providing URLs for privacy policy, logo link, and similar, it can be the case that special characters are needed. In Norwegian, 'terms' is 'vilkår' and for 'policy', 'erklæring' can be used.
It's much easier to read
https://example.no/personvernerklæring
thanhttps://example.no/personvernerkl%C3%A6ring
The solution to this is to allow for IRIs in the specification.
IRIs are supported by all web-browsers and is of course supported by the feed provider if they provide the IRI.
This is not a breaking change since IRIs is an extension of URLAs @futuretap mentioned, this will actually be a breaking change
The text was updated successfully, but these errors were encountered: