Skip to content

XHTML support in HTML script extraction #244

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

Closed
ByteEater-pl opened this issue Dec 12, 2019 · 8 comments
Closed

XHTML support in HTML script extraction #244

ByteEater-pl opened this issue Dec 12, 2019 · 8 comments

Comments

@ByteEater-pl
Copy link

The spec contains special handling for text/html resources. Lack of application/xhtml+xml seems an unfortunate omission.

@gkellogg
Copy link
Member

XHTML is no longer an actively maintained specification (marked superseded now), so is not specifically mentioned. Neither is HTML4. However, JSON-LD should embed just fine in either, although there may be some considerations for how to encode script content.

@azaroth42
Copy link
Contributor

Propose close, intentionally omitted.

@ByteEater-pl
Copy link
Author

ByteEater-pl commented Dec 12, 2019

XHTML is no longer an actively maintained specification (marked superseded now), so is not specifically mentioned.

The HTML 5.2 spec contains the IANA registration of the application/xhtml+xml MIME type [1].

However, JSON-LD should embed just fine in either, although there may be some considerations for how to encode script content.

I was referring to HTML script extraction [2]. The current spec seems to make it work only for content served as text/html and gratuitously not with application/xhtml+xml.

[1] https://www.w3.org/TR/html52/iana.html#application-xhtmlxml
[2] https://www.w3.org/TR/json-ld11-api/#dfn-html-script-extraction

@ByteEater-pl ByteEater-pl changed the title XHTML support XHTML support in HTML script extraction Dec 12, 2019
@iherman
Copy link
Member

iherman commented Dec 13, 2019

This issue was discussed in a meeting.

  • RESOLVED: We accept that syntax and api should also refer to XHTML where they refer to text/html
View the transcript 4.1. XHTML vs HTML
Rob Sanderson: #244
Rob Sanderson: gkellogg objected that XHTML is not an active spec
… but the author or the issue noted that application/xhtml+xml is one of the content-types specified for HTML 5.2
Ivan Herman: my initial reaction was the same as gkellogg, but the latest argument is compelling
Rob Sanderson: https://www.w3.org/TR/json-ld11-api/#dfn-html-script-extraction
Ivan Herman: but since both content-types are for the same format,
… all we have to do is add “or ‘application/xhtml+xml’” whenever we mention ‘text/html’
… Also, epub still refers to XHTML.
Gregg Kellogg: my concern was that XHTML 1.0 would use different encoding for scripts.
… If this is just about accepting ‘application/xhtml+xml’ for HTML5, this is not a problem.
… I would rather not wait on this thing. It is easy to get lost.
Ivan Herman: if we want to republish something between now and end of CR,
… this is borderline to substantial change.
Gregg Kellogg: we will have the same problems with other issues.
Ivan Herman: many things that will come up are hopefully editorial.
Rob Sanderson: given the other issues, we will probably want to update the CR.
… considering this is day 1, and we already have a list of issues and associated PRs.
Ivan Herman: we are not talking about going back to WD.
… but we need to go to the director again if we make non-substantial changes.
Gregg Kellogg: last week we resolved that changes in the text of the algorithms
… that does not change the result of any test suite,
Gregg Kellogg: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-06-json-ld#resolution3
Gregg Kellogg: would be considered editorial.
Rob Sanderson: but surely we were referring the existing test suite
Gregg Kellogg: dlehn proposed to add new tests, to address some corner cases
… I thing resolution3 is about “not changing the result of any existing test”
Proposed resolution: We accept that syntax and api should also refer to XHTML where they refer to text/html (Rob Sanderson)
Gregg Kellogg: +1
Ivan Herman: +1
Rob Sanderson: +1
Harold Solbrig: +1
Pierre-Antoine Champin: +1
David I. Lehn: +1
Benjamin Young: +1
Resolution #2: We accept that syntax and api should also refer to XHTML where they refer to text/html

@iherman
Copy link
Member

iherman commented Dec 14, 2019

Reopening this; better to keep it open until the changes are done in the document.

@iherman iherman reopened this Dec 14, 2019
gkellogg added a commit that referenced this issue Dec 18, 2019
It MAY be added on requests, and MUST be handled in responses.

For #244.
@gkellogg
Copy link
Member

@ByteEater-pl, please indicate if the change in #250 adequately addresses your concerns.

@ByteEater-pl
Copy link
Author

It does, thanks.

gkellogg added a commit that referenced this issue Dec 19, 2019
It MAY be added on requests, and MUST be handled in responses.

For #244.
gkellogg added a commit that referenced this issue Dec 19, 2019
It MAY be added on requests, and MUST be handled in responses.

For #244.
gkellogg added a commit that referenced this issue Dec 19, 2019
It MAY be added on requests, and MUST be handled in responses.

For #244.
@iherman
Copy link
Member

iherman commented Dec 20, 2019

This issue was discussed in a meeting.

  • RESOLVED: Close completed editorial issues API#242, #243, #244, #245, #246
View the transcript Close editorial issues
Proposed resolution: Close completed editorial issues API#242, #243, #244, #245, #246 (Rob Sanderson)
Ruben Taelman: +1
Gregg Kellogg: +1
Ivan Herman: +1
Pierre-Antoine Champin: +1
Jeff Mixter: +1
Tim Cole: +1
Rob Sanderson: +1
Adam Soroka: +1
Resolution #9: Close completed editorial issues API#242, #243, #244, #245, #246

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants