- From: Ruben Taelman <ruben.taelman@ugent.be>
- Date: Thu, 21 Sep 2017 08:55:37 +0200
- To: Blake Regalia <blake.regalia@gmail.com>, Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: Laurens Rietveld <laurens.rietveld@vu.nl>, RDF-JS <public-rdfjs@w3.org>
- Message-ID: <etPan.59c3626e.72ddea55.123a2@ugent.be>
Hi Blake, That definitely makes sense, I was just following the spec, thinking that there might be a good reason for leaving this open, but I can indeed also not think of any reason for not restricting this set of possible termType values. According to git blame, Ruben Verborgh wrote that part of the spec. @Ruben, can you confirm that Blake’s interpretation is indeed the intended one? After confirmation, I can send a PR for clarifying that sentence. Kind regards, Ruben Taelman On 20 September 2017 at 19:33:24, Blake Regalia (blake.regalia@gmail.com) wrote: Hey Ruben, Thanks for the contribution. Possible values include "NamedNode", "BlankNode", "Literal", "Variable" and "DefaultGraph”. I wouldn't interpret the words "possible" and "include" too literally here. Maybe we should address this in the specification, but I believe it should be something more along the lines of "Must be one of the following". If an implementor has some use case for another term type that does not extend one of these, I cannot see how it is still RDF. More importantly, I think the bottom line is that the idea of an interface is to conform, so what would be the point of leaving termType open to `string`? This could also lead to trouble down the line, e.g., if a developer assumes that a final 'else' branch should be the remaining untested type. - Blake On Wed, Sep 20, 2017 at 2:22 AM, Ruben Taelman <ruben.taelman@ugent.be> wrote: Dear Laurens, I could indeed make the termType types of each Term subtype stricter, will do that. Regarding the termType type of Term itself, the current spec states the following: Possible values include "NamedNode", "BlankNode", "Literal", "Variable" and "DefaultGraph”. As I understand this, other implementations may therefore choose to support other values as well, which would not conform with the following type anymore: `termType: 'NamedNode' | 'BlankNode' | 'Literal' | 'Variable' | 'DefaultGraph’` I could however change it to the following: `termType: 'NamedNode' | 'BlankNode' | 'Literal' | 'Variable' | 'DefaultGraph’` | string So that other values are still allowed, but the given values are simply there as a suggestion. Any thoughts on this? Kind regards, Ruben Taelman On 20 September 2017 at 11:12:17, Laurens Rietveld (laurens.rietveld@vu.nl) wrote: I like it, good initiative. Using Typescript myself extensively as well. A technical comment: what about making the types a bit stricter. I.e., instead of `termType: string`, using `termType: 'NamedNode' | 'BlankNode' | 'Literal' | 'Variable' | 'DefaultGraph'` gr Laurens On Wed, Sep 20, 2017 at 11:03 AM, Ruben Taelman <ruben.taelman@ugent.be> wrote: Dear all, Some people (including myself) prefer using typed Javascript, using TypeScript for instance. As I was not able to find any type definitions for the RDFJS interfaces, I’ve implemented these myself here: https://github.com/rubensworks/DefinitelyTyped/commit/44292d468be8893f589a1ee4a76dd8d50b588ce3 Before I make a PR with these types to the DefinitelyTyped repo, so that these types would become available as `@types/rdf-js`, I first want to make sure everyone here agrees with this implementation. The JSDoc has been taken directly from the spec. Any feedback or comments are welcome! Kind regards, Ruben Taelman -- VU University Amsterdam Faculty of Exact Sciences Department of Computer Science De Boelelaan 1081 A 1081 HV Amsterdam The Netherlands www.laurensrietveld.nl laurens.rietveld@vu.nl Visiting address: De Boelelaan 1081 Science Building Room T312
Received on Thursday, 21 September 2017 06:56:05 UTC