Sarven isn't here.

(Sarven isn't here today)

Skipped

Sarven: No response from the WG but they are working on our feedback.

Hadley: Should we mark it pending external feedback?

Sarven: Yes. It also doesn’t need to be in the agenda.

Hadley: We marked it done for resolution, but we aren’t done with it yet?

Sarven: Ok, so the N-triples is ambivalent.

Hadley: Ok, I would like the resolution tag off. Do you want to post a nudge to wake them up?

Sarven: I know they have a PR coming up.

Hadley: Ok, I see it in their comment.

Sarven: I think it is fine.

Hadley: Changed the progress label to “pending external feedback.”

Sarven: We closed the 'concepts' one recently. Now we're looking at what to do with this last one. The group is asking, based on changes they made, can they close the issue. I left a comment just before this call. My concern... I think they went on in this 'versioning' direction, but because of the way RDF is designed, it doesn't have clear error handling descriptions for implementations.

RDF 1.2 introduces some backwards-incompatible changes. 1.1 processors, when they encounter some of the new features, who knows what's going to happen. In reality implementations are decent, but on paper it's not good. The concern I had for the concepts issue is that they did some updates to it, but they didn't respond back to our concerns about implementations that can't handle this stuff. They said they'd fix it in the concrete syntax. We also raised the concerns more concretely. When we look at the N-Triples they touch on it, but not in a way that addresses our concerns.

... I don't know what would be an appropriate TAG response... we told them what we think they should consider. Unless we think that they really need to address this? Not sure where to draw the line.

Jeffrey: I think you're raising important concerns and I think you're right that they've not adequately addressed them. The case of the 1.1 parser running into 1.2 data is really important on the web. We publish the data, we can't control which clients see it. So you need some sort of negotiation. But the MIME type solution wouldn't work becuase old things are not going to be looking at the version part. If new things are required to send the header, maybe that's a solution.

Yves: It's way more complicated than that due to CDNs etc that are not likely to change.

Jeffrey: So if they're not doing the negotiation, they need to handle this in some content way, and it seems they're not. And this is not acceptable for a format on the web, in my opinion.

Sarven: So how do we resolve this? I don't want to repeat what we said either.

Jeffrey: Their reply on the concepts review says they'd rather get that comment on the individual format reviews, so repeating si the right thing to do. The question is whether we are unsatisfied, or satisfied with concerns.

Sarven: The original comment in the concrete one, we did link back to the original review and said 'take this into account'

Yves: It's up to them whether they want to break things or not. We have our opinion bu they are making an informed choice, so it should be 'satisfied with concerns'

Jeffrey: I'm wanting to make sure that we're looking at this from a web format architectural perspective - if you are a web format, forwards compatibility is very important. This design constraint is not something that people who are at the bleeding edge of their domain, working with up to date parsers might be considering.

Matthew: Another aspect of this is we don't know how much in practice the damage will be, but they might not be able to predict the damage either, because we don't know how many 1.1 parsers are out there that can't be upgraded. This could be 'unsatisfied' because we're concerned that this will break things over the web. If we don't have data saying 'all parsers can be upgraded it's fine', then in practice it could be a real problem. Did we suggest or tell them that they shoudl just have a new MIME type, because the semantics are different?

Sarven: 1.2 isn't introducing something that the 1.1s aren't equipped to handle. Even without 1.2, 1.1 can encounter any random thing, and they'll be in the same situation. The version thing being in the payload isn't a new problem category. They'll behave in the same way. 1 possibility is that because they have this new feature written down, there may be a path for 1.1s or their owners to upgrade published data. On the media type, the concern was that in the ecosystem, there are so many different ways of having RDF syntax, so introducing another one makes the Accept headers way too long. Gets the applications into CORS. Concerns about having too many media types. Application shouldn't need to include too many. That's part, but not the whole reason. It's been discussed.

Sarven: quoting RDF 1.2 Turtle https://w3c.github.io/rdf-turtle/spec/#sec-version :

 This allows parsers that do not support these features to detect      the presense of such features early, and potentially       inform the user, giving them an opportunity to stop the job      or otherwise act on the fact that some amount of the input data       will not be processed as desired.    

Matthew: Everything you said, I accept. But we've had this discussion a few times. I'm sure we had a call where we agreed that there would be a difference in output in 1.1 vs 1.2 parsers over the same document, so it's a semantic fork. If that's correct, it's problematic. Think we should double-check.

Sarven: Isn't that point in the comment I wrote?

Matthew: Might be.

Jeffrey: If we are valuing things differently, we can say, 'we're not convinced by your response; here's our opinion; do what you will' and they can carry on. We don't have to figure out ourselves whether there is this semantic fork. We can ask them to figour out what will happen between parsers and document versions.

... I feel like we should flag that this is a big concern. Sarven is the domain expert here, so if you feel this is only a 'satisfied with concerns' level of concern I'm OK with that - but we should let them know.

Sarven: Highlighting a sentence in the spec: [LINK]

Jeffrey: I think that would have been adequate if that had been there from the beginning, but now they have a pile of 1.1 parsers that don't expect that versioning parameter, and they need to think about what is going to happen when they get unexpected data.

Sarven: But this isn't introducing a new problem to 1.1s. Becuse 1.1 doesn't have that strict way of handling unknown features. That's no different to the ones with this version thing. The problem exists without 1.2 in the picture.

Jeffrey: I think you're saying that the forwards compatibilty is that 1.1 parsers drop data they don't understand, so 1.2 lines in a file will be ignored. I think that's a reasonable answer if that's what the WG says is the forward compatibility story.

Sarven: That was our reasoning as to what the situation is. I suggest they tighten the language in the sentence I just read. I'll leave a draft comment in the private thread.

Jeffrey: Please leave the comment and we can review. Satisfied with concerns sounds like the direction. Can do async.

Sarven: Noted Matthew's and Jeffrey's comments after my draft. I'll try to re-capture / draft the (new) concerns or things that need a clarification.

Jeffrey: I wanted to ask for our sense of how much to push on this. 1.2, at least Turtle and N-Triple formats are backwards-incompatible (they add new grammar that older parsers won't understand). The behaviour when finding unkown things is undefined. My impression from Sarven is that parsers vary. The WG has a statement in 1.2 that says parsers reject new syntax, but I'm not sure how correct it is. If they reject new syntax, that's like CSS. But in an RDF context, maybe that's the wrong behavior. The WG has not addressed these questions - they have simply said it's not a problem.

Lola: They've not said why?

Jeffrey: Pretty much; they've not discussed it with us. So do we trust them, or do we push on this?

Matthew: It's such a low-level technology, concerned about the ramifications. If it's not a problem, can't they convince us? Parroting Martin's concern about how changeable the parsers are in the wild.

Lola: Agree, also concerned. Could we invite them to a plenary?

Christian: +1. We have the same thing when we discussed the new PNG adjustments. The new formats there, and we had the exact same concerns. We should apply the same logic. Ask them to make sure this transition can work.

Lola: I can't make the next plenary but can someone invite them?

Jeffrey: Yes, I can.