14:53:01 <RRSAgent> RRSAgent has joined #csvw
14:53:01 <RRSAgent> logging to http://www.w3.org/2014/11/19-csvw-irc
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 http://lists.w3.org/Archives/Public/public-csv-wg/2014Nov/0044.html 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> likewise
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> +Ivan
15:02:42 <danbri> zakim, aaaa is danbri
15:02:42 <Zakim> +danbri; got it
15:02:47 <jtandy> #2789
15:03:07 <Zakim> +??P6
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> https://github.com/w3c/csvw/issues/54
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> http://www.w3.org/TR/xpath-functions-30/#formatting-dates-and-times
15:09:59 <danbri> jtandy: I've also looked at xpath, xquery functions
15:10:02 <danbri> rrsagent, pointer?
15:10:02 <RRSAgent> See http://www.w3.org/2014/11/19-csvw-irc#T15-10-02
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 http://www.w3.org/TR/xpath-functions-30/#formatting-dates-and-times section 9
15:11:21 <jtandy> http://www.w3.org/TR/xpath-functions-30/#dates-times
15:11:35 <danbri> thanks
15:11:42 <danbri> jtandy: if you go to 9.2.1 you see some examples
15:12:13 <jtandy> http://www.w3.org/TR/xpath-functions-30/#formatting-dates-and-times
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> 9.8.4.1 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> http://www.w3.org/TR/xpath-functions-30/#date-time-examples
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>  gives
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> https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior
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> http://momentjs.com/docs/
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: https://code.google.com/p/jaxson/source/browse/trunk/jaxson/WebRoot/jsSrc/org/jaxson/util/SimpleDateFormat.js?r=41)
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: http://lists.w3.org/Archives/Public/public-csv-wg/2014Nov/0043.html
15:31:46 <danbri> http://lists.w3.org/Archives/Public/public-csv-wg/2014Nov/att-0043/csv_profiler_report_copy.pdf
15:32:55 <danbri> jtandy: weather date formats can be odd
15:33:02 <danbri> http://en.wikipedia.org/wiki/Stardate
15:33:27 <danbri> "The first two digits of the stardate are always "41." The 4 stands for 24th century, the 1 indicates first http://en.wikipedia.org/wiki/Television_program#Seasons.2Fseries."
15:33:39 <danbri> q+
15:33:44 <danbri> q-
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 https://github.com/trending?l=javascript
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> http://www.w3.org/TR/xpath-functions-30/#formatting-numbers
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> -danbri
15:49:29 <danbri> er
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> +danbri
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> See http://www.w3.org/2014/11/19-csvw-irc#T15-55-43
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> -danbri
15:57:59 <Zakim> -jtandy
15:58:39 <Zakim> -Ivan
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 http://www.w3.org/2014/11/19-csvw-minutes.html 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 http://www.w3.org/2014/11/19-csvw-minutes.html trackbot
15:59:51 <trackbot> RRSAgent, bye
15:59:51 <RRSAgent> I see no action items