<bigbluehat> scribenick: timCole

<bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-11-30-json-ld

Approve Minutes

bigbluehat: Any questions or corrections?
... it doesn't say what group Telco these are, also missing chair name

ivan: I will take care of it

bigbluehat: Chair was me last week

Announcements

<bigbluehat> 2019 Spring Face-to-Face - February 7-8 (Thursday & Friday) in Washington, DC

Adam: we have location and rooms, will get that out very soon
... we got a room in Smithstonian castle
... will get recommendations about hotels, but location is downton DC on National Mall

<ivan> https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit -> F2F meeting page

ivan: I have prepared a file for f2f
... so Adam, you can put info in this google doc
... will make sure everybody have edit access

<ivan> https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit?usp=sharing -> roght address

<gkellogg> https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit?usp=sharing

Call schedule for the remainder of 2018

bigbluehat: As far as I know we have 14 Dec., but do we need either of the next 2 weeks (21 & 28)?
... I will be unavailable those 2 weeks
... does anyone need a call on either of those days?

gkellogg: May not be available either date. Not sure yet.

bigbluehat: sounds like we should skip 21 & 28 and restart on 4 January

ivan: do we keep 4 January?
... let's do 4th, drop 28 dec and not sure about 21 dec

<pchampin> for what it's worth, I'll probably be unavailable on the 21; and surely on the 28

bigbluehat: will query the list about 21 dec and 4 jan

Recent Changes / Merges

bigbluehat: Greg please summarize these

<gkellogg> https://github.com/w3c/json-ld-syntax/issues/56

gkellogg: issue 56 - this was looking for examples to indicate unexpected behavior when type is a vocab
... i think ball was in Ivan's court whether the examples were sufficient
... we are not closing the issue until after the PR, so question is whether we are ready to close
... we added 2 examples
... next issue is 77, disambiguate uses of @type
... Webex seems to have some problems with this meeting, especially if changing focus on my computer
... we discussed adding @datatype, instead decided to add text around different uses of @type
... are people satisfied with wording?

bigbluehat: summarize one more and then we'll pause

gkellogg: use of @none regarding language
... in seeming conflict with requirement that language has to be string, @none didn't specify
... fixed that wording making clear that @none has to be a string

bigbluehat: these are tagged proposed closing
... we need to decide if ready to close

ajs6f: I wanted to mention the @datatype issue - I'm okay with this, but we may need a gitHub tag for whenever issues about @type comes up
... this will be a way to verify that spec wording update is enough to minimize confusion

<gkellogg> https://github.com/w3c/json-ld-wg/issues/24

gkellogg: I did raise issue 24 about surfacing the minutes on this topic like we did in Community Group
... could we do this?
... was useful in community group

ivan: minutes cleanup is done by me, and summarizing each meeting may not be a good idea

gkellogg: there is a scribe tool that builds summaries and indexes automatically

bigbluehat: it works on issues and action lists at top/bottom of each meeting minutes

gkellogg: the good thing is it aggregates all minutes on each issue

bigbluehat: I will take an action to investigate to see if we can build index of minutes by issue
... I think this is a good idea

gkellogg: will work with bigbluehat on this since I worked on CG

bigbluehat: can we close these 3 issues
... 56, 77 and 102

ivan: can we do a resolution to close these 3 issues?

<bigbluehat> PROPOSE: close issues 56, 77, and 102 as having been addressed by recent merges

<ivan> +1

<gkellogg> +1

+1

<bigbluehat> +1

<workergnome> +1

<pchampin> +1

RESOLUTION: close issues 56, 77, and 102 as having been addressed by recent merges

<bigbluehat> https://github.com/w3c/json-ld-syntax/issues?q=is%3Aissue+is%3Aopen+label%3A%22propose+closing%22

bigbluehat: one more propse closing to consider, issue 76
... it's marked as out of scope.

gkellogg: no editorial work has been done on this

bigbluehat: we'll put on agenda for next meeting (dec 14)

<bigbluehat> Sub-Topic: Remove the need for wrapping comment-open/comment-close text in data blocks

<bigbluehat> https://github.com/w3c/json-ld-syntax/pull/97

gkellogg: most of these are related to PRs just discussed, but not all

<gkellogg> https://github.com/w3c/json-ld-syntax/issues/96

bigbluehat: current draft talks now about html entities for escaping

gkellogg: given that it has to be valid json-ld, how do we deal with escaped entities
... leaves us with problem of how to represent <script> tags and comments in json?

bigbluehat: one option is to mark propose closing and discuss more later

gkellogg: DanBri involved and noted in discussion (of this or another related issue 100)

<bigbluehat> PROPOSE: close #97 as fixed with recent merges; other issues raised in #100

gkellogg: so we could close 97 and leave 100 for further discussion

<gkellogg> +1

<workergnome> +1

+1

<bigbluehat> +1

<ivan> +1

RESOLUTION: close #97 as fixed with recent merges; other issues raised in #100

<bigbluehat> Sub-Topic: Text and tests for using HTML base for embedded JSON-LD

<bigbluehat> https://github.com/w3c/json-ld-api/pull/51

bigbluehat: this one is about how to resolve urls are resolved, e.g., how html base is used

<gkellogg> https://github.com/w3c/json-ld-syntax/issues/23

gkellogg: the associated issue is 23, which we have closed
... this does not deal with referencing html for context and that should stay a separate issue

bigbluehat: does anyone want to write up this other issue - Adam volunteered

<bigbluehat> Sub-Topic: Text and tests for using HTML base for embedded JSON-LD

bigbluehat: any issues about recent merge

<bigbluehat> https://github.com/w3c/json-ld-api/pull/51

<bigbluehat> Sub-Topic: Clarify IRI compaction

<bigbluehat> https://github.com/w3c/json-ld-api/pull/52

gkellogg: PR 52 resolves issue 75
... based on previous discussion, I did use autoclose on this

Pending PRs

bigbluehat: last chance for anyone to raise questions about this PR

<bigbluehat> Subtopic: Clarify that language map values of `@none` are strings

<bigbluehat> https://github.com/w3c/json-ld-syntax/pull/104

bigbluehat: hearing none, we will move on
... 104 is about clarifying the language map and use of @none

gkellogg: this is like the one discussed earlier
... giving Rob a chance to comment

bigbluehat: would love people raising questions / comments between calls, but want to provide opportunity on calls as needed

Issues

bigbluehat: we need to better relate PRs and issues being closed

<bigbluehat> Subtopic: Handling HTML character references in embedded JSON-LD

<bigbluehat> https://github.com/w3c/json-ld-syntax/issues/100

bigbluehat: so far most of work has been Greg and Dan

gkellogg: this is a relatively narrow issue - we should solve by not resolving html entities in the API
... the narrow use case is script tags and comments
... so we should document by clarifying in spec language but not resolving the html entities
... if an html embedded in json (which is inside a script tag) closes the script tag, then rest of json will be treated as body
... in theory you can end up embedding javascript
... I suggest we document and say don't do this
... and leave browser to defend against this

bigbluehat: agree this seems not our problem
... people who put end script tag in their json-ld will find that they've broken their html
... if people need to escape character entities, they'll do, but it will become an html issue not our problem
... while we don't want to avoid edge cases, this still doesn't seem to be our issue
... but would love to her back from Dan on this
... just add note that you could disrupt html parsing by doing this and leave it at that

ajs6f: I don't want to minimize the security concern, but since this is coming from server side, it seems not as threatening
... not as bad from accepting user input

gkellogg: I would propose that we close this issue and remove all except a non-normative caution note
... that data block should remain valid
... I don't anticipate anything different on this from schema.org
... this removes some text from API doc and maybe some changes in syntax document where we currently talk about how to escape

<bigbluehat> PROPOSE: close #100 with note about authoring concern related to HTML charcters and </script> and remove existingtext on JSON-LD processors handling character encodings

<gkellogg> +1

+1

<bigbluehat> +1

<ivan> +1

<ajs6f> +1

<workergnome> +1

<pchampin> +1

RESOLUTION: close #100 with note about authoring concern related to HTML charcters and </script> and remove existing text on JSON-LD processors handling character encodings

<bigbluehat> Subtopic: Introduce concept of "sealed" contexts

<bigbluehat> https://github.com/w3c/json-ld-syntax/issues/20

bigbluehat: Digital Bazar has weighed in with more of their use cases that break

ajs6f: A meta comment - Digital Bazar has been producing interesting and valueable use cases
... can we get someone from Digital Bazar to join an upcoming call

dlehn: I'm here but not ready to volunteer on this issue

bigbluehat: We need to get some more time and get additional folks from Digital Bazar
... other thoughts?

<bigbluehat> Subtopic: Allow @type for @none in Language Maps

<bigbluehat> https://github.com/w3c/json-ld-syntax/issues/91

bigbluehat: hearing nothing now, please keep working on this issue on GitHub
... Idea with 91 is that there is no way to fall back to HTML, which international has suggested is best way to deal with language issues

gkellogg: issue is to allow non-string values, for which a value object without type might be one option, and opening that door allows almost anything
... that ruins the normality, and not sure it helps the use case
... seems you'd be more likely to use either all language tags or all html literals

ivan: i think you should either close or defer - this issue did come up in pub wg
... their concern is a bit convulted to talk about
... when I wrote it down, I got a private message that they didn't really like this solution (right after TPAC)
... pinged them 2 days ago.
... the result may be that in JSON and JSON-LD this issue can not be done perfectly, and we should be cognizant of perfect is the enemy of the good
... title element seems one place where this could come up, but title doesn't allow html text
... we should avoid being more catholic than the pope

ajs6f: mostly agreeing with what's been said
... a pattern of string, string, string, complex stuff, string, string is not good

<ajs6f> +1

<workergnome> +1

ajs6f: goes against trying to keep json-ld in line with expectations

pchampin: i agree that this is a strange use case, but regardless i posted a solution that works in dev playground
... having 2 distinct properties, one accept a string, one a language map

bigbluehat: similar to Annotation and Social WG for some of their specs

pchampin: a little more cumbersome

<bigbluehat> PROPOSE: close #91 as wrong solution for the right problem

ajs6f: the kind of thing pchampin is offering seems a good option, can we open an issue to generate examples

<ivan> +1

<bigbluehat> +1

<gkellogg> +1

<pchampin> +1

ajs6f: this is a pattern that could be confusing, we should offer best practices

+1

<workergnome> +1

<ajs6f> +1

RESOLUTION: close #91 as wrong solution for the right problem

ivan: can I close after transferring comments to issue?

bigbluehat: yes
... adjourn

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/ ext/text/
Present: bigbluehat gkellogg ivan ajs6f pchampin timCole David_Lehn workergnome
Regrets: azaroth jeff
Found ScribeNick: timCole
Inferring Scribes: timCole
WARNING: Could not parse date.  Unknown month name "12": 2018-12-07
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)