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.

(Skipped.)

JY: the issue or question is around the RDF 12. versioning could work it's unclear from the document how it works There is no description for how the ecosystem system should adjust and how servers and clients should deal with that how do you expect the ecosystem to handle updating to the new version

PC: RDF 1.2 is an incremental change with two new features the data model is not unchanged it is still expected that the new RDF 1.2 data should still work with old clients There was consensus in the WG that this is ok. There was question in the goup about whether we should create a new media type, but we decided not to.. Because the new version is still backwards compatible so server can still signal they are 1.2 So clients can still keep processing "RDF" even if they don't know about the new features As the media type does not distiguish between the two should still continue to work on old clients So the old client may signal an erros even though they don't know what to do with the new format RDF doesnt define what to do when a feature is unknown by the client RDF's fallback model is not the same as HTML in that sense. The behavior is undefined.

BK: You said that the WG chose not to create a new media type, but I didn't understand that you'd articulated why - I'm interested as to hearing the rationale for the choice

PC: Imagine the ?? format that is based on RDF. This format could sever the 1.2 media type Content media is not always an option Some clients will use the new feature but others won't There are situations where the server will serve the new media type, but that would cut off the old clients So the rationale is to not to damage the ecosystem, as we don't want old clients to fail on the new media type

OL: This is somewhat polical, but I wonder what will happen if we split the world between RDF 1..1 and 1.2 There is going to be significant cost and we don't know what that is going to be

JY: We are trying to understand the implications in the range of options: will it drop the unknown properties? Will it just work? will it ignore the whole file? We would like for you to document what will happen, as the WG knows the ecosystem best

SC: the TAG feels the right solution is to send a new media type. Given the capabilities, it's can be a new media type because of the new constructs in 1.2. So there's a bit of a mismatch, because if the old clients can't parse the 1.2 then that could be a problem since it is a different format. So, what's acceptable to keep and throw out. In 1.1 it was ok to igore it... it might cause the client to crash. But that's not defined in the spec. If the media type is text/turtle, then there's an expectations for clients for what they are going to get.

SC: the working group is in the best postions to guide the TAG here because we (TAG) don't know what the impacts are going to be. So we are wondering form the group. For the TAG, the new media type is the logical solution here, but maybe the WG is in the best position to make a call here. If the concepts explain the landscape well enough, but we didn't get that from reading the spec - that's why we find ourselves here to resolve that.

Marcos: There are hard lessons to be learned about ... HTML used to be very loose, and that lead to security issues, which is why you see strict enforcement of contect types. Need to watch out. Ora mentioned that we don't know what's going to happen to the clients. The documents don't say what will happen. Something bad could happen, and making the breaking change is important to consider. If clients start behaving differently, could be a problem. If there's something semantically important, and the new properties change the semantics, and trhe clients don't understand that. There's not defined fallback model, while in HTML there's a very defined fallback model. Core part of HTML is that the user comes first. Different from XML approach, where a broken tag makes parsing fail. In web platform ecosystem we moved away from that for HTML, while JS breaks entirely with bad syntax. For the end user, who suffers when they can't read the 1.2 syntax?

Ted: Not one new media type; ~ten new media types, one per existing serialization. Note that this problem was largely created by the hubris of previous Working Groups (and their reviewers) who were encouraged to think, "this will be the only version of this, ever."

Ted: The previous editors thought there wil only ever be a single version of RDF. This WG was not chartered to make breaking changes. So there is a risk of blowing the scope of the WG.

Ora: my worry is about the adopting. It's taken a long time RDF getting adopted and I don't want to put up new hurdles for adoption. RDF is used in a lot of enviromments where media types don't always pay a role, so that's not clear to me. So I'm unsure about the forward compatabilty story. So we are unsure what the original editors were thinking about when it comes to future compatibity. We don't know what the damage is going to be if we add the new media type.

Pierre: to answer some of the questions. Sarven, I would call back to the damage to the ecosystem, and I hear you acknowledge that. To Jeffrey, we try to address the server concerns in the spec itself. In some cases the server won't care. There are cases where server does care where it uiltimately what goes to the client so we do have a way to provide an alternative way to encode the new properties so it's 1.1 compatbile. So servers that care can downgrade the data to be 1.1 compatible. To Marcos' point, there are very generic syntaxes, with a generally very low level of semantcs. For things like digital identity, when RDF is used, it is used with a media type and that's a good thing. The ideal model is that RDF is processor neutral, but people people point out that is not the case. But the spec say that it is.

JY: You could require new clients to send 1.2 parameters. That would mean that servers are supposed to send 1.2 things in response.

PC: we did some testing and we found it wasn't an issue.

JY: If they define how clients behave when they see an undefined triple or if they should drop the whole client, then at least future clients will have a specified behavior model.

YL: I was going to say the same thing. If you define the breaking change model now, then future version of the spec will be covered as new clients are implementing the breaking change. So that gives you an out in the future.

OL: I like what Yves said. It might be good to be the people that fix it now for the future WG. People are supposed to upgrade things for security reasons.

JY: are we TAG ok with keeping the old media type?

Andy: one of the justifications for putting the breaking change behavior is to protect ourselves to the future. In turtle, it's a parser error. So there they can cope by erroring. So turtle doing error recovering is non-conforming. So, it can behave like HTTP error correction might, what do you do with junk data, etc.

JY: If you say the whole file must be dropped, that reasonable. I didn't see that in the spec.

Andy: it might be a "sin" so you might end up dropping data.

Marcos: I'm ok with it if there's evidence about the error recovery. You've described the fallback model: if someone sends a 1.1 request and you're a 1.2 server, you can jiggle the values to make it work. Has to be explicit. Hope we've convinced you it's needed going forward. Appreciate minimizing damage to the ecosystem. Specify the behavior so there's protections for later. Is the Turtle representation ... the Turtle one gives an error on new data? XML? Do they do the same error recovery?

Sarven: Think they're all different.

Andy: Not specified. Think the behavior is complete failure. Might have been a recovery attempt for N-Triples. For XML, structural errors will come from XML being wrong. XML parsers tend to be very picky. Could specify that.

Sarven: I want to acknoledge that the situation is not ideal. With the cost of a new media type being well understood... whether this sets a precedence for other specs, that sets a bad precedence. We, TAG, need to look at the example here / lessons / considerations and document that for our understanding so that we are clear on tradeoffs vs. correctness. I agree with Marcos that the behavior should have something specified. Here we seems to be weighing things. We seem to be agreement that the current solutions is not the most idea situation.

Yves: to talk about existing infrastructure, we still have HTTP 1.0 servers that are potentially buggy. So its good to understand what is happening in the RDF ecosystem, so if changing the media type is right and what the impact will be.

Marcos: Lesson from old IE 6: The Great Reverse Engineering Effort at the WHATWG. Given that these implementations are open source and freely available, throw lots of things at these servers [clients?] and see what happens. tHat might give you a story to put in the spec. Jsut document what programs actually do. Might find that servers in the ecosystem have aligned on a certain behavior. If 90% do error recovery in a certain way, can go with that. Lots of ways to recover. It's painful archaeology, but it's doable. Test suites. See what comes out from the servers&clients. Might answer the question. Re Ted, don't know how concerned you should be about taking time. RDF has been around a long time, ok to take a bit longer. Charter extensions are cheap.

Ted: Working group members are not encouraged to consider charter extensions as cheap or easy.