Change to using URL standard

[mattgarrish]

I've updated the authoring and reading system specifications to use the URL standard terminology.

There are a number of changes in this PR, but they basically all break down along these lines:

• relative IRI has become "relative-URL string" where it doesn't seem to make sense to allow fragment identifiers (manifest item and media overlays audio src)
• relative IRI has become "relative-URL-with-fragment string" for all other cases
• same changes as above for absolute IRIs
• where we hadn't broken our relative from absolute, I went with "valid URL string"
• base IRI has become base URL

The one tough case was in ocf, where the rootfile and link elements required the IRI be "a path component [RFC3986] which MUST take the form of a path-rootless [RFC3986] only". My best interpretation of this is that it is the equivalent of the URL standard's "path-relative-scheme-less-URL string".

I've also used this definition for the property datatype definition to replace irelative-ref in the ebnf.

Please let me know if you think I've made a mistake with any of these.

Otherwise, I've moved a few more passively expressed reading system requirements over to the proper document. These were all related to creating URLs from the default vocabulary base URLs. Reading systems are the ones that create these expanded URLs.

Fixes #808

• Reading Systems preview
• Reading Systems diff

EDIT: Also fixes #1673 by adding requirement for reading systems to ignore properties that expand to invalid URL strings and also prefixes without a referent.

EDIT 2: Also fixes #1303 by restricting manifest items to fragment-less URLs.

---

Preview | Diff

[iherman]

I did not find any problems with the mapping from the RFC concepts to the URL spec... All my comments are minor editorial one.

Thanks!

[rdeltour]

Relying on the well-defined URL standard is a good move, well done! 👍

I find however that the PR sometimes mixes the serialization terminology (strings) and the concepts (URL record). For instance it often says "resolve relative URL string to absolute URL string" when the URL standard would rather say "parse relative URL string into URL". See the inline comments for details. 😊

[mattgarrish]

I believe everything has been addressed now, so I'm going to go ahead and merge this. New issues are welcome if anyone spots anything amiss.