07:05:37 RRSAgent has joined #annotation 07:05:37 logging to http://www.w3.org/2016/05/18-annotation-irc 07:05:43 takeshi has joined #annotation 07:05:44 rrsagent, set log public 07:05:58 Present+ Rob_Sanderson 07:06:15 Meeting: Annotation WG F2F, Second Day 07:06:17 Present+ Takeshi_Kanai 07:06:24 Present+ Ivan_Herman 07:06:34 Chair: Rob, Tim 07:06:35 TimCole has joined #annotation 07:06:41 present+ Tim_Cole 07:06:47 TOPIC: Issues, continued 07:08:59 scribenick: bjdmeest 07:09:25 Present+ Richard_Ishida 07:09:30 present+ felix_sasaki 07:09:35 r12a has joined #annotation 07:09:50 bjdmeest has joined #annotation 07:09:56 Present+ Benjamin_Young, Doug_Schepers 07:09:58 Present+ Ben_De_Meester 07:12:48 tantek has joined #annotation 07:13:15 TimCole: we going to try resolve all issues except for 2, which we will do this afternoon 07:13:30 azaroth: we closed some of the 'new' issues 07:13:36 ... #223 07:13:39 ... that was intentional 07:14:00 ... in JSON-LD, if you would associate a language, it would look like a resource 07:14:04 ... which would be confusing 07:14:33 ... #224 not our concern about how a client does requests headers 07:14:49 ... the client does not have access to response headers 07:14:56 ... javascript doesn't allow it 07:15:08 ... for security reasons (cookies etc.) 07:15:18 q+ 07:16:08 ... about #219: you can always add annotations to a collection 07:16:12 s/#224/#220/ 07:16:26 ack r12a 07:16:28 ... default would have very little value 07:16:43 Present+ Nick_Stenning 07:16:48 Present+ Lena_Gunn 07:17:28 TimCole: bodies and targets may have languages, the annotation itself does not have a language 07:17:38 The issues we closed: https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Ai18n-review+is%3Aclosed 07:18:03 azaroth: the link is about the issues we closed yesterday 07:18:30 tbdinesh has joined #annotation 07:18:45 r12a: when the annotation have no language or direction, doesn't an annotation have some text? 07:19:01 TimCole: the model separates the body (the content) from the annotation itself 07:19:18 ... the structure is more a description of the content than the body itself, the body may be embedded or referenced 07:19:51 ... the body can be a resource without properties, we also have some basic properties, all optional 07:20:06 ... the creator can always add additional properties from different vocabularies 07:21:06 r12a: something like this additional info should be added to #209 07:21:07 fyi, d12a, an annotation as an object is a *relationship* between a body and a target 07:21:26 bodies/targets may well have language/direction, but annotations themselves do not 07:21:29 ... so that everyone can understand 07:21:34 *r12a 07:21:38 TimCole: good point 07:22:01 ... so, about #223... 07:22:24 azaroth: #223 is specifically about the string body, that must be just a string 07:22:51 ... in rdf and JSON-LD, you can associate a language to a string, but for JSON-LD, you then get an object 07:23:05 ...the point of bodyValue is to have purely a string 07:23:27 q+ 07:23:46 ... we don't need an object for bodyValue, that is already taken into account elsewhere (the body object) 07:24:15 TimCole: bodyValue was added for 'the simplest case': no additional properties 07:24:15 ack nickstenn 07:24:48 q+ 07:24:57 nickstenn: for clarity, could we add a parenthetical: if your use case needs additional properties, use 'this structure' 07:25:09 ack r12a 07:25:38 r12a: if I wanted to make annotations, I would take the easiest approach, and would end up with lots of annotations without language 07:25:46 ... so I couldn't display them properly 07:26:06 azaroth: indeed 07:26:40 ivan: e.g., SVG WG uses annotation structure to add annotations to CSV metadata 07:27:15 s/SVG WG/CSV WG/ 07:27:21 ... for systems that do annotations in 'isolation', it's not usefull, but for systems that have context, this system might be useful 07:27:40 TimCole: people will abuse this, that's likely to happen 07:27:49 ... the consensus was that we should allow this 07:27:55 Spec ref: https://www.w3.org/TR/annotation-model/#string-body 07:27:55 ... partly because would do it anyway 07:28:09 And commenting is 5th requirement bullet 07:28:37 q+ re inheritance 07:28:38 r12a: this is the reason why I added the issue of adding language to a collection of stuff 07:28:52 Zakim has joined #annotation 07:28:58 q+ to discuss rdf and inheritance 07:29:06 TimCole: well, you may be talking about the language of the body, the target, multiple bodies (each having a distinct language)... etc 07:29:51 ack azaroth 07:29:52 azaroth, you wanted to discuss rdf and inheritance 07:29:52 r12a: but there, you must provide the language information 07:30:00 ... I was talking about a default 07:30:06 ... like in HTML 07:30:27 azaroth: issue about RDF and inheritance of properties is tricky 07:30:52 ... 'for all annotaties, for all bodies, for dc:language...' etc. 07:31:23 ivan: the mapping on RDF is hard 07:31:43 ... you want 'all the literals should be of language X', which is not a concept RDF has 07:32:54 azaroth: r12a, thanks for raising the issues 07:33:01 r12a: about #218: does a person have to assign a language every time he creates an annotation? 07:33:09 azaroth: language is not required 07:33:52 TimCole: the language could be figured out by the client 07:33:52 azaroth: how the language gets assigned is an implementation details, just as a Request Header 07:34:31 TimCole: do we need changes in the spec for this? 07:34:56 azaroth: there is a note we could extend 07:35:15 note discussed is in this section https://www.w3.org/TR/annotation-model/#external-web-resources 07:35:34 r21a: when reviewing the model spec, I was very happy to see all the examples, extremely helpful 07:36:47 azaroth: about #211: the agreement was that we would specify the intended audience from the annotation perspective, it would be up to schema to add a property to say 'a person that understands language X is a member of this audience' 07:37:01 ... we would recommend the audience property of schema.org 07:37:18 TimCole: it avoids us needing to do audience description, which is not in our scope 07:37:38 https://github.com/w3c/web-annotation/issues?utf8=✓&q=is%3Aissue+label%3Ai18n-review+label%3Aeditor_action+ 07:37:45 ivan: we also have a list of 'editor'-issues 07:37:59 ... they are editor actions, once done, they are considered to be closed 07:38:37 azaroth: BCP47 changes to keep up to date 07:38:55 ... can we normatively refer to it? 07:39:21 tantek has joined #annotation 07:39:21 ... BCP47 is not versioned 07:39:46 r12a: BCP47 is a hook, because people are referring to out of date RFCs 07:40:02 ... it is created so that specifications stay up to date 07:40:27 ivan: we have a precedence, W3C rec refers to this, so I think can close it with that 07:40:52 r12a: lots of spec refer to BCP47 normatively 07:41:14 azaroth: #225 is fine to continue dc:language, but add a note: 'we require BCP47' 07:41:25 TimCole: because dc:language doesn't preclude that 07:41:44 azaroth: #216 and #215 are accepted, we would require UTC 07:43:48 TimCole: there was a comment that W3CDTF is more flexible 07:44:09 https://github.com/w3c/web-annotation/issues?utf8=✓&q=is%3Aissue+label%3Ai18n-review+-label%3Aeditor_action+ 07:44:11 feedback was on #217: https://github.com/w3c/web-annotation/issues/217#issuecomment-219939781 07:44:46 azaroth: about #210: logical order is way better that visual order 07:44:51 Pending issues for i18n: https://github.com/w3c/web-annotation/issues?utf8=✓&q=is%3Aissue+label%3Ai18n-review+-label%3Aeditor_action+is%3Aopen 07:44:56 azaroth: about #224 (base direction) 07:45:11 r12a: we aren't talking about language, we are talking about direction 07:45:57 azaroth: the example is not correct, but can we require HTML when bidirectional text is required, instead of importing it? 07:46:15 r12a: so require HTML for all arabic, hebrew, etc? 07:46:31 azaroth: only if it is bidirectional, right? a single language determines the direction? 07:46:43 r12a: not necessarily, hebrew could be in latin script 07:47:09 Isn't that ar-latn vs ar-somethingelse ? 07:47:14 ... the kinds of values to need to handle direction aren't the same as for language 07:47:56 fsasaki: the remark was not on the language, but on the unicode characters themselves 07:48:51 r12a: we have some hebrew and latin, but W3C needs to be placed on the left-hand side, and you know which are hebrew characters, but you dont' have an idea about the base direction 07:48:57 ... there's hebrew and latin text 07:49:43 ... an algorithm could put the hebrew text and latin text separately in the correct order, but cannot put the latin text to the left-hand side of the hebrew side without a base direction 07:50:11 ... you have 2 runs (1 hebrew + 1 latin), and 1 base direction 07:50:31 ivan: is it enough to have something like 'direction: ltr'? 07:50:46 azaroth: how many values are there? rtl and ltr? 07:51:06 r21a: you may have a value 'auto' (determine the direction based on the first strong character) 07:51:30 ivan: I would propose: add this term to the vocabulary, with two terms 'ltr' and 'rtl' 07:51:42 fsasaki: this is only relevant for textual body, right? 07:52:10 azaroth: it could be a plain text as resource 07:53:58 ... we should define rtl and ltr as URIS? 07:53:59 ivan: it should be put in the context 07:54:07 PROPOSED RESOLUTION: Add a `direction` property to the vocabulary, to be associated with any content resrouce (body or target) with two possible values, rtl and ltr (in JSON-LD) and define URIs to identify the concepts 07:54:34 ... is it safer to refer back to the HTML doc? in this case, auto could also be used 07:54:59 PROPOSED RESOLUTION: Add a `direction` property to the vocabulary, to be associated with any content resource (body or target) with three possible values, auto, rtl and ltr (in JSON-LD) and define URIs to identify the concepts. Refer back to HTML5 document for the definitions. 07:55:08 r12a: if auto is the default, it may catch a lot of cases 07:55:17 +1 07:55:24 +1 07:55:27 +1 07:55:27 html reference is https://www.w3.org/TR/html5/dom.html#the-dir-attribute 07:55:30 +1 07:55:32 +1 07:55:43 +1 07:55:47 +1 07:55:52 rrsagent, pointer? 07:55:52 See http://www.w3.org/2016/05/18-annotation-irc#T07-55-52 07:55:52 q+ 07:56:11 tbdinesh has joined #annotation 07:56:18 RESOLUTION: Add a `direction` property to the vocabulary, to be associated with any content resource (body or target) with three possible values, auto, rtl and ltr (in JSON-LD) and define URIs to identify the concepts. Refer back to HTML5 document for the definitions. 07:56:22 +1 07:56:24 rrsagent, pointer? 07:56:24 See http://www.w3.org/2016/05/18-annotation-irc#T07-56-24 07:56:29 Clarified that this is the same as where Language property is appropriate 07:56:43 Present+ TB_Dinesh 07:56:47 azaroth: about #222 07:57:38 r12a: when using 'normalization', you mean more than unicode character normalization, but you include it 07:58:04 ... what we are saying, is that if you get a piece of non-normalized form 07:58:20 spec ref: https://www.w3.org/TR/annotation-model/#text-position-selector 07:58:24 ... and you want to establish a range by counting characters, you shouldn't normalize the target document 07:58:46 ... there are reasons why people don't put something in, e.g., NFC 07:59:02 ... however, for text/string matching, you need normalization 07:59:39 ... there was a time to say everything should be normalized, but that time is passed 07:59:57 q+ to ask re DOM manipulation 08:00:02 ack nickstenn 08:00:47 nickstenn: specifically, text position selector, we agreed to be code point sequences 08:01:03 ... that doens't mean normalizing the text, but understanding what the normalized version would be 08:01:05 ack azaroth 08:01:05 azaroth, you wanted to ask re DOM manipulation 08:01:07 ack azaroth 08:02:08 azaroth: the whitespace normalization would be very hard to undo if you're in a browser context, you don't have the raw whitespace 08:02:25 tantek has joined #annotation 08:02:43 TimCole: It's a hard problem, but I'm not sure there's a change we need to make 08:03:04 r12a: I was talking about unicode normalisation 08:03:32 ... you could encode e-acute using 4 codepoints vs 3 codepoints 08:06:37 bjdmeest_ has joined #annotation 08:06:50 scribenick: bjdmeest_ 08:06:55 nickstenn: let's say we can have the same content in two targets, but unicode normalization is different 08:07:01 ... we want to use a text position selector to be useful in both targets 08:07:35 ... what a user agent would allow a user to do, you would still only be able to select grapheme clusters 08:09:15 q? 08:13:03 q+ 08:13:55 ack r12a 08:14:00 q? 08:14:52 bjdmeest has joined #annotation 08:15:45 scribenick: bjdmeest 08:16:33 r12a: let's say, we start our selection 34 characters from the beginning of a paragraph 08:16:38 ... depending on the normalization, we have 33 or 34 08:16:42 nickstenn: we need more discussion, there are cases where we need to normalize before selection 08:17:13 ivan: can we say, by default, everything works with code points, and it has to consistent 08:17:17 ... and we introduce a separate flag, to tell explicity, and we don't normalize 08:17:22 ... I think, in 90% of the cases, the normalization is right choice 08:17:26 TimCole: we have to test implementations 08:17:38 ... will they likely be normalized? 08:17:41 nickstenn: there are two layers: javascript doens't allow an easy way of counting code points 08:17:46 ... and there's the question of counting code points vs counting normalized code points 08:17:50 ivan: seeing an e-acute 08:18:05 nickstenn: you count the code points of the document 08:18:09 ... it is either very interoperable in principle but hard in practice, or vice versa 08:18:14 fsasaki: talking about trans-format documents 08:18:18 ... you cannot enforce normalization for the user perspective 08:18:22 ivan: we could make an explicit case if necessary 08:18:27 r12a: if I'm referring to a target with resume (with acutes), and that target is copied somewhere 08:18:31 ... if I am an implementation trying to find the position of the 's', it may not be problematic to normalize the text 08:18:36 fsasaki: in the IPA case, you don't want your application to do normalization 08:18:40 r12a: I want to keep the text as I have written it, but don't mind the normalization for annotations 08:18:44 nickstenn: we assume we don't alter the document you are annotating 08:18:49 ... we might copy a part and normalize that 08:18:55 r12a: great 08:18:58 nickstenn: so we need a note: please clients, don't alter the current DOM 08:19:03 ivan: so we can close #222? 08:19:08 nickstenn: I'm adding a comment 08:19:33 azaroth: about normalizing whitespace: we didn't mention anything about normalization 08:20:24 ... #206 08:20:37 r12a: that's about a different question 08:20:47 ... not about normalization 08:21:25 ivan: it is, because for a user, the 's' is the third character of resume (with e-acute etc) 08:22:09 ... the text quote selector is a user-controlled selector 08:22:30 nickstenn: there are two layers: pay attention to code points vs encoding 08:22:41 ... and pay attention to normalized vs non-normalized code points 08:22:43 ...they are separate 08:23:22 q? 08:24:40 KevinMarks has joined #annotation 08:25:29 Nick's comment: https://github.com/w3c/web-annotation/issues/222#issuecomment-219958840 08:25:30 https://github.com/w3c/web-annotation/issues/222#issuecomment-219958840 08:25:54 TimCole: you could comment on that, we can revisit if necessary 08:26:17 r12a: that captures protecting the original document 08:26:32 ... about normalizing the text for text quote selector... 08:26:37 ivan: that's #206 08:27:15 azaroth: #221 is about 'normalizing unnecessary whitespace' 08:27:26 ... but there is no separate spec 08:27:31 r12a: whitespace is trending 08:27:44 ... problem is that it's not really defined here 08:27:54 ivan: but there is no such specification? 08:28:35 fsasaki: xpath 2.0 there is regex function using unicode character classes, defining what is whitespace and what isn't 08:28:53 ... interoperability across whitespace across technologies is 'hard' 08:30:58 (the xml schema list of whitespace: http://www.xmlschemareference.com/regularExpression.html#MultipleCharacterEscape ) 08:32:31 (white space in xml https://www.w3.org/TR/REC-xml/#sec-common-syn ) 08:32:42 https://github.com/w3c/web-annotation/issues?utf8=✓&q=is%3Aissue+label%3Ai18n-review+-label%3Aeditor_action+is%3Aopen 08:32:43 bjdmeest_ has joined #annotation 08:32:48 scribenick: bjdmeest_ 08:32:53 ... on of the reasons about trending whitespace, is that whitespace handling of javascript is different from HTML 08:32:58 ivan: we were hoping to get a simple reference to use as a normative reference 08:33:02 ... or to the xpath thing 08:33:07 ... I think everyone would be fine with that 08:33:15 nickstenn: as long as I can use it in the DOM 08:33:22 azaroth: about #217 08:33:39 ... we talked about using dc:datetime and UTC 08:33:58 s/dc:datetime/xsd:datetime/ 08:34:31 ivan: so we can close with ref to #216 08:34:45 azaroth: about #213 08:35:14 ... more than one language is hard for text processing 08:35:44 ... question is: do we allow 0, 1, but not n languages? 08:35:56 r12a: question is: why would you provide a language property? 08:36:28 azaroth: e.g., display annotation from Choice-annotation based on language 08:36:38 r12a: we call this metadata-language 08:37:00 ... you still probably want one language, but might have a situation where two different audience groups read the same thing 08:37:10 ... so using lang-property for that is fair enough 08:37:12 q+ to ask about "This is hello in French: bonjour" 08:37:41 ... we need to know the language of the actual text 08:37:46 ack azaroth 08:37:46 azaroth, you wanted to ask about "This is hello in French: bonjour" 08:37:51 ... question is: can this language property do both of these tasks? 08:38:28 azaroth: is there a single language tag for "This is hello in French: bonjour"? I would say english and french 08:38:48 ... picking one language, I would take english, but there are multiple language tokens 08:39:10 r12a: actually, you need to specify language for a part of a text for some cases 08:39:32 azaroth: proposal: reduce to 0..1, multiple languages within one text would require HTML with xml:lang attributes 08:40:45 q+ 08:40:56 ack r12a 08:41:55 r12a: if you have, e.g., japanese and french, the language property could say 'this is japanese and french' 08:42:11 ... you need to visualize that properly (e.g., use the correct font) 08:42:55 ivan: we are mixing different things, we should not this issue for our own 08:43:17 ... we can fallback to formats that have means to describe these advanced cases, e.g., xml and html 08:44:15 r12a: the language property can only have 0..1 language property, so you can use that as the default text processing 08:44:45 TimCole: for someone that includes french and spanish, they either use html, or indicate one language 08:45:15 ... we could add a note 'you may use multiple languages, but it's better to use advanced formats' 08:45:35 ... MAY is doing at your own risk, so that's fine 08:46:14 q+ 08:46:20 ack r12a 08:46:25 azaroth: so leave as is, but further explain best practice in the note 08:47:07 r12a: many people don't understand the difference between text processing and metadata language properties 08:47:29 ... you will get something that is marked up with multiple language, and you won't know how to process that 08:47:41 uskudarli has joined #annotation 08:47:45 ... so I would prefer one language tag max 08:47:55 My proposal for solution: Keep the functionality, but add an editorial comment on what the MAY can be used for (and using eg, XML or multiple bodies, for more complex cases). 08:48:10 TimCole: we wouldn't recommend multiple language, but we wouldn't disallow 08:49:03 ... e.g., when you have a title of a book containing one separate token, you usually just mark that up as one language 08:49:27 ivan: I would turn this into editorial action 08:49:28 +1 to Ivan 08:52:53 bjdmeest has joined #annotation 08:52:56 scribenick: bjdmeest 08:53:02 ivan: e.g., you have books with two main languages, then you should be able to mark that up, and it would be overkill to use HTML tags for that 08:53:07 azaroth: could we just have two properties? 08:53:25 q+ 08:53:25 ivan: it is metadata, it doesn't claim to be more than that 08:53:54 nickstenn: my assumption is that these annotations need to be rendered, to be rendered correctly, we need text processing metadata 08:54:19 ivan: which wouldn't be a problem for spanish vs catalan 08:54:37 ack r12a 08:54:39 ... if there would be a problem (e.g., french and japanese), then we need more advanced markup, and that would be in the note 08:55:17 r12a: there are text processing problems, even with spanish vs catalan 08:55:50 ... you do need to render this stuff, so you need to know the default language 08:55:57 q+ to suggest first language for text processing 08:56:12 q- 08:56:29 fsasaki: so for text processing, we use html 08:57:12 TimCole: what will users do? leaving MAY in, will lead to abuse 08:57:34 ... leaving MAY out, users will put in only one language 08:57:45 ... which risk is the worst? 08:58:04 nickstenn: if you mix languages, it's complicated, there are no simple cases 08:58:34 ... we should use things as used, e.g., in xml and html 08:58:44 ... and not create a simple case that breaks this 08:59:00 q+ 08:59:31 fsasaki: if you have to copy a whole catalog (e.g., multiple bodies), that's not efficient 09:00:13 ivan: we need text-only annotations with several languages 09:01:22 ack r12a 09:02:12 r12a: I understand the need for the metadata, but why copy the whole catalog? 09:02:54 azaroth: if I want to search for a book, that is both french and italian, you need 2 annotations, once using french, once using italian 09:03:25 TimCole: that won't happen 09:03:49 ... maybe we should wait on your i11n meeting? 09:04:30 r12n: we can do an extra meeting with you guys 09:04:55 ( some background on the i18n metadata topic, discussed in the i18n group : https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion ) 09:05:03 ... one more thing: the meaning of the language property is different for the target and the body 09:05:25 ... for target, it is metadata, for body it is more text processing related 09:06:04 bjdmeest_ has joined #annotation 09:06:14 scribenick: bjdmeest_ 09:06:20 azaroth: I think #209 is the same as #206, or #221 09:06:22 https://github.com/w3c/web-annotation/issues?utf8=✓&q=is%3Aissue+label%3Ai18n-review+-label%3Aeditor_action+is%3Aopen 09:06:25 ivan: so we can close #209 09:06:55 ... r12a, these have to be closed recently? 09:07:08 link: https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Ai18n-review+-label%3Aeditor_action+is%3Aopen 09:08:27 [all]: buy r12a, thanks! 09:08:31 s/buy/bye/ 09:08:41 TimCole: about #214 09:09:05 https://github.com/w3c/web-annotation/issues?utf8=✓&q=is%3Aissue+-label%3Ai18n-review+-label%3Apostpone+-label%3Aeditor_action+is%3Aopen+ 09:09:42 ivan: these should be closed 09:10:28 azaroth: I think #214 are just editor actions 09:10:38 ... and also #227 09:10:50 azaroth: about #214 09:11:26 ... point 1, I think @context can go anywhere 09:11:38 ... point 2, datatype for rights is unclear 09:12:33 TimCole: text-based rights are deemed useless in many communities 09:12:53 azaroth: point 3: cardinalities about rights should be 0..1 09:13:06 nickstenn: you could always have a dual-license as a new URI 09:13:37 azaroth: point 4: for republishing annotations, we only use an IRI 09:14:00 azaroth: point 5 and 6 also 09:14:08 ... if no problems, moving on. 09:14:21 nickstenn: about #227 09:15:06 ... we should not talk about encoding 09:15:40 ... this is about text quote selector 09:16:11 ... just going to close it 09:17:14 planning: small break, then 1 hour testing, then lunch 09:17:30 uskudarli_ has joined #annotation 09:18:15 Thanks to bjdmeest for the scribing 09:21:34 Present+ Sergiu_Gordea 09:22:09 For the minutes, from takeshi: the unicode consortium's table of characters that share a codepoint between CJK languages, but must be rendered differently: http://unicode.org/charts/PDF/U3400.pdf 09:29:31 TimCole has joined #annotation 09:32:23 scribenick: nickstenn 09:32:59 TimCole: our goal is to talk about testing 09:33:07 Topic: Testing 09:33:08 ... plan is 10-15m introduction about what's in progress 09:33:22 ... and then bigbluehat will demo what we've been up to with Shane 09:33:39 ... we'll spend another ~1h after lunch on testing 09:34:16 ... any objections? *crickets* 09:34:38 ... Here are the tests we've been working on https://github.com/Spec-Ops/web-platform-tests/tree/master/annotation-model 09:34:59 ... goal here is to provide a platform for testing the data model and vocabulary in particular 09:35:11 ... after lunch we'll discuss whether the same platform will be used/usable for the platform 09:35:36 ... extensive documentation in the repository about how this all works 09:35:37 gsergiu has joined #annotation 09:36:20 ... the basic summary is: we're looking at the [RFC 2119 statements] in the spec 09:36:42 ... we translate those into tests ... a .tst file, which run in the test harness 09:36:56 ... we're trying to record which implementations have correctly implemented which features 09:37:20 spreadsheet: https://docs.google.com/spreadsheets/d/1QwhHYyEd-106nvwe_q-A9z02wO9R-Oa7l5vnmMlYTQ0/edit 09:37:24 ... azaroth has been working on a spreadsheet that tries to capture all the testable assertions ^ 09:37:36 And I filled out all the MUST/SHOULD/MAY for 1 last night and this morning 09:39:20 ... [walking through a (different) document with extracted testable assertions from the model spec] 09:40:21 ... looking at these makes us wonder whether all of these assertions can been tested using jsonschema 09:40:40 ... (which is the way the current tests work) 09:40:58 q+ to suggest we should not validate data values for language and format 09:40:59 ... having done that, 09:41:23 ... have manually created schemas for §3.1 in the model 09:41:55 ... e.g. "MUST have a context" https://github.com/Spec-Ops/web-platform-tests/blob/master/annotation-model/common/context.json 09:42:13 ... e.g. "context MUST have value <...>" https://github.com/Spec-Ops/web-platform-tests/blob/master/annotation-model/common/contextValue.json 09:44:29 ... [showing the format of a jsonschema, including test metadata such as "assertionType": "(must|should|may)" and a human-readable error message] 09:46:12 Link: http://json-schema.org/latest/json-schema-validation.html 09:47:12 ivan: there are tools for validating against jsonschema documents available in a variety of programming languages? 09:47:27 LuSu has joined #annotation 09:47:38 Link: http://jsonschemalint.com/draft4/ 09:47:44 TimCole: yes, and there are also web services which can be used such as http://jsonschemalint.com/draft4/ 09:48:06 http://json-schema.org/latest/json-schema-validation.html is the one we're using 09:48:08 v5 basically 09:50:03 ... here's the example schema for checking that we have an @context property, which may be an array, one element of which should be our context IRI: https://github.com/Spec-Ops/web-platform-tests/blob/master/annotation-model/common/contextValue.json 09:50:14 ... unfortunately, this doesn't test that 09:50:29 ... it tests that the *first* item in the array is our context 09:50:57 ... which may result in false negatives -- conforming documents will fail the jsonschema validation 09:52:59