search

opengeospatial / ogcapi-coverages

OGC API - Coverages draft specification
https://ogcapi.ogc.org/coverages
Apache License 2.0
22 stars 13 forks source link

Path case-sensitive #11

Closed Schpidi closed 5 years ago

Schpidi commented 5 years ago

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 commented 5 years ago

very much so, +1 for uniform appearance in the URLs. It should be a pain in the neck to always consider case for each path component. Umm...nobody voting for ALL UPPERCASE? ;-)

-Peter

On 09.04.19 16:00, Stephan Meißl wrote:

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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/ogc_api_coverages/issues/11, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejgqDDw1xepcFD-rUU7ETNG4miFrIks5vfJ0PgaJpZM4ckk4i.

-- Dr. Peter Baumann

  • Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
  • Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."
chris-little commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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