Open Cadair opened 4 years ago
https://github.com/asdf-format/asdf/pull/854 did exactly this.
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?
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...
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
I see that in the roadmap for 2.0 you are planning on dropping the
tag:
scheme forhttp://
. It's always somewhat confused me thathttp://
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 tohttp://
)?