Skip to content
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

Path case-sensitive #11

Closed
Schpidi opened this issue Apr 9, 2019 · 6 comments
Closed

Path case-sensitive #11

Schpidi opened this issue Apr 9, 2019 · 6 comments

Comments

@Schpidi
Copy link
Member

Schpidi commented Apr 9, 2019

According to RFC 3986 the path component is case-sensitive. Do we want to use the camel-case notation from XML or rather mandate all lower case?

I tend to prefer all lower case as it looks more natural in a URL.

@pebau
Copy link
Contributor

pebau commented Apr 9, 2019 via email

@chris-little
Copy link

Why are we restricting URIs from RFC3986? Why not follow IRIs from RFC3987? we are trying to establish a global standard.

Upper and lower case are really only meaningful for some writing systems. There is no distinction in Cyrillic or Chinese for example. If I wanted to access colleagues' weather services at 中国气象网, why should they have to transliterate into a subset of 1960's ASCII?

@cmheazel
Copy link
Contributor

cmheazel commented Apr 9, 2019

I suggest we follow RFC 6570 (URI Templates) since templates are what we are actually defining. I also like the approach taken by 6570
"Although the URI syntax is used for the result, the template string is allowed to contain the broader set of characters that can be found in Internationalized Resource Identifier (IRI) references [RFC3987]. Therefore, a URI Template is also an IRI template, and the result of template processing can be transformed to an IRI by following the process defined in Section 3.2 of [RFC3987]."

@chris-little chris-little reopened this Apr 10, 2019
@chris-little
Copy link

chris-little commented Apr 10, 2019

Sorry -did not mean to close this issue - hit wrong button while rushing for a bus.
@cmheazel happy with your suggestion. We should be permissive rather than proscribing. Even though it is easier to type lower case on a Western Roman keyboard. It is the service providers perogative.
However there is the issue is what is allowed for search terms to the right of the '?' and how these are folded to a canonical form, but again, not really visible or meaningful to the user. As a user, I would be really annoyed if specifying "Data" failed because I should have typed "data".

@Schpidi
Copy link
Member Author

Schpidi commented Apr 11, 2019

Sorry, I didn't mean to restrict anything. My question was only regarding the parts of the path we define in the spec, e.g., coverages or domainset. Btw. scheme and host are case-insensitive anyways.

Parts defined at runtime by a service like IDs are a different topic. Being based on XML in WCS these have to follow the NCName convention.

@Schpidi
Copy link
Member Author

Schpidi commented Jun 17, 2019

Any objection to using lower case in the spec defined path components? Please reopen if there is any.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants