/irc-logs / w3c / #html-wg / 2008-12-02 / end

Options:

  1. # Session Start: Tue Dec 02 00:00:00 2008
  2. # Session Ident: #html-wg
  3. # [00:45] * Joins: Lionheart (robin@66.57.69.65)
  4. # [00:50] * Quits: marcos (marcos@87.196.227.43) (Quit: marcos)
  5. # [00:52] * Quits: tH (Rob@129.11.83.58) (Ping timeout)
  6. # [01:08] * Joins: marcos (marcos@87.196.227.43)
  7. # [01:17] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  8. # [01:51] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  9. # [01:55] <MikeSmith> ChrisWilson: you there?
  10. # [02:04] * Quits: Dashiva (noone@84.48.51.1) (Ping timeout)
  11. # [02:06] * Quits: ChrisWilson (cwilso@131.107.0.101) (Ping timeout)
  12. # [02:08] * Joins: Dashiva (noone@84.48.51.1)
  13. # [02:20] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
  14. # [02:24] * Joins: Lionheart (robin@66.57.69.65)
  15. # [02:26] * Quits: adele (adele@17.203.14.144) (Quit: adele)
  16. # [02:46] <MikeSmith> http://crypto.stanford.edu/websec/specs/origin-header/
  17. # [02:46] <pimpbot> Title: Origin Header for CSRF Mitigation (at crypto.stanford.edu)
  18. # [02:46] <MikeSmith> (for those here who ain't seen it yet)
  19. # [02:47] * Quits: billmason (bmason@69.30.57.49) (Quit: Leaving.)
  20. # [02:49] * Quits: Hixie (ianh@129.241.93.37) (Quit: reconnecting...)
  21. # [02:49] * Joins: Hixie (ianh@129.241.93.37)
  22. # [02:51] * Quits: Hixie (ianh@129.241.93.37) (Quit: oops, config error)
  23. # [02:51] * Joins: Hixie (ianh@129.241.93.37)
  24. # [02:51] * Quits: Hixie (ianh@129.241.93.37) (Quit: leaving)
  25. # [02:51] * Joins: Hixie (ianh@129.241.93.37)
  26. # [02:55] * Quits: Hixie (ianh@129.241.93.37) (Quit: leaving)
  27. # [02:56] * Joins: Hixie (ianh@129.241.93.37)
  28. # [03:02] <MikeSmith> http://lists.w3.org/Archives/Public/www-tag/2008Nov/0125.html
  29. # [03:02] <pimpbot> Title: RE: ZIP-based packages and URI references into them ODF proposal from Ian Hickson on 2008-11-29 (www-tag@w3.org from November 2008) (at lists.w3.org)
  30. # [03:03] <MikeSmith> actually, the title for that should be something more like "Making a case for 'implementation functional specifications'"
  31. # [03:03] <Hixie> yeah i forgot to change the subject line
  32. # [03:05] <MikeSmith> Hixie: anyway, I think it was well-put. But don't seem to be any responses to it yet.
  33. # [03:06] <Hixie> larry said he would respond
  34. # [03:24] * Quits: MichaelC (Michael@128.30.52.30) (Quit: ChatZilla 0.9.84 [Firefox 3.0.4/2008102920])
  35. # [03:28] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  36. # [03:54] * Quits: marcos (marcos@87.196.227.43) (Quit: marcos)
  37. # [03:55] * Joins: marcos (marcos@87.196.227.43)
  38. # [04:13] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: sex break)
  39. # [04:23] * Quits: rking3 (rking3@24.5.77.167) (Quit: rking3)
  40. # [04:26] * Quits: maddiin (mc@87.185.243.133) (Quit: maddiin)
  41. # [04:46] * Quits: Lionheart (robin@66.57.69.65) (Quit: Leaving.)
  42. # [04:47] * Joins: Lionheart (robin@66.57.69.65)
  43. # [04:48] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
  44. # [04:59] * Quits: dbaron (dbaron@63.245.220.241) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  45. # [05:16] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  46. # [05:39] * Joins: Lionheart (robin@66.57.69.65)
  47. # [05:44] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
  48. # [05:49] * Joins: dbaron (dbaron@71.204.144.136)
  49. # [05:54] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
  50. # [05:58] * Joins: Lionheart (robin@66.57.69.65)
  51. # [06:38] * Quits: Lionheart (robin@66.57.69.65) (Quit: Leaving.)
  52. # [06:39] * Joins: Lionheart (robin@66.57.69.65)
  53. # [06:42] * Quits: Lionheart (robin@66.57.69.65) (Ping timeout)
  54. # [06:48] * Joins: heycam (cam@203.217.95.190)
  55. # [06:49] <MikeSmith> @tell hsivonen Henri, the whattf.org schema still has "optgroup = option* & optgroup* & optgroup.attrs" (optgroup allowed as a child of itself)
  56. # [06:49] <pimpbot> MikeSmith: You got it, player.
  57. # [07:05] * Quits: gavin_ (gavin@99.253.193.147) (Ping timeout)
  58. # [07:10] * Joins: gavin_ (gavin@99.253.193.147)
  59. # [07:46] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: sex break)
  60. # [08:00] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  61. # [08:01] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: sex break)
  62. # [08:02] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  63. # [08:34] * Quits: aroben (aroben@71.58.119.193) (Connection reset by peer)
  64. # [08:41] * Quits: dbaron (dbaron@71.204.144.136) (Ping timeout)
  65. # [08:57] <Hixie> MikeSmith: any news on all these people who were volunteering to edit parts of html5?
  66. # [08:58] <MikeSmith> Hixie: the same news you've heard
  67. # [08:58] <Hixie> crickets, huh
  68. # [09:00] <MikeSmith> yup
  69. # [09:00] <Hixie> i'm kinda pissed off at all the people asking for the spec to be split, and then nobody volunteering
  70. # [09:01] * Joins: aaronlev (chatzilla@92.228.77.248)
  71. # [09:50] * Joins: Sander (svl@86.87.68.167)
  72. # [09:52] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: sex break)
  73. # [10:04] * Joins: tlr (tlr@128.30.52.30)
  74. # [10:05] * Joins: ROBOd (robod@89.122.216.38)
  75. # [10:21] * Joins: hsivonen (hsivonen@130.233.41.50)
  76. # [10:21] <pimpbot> hsivonen: Sent 3 hours and 32 minutes ago: <MikeSmith> Henri, the whattf.org schema still has optgroup = option* & optgroup* & optgroup.attrs (optgroup allowed as a child of itself)
  77. # [10:22] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  78. # [10:22] <hsivonen> MikeSmith: thanks for finding the optgroup issue
  79. # [10:23] <MikeSmith> hsivonen: no problem. noticed that one a while back but was reminded of it by one of Hixie's checkins today
  80. # [10:24] <MikeSmith> Hixie: is there anything in the HTML5 date/time microsyntax spec that intentionally violates ISO 8601?
  81. # [10:24] * hsivonen wishes there were single-page HTML versions of SVG specs
  82. # [10:24] <hsivonen> ooh. there is one for 1.2 Tiny
  83. # [10:25] * hsivonen uses the PDF for 1.1
  84. # [10:31] * Joins: tH (Rob@129.11.83.58)
  85. # [10:36] * Joins: zcorpan (zcorpan@88.131.66.80)
  86. # [10:37] <MikeSmith> hsivonen: are you aware of what differences or discrepancies RFC 3339 has with current ISO 8601?
  87. # [10:37] <MikeSmith> I notice that http://wiki.whatwg.org/wiki/MicrosyntaxDescriptions references ISO 8601 instead if RFC 3339
  88. # [10:37] <pimpbot> Title: MicrosyntaxDescriptions - WHATWG Wiki (at wiki.whatwg.org)
  89. # [10:37] <hsivonen> MikeSmith: I am unaware
  90. # [10:38] <MikeSmith> OK
  91. # [10:38] <anne> I thought HTML5 just followed ISO8601, just like HTML4
  92. # [10:38] <hsivonen> that is, I am not aware of RFC 3339
  93. # [10:38] <MikeSmith> hsivonen: understood
  94. # [10:40] <MikeSmith> anne: HTML5 doesn't explicitly reference IS0 8601, so I'm wondering if it may be that by following IS0 8601, it also follows RFC 3339
  95. # [10:40] <MikeSmith> and if a page like http://wiki.whatwg.org/wiki/MicrosyntaxDescriptions needs to reference a standard, would seem better that it reference a free standard if possible
  96. # [10:41] <pimpbot> Title: MicrosyntaxDescriptions - WHATWG Wiki (at wiki.whatwg.org)
  97. # [10:42] <MikeSmith> anyway, I gotta go
  98. # [10:42] <MikeSmith> bbl
  99. # [10:42] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: sex break)
  100. # [10:48] <Hixie> ISO8601 defines about a bazillion formats
  101. # [10:49] <Hixie> html5 is intended to be a subset of those formats
  102. # [11:48] * Quits: gavin_ (gavin@99.253.193.147) (Ping timeout)
  103. # [11:53] * Joins: gavin_ (gavin@99.253.193.147)
  104. # [12:13] * Joins: maddiin (mc@87.185.191.215)
  105. # [12:19] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
  106. # [12:29] * Joins: Lachy (Lachlan@213.236.208.22)
  107. # [12:41] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  108. # [12:44] * Quits: aaronlev (chatzilla@92.228.77.248) (Quit: ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406])
  109. # [12:54] * Joins: aaronlev (chatzilla@92.228.77.248)
  110. # [13:29] * Joins: myakura (myakura@122.17.190.200)
  111. # [13:46] * Joins: Julian (chatzilla@217.91.35.233)
  112. # [13:47] <Julian> RFC 3339 vs ISO 8691 (latest): as far as I recall, the latest version of 8601 allows negative years while RFC 3339 does not
  113. # [13:47] <MikeSmith> Julian: thanks
  114. # [13:48] <MikeSmith> I wonder if the HTML5 draft allows negative years
  115. # [13:48] <MikeSmith> I think it does not
  116. # [13:49] <Lachy> MikeSmith, it doesn't
  117. # [13:50] <Lachy> 0001 is the earliest year allowed
  118. # [13:50] <Julian> I think sticking to something simple and free is the right thing to do.
  119. # [13:50] <Julian> If we feel that something important is missing from RFC 3339, we may want to discuss revising it (with Chris Newman)
  120. # [13:51] <MikeSmith> OK
  121. # [13:51] <MikeSmith> the HTML5 draft doesn't explicitly cite/reference either
  122. # [13:51] <MikeSmith> so it's not an issue there
  123. # [13:52] <MikeSmith> but it is a concern if we want to reference those somewhere else
  124. # [13:52] <MikeSmith> those being RFC 3339 or whatever the current ISO date standard is
  125. # [13:53] <Lachy> I'm not sure HTML5 needs to reference those specs, since HTML5 defines the syntax and parsing requirements for dates on its own
  126. # [13:54] <MikeSmith> well, if it were useful to have a reference anywhere, so far it seems a reference to RFC 3339 would be do-able (no need to reference any ISO spec)
  127. # [13:54] <Julian> now I'm concerned
  128. # [13:54] <Julian> is HTML5 defining it's own profile?
  129. # [13:55] <MikeSmith> Julian: essentially, I suppose it is
  130. # [13:55] <Julian> without even mentioning it's a subset of ISO8601?
  131. # [13:55] <Lachy> http://www.whatwg.org/specs/web-apps/current-work/#dates-and-times
  132. # [13:55] <pimpbot> Title: HTML 5 (at www.whatwg.org)
  133. # [13:56] <Julian> HTML4 refers to ISO8601 (for ins/del/@datetime, for instance)
  134. # [13:58] <Lachy> AIUI, ISO 8601 is more complicated than necessary for this.
  135. # [14:00] <Lachy> hmm, it seems that neither RFC 3339 or http://www.w3.org/TR/NOTE-datetime would be appropriate references, since HTML5 allows some things that they don't
  136. # [14:00] <pimpbot> Title: Date and Time Formats (at www.w3.org)
  137. # [14:01] <Lachy> HTML5 doesn't suffer from the y10k bug like they do, and the W3C Note doesn't support Weeks
  138. # [14:01] <Julian> Lachy: which feature beyond the 5 digit year issue?
  139. # [14:01] <MikeSmith> Lachy: any specific example of conflict with RFC 3339? just the Y2K thing?
  140. # [14:01] <MikeSmith> that Note can't be normatively referenced anyway
  141. # [14:02] <MikeSmith> what does HTML5 allows that RFC 3339 doesn't?
  142. # [14:02] <anne> (i haven't researched the subject) does RFC 3339 define parsing rules and error states?
  143. # [14:02] <MikeSmith> anne: no, it doesn't
  144. # [14:02] <MikeSmith> not as far as I recall
  145. # [14:03] <Lachy> MikeSmith, AIUI, it doesn't need to be normatively referenced, since the spec defines the syntax and parsing requirements already
  146. # [14:04] <Lachy> Section 3 or RFC 3339 is quite vague
  147. # [14:05] <MikeSmith> Lachy: understood, but I'm not just asking in reference to the current spec only
  148. # [14:05] <MikeSmith> but in general to what can be referenced for dates and times
  149. # [14:07] <Lachy> if we want a spec that can be normatively referenced, then we would need to write a new one that defines syntax, parsing and error handling rules
  150. # [14:08] <Lachy> I'm not sure what ISO-8601 says about parsing, but I think it only defines the syntax too
  151. # [14:14] <Lachy> MikeSmith, RFC 3339 also allows leap seconds, HTML5 does not
  152. # [14:14] <MikeSmith> ah
  153. # [14:17] <Lachy> MikeSmith, it also allows the T and Z to be lowercase, HTML5 does not
  154. # [14:18] <MikeSmith> hmm, I guess my question on that would be what rationale it has for allowing them to be lowercase
  155. # [14:20] <Lachy> "NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively."
  156. # [14:21] <Lachy> wow, it appears to be attempting to specify a normative, optional conformance criteria in a non-normative note :-)
  157. # [14:21] <Lachy> NOTE: ISO 8601 defines date and time separated by "T".
  158. # [14:21] <Lachy> Applications using this syntax may choose, for the sake of
  159. # [14:21] <Lachy> readability, to specify a full-date and full-time separated by
  160. # [14:21] <Lachy> (say) a space character.
  161. # [14:22] <MikeSmith> weird
  162. # [14:22] <MikeSmith> the BNF at http://www.apps.ietf.org/rfc/rfc3339.html#page-12 seems to only allow uppercase T and Z
  163. # [14:22] <pimpbot> Title: RFC 3339 (at www.apps.ietf.org)
  164. # [14:22] <MikeSmith> and "SO 8601 states that the "T" may be omitted under some circumstances. This grammar requires the "T" to avoid ambiguity."
  165. # [14:23] <Julian> MikeSmith: no. "A" in ABNF means "a" or "A",
  166. # [14:23] <MikeSmith> ah
  167. # [14:23] <MikeSmith> well, that's not good
  168. # [14:24] * Quits: maddiin (mc@87.185.191.215) (Quit: maddiin)
  169. # [14:24] <Lachy> LOL, I love when specs are contradictory :-)
  170. # [14:26] <Lachy> apparently, ISO 8601 allows hours in the range 00-24 instead of 00-23
  171. # [14:26] <MikeSmith> wonderful
  172. # [14:27] <MikeSmith> I think I mentioned it before, but it's quite common for open-until-after-midnight businesses in Tokyo to use dates like 26:00 and 28:00
  173. # [14:27] <Lachy> wtf?
  174. # [14:28] <tlr> "open from 5:00-28:59"?
  175. # [14:28] <Julian> I think you need "24" when you also allow leap seconds
  176. # [14:28] <Lachy> Julian, no you don't
  177. # [14:28] <Julian> time formats *are* hard if they are supposed to cover ecerything
  178. # [14:28] <Lachy> you just use 60 for the seconds
  179. # [14:28] <Lachy> "Standard time in the Netherlands was exactly 19
  180. # [14:28] <Lachy> minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
  181. # [14:28] <Lachy> 1937-06-30. This time zone cannot be represented exactly using the
  182. # [14:28] <Lachy> HH:MM format, and this timestamp uses the closest representable UTC
  183. # [14:28] <Lachy> offset.
  184. # [14:28] <Lachy> "
  185. # [14:29] <MikeSmith> tlr: not usually for places open 24 hours, but instead for bars and such like - 19:00-28:00
  186. # [14:29] <Dashiva> And TV shows
  187. # [14:30] <Lachy> MikeSmith, RFC 3339 also doesn't allow Weeks, same as the W3C NOTE
  188. # [14:30] <Philip> The people in Japan must be better at mental arithmetic than we are
  189. # [14:30] <MikeSmith> Dashiva: and "fashion health" establishments
  190. # [14:31] <Dashiva> When you're able to do 19->7, 28->16->4 isn't so much more
  191. # [14:31] <Lachy> my conclusion after reading that RFC is that it's totally inappropriate as a normative reference for anything
  192. # [14:31] <Dashiva> Perhaps you even do 28->4 directly!
  193. # [14:31] <Philip> Dashiva: I use 24-hour clocks, so I don't have to do 19->7 :-)
  194. # [14:33] <anne> didn't know that about the Netherlands, loving it :)
  195. # [14:33] <Dashiva> Surely you sometimes venture into parts of the real world that still use analog clocks (or displays of such)
  196. # [14:33] <Lachy> In Australia, it's unfortunately common for people to use 12 hour time and there are many people that struggle with 24 hour time
  197. # [14:34] <Julian> lachy: for the record; I disagree with that
  198. # [14:34] <Philip> Dashiva: If there's an analog clock, it's easier to just look at my watch instead :-)
  199. # [14:34] <Lachy> Julian, that people in Australia use 12 hour time?
  200. # [14:34] <Lachy> or about the RFC?
  201. # [14:35] <Julian> the latter
  202. # [14:36] <Lachy> Dashiva, I can't read analog clocks very well
  203. # [14:37] * Joins: maddiin (mc@87.185.191.215)
  204. # [14:37] <Lachy> Julian, why?
  205. # [14:37] <Lachy> it has ambiguities, leaves things undefined and even contradictory in parts. What good is that as a normative reference?
  206. # [14:37] * Quits: Philip (philip@80.177.163.133) (Ping timeout)
  207. # [14:37] <MikeSmith> I can imagine a possible solution being for a spec to reference it with qualifying language like, e.g. "/a 'date-time' as defined in RFC 3339, with the exception that leap seconds are not allowed, and the "T" and "Z" literals must be uppercase."
  208. # [14:38] <Lachy> it still doesn't define parsing or error handling requirements
  209. # [14:38] <Lachy> and it's suggestions for handling 2 digit years seem to indicate that implementations are allowed to do as they see fit
  210. # [14:41] * Joins: Philip (philip@80.177.163.133)
  211. # [14:42] * Joins: MichaelC (Michael@128.30.52.30)
  212. # [14:43] <Lachy> so given that neither the RFC or NOTE-datetime cover everything used by HTML5, and that HTML5 is a subset of ISO 8601, an informative reference to 8601 would be the only reasonable alternative, if such a reference is needed
  213. # [14:47] * Quits: Philip (philip@80.177.163.133) (Ping timeout)
  214. # [14:47] <Lachy> MikeSmith, perhaps we should find a volunteer to update NOTE-datetime and put it on the REC track
  215. # [14:48] <Lachy> (though that would have less priority that finding volunteers for some other sections in HTML5)
  216. # [14:48] * Joins: aroben (aroben@71.58.119.193)
  217. # [14:49] <MikeSmith> Lachy: or we could just contact the current RFC 3339 editor and ask
  218. # [14:49] <MikeSmith> ask bout getting it update
  219. # [14:49] <MikeSmith> updated
  220. # [14:50] * Joins: Philip (philip@80.177.163.133)
  221. # [14:50] <tlr> Mike, C. Newman is one of the Apps area directors these days, and part of the W3C/IETF liaison group.
  222. # [14:51] <tlr> +1 to pinging him; maybe copy public-ietf-w3c@w3.org
  223. # [14:51] <MikeSmith> OK
  224. # [14:51] <Lachy> MikeSmith, ok, that seems reasonable
  225. # [14:53] <Julian> Lachy: it's arguable whether it needs to define error handling
  226. # [14:53] <Julian> Parsing should be umambiguous by the ABNF
  227. # [14:53] <Julian> If it's not, there's a bug
  228. # [14:53] <Lachy> Julian, no, it's not. If we want interoperability, then we have to deal with the fact that implementations will receive erroneous input. Therefore, we must define error handling
  229. # [14:54] <Julian> but nor necseearily in RFC 3339
  230. # [14:54] <Julian> nor does it need to be the same everywhere
  231. # [14:54] <Julian> sometimes a parse error is just a parse error
  232. # [14:55] <Lachy> that's a tautology
  233. # [14:55] <Lachy> what do you mean by it?
  234. # [14:56] <Julian> an invalid date can be treated as an error in the message
  235. # [14:56] <Julian> keep in mind that RFC 3339 is used in lots of places
  236. # [14:56] <Julian> error handling requirements will not be the same everywhere
  237. # [14:59] <Lachy> sure, and there are ways to deal with that, much like the way HTML5 parsing allows for, e.g., either aborting or applying well defined error recovery
  238. # [15:25] <Julian> a well-defined error recovery that implies that any sequence of characters is accepted essentially closes all future extension points.
  239. # [15:25] <Julian> you may think it's the right thing to do in HTML5, but rest assured that many people think different
  240. # [15:26] <Julian> thus, in cases like date/tiem formats, it'll be up to HTML5 to define that error handling, and also to be prepared to live with the consequences of that approach
  241. # [15:26] <Lachy> no, it doesn't close all extension points at all
  242. # [15:27] <Julian> if you accept *any* sequence of characters, oit does
  243. # [15:27] <Lachy> in fact, it improves the chance of adding extensions since there wouldn't be such wildly disparate implementations
  244. # [15:28] <Lachy> CSS had relatively well defined error handling and could process any sequence of bytes, but that hasn't stopped them defining extensions
  245. # [15:29] <Lachy> interoperability problems are what causes all the problems with defining extensions, since you not only have to remain relatively compatible what the original spec said, but with what each implementation does
  246. # [15:29] <Julian> It's the difference between "must understand" to "must ignore"
  247. # [15:30] <Julian> if you accept every input and parse it into a date, you do "must ignore" with respect to future extensions
  248. # [15:30] <Julian> that may be the right thing in many cases, but *not* always
  249. # [15:31] <Lachy> so, whether something is specified as must understand or must ignore is irrelevent to whether or not its well defined
  250. # [15:31] <Lachy> I didn't say all input must be parsed into a date. That's not what the HTML5 spec currently does either
  251. # [15:31] <Lachy> but all input must have a well defined result
  252. # [15:32] <Julian> I think that's the case in RFC 3339.
  253. # [15:32] <Julian> If it doesn't parse according to the ABNF, it's invalid.
  254. # [15:32] <Lachy> the RFC contains ambiguous suggestions for letting implementations deal with 2 and 3 digit years
  255. # [15:33] <Julian> precisely what part?
  256. # [15:37] <Julian> if you are looking at http://greenbytes.de/tech/webdav/rfc3339.html#rfc.section.3
  257. # [15:37] <pimpbot> Title: Date and Time on the Internet: Timestamps (at greenbytes.de)
  258. # [15:37] <Julian> these are hints for legacy protocols that do NOT use RFC 3339
  259. # [15:38] <Julian> the ABNF clearly says "4DIGIT"
  260. # [15:40] <anne> how can the format be extended if usage of it is free to do whatever with invalid variants?
  261. # [15:42] <Julian> so you're mssing a statement that if something doesn't parse it shouldn't be treated as a date?
  262. # [15:42] <Lachy> Julian, the 4 digit requirement clearly applies to producers. But for consumers that have to deal with 2 or 3 digit years from legacy apps, the requirements are largely undefined and implementations can do as they see fit
  263. # [15:43] <Julian> I disagree.
  264. # [15:43] <anne> Julian, that'd be one possible solution I suppose
  265. # [15:44] <anne> but I'm just wondering what the strategy is if applications are free to do whatever they want
  266. # [15:44] * Parts: zcorpan (zcorpan@88.131.66.80)
  267. # [15:44] <anne> I'm also wondering what the advantage of such a strategy is
  268. # [15:46] <Lachy> Julian, "Programs wishing to robustly deal with dates generated by such broken software should detect non-numeric decades and interpret appropriately."
  269. # [15:46] <Lachy> what does "interpret appropriately" mean exactly for a parser?
  270. # [15:49] <Julian> again, I understand Section 3 as instructions for protocols that do not usethe RFC3339 format
  271. # [15:49] <Lachy> it would be more appropriate if the spec did define that non-conforming dates were to be ignored
  272. # [15:49] <Julian> Otherwise: why would it say that before actually defining the "right thing"?
  273. # [15:50] <Lachy> it seems to say most of that in order to justify why 4 digits years are necessary. But it unfortunately mixes it with poorly defined implementation suggestions
  274. # [15:51] <anne> (if the spec would say that anything not matching the grammar is not a date and should not be treated as such then that's enough error handling for it to be used by say HTML5, afaict, if it meets the other criteria as well)
  275. # [15:52] <Lachy> anne, it doesn't meet needs of HTML5 for everything though
  276. # [15:53] <Lachy> e.g. HTML5 uses the Week format, allows 5 digit years, no leap seconds. The RFC does not
  277. # [16:26] <Julian> "Collect a sequence of characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9). If the collected sequence is not exactly four characters long, then fail. Otherwise, interpret the resulting sequence as a base-ten integer. Let that number be the year. "
  278. # [16:26] <Julian> so four digit year
  279. # [16:28] <anne> yeah, though WF2 had five digit years
  280. # [16:28] <Julian> For the record: I prefer an ABNF compared to that 29-step algorithm.
  281. # [16:29] <Lachy> Julian, which copy of the spec did you get that from?
  282. # [16:30] <Lachy> the latest one on whatwg.org says "at least four characters long"
  283. # [16:32] <anne> seems Julian is reading some out of date version indeed
  284. # [16:32] <anne> there is no 29-step algorithm either anymore
  285. # [16:39] <Lachy> Julian, the /TR/ copy of the spec is 6 months out of date. Always look at the editors draft, either on whatwg.org or dev.w3.org
  286. # [16:51] * Joins: billmason (bmason@69.30.57.49)
  287. # [17:08] * Parts: anne (annevk@213.236.208.22)
  288. # [17:08] * Joins: anne (annevk@213.236.208.22)
  289. # [17:08] <Julian> Editor's Draft 24 October 2008
  290. # [17:09] * Parts: anne (annevk@213.236.208.22)
  291. # [17:09] <Julian> That's the version I looked at, and that one has the 29 step algo :-)
  292. # [17:10] * Joins: anne (annevk@213.236.208.22)
  293. # [17:10] <Julian> the version at whatwg.org is different, but it seems to contain as many steps as before, although with more structure
  294. # [17:25] <MikeSmith> hsivonen: attribute content models in whattf.org schema need to be updated (minus start/loopstart/loopend/playcount, +loop)
  295. # [17:26] <MikeSmith> for <audio> and <video>
  296. # [17:30] * Quits: aaronlev (chatzilla@92.228.77.248) (Quit: ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406])
  297. # [17:37] <hsivonen> MikeSmith: thanks. recorded as http://bugzilla.validator.nu/show_bug.cgi?id=341
  298. # [17:37] <pimpbot> Title: Bug 341 - Media element attributes are stale (at bugzilla.validator.nu)
  299. # [17:44] * Joins: rubys (rubys@75.182.87.110)
  300. # [17:59] <MikeSmith> hsivonen: thanks
  301. # [18:00] * Quits: myakura (myakura@122.17.190.200) (Quit: Leaving...)
  302. # [18:00] * Joins: dbaron (dbaron@71.204.144.136)
  303. # [18:03] * Joins: ChrisWilson (cwilso@131.107.0.103)
  304. # [18:07] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  305. # [18:12] <Philip> Julian: Is there a nice well-defined way to extract the desired structured data, using an ABNF grammar?
  306. # [18:14] <Philip> like a way for a specification to say that when you're given a string, you match it against this grammar, and then the number of seconds it represents is (...something specific...)
  307. # [18:15] <Philip> It looks like RFC 3339 doesn't do that - e.g. it says what string matches time-secfrac, but it doesn't say anywhere that you're meant to combine it with time-second and treat it as a decimal number, as far as I can tell
  308. # [18:15] <Julian> Just name the ABNF production? In this case "time-second"?
  309. # [18:15] <Julian> Ah, I see.
  310. # [18:15] <Julian> I guess that's left to the reader.
  311. # [18:18] <Philip> In this case I suppose it's reasonably obvious to the reader, but given that there's a formal way of defining what strings match the grammar it seems like there ought to be a formal way of defining what you do once you've matched the strings
  312. # [18:18] <Julian> The prose could state that. I'm not sure it needs to.
  313. # [18:28] * Joins: Lachy (Lachlan@85.196.122.246)
  314. # [18:34] <Philip> Julian: I suppose I'd ideally like the specification to be automatically translatable into an implementation that gives the right structured output, because that makes it easy to tell that everything is defined sufficiently precisely
  315. # [18:35] <Philip> but I don't know if there's any feasible way to actually do that :-(
  316. # [18:37] <Julian> Philip: now this is a relatively simple case where it looks feasible
  317. # [18:38] <Julian> I'm not sure whether that's always the case though.
  318. # [18:48] * Quits: maddiin (mc@87.185.191.215) (Quit: maddiin)
  319. # [18:59] <Philip> Is it intentional that http://www.w3.org/html/wg/html5/ hasn't been updated since 24 October?
  320. # [18:59] <pimpbot> Title: HTML 5 (at www.w3.org)
  321. # [18:59] <Philip> (http://dev.w3.org/html5/spec/ has, though)
  322. # [18:59] <pimpbot> Title: HTML 5 (at dev.w3.org)
  323. # [18:59] <Philip> (I thought that first URL used to be the latest copy too)
  324. # [19:00] * Philip wonders if someone like MikeSmith knows
  325. # [19:00] <MikeSmith> Philip: it used to just be a rewrite to dev.w3.org
  326. # [19:01] <MikeSmith> I think W3C systeam subsequently disabled the rewrite
  327. # [19:01] <Philip> MikeSmith: Ah
  328. # [19:02] <Philip> MikeSmith: It seems people are using that old copy and not realising it isn't up-to-date
  329. # [19:02] <MikeSmith> because there is some dispute about the way we are using/abusing dev.w3.org
  330. # [19:02] <MikeSmith> Philip: yeah, I see that now
  331. # [19:02] <MikeSmith> .me contemplates just quietly restoring the rewrite
  332. # [19:02] <Philip> like http://lists.w3.org/Archives/Public/public-html/2008Dec/0051.html
  333. # [19:02] <pimpbot> Title: Re: Black-box equivalence of parsing fragments directly into context node from Boris Zbarsky on 2008-12-02 (public-html@w3.org from December 2008) (at lists.w3.org)
  334. # [19:03] <Philip> (and I thought I remembered the same in IRC very recently, but can't find it now)
  335. # [19:03] <MikeSmith> yeah
  336. # [19:04] <Philip> MikeSmith: Just replace the www.w3.org copy with a <meta http-equiv="refresh" content="http://dev.w3.org/..."> and then everyone will be happy
  337. # [19:04] <Philip> Uh, that's probably content="0;http://..."
  338. # [19:04] <Philip> Anyway, surely nobody would complain about that
  339. # [19:05] <Julian> Philip: unless people sync with wget, disconnect from the internet and then complain when they don't have the spec on the airplane :-)
  340. # [19:06] <anne> heh
  341. # [19:07] <Philip> Julian: Well, apart from all the practical problems there's nothing wrong with meta refresh!
  342. # [19:07] <Philip> s/practical/theoretical and practical/
  343. # [19:08] <MikeSmith> I just changed http://www.w3.org/html/wg/html5 to a permanent redirect
  344. # [19:08] <pimpbot> Title: HTML 5 (at www.w3.org)
  345. # [19:09] <Philip> MikeSmith: Thanks!
  346. # [19:09] <MikeSmith> I will probably get my ass kicked for doing it
  347. # [19:09] * Joins: adele (adele@17.203.14.171)
  348. # [19:09] <Philip> MikeSmith: I won't mind that at all, as long as the redirect stays ;-)
  349. # [19:10] <MikeSmith> heh
  350. # [19:10] <MikeSmith> I can't see it making much sense to object to it redirecting... the dev.w3.org URL is public and known anyway. so it's not really adding to load
  351. # [19:10] <Philip> You could redirect people to the WHATWG version
  352. # [19:10] <MikeSmith> the underlying issue is that dev.w3.org is a single, old, slow machine
  353. # [19:10] <MikeSmith> heh
  354. # [19:11] <MikeSmith> yeah, actually
  355. # [19:11] <MikeSmith> but I'm sure I'd get flak for doing that too
  356. # [19:11] <MikeSmith> just a matter of who I'd rather piss off
  357. # [19:12] <Lachy> if people just read the better quality whatwg version anyway, there wouldn't be a problem
  358. # [19:13] <MikeSmith> I've been told that we never should have started dev.w3.org for publishing documents, that it was intended just for hosting code
  359. # [19:13] <MikeSmith> but, well, its use has evolved to better fit the needs of the people using it
  360. # [19:13] <MikeSmith> as such systems tend to do...
  361. # [19:14] <Lachy> the whatwg version has more useful features than the w3 version doesn't, like the update notifier, stability labels and that cross-referencing script that lists all the links linking to a dfn
  362. # [19:14] <MikeSmith> the real solution is to put a better machine behind it, and/or round-robin load-balance the way www.w3.org is
  363. # [19:14] <Philip> And multipagination
  364. # [19:14] <MikeSmith> do you guys reckon your telling me something I don't already know?
  365. # [19:14] <Lachy> Philip, I said "useful features". the pagination doesn't count :-)
  366. # [19:15] <Philip> Lachy: "Don't crash my browser" is a useful feature that results from multipagination :-)
  367. # [19:15] <MikeSmith> anyway, I got to get some sleep
  368. # [19:15] <Lachy> MikeSmith, no, that was just for the log readers who would want me to backup my claim that the whatwg version is better
  369. # [19:17] <Lachy> Philip, which browser can't handle the single page?
  370. # [19:21] <Philip> Lachy: IE8b1 hated it (not sure about b2), and Opera (9.62) freezes for tens of seconds when loading it
  371. # [19:24] <Philip> By "tens of seconds", it turns out that I actually mean about a hundred seconds
  372. # [19:24] <Philip> (It's not entirely frozen - it responds to my attempts at scrolling once every few seconds, before freezing again)
  373. # [19:25] <Philip> and it uses 100% of a 2.0GHz core, so it's doing an awful lot of thinking
  374. # [19:25] <tlr> must be the html5 parser
  375. # [19:26] <Julian> tlr: there's some script executed onload, apparently computing intensive
  376. # [19:26] <Philip> It downloads and parses and renders the page pretty quickly, so that bit's not a problem
  377. # [19:27] <Lachy> Philip, latest internal opera desktop build doesn't seem to freeze
  378. # [19:28] <Lachy> it's seems about as responsive as Firefox, which also has scrolling delays while it loading
  379. # [19:28] * Philip tries downloading the latest build
  380. # [19:30] <Lachy> I can't find any public build more recent than 9.62
  381. # [19:31] <Dashiva> Probably on Friday, considering last week's announcement
  382. # [19:32] <Philip> Lachy: In Linux build 4090, it still takes about 40 seconds before it starts scrolling smoothly
  383. # [19:33] <Julian> MikeSmith: Can I interest you in a problem with tr.rdf?
  384. # [19:33] <Philip> (4090 is 6 hours old, so I guess it's reasonably up-to-date on whatever branch it's on)
  385. # [19:44] * Joins: Lionheart (robin@66.57.69.65)
  386. # [19:50] * Quits: dbaron (dbaron@71.204.144.136) (Ping timeout)
  387. # [20:02] * Quits: gavin_ (gavin@99.253.193.147) (Ping timeout)
  388. # [20:06] * Quits: ChrisWilson (cwilso@131.107.0.103) (Ping timeout)
  389. # [20:08] * Joins: gavin_ (gavin@99.253.193.147)
  390. # [20:09] * Quits: rubys (rubys@75.182.87.110) (Connection reset by peer)
  391. # [20:22] * Joins: dbaron (dbaron@63.245.220.229)
  392. # [20:32] * Joins: dbaron_ (dbaron@63.245.220.241)
  393. # [20:32] * Quits: dbaron (dbaron@63.245.220.229) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  394. # [20:35] * dbaron_ is now known as dbaron
  395. # [20:51] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  396. # [21:01] * Joins: aaronlev (chatzilla@92.228.77.248)
  397. # [21:01] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
  398. # [21:06] * Quits: marcos (marcos@87.196.227.43) (Ping timeout)
  399. # [21:06] * Joins: marcos (marcos@87.196.201.242)
  400. # [21:16] * Quits: aaronlev (chatzilla@92.228.77.248) (Ping timeout)
  401. # [21:17] * Joins: aaronlev (chatzilla@92.226.205.238)
  402. # [21:56] * Joins: maddiin (mc@87.185.205.208)
  403. # [22:02] <pimpbot> planet: WebKit's week - #6 <http://hanblog.info/blog/post/2008/11/28/WebKit-s-week-6>
  404. # [22:03] * Quits: aaronlev (chatzilla@92.226.205.238) (Quit: ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406])
  405. # [22:11] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  406. # [22:12] * Joins: Lachy (Lachlan@85.196.122.246)
  407. # [22:33] * Quits: Julian (chatzilla@217.91.35.233) (Connection reset by peer)
  408. # [22:55] * Quits: wilhelm (wilhelm@129.241.93.37) (Ping timeout)
  409. # [23:00] * Quits: gavin_ (gavin@99.253.193.147) (Ping timeout)
  410. # [23:01] * Joins: wilhelm (wilhelm@129.241.93.37)
  411. # [23:05] * Joins: gavin_ (gavin@99.253.193.147)
  412. # [23:07] * Joins: aaronlev (chatzilla@92.226.205.238)
  413. # [23:18] * Quits: aaronlev (chatzilla@92.226.205.238) (Quit: ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406])
  414. # [23:28] * Quits: heycam (cam@203.217.95.190) (Quit: bye)
  415. # Session Close: Wed Dec 03 00:00:00 2008

The end :)