Manu Sporny: we'll be talking about the plan for PR and an update from gregg on implementation reports
Sandro Hawke: my email probably raised some things we should discuss
Manu Sporny: yeah, the first item on the agenda will cover that
Manu Sporny: the argument for not going through another LC/CR, etc.
Topic: Plan for Proposed Recommendation
Manu Sporny: the last time we talked about this, we thought we were pretty close to going to PR, the blocker was RDF-CONCEPTS still being in LC
Manu Sporny: from what i gather, it was discussed on the RDF WG call and the proposed path forward is to wait for RDF-CONCEPTS to go to CR and then we can move JSON-LD specs to PR
Sandro Hawke: it's not exactly clear when RDF-CONCEPTS will be ready to move forward, it's possible we may make that discussion tomorrow, it's due to a bunch of comments
Sandro Hawke: i think we'll have a formal objection from Jeremy Carroll
Gregg Kellogg: that's with semantics, not concepts
Sandro Hawke: they go together
Gregg Kellogg: if we move concepts first we can prevent JSON-LD from getting blocked
Sandro Hawke: i think they are both clear to go ahead, there will be some loose ends, my guess is it won't be tomorrow but probably two weeks
Gregg Kellogg: so a matter of a couple of weeks
Manu Sporny: the RDF WG charter is up in december
Manu Sporny: is it going to extended?
Sandro Hawke: no
Sandro Hawke: as long as we get to PR by the end of the december
Manu Sporny: there are no big blockers other than Jeremy Carroll's FO, but that will be resolved because the group will continue ahead
Sandro Hawke: yup
Manu Sporny: ok, thanks
Manu Sporny: so we'll go into a holding pattern until RDF-CONCEPTS goes into CR
Markus Lanthaler: we need to talk about Promises
Manu Sporny: yes, that's next, we still need to talk about the issues that sandro raised
Manu Sporny: whether or not we're going to make the API non-normative per the issue-at-risk comment, etc.
Topic: How to refer to Promises
Manu Sporny: if we make the section non-normative we still need to reference some spec out there
Markus Lanthaler: the problem is there is no specification at the moment, we could use a reference to the DOM spec, but we know that won't be the final spec, eventually it's going to end up directly in ECMAScript (JS spec)
Markus Lanthaler: up until a week ago i didn't see any mentions in the spec
Markus Lanthaler: the hope is that it will be published in december
Markus Lanthaler: google has an implementation but doesn't ship until, i think, november
Markus Lanthaler: i don't know the state in firefox
Markus Lanthaler: it's up in the air in the moment
Sandro Hawke: i think for non-normative, i think we could reference the historic DOM spec of it, we could say, specifically, we know this isn't the final thing, but for now this is what people can use and when something better comes along they should switch to it, there should be no procedural blocker
Sandro Hawke: i think we just need to point at something that developers can read and be clear about it
Markus Lanthaler: are there any restrictions as far as W3C is concerned?
Sandro Hawke: if it's not a W3C spec, it's more of a judgment call about how stable it is, there's no clear way to say what is a stable spec from somebody else
Markus Lanthaler: it would mean... even if we had an ecmascript draft we could argue it's stable enough, because, for example, chrome already implemented it
Sandro Hawke: if we had an ecmascript draft and it was implemented in chrome and firefox and we could go ahead with a normative reference, it would be a bit of stretch, but we could argue that, the ecmascript spec being ready in december may not actually happen
Sandro Hawke: we have a little bit of slack because of these other docs (concepts, and semantics) so we could just wait until then and there's an ecmascript draft by december 1st then we can use it
Manu Sporny: i just asked Anne which draft we should reference
Niklas Lindström: "To the extent possible under law, Domenic Denicola has waived all copyright and related or neighboring rights to promises-unwrapping."
Manu Sporny: this isn't ecmascript, this is a doc in the public domain
Sandro Hawke: what i heard was that dom's employer has some copyright claim to that text and hasn't been willing to do the appropriate paperwork
Manu Sporny: we could use a pointer to a specific version of it
Markus Lanthaler: scroll to the bottom, the document says: "To the extent possible under law, Domenic Denicola has waived all copyright and related or neighboring rights to promises-unwrapping. This work is published from: United States ."
Manu Sporny: the assumption we're making is that github will be around for at least 3 years, and at that point hopefully we'll have another link we can reference
Sandro Hawke: if the link happens to break it becomes a matter of archeology and people should be able to deal with that
Sandro Hawke: digital bazaar or somebody could checkout that repo and make it available on the web
Sandro Hawke: i haven't looked at the license
Sandro Hawke: it could just be that ecmascript has a really high bar on that
Manu Sporny: he's put it into the public domain and if google didn't want to do that, but i have no idea what google would want to come in and establish copyright over something going into ecma
Sandro Hawke: do you want me to go ahead and ask w3c's lawyers if we can make a copy of that
Manu Sporny: sure, you could ask
Sandro Hawke: normally we're happy to take the employee as clicking somewhere as sufficient
Sandro Hawke: we use their own word for it
Sandro Hawke: i'll do that
Manu Sporny: thanks
Markus Lanthaler: it looks like dom is not working for google
Markus Lanthaler: if the api would stay normative, would it change anything in regards to that linking?
Sandro Hawke: to stay normative we would need to clear up the legal thing about this text and then argue that it is stable because of implementations, for instance, in chrome and firefox
Markus Lanthaler: but it's not a problem per se
Markus Lanthaler: it's not disallowed to link to something like this, for example
Sandro Hawke: it's not strictly disallowed, no
Sandro Hawke: we'd just have to make the argument that the technology is stable
Sandro Hawke: if we can copy the text to our site then the text won't change and then it's just whether or not the technology is stable
Manu Sporny: i'm guess that it's going to happen soon w/ecmascript, but maybe not before we need it to happen
ACTION: Sandro to ask W3C legal about archiving Promises spec at W3C.
Manu Sporny: ok and we'll just refer to that doc if we can
ACTION: Manu to outline path forward for Promises reference to RDF WG and get input from W3C Director on the path forward.
Topic: Does non-normative API require another LC?
Manu Sporny: if the change is from normative to non-normative do we need to do another CR/LC, etc
Manu Sporny: sandro raised the point that we could make the argument that we don't need another LC, i thought we had predicted that this might happen and we put in spec text so we wouldn't have to go through another round
Manu Sporny: markus, is that spec text is in there?
Manu Sporny: saying the API could become non-normative
Markus Lanthaler: no, we just said that the reference might change
Sandro Hawke: we put an at-risk warning in there, but we phrased it as we might change the reference, we didn't include that we might take the whole API and make it non-normative
Markus Lanthaler: if it's somehow possible it would really make sense to keep the API normative, i'm not a big fan of making it non-normative
Sandro Hawke: i think we can only do that if we really have 2 implementations
Manu Sporny: a generous reading of the at-risk marker would be to say ... one way to refer to a spec that lives elsewhere is to make the reference non-normative and refer to it
Manu Sporny: if we had said in this feature at-risk marker, "this section might become non-normative as a result of us trying to figure out how to refer to a spec outside of the w3c" then we'd be fine
Manu Sporny: however that spec text does not exist, what i'm looking for is some text in this spec is to see if we can change the spec in the way we need to
Manu Sporny: i think the language hints at us needing to do something other than just updating the reference
Sandro Hawke: because we have that at-risk we have some argument
Sandro Hawke: i think the change we want to make is covered by that, it's not literally covered by that, but it's close enough, and i think we want to try to make that argument, and if we get push back we can do another LC, but we really don't want to do that
Sandro Hawke: to make that case, i think ralph, acting as director on this, will ask if it will invalidate any reviews
Sandro Hawke: is there anyone who is going to be unhappy about this change
Manu Sporny: i think the answer to that is no
Manu Sporny: i don't think any changes to implementations will happen
Sandro Hawke: i think the only people who would be unhappy about this would be people thinking strategically who want it normative, but they'd also understand that this was a change we'd have to make
Sandro Hawke: ideally we should gather some comments from people
Sandro Hawke: as evidence
Sandro Hawke: have we gotten any comments from anyone about Promises
Manu Sporny: we have lots of comments from industry about Promises, we could collect comments from people about Promises, saying Promises are a good thing and a good direction to go
Manu Sporny: the question is, would that helpful because we're creating something non-normative here
Sandro Hawke: i don't think that's particularly helpful
Sandro Hawke: so normally, the director doesn't make decisions until you have the meeting
Sandro Hawke: and we're waiting a couple weeks for those references
Sandro Hawke: we could try to have the transition now and wait a couple weeks and fix the references, but in case the answer is no, we want to have time for LC
Manu Sporny: could you get ralph to look at this to get an answer
Manu Sporny: i could write an email asking if it's ok with RDF WG and point ralph at it, and ask if it was fine to go into the transition meeting like that
Sandro Hawke: i'd like to get a binding yes or no from him, we don't want it to change later
Sandro Hawke: ok, you write that email
Sandro Hawke: i'm thinking that we should try to get a WG resolution from that tomorrow
Sandro Hawke: the other thing that ralph cares a lot about is whether or not the WG has discussed it and come to a resolution
PROPOSAL: Make the JSON-LD WebIDL API non-normative and refer to the Promises specification written by Domenic Denicola and proceed straight to Proposed Recommendation.
Manu Sporny: +1
Gregg Kellogg: +0.5
Sandro Hawke: +1
Paul Kuykendall: +1
Dave Longley: +1
Markus Lanthaler: +0.1
David I. Lehn: +0
Niklas Lindström: +0
Sandro Hawke: why the weak support? [scribe assist by Sandro Hawke]
Gregg Kellogg: I just wish there were a way to keep it normative [scribe assist by Sandro Hawke]
Niklas Lindström: (I don't feel properly informed to judge the strategic effects of either route)
Gregg Kellogg: I think it's unfortunate that this can't be a normative section, but understand that this is the best of available solutions [scribe assist by Gregg Kellogg]
RESOLUTION: Make the JSON-LD WebIDL API non-normative and refer to the Promises specification written by Domenic Denicola and proceed straight to Proposed Recommendation.
Manu Sporny: could the non-plus-1's explain why?
Manu Sporny: gregg wants it to be normative but doesn't see how we could do that
Markus Lanthaler: with making it non-normative it will be impossible to build applications on top of the API in an interoperable way [scribe assist by Markus Lanthaler]
Gregg Kellogg: it's useful to note that we don't actually have any tests that use Promises, my implementation doesn't implement them and i think other ones don't as well
Gregg Kellogg: it's really narrow, for JS in particular
Sandro Hawke: has someone done the editorial change, is it all of the API?
Sandro Hawke: so it's just how you talk to the algorithms that becomes non-normative
Sandro Hawke: all the at-risk stuff has to come out before we go to PR
Manu Sporny: yeah, that's unfortunate, so maybe next week we will go through all of those and then pass it off to the RDF WG
Sandro Hawke: as long as the CG is unanimous about all of them we'll probably sign off on them
Sandro Hawke: in the WG
Paul Kuykendall: is there a way for us to have preliminary info on which way the at-risk markers will go
Manu Sporny: the risk with doing that is that people will start debating them
Topic: Removing at risk markers from JSON-LD specs.
Manu Sporny: at great length
Manu Sporny: ok, we have resolutions on a lot of these
Manu Sporny: i think we have a generalized RDF flag for blank nodes in the property position
PROPOSAL: Allow blank nodes to be used as graph name or property.
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Markus Lanthaler: this is feature at risk 3
David I. Lehn: +1
Niklas Lindström: (given the "use-generalized-rdf" set to true (default is false) for blank nodes as properties)
Sandro Hawke: +1
RESOLUTION: Allow blank nodes to be used as graph name or property.
Niklas Lindström: .. which is the case. :)
Sandro Hawke: if we can point to public comments for each of these it would be the strongest way forward
Dave Longley: We do want to make sure that if the RDF WG sees this that they understand that there is a use_generalized_rdf flag [scribe assist by Manu Sporny]
Markus Lanthaler: i think the list of lists at-risk marker we didn't resolve completely
PROPOSAL: Support conversion of lists of lists to list objects by preserving the blank node head of the inner list. This resolves feature-at-risk #4 in the JSON-LD API specification.
Manu Sporny: +1
Markus Lanthaler: +1
Dave Longley: +1
Paul Kuykendall: +1
David I. Lehn: +0
Gregg Kellogg: +1
Niklas Lindström: +1 (better than dropping them)
Sandro Hawke: +1
RESOLUTION: Support conversion of lists of lists to list objects by preserving the blank node head of the inner list. This resolves feature-at-risk #4 in the JSON-LD API specification.
Manu Sporny: we've had a number of JSON-LD authors about having @type having a different meaning
Manu Sporny: based on context
Manu Sporny: we've had several different discussions about renaming it in different contexts, but it hasn't really gone anywhere, with a little explaining it seems like people are ok with it as is
Manu Sporny: can we make a 2-3 sentence editorial change before we go to PR?
Sandro Hawke: as long as it's just editorial and particularly if it's responding to a comment it's fine
Paul Kuykendall: i think reading a tutorial will easily cover this
PROPOSAL: Make an editorial update to the JSON-LD specification to clarify that the @type keyword is context sensitive and make its various usages more clear in the specification. This addresses issue at risk marker #9 in the JSON-LD syntax specification.
Manu Sporny: +1
Paul Kuykendall: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +0.9
Dave Longley: +1
David I. Lehn: +1
RESOLUTION: Make an editorial update to the JSON-LD specification to clarify that the @type keyword is context sensitive and make its various usages more clear in the specification. This addresses issue at risk marker #9 in the JSON-LD syntax specification.
Manu Sporny: Ok, we also need to talk about @base: null. I think consensus is that we keep it. Object if you disagree.
PROPOSAL: Keep the @base: null feature in the JSON-LD specification as it is defined in the Candidate Recommendation specification.
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Sandro Hawke: +1
David I. Lehn: +1
Niklas Lindström: +0 (I cannot really judge the effect on usability)
Markus Lanthaler: +0
RESOLUTION: Keep the @base: null feature in the JSON-LD specification as it is defined in the Candidate Recommendation specification.
Markus Lanthaler: neither do I
Manu Sporny: ok, so if we can get that raised in the RDF WG call tomorrow
Gregg Kellogg: i may not be on the call tomorrow
Sandro Hawke: ideally, if you can send an email nowish right after this call it can be on the agenda
ACTION: Manu to send an email to RDF WG stating that all issue markers are resolved.
Topic: Updated Implementation Report
Manu Sporny: pkuyken got a C# implementation report in
Gregg Kellogg: it's in the comprehensive report now as is rdflib from niklasl
Gregg Kellogg: and jsonld-java
Gregg Kellogg: it's 100% except for a couple of tests they didn't cover
Dave Longley: is it ok that some implementation reports haven't gone to public-rdf-comments but only to public-linked-json
Sandro Hawke: either is fine
Gregg Kellogg: minus some sporadic errors i think we're showing broad support for a variety of platforms
Manu Sporny: yeah, thanks to all implementors
Sandro Hawke: probably me. I don't think I hung up properly.
Markus Lanthaler: the current status keeps @index nodes
Gregg Kellogg: do we have a test?
Markus Lanthaler: yes, and it keeps it
Niklas Lindström: if you use @index it's probably computed from some other value in the node
Markus Lanthaler: the only reason to perhaps drop it is to be more consistent
Manu Sporny: do we have spec text that covers this
Markus Lanthaler: i would argue it's just a bug fix
Gregg Kellogg: it would require implementations to change and removing a test and adding another one and asking for updated implementation reports
Manu Sporny: the alternative is that we say nothing about it, and after we put the spec out we can make these changes
Niklas Lindström: i'm in favor of keeping it, i could imagine some implementation using it
Niklas Lindström: it could, in theory, be destroying information in some strange algorithm outside of what we've specified
Niklas Lindström: i'm in favor of keeping the nodes which is the current behavior and it might support some unforeseen behavior
PROPOSAL: When processing free-floating nodes, if there is an @index keyword in the node, it is not a free-floating node.
Manu Sporny: +0.7
Markus Lanthaler: +0.5 (not entirely consistent IMO but I'm fine with it and don't feel strongly about it)
Dave Longley: +1
Gregg Kellogg: +1
David I. Lehn: +0
Paul Kuykendall: +0 Not enough understanding of the problem
Niklas Lindström: +0.5
RESOLUTION: When processing free-floating nodes, if there is an @index keyword in the node, it is not a free-floating node.
Niklas Lindström: It might be good to tell people using toRDF that blank node properties could be created. [scribe assist by Manu Sporny]
Dave Longley: They shouldn't be surprised as they have to use the flag to generate them... it's off by default. It would be fine to mention it in the spec. [scribe assist by Manu Sporny]
PROPOSAL: Clarify the at-risk #10 feature in the specification by stating that if the use generalized RDF flag is set, then the toRDF algorithm could generate blank node properties.
Dave Longley: "Setting @base to null will prevent relative IRIs to be expanded to absolute IRIs." should be changed to "Setting @base to null will prevent relative IRIs from being expanded to absolute IRIs."
Manu Sporny: +1
Gregg Kellogg: +1
Gavin Carothers: would that solve your need? [scribe assist by Niklas Lindström]
Gregg Kellogg: [[[A generalized RDF triple is an RDF triple generalized so that subjects, predicates, and objects are all allowed to be IRIs, blank nodes, or literals.]]]