-
Notifications
You must be signed in to change notification settings - Fork 58
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
Permit wildcard in tag validator URIs #858
Permit wildcard in tag validator URIs #858
Conversation
860a027
to
1a33ab1
Compare
Thanks for tagging me @eslavich I thought a little bit about asdf-format/asdf-standard#271 over last few days but did not find the time to write down everything. consider the following (passing) addition to ("asdf://*/tags/foo-*", "asdf://anywhere.org/tags/foo-bar/tag-3.1", True), Of course this might be intended, but what if only all versions of the actual tag ("asdf://*/tags/foo-*", "asdf://anywhere.org/tags/foo-4.9", True),
("asdf://*/tags/foo-*", "asdf://anywhere.org/tags/foo-5.2", True),
("asdf://*/tags/foo-*", "asdf://anywhere.org/tags/foo-bar/tag-3.1", False), I am not sure about the side effects this may or may not have. To avoid this I would propose that all So for the above example we could get the following behavior to work (which I personally find more explicit): ("asdf://*/tags/foo-*", "asdf://anywhere.org/tags/foo-4.9", True),
("asdf://*/tags/foo-*", "asdf://anywhere.org/tags/foo-5.2", True),
("asdf://*/tags/foo-*", "asdf://anywhere.org/tags/foo-bar/tag-3.1", False),
("asdf://*/tags/foo*-*", "asdf://anywhere.org/tags/foo-bar/tag-3.1", True), |
Hmm... that's a good point. I didn't think about that.
I'm only resistant to this because I suspect some people will want to use versions in some other way, maybe in the path ahead of the tag. Currently the ASDF Standard and the YAML specification both permit the tag to be any valid URI, and I'm not sure it's worth restricting them to support pattern matching on our particular notion of what a versioned URI should look like. Here's another idea: how about we treat ("asdf://*/tags/foo-*", "asdf://anywhere.org/tags/foo-bar/tag-3.1", False), We could even use the ("asdf://*/tags/**/tag-*", "asdf://anywhere.org/tags/foo/tag-3.1", True),
("asdf://*/tags/**/tag-*", "asdf://anywhere.org/tags/bar/tag-4.5", True), There is still potential for overly lenient matching within the same "directory": ("asdf://anywhere.org/tags/foo-*", "asdf://anywhere.org/tags/foo-3.1", True),
("asdf://anywhere.org/tags/foo-*", "asdf://anywhere.org/tags/foo-bar-4.5", True), But we can enforce that this does not happen in the ASDF core tags (with an automated test) and in other officially supported ASDF extensions. If you do the same in your project, would this system work? Or is the matching on |
Yes, the As long as the syntax is well described I don't really see any issues. Sure ("asdf://anywhere.org/tags/foo-*", "asdf://anywhere.org/tags/foo-bar-4.5", True), might be weird but should be avoidable when aware of the implementation. |
Great, I'll adapt this PR to implement the glob behavior. Thanks for helping me think this through! |
cbe2b42
to
325f7e9
Compare
325f7e9
to
1890063
Compare
This implements an idea from @CagtayFabry discussed in asdf-format/asdf-standard#271. See #838 for an alternative implementation.
The PR is branched off of #850. The relevant changes are in the latest commit.
The idea is to allow pattern matching in the
tag
validator, so that schema authors can permit many versions of a tag. For example, the following pattern:will match any of the following:
and this will match any transform tag:
which I expect will save us a lot of tedious updating of schemas when we add or update transforms.