-
Notifications
You must be signed in to change notification settings - Fork 31
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
Unify document loading in Context Processing? #584
Comments
5.6.5 says what to do if loading the document fails; this would include cases where the URL is invalid. 5.2.4 is explicit about not dereferencing again, due to potential recursion loops. I don't think that the |
Thanks @gkellogg. I guess not but would it make sense at all to also replicate |
True, but that's a different error. 5.2.1 tells you what to do if the base URL is invalid, and therefore resolving the context URL against it is not possible. 5.6.3 does not tell you what to do in this situation... @helins has a point, we should probably render both steps more homogeneous.
I agree, but again, the fact that it is explicitly mentioned in one part, and not in another, may confuse implementers (as demonstrated by this issue). |
Discussed on [today's call](https://json-ld.org/minutes/2024-07-10/#52)#584 -> Issue 584 Unify document loading in Context Processing? (by helins) [spec:editorial] [ErratumRaised] ✪
Gregg Kellogg: Perhaps a chance to DRY up the text. ✪
Pierre-Antoine Champin: I'm hesitant to extract the common functionality, so maybe just go for consistency so as not to disrupt the flow of the document. ✪
|
The Context Processing Algorithm deals with dereferencing remote documents at 2 occasions:
5.2
and5.6
. Both look very similar to the point where I do not understand why there are seemingly differences:5.2.1
details how resolving thecontext
string againstbase URL
might fail ;5.6.3
does not mention anything about failure when resolving the value of@import
againstbase URL
5.2.4
is very explicit about not dereferencing a URL that has already been dereferenced ;5.6.4
goes straight into dereferencing without any further considerationThe text was updated successfully, but these errors were encountered: