Meeting minutes
Approval of minutes from the last two meetings: 1 2
<ora> PROPOSAL: Approve last two weeks' minutes.
<ktk> +1
<gtw> +1
<olaf> +1
<lisp> +1
<tl> +1
<MacTed> +1
<ora> +0 (not present)
<AndyS> +1
<pchampin> +1
<niklasl> +1
<rubensworks> +0.5 (only present for one of them)
<Dominik_T> +0 (not present)
RESOLUTION: Approve last two weeks' minutes.
TAG's advice on error processing
ora: further feedback from the TAG about error processing
pchampin: not satisfied about future versions come out and reuse the media types
… so far we have said parsers signal an error on features not in the they support or before
… TAG would rather have a predicable behavior -- "no triples", "some triples up to the error", ...
… we do not say which
… option 1 - we are more explicit parser should be doing - more than "signal an error"
… option 2 - could specify the error includes the behavior
ora: in the chairs call, we discussed we could define vocabulary to describe the nature of the error.
rubensworks: about vocabulary - JSON-LD has a similar mechanism
… want to make behavior of parsers more predictable
AndyS: my feeling is that this has moved into a discussion about API
… with the idea of switching between different systems
… If you are using the SPARQL Graph Store protocol, how would you get this kind of error?
… Not arguing one way or another, just commenting.
pchampin: one clarification - goal is not describe the error, only the behavior of the parser
… explicit about the error handling
… Graph Store Protocol case - another level - the server is not returning the triples
gtw: as an impl datapoint - we allow users to indicate the behaviour - keep going to triples after the error
… don't want to be over restrictive to what implementation can do
j22: if we get too detailed on error then head towards all parsers know all errors kinds.
pchampin: no intention to define errors - it is the behavior when an error is detected and report it.
pchampin: Yves suggestion was in the version directive could have behaviour specification.
… then consumer can direct what to do with what it gets.
pchampin: who should be in control - consumer or producer
… option 2 does not prevent the gtw example
lisp: from this discussion, I suggest remove the text about behavior in the error case. Handling is an API issue, not a core spec concern.
… under and over specification both have costs on implementers.
… . its says the result is "undefined" and say API should react as appropriate to the situation.
j22: producer have no idea what the application intent is
tallted: TAG approach has backwards-spec effects. It is quite late for that.
pchampin: TAG acknowledges that we can not (re)define for RDF 1.1. Wanting to have the ground clear for future 1.2->1.3
… I tried to bring up the argument that CSS is different from the data web.
… we could allow impls to return their own IRIs in option 2.
lisp: that (extensible URIs for error) effectively goes for undefined option.
pchampin: this is my understanding of the TAGs position.
… anything saying "undefined" means can't reuse the media type in the future. We
niklasl: Why not write something like "If there is a syntax error in the input, a parser SHOULD produce triples up until that error, MUST NOT, by default, continue parsing, but MAY produce a _separate graph_ describing the error, and possibly additional data (such as subsequent triples, warnings, etc.)"? Is that too much for us, and still not what
ora: niklasl, how is this different from what gtw suggested?
… or maybe that's a question for gtw
ora: to gtw - is this in contradiction to what you describe?
gtw: it is a little hard to tell; I'm not sure where the TAG would come down on whether this is an API issue on the parser
… users of Neptune are not interacting with this API directly, only through an HTTP API
gtw: I think it is - there are several layers between users and parsers.
… we could also deliberately ignore those corners cases in the spec, though I would prefer not to
AndyS: is there any sense that what people are doing already is going to be spec forbidden?
… even for RDF 1.2, we are a long way through the process, we have test suites
… is the point of the TAG that we have to make changes that will affect 1.2 as it currently is?
… or only to make it future proof?
pchampin: TAG is saying what to aim for. Not how to get there.
… not clear they want to change current behavior
… option 2 is being more information (which apps can ignore)
ora: we need to choose. option 1,2, 3 (lisp's option)
… for opt 2 is this SHOULD or MUST?
<pchampin> lisp, I personally agree, but the TAG seems to think differently
lisp: responding to pchampin - this is not precluding future version behavior - it's "undefined"
AndyS: from an implementer's point of view, there are typically two cases
… either you are in a transaction, things go wrong, you abort
… or you are bulk loading, where many things can go wrong
… If it is a bad IRI, what sort of an error is that?
… "bad IRI" is different from one system to another
<Zakim> gtw, you wanted to ask about option 3
gtw: if we go with option 3, are we delaying the issue e.g. SPARQL graph store protocol.
lisp: Graph Store Protocol (GSP) is an API.
ora: I think we are offering advice to implementers
… once the error has happened.
… useful for implementers rather than strict spec material.
<niklasl> +1 this should be advice, which sounds congruent with "what we should aim for"
j22: looked at CSS - any parser error is an error except bad URLs. With recovery behavior.
pchampin: trying to seek consensus here - TAG concern is "future proof" the media type.
… future versions could require version announcement is mandatory
… we could say in future (post 1.2) version announcement is required.
… I am not clear what the TAG reaction will be.
… maybe need to explain that the produce/consumer is different for HTML/CSS because the intent is known.
s!produce/!producer/!
lisp: I am not so concerned about 1.2 to 1.3
… for 1.2 we have new feature is new/breaking syntax
j22: CSS has one option is "first error - stop" and one skip to recovery point.
… so if we take the first then nothing changes.
pchampin: allow future versions to define current "undefined" - i.e. say no redefinition of existing behavior
lisp: it is more complicated than an assumed linear model underlying the TAG feedback.
ora: homework - options for responding to the TAG.
… next week we will continue this discussion
lisp: for SPARQL, most are obvious