Meeting minutes
Approval of minutes from the last two meetings: 1 2
ora: Any concerns about the minutes?
<ora> PROPOSAL: Approve last two weeks' minutes.
lisp: Can you put the link to the new YASGUI repo in the minutes?
<ora> +1
<AndyS> +1
<rubensworks> +1
<tl> +1
<lisp> +1
<ktk> YASGUI Successor repo: rdfjs/
<Souri> +1
<ktk> +1
<TallTed> +1
RESOLUTION: Approve last two weeks' minutes.
TallTed: Could my name be fixed in the last minutes? (wrong IRC name)
TAG's advice on error processing
ora: Adrian spoke about this at our chairs meeting. We are defining a language, thus the spec indicates what is correct language and what is not. We are not designing a protocol. So it is up to the client/user/parser to decide what to do. Clients could have parameters on how to behave. The important thing is that if the language is incorrect, is up to the parser. The previously discussed IRIs are the most
… common cursive(?) descriptions.
lisp: I don't see an IRI as a shorthand for this description.
ora: Incorrect language must get signaled. We are not trying to hardwire a predefined behaviour. It's up to the parser implementors when an error is encountered.
ktk: We could see it as a return code in a shell command. 3 means this, 4 means that, ...
lisp: I agree with your description, but I don't agree with linking it to an IRI.
… IRIs are not exhaustive. I feel like we are not ready to make a taxonomy out of this.
… IRIs are supposed to be opaque. They are different to numbers.
ora: I see no difference here between IRIs and numbers, if numbers have a defined meaning.
lisp: If I see random numbers in error codes in an old device, I would not attach special meaning to them.
ktk: So you're saying that by creating only numbers, we don't give special meaning to them, but only say that they are "different"?
lisp: Yes
ora: At the end of the day, if I build software, I need to know what to do when specific numbers come out. Same as with an IRI.
lisp: If you would choose an IRI. Would you put random values in the values?
ora: You are afraid of people seeing them as mnemonics?
tl: To James, I don't understand how you agree with Adrian's description.
lisp: A complex categorization is fine, but I resist the mnemonics, which is what the IRIs turn into.
tl: This is what a standard is intended to do.
lisp: If someone puts out a categorization for failure modes that convinces me, then I change my position. But right now, there is none yet.
tl: So you agree to Adrian's earlier description in last meeting?
lisp: Yes
tl: The descriptions right now are not complete indeed, but they are a start.
lisp: If one would produce a categorization, and later we notice that the categorization needs to be changed, things are hard to change later on.
ora: I think you are worried about people not treating IRIs as opaque. If I chose some namespace prefix, and I chose IRIs using that prefix, and suffixes as 1,2,3, you would agree with it?
lisp: Yes
… Because they are actually opaque.
ora: This is a discussion about IRI opaqueness that we can't have in this group anymore. If we're treating IRIs are not opaque, them things people have said about RDF over the years become questionable.
lisp: The people we work with consider IRIs as not opaque.
ora: We are trying to attach meaning to errors.
lisp: But this is too fragile at the moment, as we don't understand it well yet.
ora: You are worried about our thinking on parser failures.
lisp: Yes
ktk: We have this discussion because TAG was not happy with compat between 1.1-1.2 on media types. We are looking for a solution. What James said is that we have to think very hard about such a taxonomy, and we can't take shortcuts.
tl: We can't just put the error description in the spec, as the spec can't be changed anymore.
lisp: I think the descriptions can go in the spec as how things can fail. In a future spec version, these descriptions can be extended.
ora: So we can extend the set of descriptions? But not modify the existing ones.
ora: Does that mean even the numbers we could designate should not be there?
lisp: I would not even put the numbers in the spec.
lisp: Example on how treating UTF decoding: how would you do this later if you already named all the ways things can fail?
ora: We shouldn't define all failure modes, just some.
ora: Where does that leave us?
… Sufficient for TAG that parser must signal an error?
ora: What I understood from you James is that the lang should define what is correct and not.
… The only thing we should say, is that the user using the parser should be able to find out if something is wrong.
… This is not just a question of lang correctness.
tl: I can't think about something more basic than saying there is an error or not. What is wrong with that?
lisp: How to communicate that? There's nothing in the spec about the return control flow.
tl: I don't know the answer to that.
AndyS: I tried to think about a very inconvenient error: if an IRI has a space in it, that is a hard error in Turtle. But there are parsers that go over it, and produce a warning.
… Similar behaviour, if there are junk characters in strings.
… You should get some kind of signal in all cases.
lisp: Does the spec even have the notion of a language processor?
… I don't think it does.
ora: We offer this as non-normative guidance to implementors as far as I understand.
lisp: Either a document is correct, or a document is an error, or situations where the quality of a doc is undefined.
… In a processing model, we can think about how to process such a document towards this.
ora: We indeed have a grammar. The existence of a parser is merely implied.
… I don't think we disagree about the lang being incorrect or not.
… What we try to understand is that implementations take some latitude with respect to this.
… And we should handle the concerns of TAG.
ktk: We could consider going back to the TAG that we as a group decide to go forward with what we have now.
AndyS: We could stronger than saying they must signal, we just don't say what the signal means and how.
… Signal is out of the spec.
ora: Are we comfortable with this?
ktk: Let's discuss with PA how to handle this with TAG.
ora: Any other thoughts?
lisp: I would be stricter about it.
rubensworks: I also don't think we should define a meaning of specific error codes. I would agree of defining one fixed behaviour of failures. This was one of the options also proposed by TAG. This sounds straight forward and easy to do. But I can also live with keep what we have right now.
TallTed: As a data worker, I wanted to succeed or fail on a given input. We have streaming use cases, where it's difficult to define the behaviour on documents, since it's a continuous stream.
… We must specify a lot more on what impls have to do.
lisp: In what you describe, ... (did not understand everything) failure states.
ora: Let's decide on this next week.
ktk: And let's vote next week.
ora: This was a good discussion; I have a clearer understanding.
Review of open actions, available at 3
Review of open PRs, available at 4
ora: Let's start from the oldest.
AndyS: The RDF/XML ones depend on a higher level decision on what to do.
ora: What is the issue?
AndyS: The spec now has a rigid way of defining what is not in the spec. For unknwon parseType, it is interpreted as an XML Literal. Thomas Pellesier-Tanon though it was going to be an error. Similar to annotation attributes.
… This does affect compatibility.
… Technically ITS, changes RDF/XML.
… These issues could lead to breaking changes in the spec.
ora: How does the spec currently deal with attributes not supposed to be there?
AndyS: This working group decides on the use of the RDF/XML namespace, so if people misuse it, it could be seen as other people's problem.
ora: People should respect the spec.
AndyS: Arguments on both sides.
AndyS: What is this WG comfortable with?
ora: How to deal with ITS?
AndyS: We could say that it's being imposed on us.
ora: Someone could have used in the past as using its as prefix.
AndyS: It's used as an IRI.
AndyS: It's not a technical issue.
ora: Are we adding ITS now?
AndyS: Yes
AndyS: In top-element of a doc, the top-element can only declare namespaces. You can't put the rdf-version in. That's just what the spec says.
AndyS: We define a meta syntax.
ora: What prevents us from allowing top-level version in the spec?
AndyS: A very strict 1.1 parser for RDF/XML would see top-level version as an error.
AndyS: ... This could break streaming output.
rubensworks: are you saying a very strict 1.1 parser would see those as an error. Is that not what we want to happen?
AndyS: If you fully stream a database and you don't know yet if you have any RDF 1.2 triples or not, you have to make this decission upfront.
rubensworks: so it's a data producer issue?
AndyS: it's one of these balance issues.
rubensworks: would it be an option to leave it at a top level or somewhere internally?
ora: rdf:version doesn't exist yet in the namespace, so it couldn't come out?
… It should come out as an error?
AndyS: The spec doesn't talk about warnings or errors.
AndyS: Lots of little points like this.