| 00:05 | <tantek> | Hixie, from reading RFC2445 4.8.1.11 "Purpose: This property defines **the** overall status or confirmation for the calendar component." (**emphasis** added) |
| 00:06 | <tantek> | Thus at first glance I would conclude at most **one** STATUS per VEVENT |
| 00:06 | <Hixie> | sure but is there a conformance criteria anywhere saying how many you can give? |
| 00:06 | <Hixie> | some of them are explicit |
| 00:07 | <tantek> | Hixie, compare with the next section 4.8.1.12 Summary which says "Purpose: This property defines **a** short summary or subject for the calendar component." |
| 00:07 | <Hixie> | yes but e.g. some say "The property can be specified once" |
| 00:07 | <Hixie> | and others say "This property can be specified in" |
| 00:07 | <tantek> | lacking explicit conformance criteria - such differences in property definition are another source of intent we have to go by |
| 00:07 | <tantek> | also, by what "makes sense" |
| 00:07 | <tantek> | e.g. it makes sense for an event to have at most one STATUS |
| 00:08 | <Hixie> | my goal here is to merely duplicate the exact conformance criteria of the rfc |
| 00:08 | <Hixie> | without interpretation |
| 00:08 | <tantek> | no matter how you read it you will be doing some interpretation |
| 00:08 | <Hixie> | without interpretation beyond the literal |
| 00:09 | <tantek> | and it also makes sense for an event to have multiple SUMMARY value, perhaps of different lengths |
| 00:09 | <Philip`> | Why not just say the data represented in the markup must follow the conformance criteria of the RFC (and not explicitly say what they are), and let validator developers work out what it means? |
| 00:10 | Philip` | remembers reading things recently about someone attempting to make an iCal validator that was actually useful in practice and would tell you when your calendar would work in common applications, based on the feed validator |
| 00:10 | <Hixie> | Philip`: i couldn't work out a way to say it that made sense |
| 00:11 | <Hixie> | i hate how icalendar requires you to declare whether your value is a datetime or a date |
| 00:12 | <Hixie> | why on earth doesn't it just assume it's a datetime if there's a date and a time and assume it's a date if there's just a date? |
| 00:16 | <Hixie> | wohay! |
| 00:17 | <Hixie> | i found a part of the spec that actually says what can be included once and what can't! |
| 00:18 | <tantek> | Hixie do share which section # |
| 00:21 | <Hixie> | 4.6.1 Event Component |
| 00:21 | <Hixie> | this really is a quite well-written spec |
| 00:21 | <Hixie> | no implied conformance criteria or anything |
| 00:26 | <tantek> | good find Hixie |
| 00:43 | <Hixie> | weird |
| 00:43 | <Hixie> | 'duration' can take P1DT1S but not P1DT1H1S |
| 00:43 | <Hixie> | if you give the hours you have to give the minutes in order to give the seconds |
| 00:44 | <tantek> | I'm sure someone made an argument like "makes parsing easier" ;) |
| 00:45 | <Hixie> | i don't see how, in this case |
| 01:02 | Hixie | fails to understand the purpose and use of RECURRENCE-ID in iCalendar |
| 01:09 | <Hixie> | i wonder whether to support all the recurring event properties |
| 01:22 | <Philip`> | http://www.jenitennison.com/blog/node/104 - hmm, that "really simple scenario" seems to be basically what I was talking about last night, with fetching vocabulary definitions to discover subclass relationships |
| 01:24 | <Philip`> | (which is scary) |
| 01:24 | <Hixie> | "These are the kind of pipe dreams that I used to ridicule semantic web folk about" indeed |
| 01:27 | Philip` | wonders what happens when Amazon builds its vocabulary as a subclass of Google's, and then Google changes its own vocabulary to be a subclass of Amazon's |
| 01:44 | <Dashiva> | Philip`: They're both right, obviously |
| 01:45 | <Hixie> | jesus, iCalendar has a lot of examples for rdate |
| 01:47 | <Dashiva> | "They will now have a stake in answering the difficult questions around trust, confidence, accuracy and time-sensitivity of semantic information." |
| 01:47 | <Dashiva> | Are there even answers to those questions? |
| 01:47 | <Hixie> | it's google's job to answer questions around trust, confidence, accuracy and time-sensitivity of semantic information |
| 01:47 | <tantek> | Hixie, rdate is really complex. And not clear that all the complexity is desired or needed. |
| 01:47 | <Hixie> | Dashiva: that's pretty much what google's area of expertise is |
| 01:48 | <Hixie> | tantek: indeed |
| 01:48 | <tantek> | Hixie, I suggest you take a look at the updates (removals) to rdate etc. that iCal-BASIC is doing. |
| 01:48 | <tantek> | I was keeping up with the "ietf-calsify" mailing list for a while, but after a while was unable to do so. |
| 01:48 | <tantek> | http://lists.osafoundation.org/pipermail/ietf-calsify/ |
| 01:48 | <tantek> | you may have better luck |
| 01:51 | <Hixie> | tantek: thanks, noted |
| 02:10 | <Hixie> | ok, finished adding the vEvent vocabulary to the html5 microdata section |
| 07:18 | <hsivonen> | Philip`: where were you quoting from in http://realtech.burningbird.net/semantic-web/semantic-web-issues-and-practices/holding-on-html5#comment-1455 ? |
| 07:36 | <zcorpan_> | Philip`: my copy of webkit moves <meta>, but not <link>, to head |
| 07:36 | <zcorpan_> | wonder if someone has filed bugs |
| 07:41 | <Hixie> | shelley missed the point in Philip`'s comment |
| 07:41 | <Hixie> | which is that people _must_ understand namespaces to use them |
| 07:42 | <Hixie> | but that they can treat the reverse dns names as opaque magic incantations and it'll still work |
| 07:52 | <aja> | Hixie: ping (typo nit) |
| 07:53 | <Hixie> | aja: here |
| 07:53 | <aja> | geo says 'dix' instead of 'six' digits |
| 07:54 | <Hixie> | thanks |
| 07:54 | <Hixie> | will fix |
| 07:55 | <aja> | np....what other uF-like micro's to come? |
| 07:56 | <Hixie> | aja: vevent (i added today), bibtex (doing that now), and vcard (already in) are all i'm planning on adding right now |
| 07:56 | <Hixie> | those were the ones i needed for the use cases that came up |
| 07:57 | aja | was hoping for reviews :) |
| 07:58 | <aja> | and even hitem......yikes, item=item |
| 08:00 | <hsivonen> | https://twitter.com/arun/statuses/1787778325 |
| 08:00 | <aja> | guess those are probably far from 80% cases |
| 08:05 | <aja> | hsivonen: more like a grue, IMHO |
| 08:10 | <zcorpan_> | Hixie: "They are based on the vocabulary defined in the iCalendar specification, which should be consulted for more information about how to interpret values." - i'm a bit confused as to how to conform when one "should consult" another spec |
| 08:10 | <Hixie> | aja: nobody mentioned reviews anywhere in the use cases as far as i recall |
| 08:11 | <Hixie> | zcorpan_: what kind of conformance? |
| 08:11 | <Hixie> | (author, browser, tool, etc) |
| 08:12 | <zcorpan_> | Hixie: well that's also not so clear to me, who is the "should" intended for |
| 08:13 | <Hixie> | oh, oops, that shouldn't be a should |
| 08:13 | <Hixie> | my bad |
| 08:13 | <aja> | think twas similar wording in vcard, too, fwiw |
| 08:14 | <zcorpan_> | phew, i thought for a second it was just me (after pf suggesting html5 should say "should consult wcag" for alt requirements) |
| 08:14 | <zcorpan_> | (which also made no sense to me) |
| 08:15 | <Hixie> | yeah that was a mistake |
| 08:18 | <aja> | at least pf didn't say MUST :) |
| 08:20 | <zcorpan_> | aja: actually, after saying that "should consult" didn't make sense to me, they suggested instead "must consult" |
| 08:21 | <aja> | oh well |
| 08:21 | <Hixie> | was that a ua conf criteria? cos that would be hard to test! |
| 08:21 | <zcorpan_> | Hixie: i think it would be an authoring conf criteria |
| 08:22 | <zcorpan_> | still equally hard to test though |
| 08:22 | <zcorpan_> | since one can consult a spec but then ignore it |
| 08:22 | <Hixie> | i guess you ask the author "did you consult it?" and if they say no, their document is invalid? |
| 08:22 | <Hixie> | but if they say yes, then regardless of what they did, that criteria is met. |
| 08:23 | <zcorpan_> | yep |
| 08:24 | <Hixie> | man, bibtex is not well-defined |
| 08:25 | <gsnedders> | Hixie: What? You've found _any_ definition? You've done better than I. |
| 08:26 | <aja> | ...and has lotsa scary curly braces |
| 08:26 | <Hixie> | gsnedders: if you count tutorials and the like, i've found dozens |
| 08:26 | <Hixie> | all slightly different |
| 08:26 | <Hixie> | in subtle ways |
| 08:27 | <gsnedders> | Hixie: Oh, sure, I found tutorials and the like. Never any actual spec, though. |
| 08:27 | <Hixie> | i also found the original "spec"/documentation |
| 08:27 | <Hixie> | from like 85 |
| 08:27 | <gsnedders> | Oh, that. |
| 08:27 | <gsnedders> | That's useless. |
| 08:27 | <Hixie> | but iirc it failed to define anything |
| 08:27 | <gsnedders> | It defines what the fields mean. |
| 08:27 | <gsnedders> | It doesn't define the syntax or anything useful like that. |
| 08:30 | <Hixie> | yeah |
| 08:32 | <gsnedders> | This is why for Anolis I gave up and used refer (troff's format) |
| 08:32 | <hsivonen> | gsnedders: since when do you give up on reverse engineering stuff and use something else? |
| 08:32 | <gsnedders> | hsivonen: When I don't need one specific format badly enough |
| 08:33 | <gsnedders> | hsivonen: Also: when I have real deadlines |
| 08:33 | <Hixie> | bibtex is more widely used as far as i can tell |
| 08:33 | <zcorpan_> | so who'll write up a Web bibtex? |
| 08:33 | <Hixie> | me |
| 08:33 | <Hixie> | doing it now |
| 08:33 | <Hixie> | literally as we speak |
| 08:33 | <zcorpan_> | cool |
| 08:33 | <Hixie> | i'm up to "note" |
| 08:33 | <Hixie> | going down alphabetically :-) |
| 08:34 | <gsnedders> | Hixie: I take it you aren't worrying about real-BibTeX syntax? |
| 08:35 | <tantek> | gsnedders, you mean bibtex like for citations? |
| 08:36 | <gsnedders> | tantek: No, I mean what goes in the actual .bib file |
| 08:36 | <Hixie> | gsnedders: define "worrying" |
| 08:36 | <Hixie> | gsnedders: i'm using the vocabulary for microdata |
| 08:36 | <Hixie> | gsnedders: and defining how you convert that _to_ bibtex |
| 08:37 | <Hixie> | which is far easier than parsing it |
| 08:37 | <gsnedders> | Hixie: Needing to define syntax; so you don't need to actual parse BibTeX |
| 08:37 | <tantek> | Hixie, why did you choose bibtex when there are so many citation formats to choose from? http://microformats.org/wiki/citation-formats |
| 08:37 | <hsivonen> | Hixie: and _from_ is Someone Else's Problem? |
| 08:38 | <Hixie> | tantek: it was the best of a bad bunch (i used the microformats.org page as a guide) |
| 08:40 | <tantek> | What evaluation function did you use to determine "best" (or even an approximation thereof) ? |
| 08:40 | <hsivonen> | Hixie: is it deliberate or accidental that HTML5 defines a different tagName upper-casing algorithm than what browsers actually use? |
| 08:40 | <Hixie> | tantek: i forget, it was about 2 weeks ago. |
| 08:41 | <Hixie> | tantek: a combination of factors including deployment, support in software that would be used by the people who's use cases i was trying to address, breadth of support, etc |
| 08:41 | <Hixie> | (breadth as in how many types of works were supported) |
| 08:41 | <tantek> | ok good to know. that's been one of the blocking items for the citation microformat |
| 08:41 | <Hixie> | hsivonen: no |
| 08:42 | <hsivonen> | tantek: fwiw, I'd pick BibTeX by popularity which includes stuff like ACM offering snippets in .bib |
| 08:42 | <tantek> | too many existing (not quite compatible) citation formats to choose from |
| 08:42 | <Hixie> | stuff like ACM offering snippets in .bib was one of the factors |
| 08:42 | <Hixie> | in fact export to bibtex is quite a commonly available feature |
| 08:43 | <Hixie> | even google scholar does it |
| 08:43 | <hsivonen> | Hixie: although with those snippets, you need to be able convert from .bib |
| 08:44 | <hsivonen> | Hixie: was "no" to deliberate or accidental? |
| 08:44 | <Hixie> | hsivonen: not deliberate as far as i'm aware (sorry) |
| 08:44 | <hsivonen> | Hixie: thanks |
| 08:46 | gsnedders | finishes reading Björn's email |
| 08:47 | <gsnedders> | That was, uh, impressive. |
| 08:49 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/105 |
| 08:49 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/106 |
| 08:49 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/107 |
| 08:49 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/108 |
| 08:49 | <Hixie> | oh yes, that _is_ intentional |
| 08:49 | <Hixie> | it was based on something you said, actually |
| 08:50 | <Hixie> | namely that the parser should only have magic in the 7bit ascii range |
| 08:50 | <hsivonen> | It seems that Gecko and WebKit both have different lower-casing in the parser and in the DOM |
| 08:50 | <hsivonen> | yay |
| 08:51 | <hsivonen> | Hixie: only having 7bit magic in parser matches Gecko&WebKit, yes |
| 08:51 | <hsivonen> | Opera is different... |
| 08:53 | <Hixie> | (i don't think this is an area with great interop issues) |
| 08:54 | <hsivonen> | See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/109 in Safari... |
| 08:54 | <hsivonen> | the DOM view |
| 08:54 | <hsivonen> | ß get uppercased to SS |
| 08:55 | <hsivonen> | I wonder what upper/lowercasing Gecko uses in the DOM |
| 08:55 | <hsivonen> | it's neither ASCII nor full Unicode |
| 08:56 | <Hixie> | w(document.getElementsByTagName("gross").length) == 0 in that example |
| 08:56 | <Hixie> | good times |
| 08:56 | <Hixie> | w(document.getElementsByTagName("GROSS").length) == 0 too |
| 08:57 | <hsivonen> | clearly, WebKit lowercases argument instead of doing Unicode fold case comparison |
| 08:57 | <Hixie> | didn't this get resolved recently? |
| 08:58 | <hsivonen> | the spec says *something* but I don't recall the discussion of getting there taking data about the DOM side of implementation into account |
| 08:59 | <hsivonen> | I'd like to see an informed sign-off from people who call the DOM shots for various code bases before I try to change the algorithms Gecko uses here |
| 09:00 | <hsivonen> | I'll send email |
| 09:03 | <Hixie> | i seem to recall the discussion involved bz and mjs |
| 09:03 | <Hixie> | and them signing off on what the spec says now |
| 09:04 | <hsivonen> | ah. ok |
| 09:05 | <othermaciej> | what was the topic? |
| 09:06 | <othermaciej> | oh I'd have to review what the spec says |
| 09:06 | <hsivonen> | othermaciej: browsers currently use different upper/lowercasing algorithms in DOM operations from what the spec says |
| 09:07 | <othermaciej> | I think what makes sense is to ascii-lowercase (not Unicode) the parameter to getElementsByTagName for HTML elements in HTML documents only |
| 09:07 | <othermaciej> | and maybe also lowercase the tag name in such cases |
| 09:07 | <othermaciej> | (I think I was in favor of that but bz was not) |
| 09:07 | <othermaciej> | (if no lowercasing then you have to use localName instead of tagName to DTRT for parser-generated nodes) |
| 09:08 | <Hixie> | the spec says, for html docs only, "compare the given argument in a case-sensitive manner, but when looking at HTML elements, the argument must first be converted to lowercase" |
| 09:08 | <Hixie> | and boris signed off on it: http://lists.w3.org/Archives/Public/public-html/2009May/0020.html |
| 09:09 | <othermaciej> | and does "converted to lowercase" mean unicode or ASCII lowercase? |
| 09:09 | <Hixie> | Converting a string to lowercase means replacing all characters in the range U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) with the corresponding characters in the range U+0061 .. U+007A (i.e. LATIN SMALL LETTER A to LATIN SMALL LETTER Z). |
| 09:09 | <hsivonen> | Hixie: you really should change the term in the spec to include the qualifier ASCII |
| 09:09 | <Hixie> | someone filed a bug on it |
| 09:09 | <Hixie> | it'll happen in due course |
| 09:10 | <Hixie> | rather busy with microdata right now |
| 09:10 | <Hixie> | :-) |
| 09:10 | <othermaciej> | so I see a result of 1 in my WebKit ToT build for the case hsivonen posted |
| 09:11 | <othermaciej> | is that not right? |
| 09:11 | <hsivonen> | othermaciej: which test case? |
| 09:11 | <othermaciej> | does the spec say to compare to tagName or to localName? |
| 09:11 | <Hixie> | what's wrong in webkit for the last example hsivonen posted is that the DOM view shows .tagName says "SS" |
| 09:11 | <hsivonen> | othermaciej: at least Safari 4 public beta uses Unicode upper/lowercasing for DOM ops |
| 09:12 | <othermaciej> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/109 |
| 09:12 | <othermaciej> | is it the uppercasing of the tagName that's wrong? |
| 09:12 | <hsivonen> | othermaciej: yes |
| 09:12 | <Hixie> | a better example is http://software.hixie.ch/utilities/js/live-dom-viewer/saved/110 |
| 09:13 | <Hixie> | compare the result of getEBTN() (1, correct) to the DOM (shows two GROSSes, which is wrong) |
| 09:13 | <othermaciej> | fair enough |
| 09:13 | <Hixie> | wrong per html5, that is |
| 09:13 | <Hixie> | i don't think this is anything to worry about |
| 09:14 | <othermaciej> | I think our getElementByTagName compares localName, not tagName |
| 09:14 | <othermaciej> | which is why the DOM display is inconsistent with the results of gEBTN |
| 09:14 | <Hixie> | right |
| 09:15 | <Hixie> | the DOM display is using a Unicode ToUpper() but should use just the ASCII one per html5 today |
| 09:15 | <othermaciej> | is it correct to compare to localName? (I would think so, despite the name of the API) |
| 09:15 | <Hixie> | yes |
| 09:15 | <hsivonen> | does tagName exist in the WebKit data model |
| 09:15 | <hsivonen> | it doesn't in the Gecko data model |
| 09:15 | <othermaciej> | I don't know what you mean by "exist" |
| 09:16 | <hsivonen> | othermaciej: does an element have a pointer to a string/atom object that represents tagName? |
| 09:16 | <othermaciej> | no |
| 09:17 | <othermaciej> | it knows how to compute it from the QName |
| 09:17 | <Hixie> | appaarently it doesn't know how to do it properly :-P |
| 09:17 | <othermaciej> | (which is different for html elements in an html document) |
| 09:17 | <hsivonen> | Gecko also stores local and prefix and computes tagName if JS asks for it |
| 09:19 | <othermaciej> | really the only bug is using a unicode uppercasing instead of an ascii uppercasing |
| 09:19 | <Hixie> | yep |
| 09:20 | <othermaciej> | though it also looks to me like getElementsByTagName is doing a unicode lowercasing |
| 09:20 | <othermaciej> | which is also a bug, but not revealed by hsivonen's example |
| 09:20 | <othermaciej> | I could have sworn we added operations to do ASCII-only upper/lower |
| 09:20 | <Hixie> | and you'll get an imperceptible perf boost by following html5, horrah |
| 09:24 | <hsivonen> | othermaciej: it was revealed by one of my earlier examples |
| 09:24 | <zcorpan_> | wait, getElementsByTagName uses localName? |
| 09:24 | zcorpan_ | has probably got that wrong in Web DOM Core then |
| 09:24 | <hsivonen> | zcorpan_: I sure hope so |
| 09:25 | hsivonen | hasn't tested |
| 09:25 | <othermaciej> | amusingly, DOM 3 Core is unclear |
| 09:27 | <zcorpan_> | firefox uses nodeName |
| 09:27 | <zcorpan_> | opera and webkit use localName |
| 09:27 | <zcorpan_> | ie uses the equivalent of localName, too |
| 09:27 | zcorpan_ | will fix web dom core |
| 09:29 | <hsivonen> | I guess I should file a Gecko bug, then |
| 09:30 | <Philip`> | hsivonen: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html |
| 09:31 | <hsivonen> | Philip`: thanks |
| 09:36 | <zcorpan_> | http://simon.html5.org/specs/web-dom-core#dom-document-getelementsbytagname fixed |
| 09:37 | <zcorpan_> | that just made getElementsByTagName more useful in compound documents, like selectors |
| 09:39 | <gsnedders> | zcorpan_: What's a filter? |
| 09:39 | <zcorpan_> | gsnedders: "A NodeList is a collection, except that NodeLists can be static (as opposed to live) if a specification defines them to be static. [HTML5]" |
| 09:40 | <gsnedders> | um, how am I meant to know that is what a filter refers to? |
| 09:40 | <zcorpan_> | gsnedders: i guess i should reference html5 for that |
| 09:54 | <Philip`> | jgraham: <type 'exceptions.NameError'>: global name 'reflib' is not defined |
| 09:54 | <Philip`> | in microdata.py:193 |
| 09:55 | <Philip`> | using http://iandavis.com/2009/microdata/ as input |
| 09:55 | <hsivonen> | http://blogs.adobe.com/jd/2009/05/building_upon_untested_assumpt.html |
| 09:55 | <jgraham> | Philip`: Fixed? |
| 09:56 | <jgraham> | (I literally only tested the test document as input and I only checked that the output existed not that it made sense so, as I said, there are bugs) |
| 09:56 | <Philip`> | jgraham: Seems to be happier now |
| 09:57 | <Philip`> | "[<microdata.SimpleUrl object at 0x2b07e4e47490>]" _3:title "Internet Alchemy"; |
| 09:59 | <Philip`> | Hmm, the output seems to be only vaguely correlated to what it should be |
| 10:00 | <Philip`> | (even on test.html) |
| 10:01 | <Philip`> | So I agree there are bugs :-) |
| 10:39 | <gsnedders> | "Summary: The HTML5 editor says he's fighting a battle against Flash. But he doesn't explain why, so it's hard for us to help him get better." — jd |
| 10:50 | <aja> | anyone know if chromium pre-alpha nightlies are pulling webkit trunk? says 530.10 |
| 10:51 | <Hixie> | chromium is usually a bit behind |
| 10:51 | aja | obviously knows nada abouit webkit version numbering |
| 10:51 | <Hixie> | they merge to trunk every few days/weeks (not sure the schedule) |
| 10:51 | <Hixie> | (at least they used to, they were aiming to just be on tip always, dunno if they got there yet) |
| 10:52 | <Hixie> | there's a #chromium channel which might be more appropriate :-) |
| 10:52 | <aja> | yeah,that's why i was wondering |
| 11:30 | <zcorpan> | wonder if html5 should be published again once the microdata stuff is "done" |
| 11:31 | <zcorpan> | to promote wider review of the microdata stuff |
| 11:31 | <Hixie> | probably |
| 11:31 | <Hixie> | i wonder when sam will do that review he said he'd do |
| 11:31 | <Hixie> | i thought he said he was going to do it last month |
| 11:32 | <Hixie> | we sent out the whatwg call for review and everything, but i don't think he ever did anything with it |
| 11:34 | <zcorpan> | Hixie: re running out of punctuation characters to use, there's "|" |
| 11:34 | <zcorpan> | Hixie: also, s/tetx/text/ |
| 11:35 | jgraham | wonders hy Hixie is running out of punctuation characters |
| 11:35 | <jgraham> | *why |
| 11:40 | <zcorpan> | don't remember what he'd use them for, and can't find it in the logs, but i think it was something with abbreviating microdata names, and "." and ":" were taken |
| 11:45 | <Hixie> | zcorpan: yeah, | might work. It's what CSS uses, I guess. |
| 11:45 | <Hixie> | jgraham: basically if we want to register prefixes, we'd need a prefix punctuation character |
| 11:46 | <Hixie> | jgraham: so e.g. "foaf" could be registered in the wiki |
| 11:46 | <Hixie> | foaf|name |
| 11:46 | <Hixie> | item="foaf|Person" ... itemprop="foaf|name" |
| 11:46 | <Hixie> | could work i guess |
| 11:46 | <Hixie> | zcorpan: (fixed tetx, thanks) |
| 11:47 | <Philip`> | Or use "-" |
| 11:47 | <hsivonen> | the openid rel stuff uses . |
| 11:48 | <Hixie> | Philip`: too many one-word terms use "-" |
| 11:48 | <Hixie> | hsivonen: "." is in uris and reversed dns thingies |
| 11:48 | <jgraham> | It has to be a non-uri character, right? |
| 11:48 | <zcorpan> | a uri will have a colon and a reversed dns would have at least two dots |
| 11:48 | <zcorpan> | whereas a prefixed name would have just one dot |
| 11:49 | <Hixie> | true |
| 11:49 | <Philip`> | Could get rid of the reversed DNS thing, and then '.' would be free |
| 11:49 | <jgraham> | using 1 vs multiple dots seems really bad |
| 11:50 | <Hixie> | Philip`: i don't want to require that people use ugly URIs or require that they prefix things. |
| 11:50 | <Hixie> | with registered prefixes |
| 11:50 | <jgraham> | Would / work? |
| 11:51 | <Philip`> | Hixie: They can still use non-globally-unique strings in that case |
| 11:51 | <zcorpan> | # ? |
| 11:51 | <jgraham> | Philip`: I think the reverse dns thing is nice |
| 11:52 | <zcorpan> | item="foaf/Person" ... item="foaf#Person" |
| 11:52 | <jgraham> | Philip`: Also if you want ot report bugs on my microdata implementation, please do :) |
| 11:52 | <Philip`> | The reversed DNS thing only seems to be useful when they want a globally unique identifier, and they don't want to register a prefix, and they think "z.y.x.a" is significantly less ugly than "http://x.y.z/a"; |
| 11:52 | <Philip`> | jgraham: It's too broken for me to bother reporting specific bugs - you should just look at it yourself ;-) |
| 11:52 | <jgraham> | Gah |
| 11:53 | <Philip`> | (at least the RDF bit) |
| 11:53 | <jgraham> | I was hoping that you would have noticed some particular class of underlying brokenness which suggested a simple but far reaching bug |
| 11:54 | <Philip`> | jgraham: As far as I can tell, the underlying brokenness is that your RDF extraction is totally broken :-p |
| 11:54 | <Philip`> | but it might still be a simple fix in the implementation |
| 11:56 | <Philip`> | jgraham: e.g. "Amanda" and "Jazz Band" aren't properties of whatever item they're meant to be properties of |
| 11:56 | <jgraham> | Philip`: That wasn't too helpful :p (seriously though I will try to look at it this evening or so) |
| 11:56 | <Philip`> | and all the top-level items should be in vocab:item |
| 11:57 | <Philip`> | and there's no rdf:type anywhere |
| 11:58 | <jgraham> | Is rdf:type something that was added more recently than Sunday? I didn't actually read the spec again since then |
| 11:58 | <Philip`> | It's always been there |
| 11:58 | <Philip`> | (vocab:item was new, though) |
| 11:59 | <Hixie> | ah well i figure we'll punt on the registered prefixes for now |
| 11:59 | <Hixie> | i'm sure we can find something to make it work if we need to later |
| 11:59 | <Hixie> | first though i must sleep |
| 11:59 | <Hixie> | nn |
| 11:59 | <Philip`> | jgraham: Also, in things like '<http://www.w3.org/1999/xhtml/custom#com.damowmow.img>; "http://james.html5.org/microdata/hedral.jpeg"'; I think the object should be a resource rather than a string |
| 12:00 | <jgraham> | Philip`: That sounds reasonable |
| 12:00 | <Philip`> | jgraham: Also: """Silver is years old and refuses to eat alone, always waiting for either Yellow or Blue to eat with him.11""" |
| 12:01 | <jgraham> | Interesting |
| 12:01 | <Philip`> | Also looks like <time> isn't being handled properly |
| 12:03 | <jgraham> | Philip`: Thanks |
| 12:09 | <zcorpan> | Hixie: btw, you ought to change (or remove) the fallback text in http://damowmow.com/playground/demos/flash/001.html since i see people pointing to it still and hence people copy-and-paste verbatim and the web is full of "FAIL (the browser should render some flash content, not this)." |
| 12:10 | <zcorpan> | s/verbatim/and change only the parts needed to make it work/ |
| 12:13 | <zcorpan> | Hixie: also the cc should look like <!--[if !IE]>--> ... <!--<![endif]--> in order to be valid in html5 |
| 13:54 | <hsivonen> | hmm. it seems to me that http://rdfa.info/wiki/Rdfa-profiles would render new content written with RDFa profiles incompatible with existing RDFa consumers |
| 13:54 | <hsivonen> | just like HTML5 microdata would be incompatible with existing RDFa consumers |
| 13:57 | <Philip`> | I guess changing xmlns:*="" to prefix="..." would be similarly incompatible |
| 14:00 | <Philip`> | (So it'd be nice to sort out any such issues before everyone starts deploying RDFa more than they have already) |
| 14:33 | <hsivonen> | I'm completely puzzled why http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/444375-1-ref.html renders differently with the HTML5 parser even though the DOM looks the same to me |
| 15:03 | <gsnedders> | Is anyone expecting @autosave or @results to be valid on input? |
| 15:06 | Philip` | decides that the microdata DOM API is crazy, because sometimes it'll return a string and sometimes it'll return an array and you have no way of predicting which it's going to be and your code will break horribly when you expect something to specified multiple times and it's only specified once |
| 15:06 | <Philip`> | s/to spec/to be spec/ |
| 15:32 | Lachy | finally found a few minutes to look at the new microdata section |
| 15:32 | <Lachy> | looks interesting, but only read the introductory text so far |
![http://james.html5.org/microdata/hedral.jpeg"'](http://james.html5.org/microdata/hedral.jpeg"'){kind=link}