Change to using URL standard - #1670
Merged
Merged
Conversation
mattgarrish
requested review from
GarthConboy,
bduga,
danielweck,
dauwhe,
iherman,
llemeurfr,
marisademeglio,
rdeltour,
shiestyle and
wareid
May 9, 2021 01:08
iherman
approved these changes
May 9, 2021
iherman
left a comment
Member
There was a problem hiding this comment.
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!
marisademeglio
approved these changes
May 11, 2021
llemeurfr
approved these changes
May 11, 2021
rdeltour
suggested changes
May 11, 2021
rdeltour
left a comment
Member
There was a problem hiding this comment.
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. 😊
…t consist only of a prefix
add change log entries
wareid
approved these changes
May 14, 2021
shiestyle
approved these changes
May 14, 2021
Member
Author
|
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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
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