09:15:13 RRSAgent has joined #csvw 09:15:13 logging to http://www.w3.org/2015/02/12-csvw-irc 09:15:36 Meeting: F2F meeting, 1st day, 2015-02-12 09:17:24 Present: Jürgen, Davide, Dan, Jeremy, Jeni, Gregg, Ivan 09:17:36 scribenick: danbri 09:18:11 jumbrich has joined #csvw 09:18:21 introductions 09:19:41 jenit: orientation … 09:21:29 reviewing charter 09:21:29 http://www.w3.org/2013/05/lcsv-charter.html 09:21:49 DavideCeolin has joined #csvw 09:22:03 discussion of xml mapping 09:22:16 JeniT has joined #csvw 09:22:21 proposal: XML mapping will not be undertaken by this WG (for lack of interest) 09:22:25 +1 09:22:28 +1 09:22:30 +1 09:22:31 +1 09:22:32 +1 09:22:36 +1 09:22:36 jtandy has joined #csvw 09:22:44 +1 09:23:03 phila has joined #csvw 09:23:03 resolved: XML mapping will not be undertaken by this WG (for lack of interest) 09:23:10 phila, are you in the building? 09:23:33 yes. waiting in recrption 09:23:46 ed can come get you 09:24:19 jenit: use cases + requirements may need some rounding out to publish as a Note (tidy issues etc) but is basically there 09:24:26 (reviewing deliverables) 09:24:33 Metadata vocab for CSV data ... 09:24:48 gregg: do these docs all need some review w.r.t. what we've done 09:24:55 http://www.w3.org/2013/05/lcsv-charter.html#deliverables 09:25:06 jtandy: some issue work, … 09:25:21 … we have implicit u/standing in issue list but may be hard for outsiders to follow 09:27:11 1. turn requirements into much more structured text. 2. review both requirements and the usecases against what we have actually done. 3. need to close out the 9 issues that are in the doc, 3 of which need discussion in this meeting. 09:27:27 … 09:27:34 open vs closed validation 09:27:45 closed is "these are the only cols in csv, error if others" 09:27:53 open is "unexpected columns allowed" 09:28:02 jtandy: we discussed phantom/virtual columns 09:28:07 currently you need same number of cols 09:28:20 jtandy: also foreign keys only working in batch of files -> is on agenda 09:28:29 discussing Metadata doc for CSV. 09:28:56 is its own doc. whereas, 09:29:05 Access methods for CSV metadata is a portion of larger doc 09:29:22 Mapping mechanisms: for conversions into RDF and into JSON 09:29:27 this meets our 4 deliverables 09:29:44 jenit: our milestones … we are behind 09:30:13 ivan: (re process) formally speaking this milestone doc is outdated because W3C process has changed. Last Call and Candidate Rec are simplified as 1 step. 09:30:13 phila_ has joined #csvw 09:30:29 .. we need to count on 6 weeks for AC vote 09:30:43 so there needs to be 6 weeks before rec 09:31:02 phila_ has changed the topic to: Agenda: https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02 09:31:04 the last step (lcc and pr) distance between two depends on us, i.e. where we are w.r.t. implementations. No formal rule. 09:31:21 JeniT: last call CR is supposed to be … all known issues closed resolved, ready for impl 09:31:33 LCCR we need two implementations (according to whatever we define) 09:31:49 independent impl for each "feature", although we need to be clear what we think a feature is 09:31:57 conversions, metadata finding / merging, … 09:32:09 … then validation 09:32:17 gregg: we also define a viewer 09:32:29 ivan: is it in the charter? 09:32:37 jenit: it is defined non-normatively 09:32:46 ivan: I would propose that we do not talk about viewers as a normative thing 09:32:50 brings on extra load 09:33:04 gregg: raises the question of talking about text direction as it only pertains to viewing 09:33:42 discussion of whether text direction is normative 09:34:13 jtandy: somebody who will use this output data, may use the metadata to provide additional info ... 09:34:15 ivan: minor issue 09:34:24 lets not talk about viewers in terms of normative, ... 09:34:49 gregg: in terms of impl, ivan's and mine, … transformation implementations, … with a small amount of validation but not point where we can pass tests 09:35:11 ivan: regarding formalities, … 09:35:22 … once doc is in PR it is owned by w3c team and not wg any more 09:35:28 our charter ends at end of august 09:35:39 if by end aug we are at PR we can finish and publish without any formal problem 09:36:00 jenit: hard hard deadline is end aug PR then? 09:36:03 ivan: ideally yes 09:36:33 … even with mood of much more stringent oversight, if we have a LC CR available end of [northern-hemispheric] Spring early Summer 09:36:36 … early June, ... 09:36:43 then getting a 6 months cr, ... 09:36:53 …should be ok. Otherwise it could be a problem. 09:37:08 Phil: this group is going so fast and well that would not be a problem 09:37:40 jenit: hard hard deadline, early june for lccr as our next big milestone 09:37:50 jenit: I'd like us to get there sooner 09:38:19 danbri: attendance is an issue 09:38:34 jenit: discussing things I wanted to cover w.r.t. charter review 09:38:53 ivan: my feeling for realistic planning, is a new series of drafts for entire rec track set, mid-end march. 09:39:10 … and then, all issues this solves, it would clarify things for impl 09:39:31 if that goes well and there are no major issues, we can publish an LC CR mid may, end may, … effectively June. 09:39:46 jenit: also let's discuss w.r.t. charter, the aspect of parsing CSV files 09:40:00 that is explicitly not in formal scope 09:40:08 gregg: although we do define some dialect 09:40:13 ivan: non normatively 09:40:22 jenit: this is an area of difficulty 09:40:34 since anyone actively implementing needs an actual parser 09:40:51 so not having the definition normative actually leads to a situation with inconsistencies between implementations 09:41:06 from that p.o.v. it is a bad thing 09:41:18 … w.r.t. scoping and reduced workload it is good not to take on extra work 09:41:30 ivan: seems we have lost Yakov since he changed jobs 09:41:47 gkellogg has joined #csvw 09:41:55 … the w3c management discussion was that "we do not standardize CSV" 09:42:10 … pref is for IETF to handle that layer 09:42:20 the discussion w/ Yakov was that it could be handled there 09:42:36 ivan: I have no idea what if anything is happening there 09:42:54 gregg: we should probably look at our dialect defs then 09:43:02 parameterized aspects, separators, quotes etc 09:43:07 q? 09:43:14 Zakim has joined #csvw 09:43:22 zakim, this is CSVW 09:43:23 sorry, danbri, I do not see a conference named 'CSVW' in progress or scheduled at this time 09:43:38 jenit: most CSV files on the Web are not in fact CSV files per the IETF spec 09:43:45 which is the motivation for the dialect description 09:44:02 which is about parsing a text file into a tabular data model, rather than a proper CSV into... 09:44:23 jenit: let's look at this when we talk more about parsing 09:44:47 jumbrich: we sent around report end of 2014, examined 80k CSV files, 20% had some errors via slightly modified Python lib 09:44:54 q+ to ask about test suites 09:44:57 also the delimiter was in 80% a comma 09:45:16 we found tab in 3.8% of the docs 09:45:23 jenit: how did you choose the docs? 09:45:37 jumbrich: via ckan repo 09:45:53 jenit: you may have missed some defined as TSV then 09:46:00 ivan: having data is a good thing to have 09:46:16 gregg: do we consider tsv a dialect of csv? 09:46:25 [yes, ish] 09:46:42 jenit: the wording of the docs i've worked on tries to use 'tabular data' 09:46:48 from the charter: "The mission of the CSV on the Web Working Group, part of the Data Activity, is to provide technologies whereby data dependent applications on the Web can provide higher interoperability when working with datasets using the CSV (Comma-Separated Values) or similar formats." 09:46:55 ivan: a minor thing, … in our docs for metadata, we rely on the suffix being .csv 09:46:58 jenit: no we don't 09:47:12 gregg: no, filename .json 09:47:20 ivan: withdrawn, you're right. 09:47:35 phila: charter mentions CSV explicitly in the charter, we use CSV as a generalization of tabular data 09:47:36 q? 09:47:39 ack phila 09:47:39 phila, you wanted to ask about test suites 09:47:39 ack me 09:48:01 phila: Use case doc has lots of data, is it going to be turned into a test suite? 09:48:07 jtandy: it is avail for use in tests 09:48:21 … we should talk about usecases -> specs -> test suite to have consistent examples throughout 09:48:33 gregg: i have been adapting the examples as i maintain tests 09:48:43 … my intention w/ examples was to go back into docs 09:48:52 completely agree that our usecases should ... 09:49:05 ivan: let's be careful, the use cases themselves as test cases, … are unusable 09:49:07 jtandy: +1 09:49:28 ivan: each use case should have a repr in test cases but perhaps indirectly 09:49:40 ... 09:49:45 gregg: staggering combinatorics 09:50:02 you test the smallest things, … different places in diff merged files, … 09:50:19 jenit: the model that i would suggest is that we continue to focus not on the parsing 09:50:29 we have dialect as a set of hints, … 09:50:32 … but not formal 09:50:50 gregg: in my testing, … might want a class of tests, merged metadata in output 09:51:05 ivan: we need something that says "of these scattered files these are the final aggregated metadata items" 09:51:09 jenit: yes 09:51:28 … re test suite input docs, informed by use cases but CSV files that do not require any dialect description in order to process them 09:51:41 jtandy: test should say "this test inspired by UC-xyz" 09:51:51 …. palo alto tree data. also govt salary thing. 09:51:59 these came right through from UCs 09:52:02 others less direct 09:52:31 ivan: unfortunately, some entries in the dialect that we can treat as you said jtandy, … e.g. separator 09:52:43 but others like no. of rows / cols, that you will want to ignore, that affect our processing 09:52:49 jenit: or _might_ affect 09:52:55 ivan: but there are some that might 09:52:59 those have to be tested 09:53:19 gregg: we could divide the dialect info into parts that might affect parsing 09:53:28 [...] 09:53:36 gregg: do we want to test some TSVs? 09:53:39 jenit: no 09:53:43 gregg: can we have a resolution 09:54:12 proposed: we will only use CSV files in our test suite (not TSV, not anything that needs dialect description) 09:54:22 jtandy: tests will be inspired by the use cases, but skipping rows, dialects etc., we'll normalize into clearer CSV 09:55:00 +1 09:55:07 +1 09:55:14 +1 09:55:19 +1 09:55:51 +1 09:56:09 CSV = IETF CSV with UTF-8 & LF or CRLF for line endings 09:56:51 gregg: things we're not processing: encoding, line terminator, quote char, double quote, deliminator, trim … 09:57:03 jenit: assume no trim 09:57:10 resolved: we will only use CSV files in our test suite (not TSV, not anything that needs dialect description) 09:57:14 +1 09:57:16 +1 09:57:22 RESOLVED: we will only use CSV files in our test suite (not TSV, not anything that needs dialect description) 09:57:37 ivan: returning to q, … do we know what is happening with IETF 09:58:02 danbri: I assume nothing 09:58:26 jenit: we know of nobody having picked it up after Yakov's work 09:58:33 people from this group could get involved 09:58:57 ivan: since it was mentioned in charter we will need to be ready to explain this situation. 09:59:40 jtandy: re charter, … the piece that we have gone for "simple mapping": that we discussed templated mapping, … haven't seen anything active on this 09:59:54 danbri: I circulated a draft charter ~nov but it got v little discussion, i think ok to wait 10:00:02 jtandy: when we publish we should refer to CG charter 10:00:24 … e.g. point from the conversion doc to CG [if it exists] 10:00:34 ivan: at this point there is no CG just a mail from dan 10:00:51 jtandy: we talk in the specs about template formats 10:01:10 q+ 10:01:17 gregg: something somewhere about tempalting? 10:01:19 ivan: shouldn't be 10:01:49 we had some discussion of what the input to templates might be 10:02:02 in simple mapping itself it should be silent on any complex mappings 10:02:16 gregg: if we say something normative it would seem that we need a test 10:02:18 q- 10:02:23 q+ to suggest citing an issue not a mail 10:02:50 jenit: we have extension conversions item for tomorrow 10:03:36 jenit: 3 things before 10:30. 1) gregg talk about test suite 2) go through agenda incl. ivan's notes 3.) that's it. 10:03:59 Agenda: https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02 10:04:27 q? 10:08:11 gkellogg: RDF tests use graph isomorphism, JSON use deep equality 10:08:33 … tests use the output that my implementation gives as the target output 10:09:42 … I set any optional outputs (like provenance) as false, as that’s where it’s likely there will be implementation differences 10:10:12 q- 10:10:56 … the metadata components of the tests are implicitly referenced but should be located by the implementation based on the location of the CSV file 10:11:46 … there’s also an option to provide user-defined metadata, and to fake the creation of the Link header 10:12:24 https://github.com/w3c/csvw/tree/gh-pages/tests 10:12:49 not to be confused with https://github.com/gkellogg/csvw-test 10:12:54 … which is a test runner 10:13:19 ivan: I’d love separate folders for each test 10:14:15 discussion of file names vs folders 10:14:34 gregg: this happens to be the test runner running off of my distiller dir 10:14:41 … which is v reminiscent of the RDFa tests 10:15:00 … probably has to start up, can run a test, pass/fail, check details to see what the input files were, what the result was 10:15:20 … you can run whole set and get EARL output 10:15:34 jenit: if you are someone making a new impl, what process to integrate with this? 10:15:45 gregg: for me I integrate with my impl's own testing 10:15:55 i download the manifest and iterate through the downloaded tests 10:16:11 jenit: and if you are doing an impl, … that is based on say .js, that doesn't have any RDF processing, ... 10:16:22 gregg: in my processing I turn it into a json-ld manifest and then run over the json 10:16:27 we could easily maintain a json version 10:16:34 jenit: can we do that please, easier … 10:16:44 ivan: this or other one, relies on some sort of web service to run the conversion 10:16:52 gregg: which is why i run it off my site 10:16:57 ivan: i use a jquery extension 10:17:03 it will save time for some but not for all 10:17:14 … my stuff tries to do a jquery extnsion 10:17:23 read in csv file, … display as turtle, 10:17:31 gregg: people have used node.js to do that 10:17:44 ivan: then i'll need to compare jquery promises w/ node promises, … difficult 10:18:06 jenit: msg then is that, if you are implementing, … you'll need to handle these manifests/tests somehow 10:18:25 gregg: I am happy to make sure we have a json-ld representation of the manifests 10:19:03 danbri: woudl generated json-ld be acceptable to non-rdf wonks? 10:19:23 gregg: [shows pretty looking json] 10:19:29 jenit: Validation tests 10:19:33 gregg: nothing so far 10:19:51 … there is a vocabulary definition … 10:19:55 …does include diff types of test 10:20:10 a positive eval syntax, and a csv to rdf, csv to sparql, csv to json, … metadata to rdf, … 10:20:20 gregg: I can add more test types for validation and its variations 10:20:27 q? 10:20:41 ivan: so the program that you used in past to generate a formal report from the EARL should just work 10:20:43 gregg: yes 10:20:51 ivan: this was used in earlier groups to generate reports 10:20:59 … question now is how many impl we will have 10:21:08 ivan: for time being we have one 10:21:14 … which the test results are based on 10:21:29 gregg: I asked AndyS, but no response yet 10:21:38 jumbrich: how much effort? 10:21:59 ivan: only part which is relatively complex is managing/merging the metadata, maybe extracting all the info for each cell that the metadata really gives you 10:22:15 once that mechanism is in place, generating rdf e.g. via rdflib, or json, … is relatively easy 10:22:24 finding/extracting metadata per cell is hardest part 10:22:49 jumbrich: i don't understand that aspect, i thought we start with a metadata file 10:23:02 ivan/jenit: that's the naive view, the spec is more complex see discussion later 10:23:10 jumbrich: we have a uni project around this, ... 10:23:24 ivan: I didn't attempt python but if uni team want to do python i am happy to help 10:23:35 … rdflib is a v solid basis 10:23:55 gregg: and ruby is pretty similar; my impl is unencumbered 10:24:04 jumbrich: we used java before 10:24:21 ivan: ideally you would use python since if andys does it he'll use java 10:25:50 jenit: after the break we'll look at parsing csv + tab data 10:26:09 after lunch we'll have 1.5h on metadata discovery and merge, … then a break 10:28:56 reviewing https://www.w3.org/2013/csvw/wiki/F2F_Agenda_2015-02 10:29:44 q+ lunch logistics 10:29:51 q- 10:29:52 q- 10:29:56 q- lunch logistics 10:31:53 gregg: let's get resolutions in github, and editor actions, being clear what the action is 10:32:10 ivan: at end of 2 days we'll have a list of issues assigned to editorial work 10:32:24 ivan: we turned into github issue freaks after tpac 10:32:26 :) 10:32:48 jenit: what we have here through this agenda are all the issues marked as needing discussion 10:32:56 … still open but not at resolved or editor-action level 10:33:00 aiming to get get through all of those 10:33:14 … comment in github needs to be clear on what the editor action is 10:33:54 BREAK, back at 10.45. 10:42:29 jumbrich has joined #csvw 10:43:31 gkellogg has joined #csvw 10:47:00 gregg: consider branchs, pull requests etc., … 10:47:09 jenit: we could quickly now go through those 10:47:56 jtandy: i have queued up a bunch of things to do on the rdf conv doc 10:48:07 looking at pull #187 10:48:23 gregg "conseq of using about predicate url etc" 10:49:43 #187 not currently mergeable 10:50:57 - topic Tabular Data Model 10:51:09 jenit: need to merge in #192 … joins core and annotated data models 10:51:18 everyone happy? [nodding yes] 10:51:25 ivan: good simplifying impact 10:51:52 jenit: so had two kinds of level, annotated tabular data model, … and grouped, which says "there is a group of tables" 10:51:58 … and then that group may also have some annotations 10:52:20 … so the most useful is the annotated table 10:52:55 jenit: this is really simple, exactly what you'd expect from a tabular data model. You have a table with rows in it, cells in it, cols in it. Rows and cols have numbers. Cells belong to a particular row/column. 10:53:20 …. the bit that goes anywhere near controversial is distinction between string value of cell and value value of cell 10:53:28 … which is the parsed and processed datatyped value 10:53:37 for eg. if string value is empty string, cell value is null 10:53:49 various bits from the metadata can affect the cell value 10:54:08 value value can be an array 10:54:29 gregg: an rdf issue, a list or multiple values 10:54:34 jenit: that is the data model. 10:54:55 all of these can be annotated. Idea is that all the ops that are described 10:55:05 (annotations live in the metadata) 10:55:24 gregg: except we don't yet provide mechanisms to annotate all these things e.g. cells 10:55:31 jenit: well you can inherit into them 10:55:42 ivan: when you talk about annotation, this is not the annotations of the annotation wg 10:55:47 jenit: corret 10:55:49 ^c 10:56:13 … annotations, properties, attributes, … all mean essentially the same. Something will always get confused. 10:56:55 ivan: probably worth adding a note here that the term annotation as used in this doc is not exactly same as used in the Annotation WG 10:57:13 acti*on on someone? 10:58:37 (admin: we're capturing all actions into github not w3c tracker) 10:58:47 jenit: this data model is basis for conversions 10:58:55 …everything in the metadata doc should talk about how it affects that model 10:59:07 gregg: there was an issue w/ cell values, reconciled in one of these pull requests 10:59:46 jenit: the bit then to discuss now is around parsing the CSV or other files INTO that model 10:59:56 we take the model as being the central thing through which everything passes 11:00:02 CSV TSV HTML tables etc etc 11:00:27 ...things like CSV but with extras e.g. HXL (see usecase) 11:00:42 https://data.hdx.rwlabs.org/dataset/hxl-validation-schemas 11:01:04 http://www.w3.org/TR/csvw-ucr/#UC-CollatingHumanitarianResponseInformation 11:01:23 https://github.com/w3c/csvw/issues/9 11:01:24 going through the issues… 11:02:54 from #9 -> http://w3c.github.io/csvw/use-cases-and-requirements/#UC-PublicationOfNationalStatistics 11:03:17 jenit: propose close #9, we handle being able to id places within csv files, and have other issues for notes/annotations on cells 11:03:26 "Locating data region(s) within a CSV file #9" 11:03:39 jtandy: presupposes we do not have 2 tables within one csv file 11:03:51 jtandy: we should be clear that we do not allow multiple tables within a single file 11:04:10 gregg: we distinguish CSV vs model created from it 11:04:28 if it was the more abstract sense, someone might create something that extracted tables, put them into a processable form 11:04:39 jenit: I think the metadata doc does make that distinction in most places except dialect descriptions 11:04:50 (except we have url ref back to src file) 11:04:59 ivan: we separate rfc blahblah as a diff issue? 11:05:22 jenit: not relevant unless we support referencing areas of a csv file in a diff way, e.g. to say 'this bit is the tabular data', … 11:05:32 ivan: RFC came up at TPAC for handling of Web Annotations 11:05:35 that's where it'll fit 11:05:37 ok 11:05:56 jtandy: the other thing this issue was about, … e.g. in usecase there were multiple header rows 11:06:05 now we have parsing suggestions that can hint about skipping 11:06:12 PROPOSAL: close #9 as handled by dialect description 11:06:15 +1 11:06:31 jtandy has joined #csvw 11:06:44 DavideCeolin has joined #csvw 11:06:52 logger, pointer? 11:06:59 rrsagent, pointer? 11:06:59 See http://www.w3.org/2015/02/12-csvw-irc#T11-06-59 11:08:39 https://github.com/w3c/csvw/issues/52 11:08:44 "Should we check integrity of CSV files in some way #52" 11:09:01 jenit: in data packaging spec which our work is based, … words around integrity checking 11:09:08 also subresource integrity checking 11:09:20 e.g. refs to scripts, you can provide an integrity url 11:09:38 see http://www.w3.org/TR/SRI/#use-cases-examples 11:09:43 jenit: we could do something like that 11:09:50 … I suggest we don't for now 11:10:07 ivan: that work is fairly early still 11:10:18 jenit: this can be explored later 11:11:02 rrsagent, pointer? 11:11:02 See http://www.w3.org/2015/02/12-csvw-irc#T11-11-02 11:12:04 Resolved: to not handle integrity. Editor action to remove the issue reference from the document. 11:12:21 https://github.com/w3c/csvw/issues/182 11:12:25 "Fall-back value of the `name` property? #182" 11:12:59 also similar, 11:12:59 https://github.com/w3c/csvw/issues/53 11:13:04 "Should there be limitations on the syntax of column names? #53" 11:13:13 taking #53 first, ... 11:13:33 jenit: these names get used in syntactic contexts that are restricted e.g. in json etc 11:13:42 "What syntactic limitations should there be on column names to make them most useful when used as the basis of conversion into other formats, bearing in mind that different target languages such as JSON, RDF and XML have different syntactic limitations and common naming conventions." 11:14:23 ivan: there are two things, … one is that we do say a name has to abide to restriction of templates. we have to. 11:14:39 … also we say if no name, but a title, then a name must be created from title so needs some normalization 11:15:40 gkellogg has joined #csvw 11:15:40 jenit: re #53, I proposed change from SHOULD to MUST re syntax constraints 11:15:48 you'd get an error if col had wrong names 11:15:57 jenit: metadata files themselves should always be validated 11:16:22 … checking the metadata is important 11:16:27 gregg: it's useful … but complex 11:16:41 ivan: I think we said these things are separable. The conversion doc starts with metadata that is correct, … 11:17:00 ivan: I use the name, rely on getting it from the metadata, … 11:17:23 jenit: it is correct for the conv doc to rely on the tabular data model, … but metadata doc has to be parsed and processed 11:17:34 gregg: e.g. must foreign keys be consistent? 11:17:51 you can still generate reasonable json and rdf even if keys are wrong 11:18:02 jenit: then we need this as an explicit choice and resolution 11:18:21 … if metadata isn't right, do we ignore those properties, provide an error/warning, etc? or error out completely 11:18:40 gregg: in my previous rdf processors, i've always tried to generate data when i can, ... 11:18:49 ivan: In this case, what we do is not only for conversion, … 11:19:01 … the metadata once it is there can be used for all kinds of other things 11:19:06 … in this sense they are separable 11:19:22 … i am in more favour of saying 'if it is not kosher then it is in error' 11:19:54 jenit: what you're suggesting there is that if the impl is a convertor, it should ignore unknown properties in the metadata, whereas if it is a validator it should report error 11:20:10 ivan: validators certainly should cry foul and not try to find a reasonable default 11:20:33 rrsagent, pointer? 11:20:33 See http://www.w3.org/2015/02/12-csvw-irc#T11-20-33 11:20:48 ivan: validator is a v diff thing 11:20:57 gregg: validating metadata vs validating csv files 11:21:16 … purpose of validator is checking data integ not syntactic correctness 11:21:50 ivan: [missed point] 11:21:57 gregg: processor can impl a relaxed mode 11:26:19 (discussing #53, see comments in github) 11:26:25 and #180 11:26:51