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

On URI Schemes #274

Open
Cadair opened this issue Aug 25, 2020 · 4 comments
Open

On URI Schemes #274

Cadair opened this issue Aug 25, 2020 · 4 comments

Comments

@Cadair
Copy link
Contributor

Cadair commented Aug 25, 2020

I see that in the roadmap for 2.0 you are planning on dropping the tag: scheme for http://. It's always somewhat confused me that http:// is used as a scheme for asdf given that the vast majority of things aren't actually resolvable using http.

Why not implement a asdf: scheme or something which has the current resolving semantics (eventually falling down to http://)?

@jdavies-st
Copy link
Contributor

jdavies-st commented Aug 25, 2020

asdf-format/asdf#854 did exactly this.

@Cadair
Copy link
Contributor Author

Cadair commented Aug 25, 2020

Not really sure how I missed that... [oh it was in the asdf python package repo]

Is the plan then to transition both id's and tags to using that?

@eslavich
Copy link
Contributor

Is the plan then to transition both id's and tags to using that?

We're planning to try out asdf:// URIs on the next version of the transform schemas, and then migrate everything else if that works out. The URI authority is moving from stsci.edu to asdf-format.org anyway so it's an ideal time to also change the scheme from http/tag to asdf.

I need to update the roadmap, that was written up before you suggested the asdf:// scheme...

@acovaci
Copy link

acovaci commented Jul 8, 2024

To jump on this issue, I would argue both http(s) and asdf are highly misleading. In fact, using an URL for the schema is misleading, as long as you don't plan to make a document available under that URL.

In general URIs are meant to identify network-accessible resources. Thus, switching to asdf would imply you implementing an ASDF protocol to access said resource.

I think significantly more appropriate would be to use an URN. This would be able to define the kind of ASDF schema, without creating expectations about a document existing. E.g.: urn:asdf:schema/draft/1 or urn:asdf:schema/v1.1.1 etc.

Or, if you want to allow the possibility of these schema documents be available over the network, you could allow both URIs and URNs, with URN by default for the ASDF standard. This could be easily parseable by looking for the urn: beginning.

EDIT: For example, the MPEG schema is urn:mpeg:mpeg7:schema:2001

EDIT 2: I am happy to come up with a draft specification snippet (i.e. RFC) for this, if you require more hands on deck

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

No branches or pull requests

4 participants