Issue 66 html context #83
Conversation
…lements of type `application/ld+json;profile=http://www.w3.org/ns/json-ld#context`. For w3c/json-ld-syntax#66.
|
Note that I didn't add compact tests, as the compact tests take the extracted context, and not a URL. All the important paths are checked here. We'll want to add text to allow frame documents to be HTML too, for the same reasons of documentation. |
|
Is there a particular reason to only take the first context that was found in the HTML? <html>
<head>
<script id="context" type="application/ld+json;profile=http://www.w3.org/ns/json-ld#context">
{
"@context": {
"term3": "http://example.com/term3",
"term4": "http://example.com/term4",
"term5": "http://example.com/term5"
}
}
</script>
<script id="context" type="application/ld+json;profile=http://www.w3.org/ns/json-ld#context">
{
"@context": {
"term4": "http://example.com/term4",
"term5": "http://example.com/term5"
}
}
</script>
</head>
</html>In situations where Web designers are generating their views from multiple templates, Semantically, this could be processed similarly as context arrays. |
|
It is certainly something to consider, but if we fall back to using the profile-less type, I don’t see us taking them all, just the first, so it might seem inconsistent. People should 👍 or 👎 your suggestion. |
|
I tried to implement this, and ran into problems. One problem is that several tests fail, which previously passed, as normative text requires that a remote context be a top-level object, not array. From Context Processing Algorithm step 3.2.4:
I don't think it's worth softening or confusing this text without a compelling use case. |
|
I can see this approach being fraught with problems, mostly around dynamically generated script tags. Many (most?) people don't build static sites anymore -- which is why the search engines have adapted to run JS to do things like read JSON-LD on the page. Are we going to require the same of JSON-LD processors? If not, we're relying on a pretty specific scenario under which this will work: A website that serves a static page or at least one where the first script tag with an It seems to me like this might be a feature that's too targeted for the Web of yesterday ... or one that requires much more than the (already heavy) HTML parsing lift to function in a way users expect. |
|
The stated purpose of using HTML files for context (and frame) is to be able to document those files, in which case the JSON-LD script elements can be statically generated (perhaps the HTML is dynamically generated from the JSON-LD). Otherwise, if the JSON-LD is dynamically generated and inserted into a script tag, you may as well content-negotiate to generate the pure JSON-LD file for a direct response. We certainly can't anticipate every new web technology that may come about, but we can recommend practices for working for JSON-LD in web pages, particularly when the documentatative aspect is primary. |
…or a full processor (or not a pure JSON Processor).
|
@BigBlueHat @dlongley @iherman I added a section on processor levels and added text around parts of the algorithm which manipulate HTML to use them. (Also added similar text to w3c/json-ld-syntax#167). See if this satisfies your concerns. If so, I can split out tests into a separate context. |
Static websites are still very much a thing. Many highly popular tools exist for this (Jekyll (used by GitHub pages), Gastby, Mkdocs, ...), so we should definitely consider this an active domain.
In any case, I don't have a strong preference to allow multiple context, but I could imagine that people writing webpages expect this to be possible. For example, CSS allows multiple stylesheets to be referenced, where each next one builds upon the previous one. So logically, a developer may assume that JSON-LD (contexts) work in the same way. That being said, defining JSON-LD contexts in HTML is a very specific use-case, so I don't think multiple contexts in HTML are a must-have feature, it just would be nice-to-have for developers. |
I am basically fine with this. The minor thing that bothers me is that the definitions for pure processor & Co. are in a non-normative sections, whereas the reference to these terms are all in normative sections. Maybe these terms should become normative? |
|
+1 to @iherman about making "pure JSON processor" and "full processor" normative. However, "event-based JSON processor" should probably not be, because:
|
|
Thinking more about it, I think that mixing the "pure JSON vs. full" distinction with "event-based" is confusing... especially if two out of three are to be defined normatively. "Event based" is not a "level", it is somewhat orthogonal to the others. I propose to
|
|
I can certainly make the section normative, which will require moving it someplace else. Whether or not the term “event-based JSON Processor” is, itself normative, it’s not referenced from any other normative statements, but the text can elaborate that the term is non-normative, or I can add a non-normative subsection to describe it. |
…xt/html and the processor is a pure JSON processor.
Allow contexts to be HTML documents, with preference towards script elements of type
application/ld+json;profile=http://www.w3.org/ns/json-ld#context.For #66.
Preview | Diff