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

Amend URI Expression to specify whether relative URIs are allowed in 1.2 #10

Open
DavidUnderdown opened this issue May 20, 2016 · 2 comments
Assignees
Milestone

Comments

@DavidUnderdown
Copy link
Contributor

The current URI Expression allows both absolute and relative URIs, in general we want to ensure it's an absolute URI. To enable backwards compatibility this should be implemented as either a new absoluteUri expression, or by adding an optional flag to the existing uri expression in 1.2

@adamretter
Copy link
Contributor

@DavidUnderdown Can you provide some example expressions showing the issue that you are having with this?

@logicplace
Copy link

To +1 this, basically the issue is that "uri" is essentially a useless validation, as any basic string like "aaaa" "asljfl#kels" will validate just fine, iirc even spaces will validate fine. There are very few things that fail to validate under the spec. Of course, bare paths such as "/a/b/c" or "a/b/c" will validate fine as well.

I assume the original intention of the validator was to require the scheme, but it's not actually required by RFC-3986 nor the validation method used by the reference implementation. As such, it would be useful to be able to assert that the scheme should exist, or that it should be a specific thing (e.g. "file"). That can be done with starts of course, but it makes me wonder what the value of uri actually is in that case.

My ideal syntax for this would be like this:

UriExpr ::= "uri" ("(" ColumnValidationExpr ("," ColumnValidationExpr ("," ColumnValidationExpr)?)? ")")?

Which would apply a ColumnValidationExpr to the scheme, host, and path, respectively. One could possibly also add two more optional arguments for the query and fragment, but I don't think that would ever really be necessary (may worth throwing in if you went this route, though).

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

No branches or pull requests

4 participants