What is 'base' for an embedded json-ld? #23

iherman · 2018-07-01T04:50:55Z

The definition of the embedded JSON-LD does not specify what the 'base' for that JSON-LD must be. It should specify it.

(cf #22)

iherman · 2018-07-01T04:52:29Z

My view is that, unless base is explicitly set in the JSON-LD content, the base URL of the HTML containing the script element must be used as a base for the JSON-LD snippet.

gkellogg · 2018-07-01T22:14:47Z

There are a couple of possibilities:

Document Base URL
The Node Documents's BaseURI, which I believe can be affected by xml:base.

I find the HTML and DOM descriptions somewhat confusing, but basically it's a matter of if it uses the base URL in the scope of the script element, or that of the document itself, either from it's location, or from html>head>base@href.

iherman · 2018-07-02T07:08:30Z

The (WhatWG) DOM document says:

The baseURI attribute’s getter must return node document’s document base URL, serialized

The HTML standard says:

The document base URL of a Document object is the absolute URL obtained by running these substeps:

If there is no base element that has an href attribute in the Document, then the document base URL is the Document's fallback base URL; abort these steps.

Otherwise, the document base URL is the frozen base URL of the first base element in the Document that has an href attribute, in tree order.

I do not find this particularly confusing... Whether xml:base affects the document base URL in the HTML sense: probably if the XHTML serialization is used. But this is not of our concern if we simply refer to the HTML spec's base URL.

gkellogg · 2018-07-02T21:30:16Z

What I found confusing was how xml:base is handled on intermediate nodes, which would create a different base IRI for that element and it's descendants; it's as if DOM and HTML consider that to create a new document, but I'm unclear on their logic.

In any case, it would be fine for us to ignore this usage and rely only on the original document base URI>

iherman · 2018-07-22T08:14:30Z

@gkellogg,

in some sense, this is not our problem:-) If what we say is that the base as valid for the <script> element, is the default base for the JSON-LD, we are fine. Whatever confusion exists (like the usage of xml:base is not really our problem. In most of the cases that will be the document base, so I do not see that as a problem in practice.

There is a similar question, b.t.w., which did come up lately at the Publication WG: what about the possible lang setting in the document node hierarchy down to the script element itself? Should we consider that as the default language of the JSON-LD textual data?

BigBlueHat · 2018-08-03T19:40:36Z

The underlying question seems to be about whether the surrounding HTML effects the contained JSON-LD (i.e. <base>, <srcipt lang>, etc).

Right now, it's my assumption that the markup does not need to be consulted when extracting or using the JSON-LD, but that the request URL and response headers used to convey the HTML (with the embedded JSON-LD) would retain their meaning to the JSON-LD.

For example (riffing off this example in the spec):

GET /markus
Host: http://example.com/
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html
Link: <https://json-ld.org/contexts/person.jsonld>;
        rel="http://www.w3.org/ns/json-ld#context";
        type="application/ld+json"

<html>
<head>
  <script type="application/ld+json">
{
  "@id": "",
  "name": "Markus Lanthaler",
  "homepage": "http://www.markus-lanthaler.com/",
  "image": "http://twitter.com/account/profile_image/markuslanthaler"
}
  </script>
</head>
<body>
  <img src="http://twitter.com/account/profile_image/markuslanthaler" />
  <a href="http://www.markus-lanthaler.com/">Markus Lanthaler</a>
</body>
</html>

Given that the document was requested from http://example.com/markus then the triples I'd expect would be:

<http://example.com/markus> <http://xmlns.com/foaf/0.1/homepage> <http://www.markus-lanthaler.com/> .
<http://example.com/markus> <http://xmlns.com/foaf/0.1/img> <http://twitter.com/account/profile_image/markuslanthaler> .
<http://example.com/markus> <http://xmlns.com/foaf/0.1/name> "Markus Lanthaler" .

Essentially...

the request URL becomes the Base URI (as described in that section)
the context is set (in this case) just as it would be for a "plain JSON" document (as current described in Interpreting JSON as JSON-LD).

This would avoid the complication(s) of consulting the surrounding formats many similar value expressions (lang, base, etc), while still benefiting from the HTTP message headers we're already leaning on for the "plain JSON" use case.

If this is on the right track, I'm happy to contribute text to make the Embedding JSON-LD in HTML Documents normative (following the pattern set in the "plain JSON" section).

Just let me know. 😃

BigBlueHat · 2018-08-03T19:42:06Z

FWIW, this is how the JSON-LD Playground experience feels now (at least as regards the Base URI). Any "@id": "" will get <https://json-ld.org/playground/> as it's URI in the output triples.

gkellogg · 2018-08-03T22:03:07Z

That's always been my interpretation, other things to consider are the following:

<html>
<head xml:base="http://example.org/alt-base/" lang="EN-alt">
  <script type="application/ld+json">
{
  "@id": "",
  "name": "Markus Lanthaler",
  "homepage": "http://www.markus-lanthaler.com/",
  "image": "http://twitter.com/account/profile_image/markuslanthaler"
}
  </script>
</head>
<body>
  <img src="http://twitter.com/account/profile_image/markuslanthaler" />
  <a href="http://www.markus-lanthaler.com/">Markus Lanthaler</a>
</body>
</html>

Does xml:base, or head>base@href affect the processing (mine doesn't).
Does the in-scope language setting affect the default language values (mine doesn't)

We need to be careful about putting too many restrictions on implementations; by making HTML processing normative, all compliant processors will need to include an HTML parser, whereas now they only need to process JSON. My library depends on the RDFa processor to look for other embedded encodings in an HTML document, including Microdata, RDF/XML, and anything in a script tag for which it can find a reasonable reader. We may want to keep these requirements in a different spec.

iherman · 2018-08-04T07:20:14Z

The problem I have with the strict HTTP response based approach is my usual one: for most of the users/authors out there (think of all the schema.org users!) setting the HTTP response headers is not an option: they have neither the knowledge nor the access to do that. I believe any setting must rely on what they can really control, namely the HTML content itself.

I also believe we should not shy away from relying on the usage of an HTML parser. After all, if a JSON-LD processor does implement the embedded JSON-LD extraction, then the most natural way of doing so is to parse the HTML file with a parser (and they are available everywhere for all types of languages) and perform something like:

const script = dom.window.document.querySelector(`script[[type="application/ld+json"]`);
const jsonld = script.text

We should encourage using this pattern rather than using some sort of a text processing trick imho.

That being said: I think we have three generic behaviors that we need to specify.

Base: To use the code snippet above we should say that the base for the embedded content is the value of script.baseURI. We have the HTML5 and DOM specs that define exactly what that means, we do not have to get into the details. In the usual case this falls back to what the HTTP return value gives, but also accounts to possible base setting in the HTML using whatever means that HTML authorizes.

Default language: I think if the language is set explicitly in the HTML source, this should be honored. A question that is not 100% clear to me is whether any inherited language should be considered or only an explicit setting.

Ie, I believe that the following case:

<script type="application/ld+json" lang="fr">
...
</script>

must be equivalent to a "@language":"fr" in the context (of course, any explicit setting within the JSON-LD content would overwrite this). If, as an author, I go out of my way to set the language via a perfectly legal HTML attribute, then I would expect that to mean something.

The slightly more unclear case is whether

<head lang="fr">
<script type="application/ld+json">
...
</script>

has the same effect. I think the answer should be 'yes', too. One reason is that if I use that mechanism for any other HTML element, like a <p>, then the two approaches have exactly the same effect on the content of <p>, so not doing for this script may be considered as unnecessary exception. (Note that the user may switch the language off by setting lang=''.)

Default text direction: (Ie, the dir=ltr attribute). The issue here is that we do not address the problem of direction in JSON-LD at all, so we may want to ignore this. Specific applications may take that value into account if they do something with the literal values of the JSON-LD, but we would not specify this. We may want to mention that in a note, though, to avoid ambiguities or questions.

I do not see any attributes for the script element that would/could affect the JSON-LD processing. I other words, I believe all other attributes can be ignored as far as JSON-LD is concerned. Which means that spec-ing all this does not look like an overcomplicated issue...

BigBlueHat · 2018-09-05T13:35:14Z

Relates to #57.

BigBlueHat · 2018-09-05T13:48:53Z

I do not see any attributes for the script element that would/could affect the JSON-LD processing. I other words, I believe all other attributes can be ignored as far as JSON-LD is concerned. Which means that spec-ing all this does not look like an overcomplicated issue...

I'm concerned that making the exterior "packaging" influence the "contents" that heavily introduces far too much overhead and confusion--especially when considering CMS and SEO usage where the same snippet of JSON-LD might be injected into multiple pages or even sites.

Also, with the exception of text direction, base and language already have their equivalences in JSON-LD, so the "can't edit HTTP headers" scenario doesn't apply for those.

iherman · 2018-09-05T14:02:45Z

I am not sure I understand the problem. Obviously, if the JSON-LD content has, e.g., a language setting, that overrules everything else. The issue is when this is not the case.

If an author includes JSON-LD via a script tag, I would think that she would expect, e.g., and explicit language setting to be valid for the metadata expressed in JSON-LD, too (unless explicitly stated otherwise in the metadata).

azaroth42 · 2018-09-17T21:58:30Z

I share @BigBlueHat's concerns about the scope of inclusions into the graph from the surrounding HTML as defaults, rather than by explicit reference. You would need to traverse the DOM all the way up, looking for lang and xml:lang attributes for each json-ld inclusion. That seems expensive, and outside of the scope of most JSON-LD processors.
Similarly, what about if I include a element in the HTML? Can I use that to override the base URI?

Can we split the effects of surrounding document structure off into a separate issue, and keep this one as the base URI only?

BigBlueHat · 2018-09-21T16:52:45Z

The HTML5 spec calls these "data-blocks" and says the following:

Setting the attribute to any other value means that the script is a data block, which is not processed. None of the script attributes (except type itself) have any effect on data blocks. Authors must use a valid MIME type that is not a JavaScript MIME type to denote data blocks.

Consequently, I'd suggest we avoid the intermixing of DOM parsing and unique-to-us data-block handling.

gkellogg · 2018-09-21T16:53:34Z

HTML5 pretty much shuts the door on using the DOM to interpret script elements (data blocks).

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

iherman · 2018-09-24T12:14:28Z

@BigBlueHat on #23 (comment) : that is not how I interpret this text. What it says is that the HTML spec is completely silent (as it should) what happens in that block. That does not mean that the specification for that specific mime type cannot specify what it wants.

In particular, the script DOM element, as all HTML DOM element, has its baseURI set. I do not see any spec issues defining the JSON-LD content to reuse that.

iherman · 2018-09-24T12:20:35Z

@azaroth42 per #23 (comment) : it is indeed actually strange to me that the DOM is specified in a way that, while the base URI (which is also to be calculated) is per definition available in the DOM element, this is not true for the language. I have the impression that this could be considered as a bug, but I would leave that to @r12a and his friends to decide...

While I do not consider the resulting extra calculation to be complex (the processor handling embedded JSON has, presumably, access to the DOM, because it has to find the script element; if so the rest is a simple recursion via the parentElement DOM attribute), I am fine separating the base URI and the language issues. My concern is to follow the DRY principle for the JSON-LD author who embeds this into an HTML file.

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

iherman · 2018-09-26T14:32:50Z

I have just read the resolution on the last WG call:

When establishing the base URI, use the document base URL only and ignore all surrounding data such as xml:base

and I must admit I would have voted -1, had I been at the call. I have already put my argument into #23 (comment) and I do not want to repeat them. Any JSON-LD processor that understands embedded JSON-LD have to do some level of HTML DOM parsing, and the DOM parser will provide the value of baseURI on the script element. There is no complication whatsoever using that value.

Although I admit it is rarely used, I would expect that the author of a document with embedded JSON-LD will be surprised that a <base> element in the header will not affect the relative URL-s of the embedded JSON-LD. This is not the expected behavior imho.

azaroth42 · 2018-09-26T15:41:34Z

WG resolution on call of 2018-09-21 was (indeed) to use the document base URL only and ignore all surrounding data such as xml:base.

The rationales included the data-block definition seeming to at the very least imply a clean separation, the additional requirements on processing regardless of how complex, and the perceived surprise of mixing data and presentational content.

azaroth42 · 2018-09-26T15:56:03Z

And now not as chair ...

Outside of the browser environment, parsing HTML into a DOM is a pain. A regular expression can find script tags in the HTML tag soup and extract those that have the right media type ... but then would not have the surrounding information beyond the tag and its contents. So it could get an attribute on the script tag, but it would be harder to find other elements, and very hard to process the tree to find the closest wrapping element with a particular attribute ... that would need a full DOM based stack.

The extent to which Benjamin's reading of the data-block specification is correct or not ... I think we could verify at TPAC. "None of the script attributes (except type itself) have any effect on data blocks." seems clear to me that regardless of what attribute values are set on the tag, the interpretation of the contents of the tag are not to be changed due to those values. Then the question is the extent to which embedded media types can assert dependence on the embedding media type rather than the other way round ... and I think we need to seek guidance on that.

I agree with Gregg that the principle of least surprise should be given due attention, and that's a very subjective issue. What is surprising to one person is intuitive to someone from a different background. In this situation I would defer to developers who want to create JSON-LD embedded in HTML ... for whom @danbri seems like the best proxy. Not to try and discuss everything at TPAC, but that seems like something else we could determine in person.

iherman · 2018-09-26T16:12:08Z

@azaroth42 yes, this is really something to be discussed at TPAC, ie, we should definitely not close the issue here.

Not as a staff contact:-) I believe using regular expression to extract the script tag is even more of a pain... having the right expression that avoid such pitfalls as having a

<title>this document is about the HTML script element</title>

may be tricky. I think that any decent programming environment these days have an HTML parser, ie, I would certainly not even dream about doing this in any other way than getting to the DOM (I did implement a Web Publication Manifest extractor and I just used a library to get this done. It was a breeze.)

Let us add this to the TPAC agenda...

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

…e about prospect of dynamically changing base. This reflects discussion from #23 (comment) and resulting TAG advice w3ctag/design-reviews#312 (comment).

…arate PR for #23.

BigBlueHat · 2018-11-13T21:44:33Z

So far we've mostly focused on <base href="..."> potentially being equivalent to {"@context": {"@base": "..."}} in the JSON-LD data document. However, if we do determine that <base href="..."> in the surrounding HTML does have an effect on the embedded JSON-LD's processing, then it's more likely consequence would be changing the processing around relative @context references (and possibly @vocab's calculation--see #72).

In other words <base> isn't equivalent to @base. It would effect a lot more plumbing.

azaroth42 · 2018-11-13T21:47:47Z

I don't see how that follows. The document space is different from the vocabulary space. Base affects the interpretation of the document space, but not the vocabulary space.

gkellogg · 2018-11-13T22:10:34Z

In light of #72, the vocabulary space is the document space (at least its relative to it). But, I believe, that in both cases it would be relative to any existing @base, which may itself be a relative URL.

azaroth42 · 2018-11-13T22:32:22Z

Sure, if via @vocab you set the default vocab space to the document space, then @base / will affect the vocabulary. Perhaps I was misreading @BigBlueHat, but I interpreted the comment that it would /always/ affect the vocab space.

iherman · 2018-11-14T10:28:31Z

I think one of the questions of @BigBlueHat is what would happen with the URL of a context file. Ie, what is the outcome of the following context if the url of the JSON-LD file is http://ex.com?

"@context" : [
    {
       "@base": "http://www.foo.bar"
    },
    "foo.context"
]
...

Will the linked context file be http://www.foo.bar/foo.context or http://ex.com/foo.context? Obviously, if it is the former, then a possible <base> would influence this, too (which does not shock me, b.t.w.).

As an aside: looking through the syntax document I have found only one example that uses an array of contexts like above (ex. 103) and I did not find any statement whether the context can be an absolute URI only or not. Actually, I have not found, through a search on @context and example of linking to an external context file. I think such examples should be added... and I am not sure about the formal spec on @context which does not seem to define that either...

gkellogg · 2018-11-14T18:29:32Z

@iherman from 3.2.1 of the Context Processing Algorithm:

Set context to the result of resolving value against the base IRI which is established as specified in section 5.1 Establishing a Base URI of [RFC3986]. ...

So, the linked context file would be http://www.foo.bar/foo.context.

This does have implications for setting base from HTML envelope, but that already exists for setting @base from an in-scope context. In such circumstances, authors should be encouraged to use absolute URLs for loading remote context files.

If we were to address this, it would require keeping separate notions of "base", and passing them into the context processing algorithm.

danbri · 2018-11-14T20:33:17Z

Slight aside, but do we all agree that URLs inside HTML inside JSON-LD inside HTML script sections are never going to get expanded with base URIs from the outer HTML?

i.e. no variations on this will expand 'here/' to a full URI:

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "description": "Click <a href='here/'>here</a> for bio."
}
</script>

BigBlueHat · 2018-11-14T20:51:12Z

@danbri unless that description is injected into the same page housing the <script type="application/ld+json">...in which case it's been "moved" I suppose. As a "dumb" value of a key, I'd not expect a JSON(-LD) processor to do anything of that sort.

gkellogg · 2018-11-14T21:26:09Z

@danbri In this case, the content is just a string, and I don't know anywhere that strings are processed as HTML, even if an rdf:HTML literal; the processing happens in RDF/XML or RDFa to perform the exclusive canonicalization when generating the literal; JSON-LD has no such rules.

Any other use as @BigBlueHat suggests is out of scope. Of course, if someone takes on the task of imbuing more intelligence for embedded JSON-LD (as suggested by @hadleybeeman in the TAG response), that might be another issue. In that case, it would likely be similar to any other but of JavaScript injecting HTML, which I presume would case the relative URL to be evaluated against the document base.

…in a separate PR for #23." This reverts commit 9f2ef52. # Conflicts: # index.html

iherman · 2018-11-16T18:11:38Z

This issue was discussed in a meeting.

RESOLVED: merge open HTML related PRs #93 and #68 and #50 after adding “At Risk” (or similar terminology) to present that things are not finalized

View the transcript

3. What is ‘base’ for embedded json-ld?
Ivan Herman: link: #23
Ivan Herman: Link of the PR: #93
Benjamin Young: #68
Gregg Kellogg: w3c/json-ld-api#50
Benjamin Young: we discussed that one at tpac
… we sent it in for TAG review, and they basically widened the scope
Gregg Kellogg: there are 2 open PRs
… 1) basic support for json-ld in html
… 2) PR-93 adds text to specifically add text to add html as base
… in the API spec, it’s PR-50
Adam Soroka: quick question, what are we expected to do with their comments?
… shall we respond?
Ivan Herman: what they propose is interesting but beyond our charter
… this would elevate json-ld
… but yeah beyond our charter
… I would say this is something the CG has to pick up
… and we can cross the bridge at some time, but if this is realistic from a manpower perspective I dont know
Benjamin Young: #68 (comment)
Ivan Herman: regarding the PR-93, there is some stuff about having XML
Benjamin Young: the thing I just linked shows how script tags affect html parsing
… it’s syntactically correct json-ld
Gregg Kellogg: what I did in the PR-68 I call out specifics on how to handle those blocks if the media type is application/json
… I think I’ve taken in the specifics on how content of script tags has to be handled and adjusted in for our needs
… we asked specific questions to TAG, got an answer but they kinda got a bit over enthusiastic
… out of this needs to come something that improves web platform
Benjamin Young: the HTML comments stuff as really bothered me since I’ve read it
… but it seems to primarily affect only HTML parsing
… question is how much of this we need to have in the spec
… json-ld in script tags vs “raw” json-ld
… both have totally different escaping rules and what not.. and none of that has something to do with html base
Ivan Herman: for the comment storing, the whole section is a normative thing
… I have the impression this is an HTML problem
… which we should certainly mention, but maybe not as part of a normative section
Benjamin Young: HTML5 spec level text about parsing <script> tags https://www.w3.org/TR/html5/semantics-scripting.html#restrictions-for-contents-of-script-elements
Ivan Herman: we should officially answer to the TAG and will officially add to the standard what they said about base
… and that we try to get the CG involved
Adam Soroka: +1
Gregg Kellogg: comments in html and escaping.. it depends on the encoding
… we don’t need to give guidance on how to handle this
Ivan Herman: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/68.html#ex-103-embedding-json-ld-in-html-with-comments
Ivan Herman: it has to be valid json-ld
… that’s invalid json
Gregg Kellogg: that’s something you see quite often
Benjamin Young: ivan: because https://www.w3.org/TR/html5/semantics-scripting.html#restrictions-for-contents-of-script-elements
Gregg Kellogg: comments are often used just to make sure there are no other issues embedded in the script elements that would cause any issues
Benjamin Young: I did quite some digging on that issue
… the DOM parsing is only concerned with what’s inside the tags
… it’s just treated as raw string
… if there’s something inside the json-ld an html parser would choke on
… the json-ld would need to be treated in such a way such that an html parser wouldn’t choke on it
Pierre-Antoine Champin: one crazy idea by looking at the json-ld embedded in html comments: you could add a js comment in front of the html comment, making it valid javascript
… it could become technically correct
Benjamin Young: sadly it wouldn’t
… it would continue being parsed
… we could make it our own parsing space
… the question is how far the parser gets before it finds the ending script tag
Gregg Kellogg: the json-ld would not be allowed to contain anything that could be interpreted as html and/or html comments
… not really feasible and also not helping our mission
… I’ve outlined multiple approaches to tackle this
… there are only a few cases where json-ld would contain things that resemble comments
Harold Solbrig: why is this an json-ld issue but not a javascript issue?
Gregg Kellogg: [explains why it isn’t]
Gregg Kellogg: it did some test cases for this, exploring corner cases we know of
… I don’t know how to move forward unless addressing at least some of the stuff from the PR
Gregg Kellogg: it describes script tags and data blocks are a subset
Benjamin Young: what’s breaking it, is the potential of one to too early close the script tag
… so this would need somehow being taken care of
… the risk is, the json-ld could contain content that jacks up the html it’s contained in
Ivan Herman: is it so horrible to say, if I put json-ld in a script tag I’m supposed to escape anything that html would need to have escaped
… thus a json-ld parser would have to do the unescaping
… but you are in HTML regardless.. so
Gregg Kellogg: for someone who’s actually looking at the source, those entities become rather annoying
Ivan Herman: realistically, I don’t know how often this would happen
Benjamin Young: the escaping issue is very similar of putting json-ld inside a text env.
Ivan Herman: I think it’s perfectly reasonable to accept both PRs, close the issue
… and open a new issue on the specific problem
Gregg Kellogg: it’s a editor’s draft not a working draft
Ivan Herman: we would open a issue right away
Benjamin Young: I would only +1 this, if we add a big red AT RISK disclaimer
Ivan Herman: a lot of very important things are pending for now
… I think it’s an edge case
Adam Soroka: I don’t think we should use a phrase like “AT RISK” but more something along the lines of “will be part of the final spec but might undergo some changes”
Ivan Herman: we cannot commit ourselves to having always consistent editor’s drafts
Benjamin Young: I’m not sure we have reached consensus on all the things contained
Gregg Kellogg: I cannot work on other open issues
Pierre-Antoine Champin: what about a parameter on the media type hinting at having to do unescaping? (like application/ld+json;escaped=html)
Proposed resolution: merge open HTML related PRs #93 and #68 and #50 after adding “At Risk” (or similar terminology) to present that things are not finalized (Benjamin Young)
Benjamin Young: +1
Adam Soroka: +1
Ivan Herman: what does “that” mean?
Gregg Kellogg: +1
Benjamin Young: I don’t want to have stuff merged without reaching consensus
… but I could live with having it marked as being “at risk” or similar
Ivan Herman: putting things that are already done “at risk” would be going backwards
… opening a new issue that highlights things that are still being discussed would be ok
… having the feeling that ~90% are done
Adam Soroka: I have to generally agree with ivan
Ivan Herman: +1
Adam Soroka: it seems for me very unlikely that we would stop talking about it
David Newbury: +1
Harold Solbrig: +1
Benjamin Young: I’m fine with merging those
Simon Steyskal: +1
Resolution #2: merge open HTML related PRs #93 and #68 and #50 after adding “At Risk” (or similar terminology) to present that things are not finalized
Pierre-Antoine Champin: +1

…e about prospect of dynamically changing base. This reflects discussion from #23 (comment) and resulting TAG advice w3ctag/design-reviews#312 (comment).

…arate PR for #23.

For w3c/json-ld-syntax#23.

iherman added the spec:enhancement label Jul 1, 2018

iherman mentioned this issue Jul 22, 2018

Setting the (text) direction w3c/wpub#220

Closed

gkellogg added a commit that referenced this issue Sep 23, 2018

Update the JSON-LD in HTML section to be normative, describe dataset …

df4157e

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

gkellogg mentioned this issue Sep 23, 2018

JSON-LD in HTML #68

Merged

gkellogg added a commit that referenced this issue Sep 24, 2018

Update the JSON-LD in HTML section to be normative, describe dataset …

1ac0921

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

gkellogg added a commit that referenced this issue Sep 24, 2018

Update the JSON-LD in HTML section to be normative, describe dataset …

36807ca

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

gkellogg added a commit that referenced this issue Sep 25, 2018

Update the JSON-LD in HTML section to be normative, describe dataset …

743d40d

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

gkellogg added a commit that referenced this issue Sep 25, 2018

Update the JSON-LD in HTML section to be normative, describe dataset …

087b6ef

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

gkellogg added a commit that referenced this issue Nov 5, 2018

Update the JSON-LD in HTML section to be normative, describe dataset …

5160552

…extraction, how to deal with multiple script elements and script element targeting using fragments. Fixes #23 and fixes #57.

gkellogg added a commit that referenced this issue Nov 7, 2018

Remove bits about resolving to HTML base element to be added in a sep…

9f2ef52

…arate PR for #23.

gkellogg added a commit that referenced this issue Nov 15, 2018

Revert "Remove bits about resolving to HTML base element to be added …

ca4c520

…in a separate PR for #23." This reverts commit 9f2ef52. # Conflicts: # index.html

gkellogg mentioned this issue Nov 15, 2018

Html base #93

Merged

gkellogg mentioned this issue Nov 16, 2018

Json ld in html w3c/json-ld-api#50

Merged

gkellogg closed this as completed in 4920d83 Nov 16, 2018

gkellogg added a commit that referenced this issue Nov 16, 2018

Remove bits about resolving to HTML base element to be added in a sep…

8c43f68

…arate PR for #23.

gkellogg added a commit to w3c/json-ld-api that referenced this issue Nov 27, 2018

Text and tests for using HTML base for embedded JSON-LD.

e5327b8

For w3c/json-ld-syntax#23.

gkellogg mentioned this issue Nov 27, 2018

Text and tests for using HTML base for embedded JSON-LD. w3c/json-ld-api#51

Merged

gkellogg added a commit to w3c/json-ld-api that referenced this issue Dec 1, 2018

Text and tests for using HTML base for embedded JSON-LD.

037b8e4

For w3c/json-ld-syntax#23.

iherman mentioned this issue Feb 6, 2019

Bunch of editorial issues, part II #127

Closed

13 tasks

gkellogg added a commit that referenced this issue Feb 15, 2019

Remove at-risk for issue #23.

ca24cd0

gkellogg added a commit that referenced this issue Feb 15, 2019

Remove at-risk for issue #23.

9953d15

llemeurfr mentioned this issue May 2, 2019

What is the origin of a packaged publication? w3c/pwpub#45

Open

azaroth42 added the satisfied Requirement Satisfied label Nov 18, 2019

danielweck mentioned this issue Jan 30, 2020

JSON base URL for resolving 'text' URL 'fragment' is base URL of HTML document specified as "alternate"? w3c/sync-media-pub#28

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

What is 'base' for an embedded json-ld? #23

What is 'base' for an embedded json-ld? #23

iherman commented Jul 1, 2018

iherman commented Jul 1, 2018

gkellogg commented Jul 1, 2018

iherman commented Jul 2, 2018

gkellogg commented Jul 2, 2018

iherman commented Jul 22, 2018

BigBlueHat commented Aug 3, 2018

BigBlueHat commented Aug 3, 2018 •

edited

Loading

gkellogg commented Aug 3, 2018

iherman commented Aug 4, 2018

BigBlueHat commented Sep 5, 2018

BigBlueHat commented Sep 5, 2018

iherman commented Sep 5, 2018

azaroth42 commented Sep 17, 2018

BigBlueHat commented Sep 21, 2018

gkellogg commented Sep 21, 2018

iherman commented Sep 24, 2018 •

edited

Loading

iherman commented Sep 24, 2018

iherman commented Sep 26, 2018

azaroth42 commented Sep 26, 2018

azaroth42 commented Sep 26, 2018

iherman commented Sep 26, 2018 •

edited

Loading

BigBlueHat commented Nov 13, 2018

azaroth42 commented Nov 13, 2018

gkellogg commented Nov 13, 2018

azaroth42 commented Nov 13, 2018

iherman commented Nov 14, 2018 •

edited

Loading

gkellogg commented Nov 14, 2018

danbri commented Nov 14, 2018

BigBlueHat commented Nov 14, 2018

gkellogg commented Nov 14, 2018

iherman commented Nov 16, 2018

What is 'base' for an embedded json-ld? #23

What is 'base' for an embedded json-ld? #23

Comments

iherman commented Jul 1, 2018

iherman commented Jul 1, 2018

gkellogg commented Jul 1, 2018

iherman commented Jul 2, 2018

gkellogg commented Jul 2, 2018

iherman commented Jul 22, 2018

BigBlueHat commented Aug 3, 2018

BigBlueHat commented Aug 3, 2018 • edited Loading

gkellogg commented Aug 3, 2018

iherman commented Aug 4, 2018

BigBlueHat commented Sep 5, 2018

BigBlueHat commented Sep 5, 2018

iherman commented Sep 5, 2018

azaroth42 commented Sep 17, 2018

BigBlueHat commented Sep 21, 2018

gkellogg commented Sep 21, 2018

iherman commented Sep 24, 2018 • edited Loading

iherman commented Sep 24, 2018

iherman commented Sep 26, 2018

azaroth42 commented Sep 26, 2018

azaroth42 commented Sep 26, 2018

iherman commented Sep 26, 2018 • edited Loading

BigBlueHat commented Nov 13, 2018

azaroth42 commented Nov 13, 2018

gkellogg commented Nov 13, 2018

azaroth42 commented Nov 13, 2018

iherman commented Nov 14, 2018 • edited Loading

gkellogg commented Nov 14, 2018

danbri commented Nov 14, 2018

BigBlueHat commented Nov 14, 2018

gkellogg commented Nov 14, 2018

iherman commented Nov 16, 2018

BigBlueHat commented Aug 3, 2018 •

edited

Loading

iherman commented Sep 24, 2018 •

edited

Loading

iherman commented Sep 26, 2018 •

edited

Loading

iherman commented Nov 14, 2018 •

edited

Loading