w3c / pub-manifest

W3C Publication Manifest
https://w3c.github.io/pub-manifest
Other
7 stars 16 forks source link

Absolute URL for schemas #226

Closed mattgarrish closed 4 years ago

mattgarrish commented 4 years ago

We've been using relative paths in the schemas to date as it made local development a little easier, but due to recent differences in how some validators work, we need to switch back to absolute URLs now that we're winding down the work. The problem is we never resolved on formal URLs for these.

For now, I've used the github pages address for the schemas: https://w3c.github.io/pub-manifest/schema/

While this seems to work fine, we should figure out if we want to put a W3C redirect on top of it, something like: https://www.w3.org/ns/pub-manifest/schema/*

Aside from not having github in the formal URL, it also gives us flexibility should we need to change locations in the future. (We'll also need a similar URL for the audiobooks schema, too.)

@iherman @marisademeglio and I have been discussing this privately while trying to iron out the validation problems the relative URLs caused, but what actual solution to use needs group approval.

iherman commented 4 years ago

Just for the records I am in favour of using W3C URLs for these.

iherman commented 4 years ago

I am o.k. with the proposed changes in principle, but I do have a problem with the incarnation in https://github.com/w3c/pub-manifest/pull/228 and https://github.com/w3c/audiobooks/pull/85...

At the moment, we use the following URL-s in our specs (including the current proposal):

  1. Publication context: https://www.w3.org/ns/pub-context
    • The URL redirects to https://www.w3.org/ns/pub-context.jsonld
    • The content is maintained in a separate github repo
  2. Publication vocabulary: https://www.w3.org/ns/pub
    • There is a content negotiation to serve this url in html, json, rdf/xml, and turtle
    • The content is maintained in a separate github repo
    • Is used for the manifest specific vocabulary items in the context file, e.g., https://www.w3.org/ns/pub#LinkedResource to identify the manifest specific LinkedResource class
  3. Publication manifest schemas directory: https://www.w3.org/ns/pub-manifest/schema/
    • The URL-s redirect to https://w3c.github.io/pub-manifest/schema/*
    • Contains an index file and a number of json schema files
  4. Publication manifest schemas directory: https://www.w3.org/ns/audiobooks/schema/
    • The URL-s redirect to https://w3c.github.io/audiobooks/schema/*
    • Contains an index file and a number of json schema files

(I hope I do not forget anything.)

There does not seem to be any consistency in our URL schemes, and that bothers me. Looking at the list, I would consider the first entry above cast in concrete: all our examples, and indeed current implementations, rely on that URL. We should not change that. Changing (2) requires a change in the context file; taking into account that I do not think any of the current implementations are JSON-LD based, I do not think that changing that URL would invalidate any of them. Put it another way we can change that if we want. Finally, (3)/(4) are still open.

One alternative may be something like:

This seems to be o.k. for future profiles: if new vocabulary entries are added in a separate vocabulary, it can be https://www.w3.org/ns/pub-vocab/foo and, similarly, new schema files can be added as https://www.w3.org/ns/pub-schema/foo/*

I am not saying this should be the final option, I am just saying we should find something more future proof and consistent...

mattgarrish commented 4 years ago

Ya, I guess that works. Would have been a bit nicer if the stem could have been https://www.w3.org/ns/pub/ but I guess in the interest of not changing the context at this stage /pub-*/ will do.

iherman commented 4 years ago

I think I am done, but better check on your side before updating the PR-s. Just to be on the safe side.

Anything I forgot?

mattgarrish commented 4 years ago

SGTM. I'm not seeing anything in the four cases above not covered.

iherman commented 4 years ago

Pfew :-)

Will you take care of the updates for #228 and w3c/audiobooks#85?

mattgarrish commented 4 years ago

Sure