16:29:10 <RRSAgent> RRSAgent has joined #json-ld
16:29:10 <RRSAgent> logging to https://www.w3.org/2020/01/24-json-ld-irc
16:29:13 <Zakim> RRSAgent, make logs Public
16:29:14 <Zakim> please title this meeting ("meeting: ..."), ivan
16:29:26 <ivan> Date: 2020-01-24
16:29:26 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jan/0016.html
16:29:26 <ivan> ivan has changed the topic to: Meeting Agenda 2020-01-24: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Jan/0016.html
16:29:27 <ivan> Chair: azaroth
16:29:27 <ivan> Meeting: JSON-LD Working Group Telco
16:29:27 <ivan> Regrets+ tcole
16:30:10 <azaroth> azaroth has joined #json-ld
16:45:50 <pchampin> pchampin has joined #json-ld
16:56:40 <pchampin_> pchampin_ has joined #json-ld
16:57:44 <gkellogg> gkellogg has joined #json-ld
16:58:19 <rubensworks> rubensworks has joined #json-ld
16:59:40 <gkellogg> present+
16:59:56 <rubensworks> present+
17:00:00 <azaroth> present_
17:00:02 <azaroth> present+
17:00:05 <ivan> present+
17:00:30 <pchampin_> present+
17:00:54 <ajs6f> ajs6f has joined #json-ld
17:02:21 <azaroth> scribenick: rubensworks
17:02:25 <azaroth> chair: azaroth
17:02:38 <azaroth> TOPIC: Approve minutes of previous call
17:02:48 <azaroth> PROPOSAL: Approve Minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-17-json-ld
17:02:49 <gkellogg> +1
17:02:50 <azaroth> +1
17:02:51 <rubensworks> +0
17:02:52 <pchampin_> +1
17:02:59 <azaroth> RESOLVED: Approve Minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2020/2020-01-17-json-ld
17:03:07 <bigbluehat> present+
17:03:09 <azaroth> TOPIC: Announcements / Reminders?
17:03:10 <ivan> +1
17:03:18 <pchampin_> q+
17:03:21 <azaroth> ack pchampin_
17:03:53 <dlongley> present+
17:04:32 <rubensworks> gkellogg: JS implementation from digitalbazaar is close to 100% for everything but framing.
17:05:13 <rubensworks> ... Treatment of entities in script elements is difficult with dom parser. So this will be difficult to get spec-compliant.
17:05:39 <rubensworks> azaroth: Will there be difficulties for all JS implementations?
17:05:42 <dlongley> q+ to support adding at risk
17:05:45 <azaroth> ack dlongley
17:05:45 <Zakim> dlongley, you wanted to support adding at risk
17:05:55 <rubensworks> dlongley: I would propose adding at-risk.
17:06:17 <ivan> q+
17:06:21 <gkellogg> jsonld.js PRs https://github.com/digitalbazaar/jsonld.js/pulls
17:06:21 <azaroth> ack ivan
17:06:26 <azaroth> q+ to ask about 1.0 vs 1.1
17:06:32 <rubensworks> ... Browsers may not be able to do what we want to do. Different behaviour may be allowed if such difficulties are encountered.
17:06:42 <rubensworks> ivan: XML entities in script elements are the problem?
17:07:19 <rubensworks> gkellogg: Script elements should be unaltered. XML Entities inside script elements are typically decoded by parsers at the moment. But we don't want that to happen.
17:07:51 <hsolbrig> hsolbrig has joined #json-ld
17:07:57 <hsolbrig> present+
17:08:06 <azaroth> q?
17:08:11 <rubensworks> ... One way to handle JSON-LD in script tags would be to escape them, but we don't want to escape them. According to what ivan said, we want script elements to remain unaltered.
17:08:40 <dlehn> present+
17:08:50 <azaroth> ack azaroth
17:08:50 <Zakim> azaroth, you wanted to ask about 1.0 vs 1.1
17:08:52 <rubensworks> ... We could encourage authors to not include such entities in script elements.
17:09:15 <rubensworks> azaroth: This is new in 1.1, so this is not a backwards-incompatibility. So we can change this as we want.
17:09:24 <gkellogg> action: gkellogg to create issue for ATRISK of entities within HTML script elements.
17:09:47 <rubensworks> azaroth: Shall we make it at-risk now? Or wait to see if we can solve it.
17:10:20 <bigbluehat> q+
17:10:21 <rubensworks> q+
17:10:27 <ivan> q+
17:10:31 <azaroth> ack bigbluehat
17:10:55 <bigbluehat> https://github.com/digitalbazaar/jsonld.js/pull/347
17:11:14 <rubensworks> bigbluehat: The PR gkellogg is for jsonld.js. Is this code running in the browser?
17:11:43 <ivan> q-
17:12:09 <azaroth> q?
17:12:10 <rubensworks> gkellogg: Testing envir mostly node. The use case within a browser is not considered in this PR.
17:12:22 <dlongley> q+
17:12:50 <rubensworks> gkellogg: The browser may have different interfaces. Should be reconsidered for this use case.
17:13:06 <rubensworks> bigbluehat: Schema.org parsing by chrome is done using headless browser.
17:13:36 <dlongley> the DOM APIs are what probably matter here: https://dom.spec.whatwg.org/#dom-node-textcontent
17:13:43 <azaroth> scribe+
17:13:45 <azaroth> ack rubensworks
17:14:22 <azaroth> rubensworks: to mention the parser I use, it's HtmlParser2. I have not looked at this problem yet. It's possible that I do not have the issue. Wondering if there are tests for this case already to see
17:14:25 <azaroth> gkellogg: Yes
17:14:44 <azaroth> ...  if you look at the PR, one of the changed files is test common, and shows a couple of commented out tests for this
17:14:50 <azaroth> (okay handing back)
17:14:55 <azaroth> s/(okay handing back)//
17:15:10 <azaroth> q?
17:15:18 <bigbluehat> q+
17:15:21 <azaroth> ack dlongley
17:15:42 <azaroth> +1 to writing to the spec :D
17:16:16 <rubensworks> dlongley: People should be writing the parsers to what the specs say. Whathever we ask should be compatible with the spec. So it's important to know if xmldom is spec-compliant.
17:16:19 <azaroth> q?
17:16:35 <azaroth> q+ to ask who can find out
17:16:36 <rubensworks> gkellogg: The specs may not specifically talk about this.
17:16:39 <azaroth> ack bigbluehat
17:16:46 <ajs6f> present+
17:16:55 <rubensworks> bigbluehat: Do we provide any guidance on getting text out of script element?
17:17:12 <rubensworks> gkellogg: There's a section in the API spec on that.
17:17:36 <azaroth> q?
17:17:39 <azaroth> ack azaroth
17:17:39 <Zakim> azaroth, you wanted to ask who can find out
17:18:02 <rubensworks> azaroth: Is someone willing to do the research on what the spec says that should happen?
17:18:18 <bigbluehat> q+
17:18:21 <azaroth> ack bigbluehat
17:18:46 <rubensworks> bigbluehat: The linked section only talks about HTML spec, not DOM spec. So we may look into that.
17:19:31 <azaroth> q?
17:19:39 <rubensworks> bigbluehat: I can look at it this afternoon.
17:20:48 <azaroth> q?
17:20:54 <rubensworks> azaroth: The Greggs have worked together, and now the pearl implementation for expansion passes all of the tests. He will now work on compaction, so expect new issues on that.
17:21:13 <pchampin_> s/pearl/Perl/
17:21:42 <dlongley> +1 to macros
17:21:45 <rubensworks> gkellogg: There was a fairly large rewrite of the compaction algorithm, which was an improvement.
17:21:47 <azaroth> TOPIC: Issues
17:22:00 <azaroth> SUBTOPIC: Normalize language tags
17:22:05 <azaroth> link: https://github.com/w3c/json-ld-api/issues/337
17:22:31 <rubensworks> azaroth: This is about our workaround language tags in i18n namespace.
17:23:12 <rubensworks> gkellogg: We removed requirements to normalize language tags to lowercase, because it is problemantic for many people in i18n community. When creating RDF, we have possibility that 2 processors create different data types.
17:23:43 <ivan> q+
17:23:47 <azaroth> ack ivan
17:23:50 <rubensworks> ... The question is if that is what we intended. To allow 2 diff datatypes by 2 different processors.
17:23:58 <rubensworks> ivan: That would be wrong in terms of RDF.
17:24:19 <rubensworks> ... If you have 2 datatypes with different cases, RDF sees those as not equal.
17:24:30 <rubensworks> ... Maybe pchampin_ will say I'm wrong...
17:24:31 <azaroth> ack pchampin_
17:25:27 <rubensworks> pchampin_: I slightly disagree. 2 different URLs may denote different things, but also the same, but this depends on implementation.
17:25:47 <rubensworks> ... It's hard to require all impls to support these different i18n datatypes and consider them equal.
17:26:13 <rubensworks> ... We could say that they are semantically equivalent.
17:26:18 <azaroth> q+ to ask about the i18n issue
17:26:31 <rubensworks> ivan: Yes, we can do that. I don't know if we are discussing something that is insignificant.
17:26:53 <rubensworks> ... If we do that, and have an implementation that does datatype reasoning, then that impl will likely fall on its face.
17:27:29 <rubensworks> ... Datatype reasoning is quite a challenge. Many implementations just check char-by-char.
17:28:06 <rubensworks> ... We could say that if you use these datatypes, that you are supposed to lowercase language tags.
17:28:07 <azaroth> ack azaroth
17:28:07 <Zakim> azaroth, you wanted to ask about the i18n issue
17:28:15 <rubensworks> ... It's ugly, but I don't see a better choice.
17:28:26 <rubensworks> azaroth: Is there some i18n requirement?
17:28:44 <rubensworks> ivan: No, it's a habbit that there is mixing of cases.
17:29:03 <rubensworks> ... Usual way is:
17:29:09 <ivan> the usual way is : en-US and not en-us
17:30:15 <pchampin_> q+
17:30:20 <rubensworks> ... We should not require normalization when using lang tags the old way, but we should when using i18n datatypes.
17:30:49 <rubensworks> azaroth: Is the set of characters that is permissable in URIs and language tags compatible?
17:30:57 <rubensworks> ivan: Just ASCII characters.
17:31:01 <azaroth> ack pchampin_
17:31:33 <rubensworks> pchampin_: There will be 2 kinds of RDF impls: ones not recognising our custom IRIs, and those that do.
17:32:12 <rubensworks> ... Those that will take into account our custom datatypes, can interpret them as lang tags and do smart things.
17:32:31 <azaroth> q?
17:32:34 <rubensworks> ... The roundtripping would be lost when direction is used. I'm still in favour of not normalizing them.
17:32:34 <gkellogg> q+
17:32:36 <azaroth> ack gkellogg
17:32:58 <rubensworks> gkellogg: I'm neutral on normalization. We should add a non-normative note in any case.
17:33:17 <azaroth> q?
17:33:18 <dlongley> q+
17:33:20 <azaroth> ack da
17:33:23 <azaroth> ack dlongley
17:33:39 <rubensworks> dlongley: Was it a mistake to not normalize language tags when they were invented?
17:33:40 <azaroth> q+ to agree with dlongley
17:33:48 <rubensworks> ivan: Invented by whom?
17:34:03 <azaroth> ack dlongley
17:34:14 <rubensworks> dlongley: Not JSON-LD, but the group that came up with it 30 years ago...
17:34:17 <dlongley> q+
17:34:23 <rubensworks> ivan: We can not change it because it's out there already.
17:34:40 <rubensworks> azaroth: We can fix it for reduced datatype IRI.
17:34:42 <ivan> q+
17:34:49 <azaroth> ack azaroth
17:34:49 <Zakim> azaroth, you wanted to agree with dlongley
17:34:51 <azaroth> ack dlongley
17:35:13 <rubensworks> dlongley: It looks like this grew organically, so the spec was built around it.
17:35:24 <gkellogg> q+
17:35:29 <rubensworks> ... What we introduce is new, so we can enforce normalization.
17:35:36 <azaroth> ack ivan
17:35:40 <rubensworks> ... So we simplify part of the space.
17:35:45 <rubensworks> ivan: I don't disagree.
17:35:57 <rubensworks> ... How important is it to roundtrip on such a detail?
17:36:02 <azaroth> q+
17:36:05 <rubensworks> ... Because that is why we are discussing this.
17:36:15 <rubensworks> ... I don't think it's important.
17:36:23 <gkellogg> From RDF Concepts: "A literal is a language-tagged string if the third element is present. Lexical representations of language tags may be converted to lower case. The value space of language tags is always in lower case."
17:36:25 <rubensworks> ... So I would normalize it.
17:36:28 <azaroth> q?
17:36:29 <azaroth> ack gkellogg
17:36:49 <rubensworks> gkellogg: We did change the language of JSON-LD, which always normalized language tags, which was over-strict.
17:37:10 <rubensworks> ... RDF spec says that language tags *may* be lowercased.
17:37:44 <rubensworks> ... We are talking here about special case: roundtripping.
17:37:59 <rubensworks> ... It's a minor thing what we are going to do.
17:38:14 <azaroth> ack azaroth
17:38:23 <rubensworks> ... I would support that we change the language in toRdf, that language tags be normalized in compound literals and i18n.
17:39:01 <rubensworks> azaroth: We ran into this in practise when having to do case-insensitive language tag comparison.
17:39:32 <azaroth> PROPOSAL: In toRDF recommend normalization of language tag based URIs
17:39:39 <pchampin_> +1
17:39:40 <azaroth> +1
17:39:41 <ivan> +1
17:39:42 <bigbluehat> +0
17:39:43 <gkellogg>  +1
17:39:43 <dlongley> +1
17:39:44 <rubensworks> +1
17:39:44 <hsolbrig> +0
17:39:53 <dlehn> +1
17:40:01 <ajs6f> +1
17:40:18 <azaroth> RESOLVED: In toRDF recommend normalization of language tag based URIs
17:40:31 <azaroth> PROPOSAL: ... also compound literal form
17:40:32 <azaroth> +1
17:40:35 <pchampin_> +1
17:40:35 <rubensworks> +1
17:40:35 <dlongley> +1
17:40:38 <gkellogg> +1
17:40:42 <ajs6f> +1
17:40:47 <azaroth> RESOLVED: ... also compound literal form
17:40:47 <ivan> +1
17:40:51 <dlehn> +1
17:40:54 <bigbluehat> +1
17:41:16 <azaroth> SUBTOPIC: Boolean comparison issue
17:41:18 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/323)
17:41:42 <rubensworks> azaroth: Last week, we concluded that we should fix 323.
17:42:19 <rubensworks> pchampin_: The value of the JSON value type should not be a structured representation of JS object, but canonical form of JSON representation.
17:42:49 <rubensworks> ... We have our own canonic process. But this was marked as non-normative. I think this should be marked as normative.
17:42:51 <ivan> q+
17:42:57 <azaroth> ack ivan
17:42:58 <gkellogg> q+
17:43:18 <rubensworks> ivan: Yes, I agree.
17:43:44 <rubensworks> ... You avoided canonicalization term, which is a good idea.
17:43:58 <azaroth> PR: https://github.com/w3c/json-ld-syntax/pull/325
17:44:20 <rubensworks> ... There is a small part that needs to be changed.
17:44:50 <rubensworks> pchampin_: I did change it.
17:44:57 <rubensworks> ivan: I may have missed something then.
17:45:03 <azaroth> q?
17:45:21 <rubensworks> pchampin_: Currently lexical value should be re-serialized.
17:45:22 <azaroth> ack gkellogg
17:46:03 <rubensworks> gkellogg: Reason it was non-normative was JSC was still in draft.
17:46:37 <rubensworks> ... Object keys are ordered by converting them by UTF16 may be controversial.
17:46:52 <azaroth> q?
17:47:01 <pchampin_> q+
17:47:20 <azaroth> ack pchampin_
17:48:14 <rubensworks> pchampin_: We should update the API doc as a copy of the normalization text in processing document.
17:48:31 <rubensworks> gkellogg: We should also change the test descriptions.
17:48:32 <ivan> q+
17:48:42 <azaroth> ack ivan
17:48:58 <rubensworks> ivan: Also the API doc currently repeats the canonicalization steps, and we should refer to the proper place.
17:49:14 <gkellogg> q+
17:49:22 <rubensworks> ... We will get a similar situation as with language tags, where we can not fully guarantee roundtripping.
17:49:28 <azaroth> ack gkellogg
17:50:07 <rubensworks> gkellogg: Yes. Ordering of keys in our case is just lexicographical, while JSC is much more detailed with localization concerns.
17:50:17 <azaroth> q?
17:50:22 <azaroth> PROPOSAL: Update api document to be in line with syntax for json datatype, test descriptions, and "canonicalization" algorithm
17:50:25 <rubensworks> ... Not including that in syntax doc would not be sufficient for interoperation.
17:50:58 <gkellogg> +1 (modulo key ordering)
17:50:59 <pchampin_> +1
17:50:59 <azaroth> ... modulo key ordering
17:51:00 <dlongley> +1 modulo gregg's comments
17:51:01 <azaroth> +1
17:51:01 <rubensworks> +1
17:51:01 <hsolbrig> +1
17:51:03 <ajs6f> +1
17:51:07 <bigbluehat> +1 modulo gregg's comments
17:51:10 <ivan> +1
17:51:19 <azaroth> RESOLVED: Update api document to be in line with syntax for json datatype, test descriptions, and "canonicalization" algorithm (modulo key ordering)
17:51:28 <dlongley> (it is important to match JCS ... and hope it sticks in the future)
17:51:38 <azaroth> SUBTOPIC:  Confusing context URL handling,
17:51:49 <azaroth> link: https://github.com/w3c/json-ld-api/issues/265
17:52:09 <rubensworks> azaroth: We concluded that the change would be good, but was too big.
17:52:22 <rubensworks> ... Now that we dropped out of CR, we should discuss whether the change is useful.
17:52:34 <rubensworks> ... Should we do that now?
17:53:00 <rubensworks> ... gkellogg, will this be an editorial change that doesn't need a resolution?
17:53:08 <rubensworks> gkellogg: It will change the algorithm signature.
17:53:28 <rubensworks> ... We need a way to keep track of the resolved context URL to use when resolving future context URLs.
17:53:41 <ivan> q+
17:53:54 <rubensworks> ... It impacts the places that call it to pass a value around.
17:54:03 <azaroth> ack ivan
17:54:20 <rubensworks> ivan: If you change the parameters, how many implementations will have to change?
17:54:45 <rubensworks> gkellogg: We don't change tests. Implementations do not have to follow the algorithm exactly.
17:55:02 <rubensworks> ivan: Does anyone else next to kasei follow the spec exactly?
17:55:40 <rubensworks> ... Do we know if we are affecting anyone else?
17:56:00 <rubensworks> gkellogg: This was behaviour that was expected in 1.0.
17:56:16 <rubensworks> ivan: If you do this change, do the implementation of Ruben and Dave have to change.
17:56:40 <rubensworks> q+
17:57:06 <rubensworks> rubensworks: I don't follow the algorithm.
17:57:11 <dlongley> agree with gregg, i don't think we need to change anything in JS
17:57:13 <gkellogg> q?
17:57:22 <rubensworks> q-
17:57:24 <azaroth> PROPOSAL: Add text to api to clarify the need for tracking of base IRIs during context processing
17:57:29 <ivan> +1
17:57:29 <gkellogg> +1
17:57:30 <azaroth> +1
17:57:30 <rubensworks> +1
17:57:32 <dlongley> +1
17:57:36 <bigbluehat> +1
17:57:36 <hsolbrig> +1
17:57:38 <ajs6f> +1
17:57:39 <azaroth> RESOLVED: Add text to api to clarify the need for tracking of base IRIs during context processing
17:57:40 <ivan> q+
17:57:42 <pchampin_> +1
17:57:43 <azaroth> ack ivan
17:57:54 <azaroth> TOPIC: AOB
17:58:02 <azaroth> SUBTOPIC: New CR timing?
17:58:28 <rubensworks> gkellogg: Probably would take 4 weeks from last week.
17:58:29 <hsolbrig> q+
17:58:51 <rubensworks> ... kasei working on framing should give us enough time.
17:59:05 <azaroth> q+ re framing
17:59:17 <rubensworks> ... So around Februari 14th, or 21st.
17:59:43 <azaroth> ack hsolbrig
17:59:46 <rubensworks> ivan: We have to go through the whole charade, so it will take a while.
17:59:54 <rubensworks> gkellogg: So we start of 17th.
18:00:15 <rubensworks> ivan: Ok, so that would mean the end of February.
18:01:08 <rubensworks> hsolbrig: Is there any wording that I can say that even though JSON-LD is not a CR yet, I can use it safely without things changing?
18:01:34 <azaroth> ack azaroth
18:01:34 <Zakim> azaroth, you wanted to discuss framing
18:01:42 <rubensworks> ivan: You can say that there is no intention to change the technical content, but we may find bugs in the spec.
18:01:51 <rubensworks> hsolbrig: Ok, that's what I need.
18:02:12 <rubensworks> azaroth: For framing, I will require kasei's time during office hours, after compaction.
18:02:23 <azaroth> q?
18:02:29 <rubensworks> ... So he will probably not do an implementation, just a review.
18:03:06 <azaroth> TOPIC: Adjourn
18:03:18 <ivan> zakim, end meeting
18:03:18 <Zakim> As of this point the attendees have been gkellogg, rubensworks, azaroth, ivan, pchampin_, bigbluehat, dlongley, hsolbrig, dlehn, ajs6f
18:03:20 <Zakim> RRSAgent, please draft minutes
18:03:20 <RRSAgent> I have made the request to generate https://www.w3.org/2020/01/24-json-ld-minutes.html Zakim
18:03:23 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
18:03:27 <Zakim> Zakim has left #json-ld
18:03:47 <ivan> rrsagent, bye
18:03:47 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2020/01/24-json-ld-actions.rdf :
18:03:47 <RRSAgent> ACTION: gkellogg to create issue for ATRISK of entities within HTML script elements. [1]
18:03:47 <RRSAgent>   recorded in https://www.w3.org/2020/01/24-json-ld-irc#T17-09-24