IRC log of csvw on 2015-07-01

Timestamps are in UTC.

13:34:37 [RRSAgent]
RRSAgent has joined #csvw
13:34:37 [RRSAgent]
logging to http://www.w3.org/2015/07/01-csvw-irc
13:34:39 [trackbot]
RRSAgent, make logs public
13:34:39 [Zakim]
Zakim has joined #csvw
13:34:41 [trackbot]
Zakim, this will be CSVW
13:34:41 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
13:34:42 [trackbot]
Meeting: CSV on the Web Working Group Teleconference
13:34:42 [trackbot]
Date: 01 July 2015
13:49:39 [danbri]
danbri has joined #csvw
13:52:11 [danbri]
who is around for a call?
13:55:33 [ivan]
I am here
13:55:43 [ivan]
zakim is just a bot:-(
13:58:13 [gkellogg]
gkellogg has joined #csvw
13:58:55 [JeniT_]
JeniT_ has joined #csvw
13:59:08 [JeniT_]
I am here
13:59:20 [ivan]
That makes the three of us already:-)
14:00:02 [danbri]
webex
14:00:07 [danbri]
step one: remember annoying company name
14:00:13 [gkellogg]
I;m here, but getting the “meeting canceled” problem on webex
14:00:39 [danbri]
trying the android app, it remembers no meeting info from prev usage :|
14:00:44 [ivan]
dan, jeni: https://www.w3.org/2013/csvw/wiki/WebEx
14:00:54 [danbri]
https://lists.w3.org/Archives/Public/public-csv-wg/2015Apr/0078.html
14:01:07 [danbri]
step 2: search mail for: "from: ivan webex"
14:01:12 [danbri]
step 3: ask ivan :)
14:04:41 [JeniT]
https://github.com/w3c/csvw/issues/631
14:05:42 [danbri]
+1
14:05:58 [gkellogg]
+1
14:07:30 [danbri]
jenit: can close #631 #634
14:07:47 [JeniT]
https://github.com/w3c/csvw/issues/632
14:07:53 [danbri]
leaves us with #632
14:08:46 [danbri]
can we change default of trim to true?
14:08:54 [danbri]
jenit: doesn't matter as non normative parsing stuff anyway
14:10:36 [danbri]
jenit: q of whether the data protocols thing from Open Knowledge that has trim in it
14:10:42 [danbri]
ah no it doesn't
14:10:45 [danbri]
so i am happy
14:10:59 [danbri]
rrsagent, pointer
14:10:59 [RRSAgent]
See http://www.w3.org/2015/07/01-csvw-irc#T14-10-59
14:11:20 [danbri]
rrsagent, please make logs public
14:11:54 [JeniT]
https://github.com/w3c/csvw/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3A%22For+LCCR%22+-label%3A%22Use+Case+Document%22+-label%3A%22Test+suite%22
14:11:56 [danbri]
gkellogg: gigantic test case repositories are my destiny
14:12:08 [danbri]
jenit: text direction…
14:12:20 [danbri]
…+ others have pull requests in flight
14:12:34 [danbri]
r12a = richard ishida
14:12:44 [danbri]
waiting on review/responses
14:13:06 [danbri]
i.e. https://github.com/w3c/csvw/issues/620 https://github.com/w3c/csvw/issues/618 https://github.com/w3c/csvw/issues/617
14:13:11 [danbri]
ivan: #524 can be closed?
14:13:33 [danbri]
resolved unanimously to close
14:13:49 [ivan]
rrsagent, pointer?
14:13:49 [RRSAgent]
See http://www.w3.org/2015/07/01-csvw-irc#T14-13-49
14:14:11 [danbri]
https://github.com/w3c/csvw/issues/555 Non-standard well-known location processing
14:14:25 [danbri]
gkellogg: Martin Duerst had a response to Mark's point
14:14:49 [danbri]
… ah no, reading an old mail.
14:15:11 [danbri]
(mail of 19th)
14:15:41 [danbri]
ivan: i offered it as an at risk feature
14:19:36 [danbri]
jenit: expectation is that any impl that isn't ignoring ALL of the metadata discovery will do this…
14:19:44 [danbri]
… if you're not providing overriding
14:20:32 [danbri]
gkellogg: if csv becomes important for seo purposes and if google etc doesn't look in these other places then it won't get used
14:20:58 [danbri]
people won't put things at well-known other than our defaults
14:21:52 [danbri]
jenit: in order to move us on, 2 pieces within #555 … there is the issue about whether we have this .well-known and …
14:22:26 [danbri]
… our current position (merged in) is that we use this for metadata discovery but we have labelled it as 'at risk' with wording asking for whether it is useful and represents impl difficulties
14:23:02 [danbri]
danbri: that will help me get reviews from search engine world
14:23:12 [danbri]
jenit: tag and david disagree
14:23:41 [danbri]
… I think we say the wording goes in. David may then collect impl feeedback/reviews ...
14:24:08 [ivan]
+1
14:24:12 [gkellogg]
+1
14:24:18 [danbri]
+1
14:24:58 [danbri]
gkellogg: also the aspect of using HTML as a discovery path
14:25:22 [jtandy]
+1
14:25:28 [danbri]
jenit: let's discuss now
14:25:34 [JeniT]
+1
14:25:40 [ivan]
rrsagent, pointer?
14:25:40 [RRSAgent]
See http://www.w3.org/2015/07/01-csvw-irc#T14-25-40
14:25:45 [danbri]
(i.e. unanimous amongst attendees)
14:25:53 [gkellogg]
https://github.com/w3c/csvw/pull/627
14:25:58 [danbri]
#627
14:26:12 [danbri]
gregg put text about identifying metadata against a CSV via an HTML document
14:26:19 [danbri]
essentially embedding the metadata in a script tag
14:26:29 [danbri]
jenit: i feel quite uncomfortable about this being a new thing we add now
14:26:48 [danbri]
… something like this should be a separate note or something that comes on top of or addition to what we have as spec
14:27:15 [danbri]
(kicked off webex)
14:27:23 [danbri]
(i.e. no audio …redialing)
14:28:40 [danbri]
ivan: gregg, details i don't remember, … but yes, we can have json-ld in a <script> within HTML … but what is the base URI rule?
14:29:07 [danbri]
gregg: this doesn't deal with tables within documents
14:29:20 [danbri]
any table URL would be expected to identify a CSV file
14:29:46 [danbri]
base used
14:30:00 [danbri]
http://www.w3.org/TR/json-ld/#embedding-json-ld-in-html-documents
14:32:09 [danbri]
jtandy: i built one of these things for camborne weather data example
14:32:27 [danbri]
could we in the same text for avoiding wellknown, mention that this is an alternative
14:32:35 [danbri]
though i hesitate about entangling them
14:40:03 [danbri]
...
14:40:06 [danbri]
jenit: #609
14:40:12 [JeniT]
https://github.com/w3c/csvw/issues/609
14:40:13 [danbri]
https://github.com/w3c/csvw/issues/609
14:40:28 [danbri]
jenit: i've not tried to get it registered (yet). I could do that or we could decide something else.
14:40:44 [danbri]
… issue is URLs vs media formats within template format descriptions
14:41:01 [danbri]
the TAG really wanted us to use media types rather than URLs, since 3rd parties can register media types
14:41:21 [danbri]
ivan was concerned about time it takes to generate media types
14:41:35 [danbri]
i proposed a test to see if we could get it done within a week
14:41:38 [danbri]
but i didn't
14:41:53 [danbri]
jtandy: the week included your time not just theirs
14:42:00 [danbri]
jenit: fair enough
14:42:41 [danbri]
ivan: I looked into this for csvm and so it was a bit easier as a w3c person
14:42:49 [danbri]
but a random member of the public will find it much harder
14:43:08 [JeniT]
https://www.iana.org/form/media-types
14:43:09 [danbri]
when i did it, for some obscure reason, some parts didn't go through well due to mail issues. Yakov got it through.
14:43:18 [JeniT]
got to through searching “register media type"
14:44:13 [danbri]
dan: [stuff we already have done]
14:44:40 [danbri]
jenit: TAG's pushback was that we are defining refs to media types, and the right thing to do/use is the media type type of string, not a url
14:44:50 [danbri]
ditto numbers, dates etc.
14:45:04 [danbri]
native,understood,recognised etc rather than wrapping it in a URI
14:46:39 [danbri]
ivan: I would (informally) object to using media types
14:47:03 [danbri]
zakim, who is making noise?
14:47:03 [Zakim]
sorry, danbri, I don't know what conference this is
14:49:42 [JeniT]
PROPOSAL: We should use media types rather than URLs when referring to formats from transformation descriptions
14:49:54 [JeniT]
+1
14:50:31 [ivan]
(informally) object (-1): for most of the average developers the registration is too arcane and complicated; it will not happen...
14:50:37 [jtandy]
-1 because I think that this will add blockage to people describing their templates correctly- they will use a more generic media type and use the title as an identifier instead (which is wrong)
14:51:01 [gkellogg]
-1: This is too high a barrier for general usage, and media types have long been missused. URIs can identify anything, including media types, and this is consistent with being a W3C spec.
14:51:03 [danbri]
-1 # I don't believe it plausible that relevant types will get registered, and an unknown but derferencable URL is more useful than a made up pseudo-mimetype string.
14:51:24 [JeniT]
PROPOSAL: We continue to use URLs rather than media types in transformation descriptions
14:51:26 [JeniT]
+1
14:51:30 [jtandy]
+1
14:51:31 [gkellogg]
+1
14:51:31 [JeniT]
s/+1/+0/
14:51:31 [danbri]
+1
14:51:39 [ivan]
rrsagent, pointer?
14:51:39 [RRSAgent]
See http://www.w3.org/2015/07/01-csvw-irc#T14-51-39
14:52:29 [danbri]
other issues...
14:52:41 [JeniT]
https://github.com/w3c/csvw/issues/46
14:52:47 [danbri]
https://github.com/w3c/csvw/issues/46
14:53:44 [danbri]
jenit takes editor action on this.
14:53:52 [danbri]
Only other LCCR issues are UC doc + test suite
14:54:58 [danbri]
jenit: I can spend next tues to go thru that
14:55:14 [danbri]
gkellogg: I need to add 1 more test for a non standard location
14:55:31 [danbri]
jtandy, /me comments aren't included in the minutes
14:55:42 [danbri]
jtandy noted: one test still not done: table group incompatibility
14:56:40 [gkellogg]
{+url}.json
14:56:41 [gkellogg]
csvm.json
14:57:22 [danbri]
jenit: what needs doing re chairing w.r.t. WG extensions
14:58:21 [danbri]
ivan: situation is: we have to extend the WG charter because we are close to the end, and that has to be 1st discussed at W3M. So what I already discussed with our domain lead, Ralph, is that he'll start discussion in W3M for an extension. I gave him an overview of where we are. Not this week, they have a f2f, but hope they'll do so in W3M meeting in exactly 1 week.
14:59:13 [danbri]
… this means that as we go to publication of CR, we'll get the extension. We agreed here to give ample time e.g. to end of feb, so we don't have to go back again for another. I hope that will be done, but knowing the timetable of Ralph, … it might be helpful if Jeni replies to mail from Ivan cc Ralph
14:59:33 [danbri]
…. this is one part. The other is, 1st of all we have to decide when we think we can publish.
15:00:34 [danbri]
Timing issues. Since this is a last call CR transition, it requires a transition call to be scheduled. The other problem is that I planned vacations week of July 13 i.e. in roughly 2 weeks. If we think we can go to a transition call, with final docs, … next week [not Use Cases as not a REC track doc, but including Tests] …
15:01:27 [danbri]
ivan: i can check Phillipe's calendar. The publication itself should happen week after when I may be not around. WG has been great at publishing pubrules-ready docs in Github, so they may be able to take it directly without Ivan, or maybe with some other help
15:01:41 [danbri]
jenit: could we pub the week after?
15:01:48 [danbri]
ivan: i'm off for 3-4 weeks (hopefully...)
15:02:20 [danbri]
ivan: if we agreed on 1 day when i'd help, I'd likely do it for a beer, since the docs are usually not too messy
15:02:31 [danbri]
… am more worried about the transition call as this requires some preparation
15:02:46 [danbri]
jenit: let's discuss by email, decide next week on pub dates?
15:02:57 [danbri]
ivan: we have to decide on the transition call, that's the difficult one
15:03:06 [danbri]
adjourned
15:37:38 [JeniT]
JeniT has joined #csvw
17:01:18 [Zakim]
Zakim has left #csvw