Open tomschr opened 2 months ago
@tomschr I did a little research and found this list of URI schemas: https://en.wikipedia.org/wiki/List_of_URI_schemes
Based on this list, schemas=['urn'] is not the right way because it's not in the list of URI schemas.
I think it would be better to have a new method .urn()
.
It's just opinion.
@tomschr I did a little research and found this list of URI schemas: https://en.wikipedia.org/wiki/List_of_URI_schemes
Based on this list, schemas=['urn'] is not the right way because it's not in the list of URI schemas.
Ahh, that's interesting. I didn't know, thanks!
I think it would be better to have a new method
.urn()
.It's just opinion.
I'm fine with using .urn()
as the way to go. 👍
My only concern is that users will find it. So one way to ensure that could be:
.uri()
for getting URNs, raise an exception and direct users to use .urn()
@tomschr
.uri()
should be good practice. In this case, it would be great to hear @fcurella opinion also.
Thanks for this great project! :heart:
If you run the
.uri()
method and pass the URN (Uniform Resource Name) scheme, it returns the wrong result.Steps to reproduce
Consider the following snippet:
Expected behavior
URNs are described in RFC 1737 and later in RFC 2141, I would have expected to have something like this:
Find more examples in the Wikipedia article about Uniform Resource Name.
Actual behavior
At the moment, the URN scheme uses slashes (
/
) which is wrong according to the mentioned specs. As the method name.uri()
implies, it's the generic term for URNs and URLs.Possible solution
I can think about different solutions to solve this issue:
.uri()
method and return the correct result when a URN scheme is requested..urn()
method.Idea 1 would probably the more generic solution as it works for URLs and URNs. On the other hand, idea 2 would make URNs stick out.