IRC log of csvw on 2014-11-19

Timestamps are in UTC.

14:53:01 [RRSAgent]
RRSAgent has joined #csvw
14:53:01 [RRSAgent]
logging to
14:53:03 [trackbot]
RRSAgent, make logs public
14:53:03 [Zakim]
Zakim has joined #csvw
14:53:05 [trackbot]
Zakim, this will be CSVW
14:53:05 [Zakim]
ok, trackbot; I see DATA_CSVWG()10:00AM scheduled to start in 7 minutes
14:53:06 [trackbot]
Meeting: CSV on the Web Working Group Teleconference
14:53:06 [trackbot]
Date: 19 November 2014
14:59:20 [danbri]
hi folks
15:00:06 [danbri]
ok per my proposal is that we do not meet formally this week, but if anyone wants to follow Jeremy's suggestion to talk about dates/functions/operators, we can chat via Zakim.
15:00:10 [danbri]
regrets from Jeni
15:00:11 [ivan]
Hi danbri, I come in a minute
15:01:03 [danbri]
15:01:06 [danbri]
too many tabs open!
15:01:48 [jtandy]
jtandy has joined #csvw
15:02:27 [Zakim]
DATA_CSVWG()10:00AM has now started
15:02:35 [ivan]
zakim, dial ivan-voip
15:02:35 [Zakim]
+ +44.207.346.aaaa
15:02:35 [Zakim]
ok, ivan; the call is being made
15:02:37 [Zakim]
15:02:42 [danbri]
zakim, aaaa is danbri
15:02:42 [Zakim]
+danbri; got it
15:02:47 [jtandy]
15:03:07 [Zakim]
15:03:18 [jtandy]
zakim, ??p6 is me
15:03:18 [Zakim]
+jtandy; got it
15:03:28 [danbri]
zakim, who is on the phone?
15:03:28 [Zakim]
On the phone I see danbri, Ivan, jtandy
15:03:35 [jtandy]
sorry - fire alarm test
15:05:56 [danbri]
talking dates, informally
15:06:02 [danbri]
[agreed not a full WG meeting]
15:06:30 [danbri]
15:06:46 [danbri]
jtandy: last week I said I'd look at ISO8601
15:06:50 [danbri]
it doesn't allow for pattern strings
15:06:57 [danbri]
gives a number of ways people can provide data
15:07:01 [danbri]
quite restricted
15:07:05 [danbri]
only uses gregorian calendar
15:07:12 [danbri]
wasn't quite what i expected of it
15:07:27 [danbri]
ivan: 8601 … some b/g ?
15:07:48 [danbri]
ivan: ah, … the one always cited.
15:08:19 [danbri]
jtandy: it doesn't allow you to say that I'll give month first then years then days (per US convention), or whatever pattern
15:08:25 [danbri]
… so this doesn't work for us
15:08:34 [danbri]
ivan: at least for RDF this is what we're supposed to use at output
15:08:52 [danbri]
jtandy: for RDF and for XML and a number of other places, 8601 is what is used
15:09:04 [danbri]
… however CSV is not so restricted so wild CSV has other date formats
15:09:26 [danbri]
…therefore for mapping we need to consume a natural date format and then publish it as ISO8601, xsd:dateTime etc
15:09:40 [danbri]
… I think from F2F the I18N guys said take a look at TR35
15:09:47 [danbri]
ivan: which is quite terrifying :)
15:09:52 [gkellogg]
gkellogg has joined #csvw
15:09:57 [jtandy]
15:09:59 [danbri]
jtandy: I've also looked at xpath, xquery functions
15:10:02 [danbri]
rrsagent, pointer?
15:10:02 [RRSAgent]
15:10:05 [danbri]
<- for gregg
15:10:31 [danbri]
… what happens there (url above) is that they provide a v good spec on how to turn ISO8601 internal date format into a natural date string
15:10:38 [danbri]
… but it is really very clear about how to do so
15:10:46 [danbri]
… even though it goes in the opposite direction to what we do
15:11:20 [danbri]
jtandy: specifically in section 9
15:11:21 [jtandy]
15:11:35 [danbri]
15:11:42 [danbri]
jtandy: if you go to 9.2.1 you see some examples
15:12:13 [jtandy]
15:12:27 [jtandy]
section 9.8
15:12:31 [danbri]
9.8 Formatting dates and times
15:13:19 [danbri]
danbri: i assume function can't be reversed as ambiguous (e.g. US mon/day day/mon order)
15:13:29 [danbri]
jtandy: see Picture String section
15:13:40 [danbri] The picture string
15:13:51 [danbri]
ivan: various of these are implemented across multiple languages
15:14:09 [danbri]
…however they don't define how to use such picture string
15:14:57 [danbri]
jtandy: various discussion on correct picture string representation
15:15:01 [danbri]
ivan: see 9.8.5 section
15:15:21 [danbri]
15:15:28 [danbri]
jtandy: examples of output
15:16:18 [danbri]
danbri: reminiscent of URI Templates
15:16:33 [danbri]
format-time($t, "[h]:[m01]:[s01] o'clock [PN] [ZN,*-3]", "en", (), ())
15:16:33 [danbri]
15:16:33 [danbri]
15:16:33 [danbri]
15:16:33 [danbri]
3:58:45 o'clock PM PDT
15:17:08 [danbri]
jtandy: if we said "a CSV impl must support gregorian calendar, and it may support other calendars… conversion functionality is impl dependent"
15:17:29 [ivan]
15:17:34 [danbri]
ivan: re issues for implementors
15:17:41 [danbri]
… this {url} is py version of the same thing
15:17:55 [danbri]
… much is similar, although they use a % sign instead of [ ]
15:18:04 [danbri]
… and then another one, ...
15:18:10 [danbri]
jtandy: yes, Moment JS lib
15:18:17 [danbri]
ivan: similar but not identical.
15:18:27 [danbri]
jtandy: and then java simple data format
15:18:31 [danbri]
… lots of places in same space
15:18:54 [danbri]
… if an impl was using e.g. py impl, they'd need to map from our picture string
15:18:58 [danbri]
… which is at least similar
15:19:05 [danbri]
… i.e. not having to do the entire job
15:19:14 [danbri]
… over time people might standardize on one picture string syntax
15:19:18 [danbri]
ivan: it's pretty much of a mess
15:19:27 [danbri]
jtandy: the general situation or this? :)
15:19:34 [danbri]
ivan: … both? :)
15:20:15 [danbri]
… if I look at the python one, and Moment likely is similar, they have diff chars for diff things, e.g. capital Y, … whereas if my u/standing correct, xpath they define microsyntaxes
15:20:27 [danbri]
… which is the worst to convert from this to the py one is a pita
15:21:06 [jtandy]
15:21:43 [danbri]
danbri: which dir do these tools go in?
15:21:46 [danbri]
ivan: both
15:22:22 [danbri]
ivan: am tempted to ignore the xsd stuff
15:22:30 [danbri]
… and pick one of the existing formats and use that
15:22:44 [danbri]
… which is probably simpler, we'd make at least some implementors happier
15:22:54 [jtandy]
Year, month, and day tokens
15:22:59 [danbri]
jtandy: for example, on Moment docs, in section Year Month Day tokens
15:23:04 [danbri]
… lists the types of tokens that you can use
15:23:42 [danbri]
…. we should look across these for consistency?
15:23:51 [danbri]
ivan: there is no consistency in sense that we know they use diff picture strings
15:23:57 [jtandy]
consistency in picture string format?
15:24:53 [danbri]
ivan: considering js ruby java c, …. is there one format that dominates? that we can therefore declare a loser/winner
15:26:00 [danbri]
jtandy: is there one pic string format that is more standardized than others?
15:26:16 [danbri]
my concern is that using these language impl picture strings, … that none of them have been defined to the same rigour as xpath/xquery
15:27:03 [danbri]
jtandy: the w3c stuff more likely to address edge cases, i18n etc
15:27:55 [danbri]
ivan: we can say our default requirement is to use the iso spec etc
15:28:01 [danbri]
… however we can choose to allow picture strings
15:28:05 [danbri]
… as they are popular
15:28:12 [danbri]
… we can say they assume at least gregorian
15:28:22 [danbri]
… but we do not think of trying to address all use cases
15:28:57 [danbri]
[missing details]
15:29:36 [danbri]
jtandy: i'd advise not to use ordinal values / nominal names
15:29:47 [danbri]
ivan: we define the weekdays as numbers
15:29:48 [jtandy]
(another dateformat implementation:
15:29:49 [danbri]
… months as numbers
15:29:53 [danbri]
… years as numbers
15:29:56 [danbri]
the seconds etc
15:29:59 [danbri]
… only numeric
15:30:06 [danbri]
… and UTC offset etc
15:30:11 [danbri]
… that certainly helps
15:30:37 [danbri]
… considering our Use Cases, how does this map against the practicalities?
15:30:53 [danbri]
jtandy: UCs don't talk about using other calendars; generally assume gregorian / CE
15:31:07 [danbri]
… do particular CSV files use american date formats?
15:31:20 [danbri]
ivan: if this is just a matter of order, … do they handle that? do they use names of the months?
15:31:37 [danbri]
CSV report:
15:31:46 [danbri]
15:32:55 [danbri]
jtandy: weather date formats can be odd
15:33:02 [danbri]
15:33:27 [danbri]
"The first two digits of the stardate are always "41." The 4 stands for 24th century, the 1 indicates first"
15:33:39 [danbri]
15:33:44 [danbri]
15:34:54 [danbri]
jtandy: [missed something that sounded important]
15:35:09 [danbri]
ivan:e.g. say implementations are required to do that
15:35:55 [jtandy]
i said: picture strings + gregorian calendar + Common Era ... named values (days, months etc.) are not permitted
15:36:59 [ivan]
I said: picture strings + gregorian calendar + common era, using only numbers is required, addtional features (named values) are optional to the implementation
15:37:12 [danbri]
dan: how much could be done with regex?
15:38:45 [jtandy]
agree with ivan
15:39:11 [jtandy]
question becomes "what picture string 'standard' shall we use"
15:39:21 [danbri]
would it be lossy, e.g. '01' and '1' representing January turn into '1'?
15:39:54 [jtandy]
(@danbri - the XPath spec deals with lossy transforms like you suggest)
15:40:22 [danbri]
ivan: if we decide to go with something in the js direction, is Moment somehow the main tool?
15:40:39 [danbri]
see also
15:41:02 [danbri]
ivan: the python one is the closest to standard in its own way
15:41:08 [danbri]
or java
15:42:04 [danbri]
danbri: don't forget .Net! they did a ton of work mapping across langs
15:42:13 [danbri]
ivan: Dart, Go, …
15:42:18 [danbri]
… we're doomed? :)
15:42:29 [danbri]
jtandy: action then is to review the common langs looking for similarities
15:42:59 [danbri]
… we'd need to specify simplifying restrictions if we wanted to include something
15:43:05 [danbri]
ivan: also problems with numbers
15:43:22 [jtandy]
15:45:05 [danbri]
15:45:50 [danbri]
ivan: can we be v loose and say that … we do not require anything in the specification sense. What we could do is something like … first we use the ISO date spec, …
15:46:07 [danbri]
… we use that, we already have issue of putting picture/format string into metadata somewhere
15:46:16 [danbri]
… we let impl decide which one they understand
15:46:29 [danbri]
… the way the metadata is defined they can give an array of a picture string for a column
15:46:39 [danbri]
… and the impl can choose which
15:47:02 [danbri]
… hope that at least one is understood
15:47:10 [danbri]
danbri: should we come up with short name codes for each pic string language
15:47:19 [danbri]
ivan: yeah
15:47:28 [danbri]
jtandy: can you see any metadata publishers bothering with that?
15:48:20 [danbri]
ivan: decent people will use the iso format
15:49:17 [Zakim]
15:49:29 [danbri]
15:49:31 [danbri]
i'll redial
15:49:36 [jtandy]
where are you?
15:49:42 [jtandy]
lost in space
15:50:30 [Zakim]
15:52:40 [jtandy]
danbri: proposes that "we strongly recommend for interoperability that you supplement your data with ISO 8601 datetime values"
15:53:06 [jtandy]
... when publishing CSV data on the web for general consumption
15:54:24 [jtandy]
(so if it's not in ISO 8601 format, then we just treat it as a string for down stream resolution?)
15:55:43 [danbri]
rrsagent, pointer?
15:55:43 [RRSAgent]
15:56:57 [jtandy]
ivan: if it's not in ISO 8601 format, we don't check - so it will be an error in the RDF
15:57:36 [jtandy]
we discussed using a hash-table of common picture string formats for javascript, ruby, python etc.
15:57:57 [Zakim]
15:57:59 [Zakim]
15:58:39 [Zakim]
15:58:41 [Zakim]
DATA_CSVWG()10:00AM has ended
15:58:41 [Zakim]
Attendees were +44.207.346.aaaa, Ivan, danbri, jtandy
15:59:33 [ivan]
rrsagent, draft minutes
15:59:33 [RRSAgent]
I have made the request to generate ivan
15:59:42 [ivan]
trackbot, end telcon
15:59:42 [trackbot]
Zakim, list attendees
15:59:42 [Zakim]
sorry, trackbot, I don't know what conference this is
15:59:50 [trackbot]
RRSAgent, please draft minutes
15:59:50 [RRSAgent]
I have made the request to generate trackbot
15:59:51 [trackbot]
RRSAgent, bye
15:59:51 [RRSAgent]
I see no action items