| 00:01 | <othermaciej> | I guess I should re-add this channel to my autojoin list |
| 00:03 | <Hixie> | so in #webkit othermaciej semi-accidentally suggested prop="" |
| 00:03 | <Hixie> | instead of property="" |
| 00:03 | <Hixie> | and that made me think maybe prop="" or propname="" would be good |
| 00:06 | <Philip`> | itemprop="" |
| 00:06 | <Hixie> | oooh |
| 00:06 | <Hixie> | itemprop="" is good |
| 00:12 | <Philip`> | Hixie: The RDF output has no way of identifying what's an item - you just get a load of blank nodes, some of which aren't used as objects in any triple and therefore can be assumed to be top-level items, which is quite indirect |
| 00:12 | <Hixie> | should we rename element.properties also if we use itemprop="" and element.itemprop? |
| 00:12 | <Philip`> | so maybe it'd be good to generate a triple like '<> <http://www.w3.org/1999/xhtml/something#top-level-item>; _:n' for each top-level item _:n, so that the relationship between items and pages is explicit (and so e.g. it's easy to iterate over them all) |
| 00:13 | <othermaciej> | renaming element.properties to element.itemprops or element.itemProperties would be weird |
| 00:13 | <othermaciej> | because in that case, the element presumably is the item, and it's redundant to ask for the item's item properties |
| 00:13 | <Hixie> | ok |
| 00:14 | <othermaciej> | I was going to say "what other kind would it have?" but it would indeed have CSS properties |
| 00:14 | <othermaciej> | still, I don't think "item properties" vs "CSS properties" is a good distinction, so if disambiguation is needed, I'd say "data properties" |
| 00:14 | <othermaciej> | or something like that |
| 00:15 | <othermaciej> | but that could be confused with the data- attribute mechanism |
| 00:16 | <Hixie> | well i just renamed property to itemprop |
| 00:19 | <Hixie> | Philip`: yeah, that's not a bad idea... |
| 00:19 | <Philip`> | http://philip.html5.org/demos/microdata/demo.html - now with itemprop |
| 00:20 | <Hixie> | that was quick |
| 00:20 | <Hixie> | you guys rock |
| 00:21 | <Philip`> | "guys"? I'm only one person :-p |
| 00:21 | <Hixie> | you and james :-) |
| 00:21 | Philip` | is happy to take all of the credit anyway |
| 00:21 | <Hixie> | you are especially awesome, if that helps :-) |
| 00:24 | <Hixie> | Philip`: added an ...#item triple |
| 00:24 | <Hixie> | let me know what you think |
| 00:24 | <Hixie> | if you like it as is i'll commit it |
| 00:24 | <Hixie> | otherwise let me know if you'd prefer a different name |
| 00:25 | <Philip`> | I don't like how my code has a line saying "value = value.value;" |
| 00:25 | <Hixie> | hah |
| 00:25 | <inimino> | Hixie: s/ancestors/descendants/ in "Properties don't have to be given as ancestors of the element with the item attribute." |
| 00:26 | <Hixie> | inimino: thanks, fixing |
| 00:26 | <Philip`> | Hixie: Is the ...#item thing visible in a place which does not require me downloading megabytes of spec? |
| 00:26 | <Philip`> | (since my current internet connection costs 1.5 pence per megabyte, and I don't want to just throw money away) |
| 00:27 | <Hixie> | i just added the following as step two in the "generate the triples for an item" algorithm: |
| 00:27 | <Hixie> | Generate the following triple: |
| 00:27 | <Hixie> | subject the document's current address predicate http://www.w3.org/1999/xhtml/vocab#item object subject |
| 00:27 | <Hixie> | with some more newlines |
| 00:27 | <Philip`> | That doesn't distinguish top-level items |
| 00:28 | <Hixie> | oh true |
| 00:28 | <Hixie> | oops |
| 00:28 | <Philip`> | Maybe it'd fit better in the place that currently says "(Nothing is done with the returned subject.)" |
| 00:28 | <Hixie> | yeah i'm putting it as a subalgorithm there |
| 00:28 | <Hixie> | is #item ok? |
| 00:29 | <Philip`> | I don't know if conflicting with <meta name=item> is fine |
| 00:30 | <Hixie> | and rel=item |
| 00:30 | <Hixie> | and explicit propitem=""s with that value |
| 00:30 | <Hixie> | i think it's fine, because it doesn't require implementations to do anything (like the rel thing implied it did) |
| 00:31 | <Hixie> | it's up to the author not to make spurious statements |
| 00:31 | <Hixie> | they could just as easily throw in spurious ones in to the triple store later |
| 00:32 | <Philip`> | I also don't know whether it's sensible to use that vocabulary space |
| 00:32 | <Philip`> | (Maybe it is; I've got no idea) |
| 00:32 | <Hixie> | no idea either |
| 00:33 | <Hixie> | inimino: fixed |
| 00:33 | <Hixie> | Philip`: ok, checking it in |
| 00:35 | <Hixie> | http://groups.google.com/group/thosch/browse_thread/thread/3aa1dc61c148c145/edfeb6432267af37 |
| 00:36 | <Hixie> | i've no idea what that last paragraph means, but it's good for us... |
| 00:36 | <Philip`> | Hixie: s/descendents/descendants/ |
| 00:37 | <Hixie> | man between that and "occurrence" (which i reliably spell "occurance") i really can't spell |
| 00:37 | <Philip`> | http://philip.html5.org/demos/microdata/demo.html - now with "<> xhv:item _:n0 ." etc |
| 00:39 | <Philip`> | (I really to output proper N3 blank-node syntax when possible...) |
| 00:39 | <Philip`> | *need |
| 00:41 | <Philip`> | Hixie: Are you aware that computers nowadays are capable of looking up words in dictionaries and automatically highlighting when you get it wrong? |
| 00:41 | <Hixie> | my dictionary says "descendents" is right |
| 00:41 | <Hixie> | and i don't bother with spell checking the spec because about 40% of the words are made up anyway |
| 00:43 | <Philip`> | http://encarta.msn.com/dictionary_1861603981/descendant.html - "Descendant is the only spelling of the noun, denoting somebody or something related to an ancestor, or something based on an earlier thing. Descendent is the usual spelling of the adjective, which means "going downward."" |
| 00:44 | <Hixie> | i didn't say my dictionary was right |
| 00:44 | <Philip`> | It's right that the word exists |
| 00:45 | <Hixie> | with an s on the end? |
| 00:46 | <Philip`> | Easy way to remember the spelling of the noun: Imagine a person whose children and grandchildren are all ants |
| 00:46 | <Philip`> | and they are his descendants |
| 00:47 | <Philip`> | Just be careful not to imagine a person whose children and grandchildren are talking trees, because that'll give entirely the wrong idea |
| 00:47 | <Hixie> | i know it has an a, the problem is i have motor memory now |
| 00:48 | <Philip`> | Hmm, I suppose a group of things which are descendent could be called descendents |
| 00:48 | <inimino> | Hixie: thanks |
| 00:48 | Philip` | decides to resolve the issue by going to bed |
| 00:48 | <Hixie> | nn |
| 00:49 | <Philip`> | jgraham: (By the way, your software is very legacy now) |
| 01:03 | <iand> | Hixie: if you're looking for implementation feedback on microdata, I have marked up a version of my homepage at http://iandavis.com/2009/microdata/ |
| 01:04 | <iand> | it's based on my existing page http://iandavis.com/blog/about which uses eRDF |
| 01:05 | <iand> | I used property attribute, not itemprop, so I could test with http://philip.html5.org/demos/microdata/demo.html |
| 01:05 | <Philip`> | That thing now only accepts itemprop, not property |
| 01:06 | <iand> | Philip`: heh, I can't keep up |
| 01:06 | <iand> | hang on |
| 01:06 | <iand> | ok, just updating |
| 01:06 | <iand> | there's one thing I can't get to work satisfactorily |
| 01:07 | <iand> | I want to say <http://iandavis.com/id/me>; <http://xmlns.com/foaf/0.1/weblog>; <http://iandavis.com/blog>; |
| 01:07 | <iand> | and <http://iandavis.com/blog>; <http://purl.org/dc/terms/title>; "Internet Alchemy" . |
| 01:07 | <Hixie> | iand: cool, looking... |
| 01:08 | <iand> | but I can't get that, currently I have a blank node instead of the blog url |
| 01:08 | <Hixie> | (btw i based this microdata thing in part on the ideas in eRDF, it was useful) |
| 01:08 | <iand> | Hixie: thanks |
| 01:09 | <iand> | if I remove the item attibute then I get the triple <http://iandavis.com/id/me>; <http://xmlns.com/foaf/0.1/weblog>; <http://iandavis.com/blog>; |
| 01:09 | <Hixie> | christ man, that page is going to be like the most microdata-irific page of the year |
| 01:09 | <iand> | but the title of the blog is then attatched to <http://iandavis.com/id/me>; |
| 01:09 | <iand> | Hixie: it was a fairly easy conversion from erdf |
| 01:09 | <Hixie> | cool |
| 01:09 | <Hixie> | ok let's see |
| 01:10 | <Hixie> | your first triple you can do using the under-documented "about" magic word: |
| 01:11 | <Hixie> | <span item><link itemprop="about" href="http://iandavis.com/id/me"><link itemprop="http://xmlns.com/foaf/0.1/weblog"; href="http://iandavis.com/blog"></span>; |
| 01:11 | <Hixie> | (gonna add more about "about" later today or tomorrow) |
| 01:11 | <Hixie> | oh to do both of those you'd do: |
| 01:11 | <iand> | yeah I think I get about, but I don't seem to be able to nest it |
| 01:11 | <iand> | not sure if that was just a limitation of the demo implementation |
| 01:12 | <Philip`> | I'm not aware of any significant ways the demo implementation diverges from the spec |
| 01:12 | <Hixie> | <div item><link itemprop="about" href="http://iandavis.com/id/me"><div itemprop="http://xmlns.com/foaf/0.1/weblog"; item><link itemprop="about" href="http://iandavis.com/blog"><meta itemprop="http://purl.org/dc/terms/title"; content="Internet Alchemy"></div></div> |
| 01:12 | <Hixie> | that should do it |
| 01:12 | <Hixie> | unless i typoed something |
| 01:13 | <iand> | ah, using meta |
| 01:15 | <Hixie> | Philip`: two bugs in your impl with that ode |
| 01:15 | <Hixie> | Philip`: you don't seem to support <meta> |
| 01:15 | <Hixie> | Philip`: and you don't remove the c:abouts |
| 01:15 | <Hixie> | oh that's a bug in the spec |
| 01:15 | <Hixie> | oops |
| 01:15 | <Philip`> | Works for me |
| 01:15 | <Philip`> | in Firefox 3.0 |
| 01:15 | <Hixie> | oh could be a safari bug |
| 01:15 | <Hixie> | makes sense |
| 01:16 | <Philip`> | and Opera 10.0 |
| 01:16 | <Philip`> | I haven't tested in Safari |
| 01:16 | <iand> | Hixie: with the solution above the title of the blog is embedded in content attribute - any way to make that work with it as visible text, i.e. for compatibility with html4 browsers? |
| 01:16 | <Philip`> | jQuery causes various browser-compatibility problems |
| 01:17 | <Hixie> | iand: sure, you <span itemprop="http://purl.org/dc/terms/title">Internet Alchemy</span> instead of the <meta> |
| 01:17 | <Hixie> | s/you/use/ |
| 01:17 | <iand> | ok |
| 01:17 | Philip` | should replace it with pure DOM code when possible |
| 01:17 | iand | hacks a bit |
| 01:17 | <Philip`> | Hixie: Nobody ever told me to remove c:about :-) |
| 01:18 | <Hixie> | yeah adding that now |
| 01:20 | <Philip`> | Assuming you're not adding something crazy, the demo implementation does it now |
| 01:20 | <Hixie> | spec has it now too |
| 01:20 | <Hixie> | just added "If name is equal to the string "about", skip this name" |
| 01:20 | <Hixie> | to "For each name name in element's property names, run the following substeps:" |
| 01:20 | <Hixie> | as substep 1 |
| 01:21 | <Philip`> | Ah, good, that's not crazy |
| 01:24 | <iand> | aha http://iandavis.com/2009/microdata/ gives the triples I want now |
| 01:24 | <iand> | source is URI crazy of course |
| 01:30 | <iand> | thanks Philip` for the microdata demo - it was very helpful |
| 01:33 | <Hixie> | iand: what's your opinion overall? |
| 01:34 | <Hixie> | (of the microdata idea) |
| 01:34 | <iand> | ignoring any conflict with rdfa etc, this would meet my needs |
| 01:34 | <iand> | I'd like an abbreviation mechanism, but I can live without it |
| 01:35 | <iand> | there seems to be no treatment of language? |
| 01:35 | <iand> | and datatypes are limited to the html5 ones |
| 01:35 | <iand> | but for me personally, datatypes were never strong goal in the design of erdf either |
| 01:35 | <Philip`> | I think the only datatypes are string and URL |
| 01:36 | <Philip`> | or at least that's how I've implemented it |
| 01:36 | <iand> | datetime as well |
| 01:36 | <Philip`> | That's a string, according to my code :-) |
| 01:36 | <iand> | :) |
| 01:36 | Philip` | wonders if he should handle it differently |
| 01:37 | <Hixie> | yeah, there's no real typing per se |
| 01:37 | <iand> | the JSON output doesn't distinguish between a URI in href/src and a URI in content - in RDF it makes a difference (i.e. literal vs resource) |
| 01:37 | <Hixie> | none of the use cases listed really needed it |
| 01:37 | <iand> | not sure if it's important for the JSON |
| 01:38 | <Hixie> | i wish i could find an abbreviation mechanism that didn't involve prefixes |
| 01:38 | <iand> | I guess a big area that is missing for RDFa folks will be XMLLiterals, i.e. values of triples that contain markup |
| 01:38 | <Hixie> | i looked at xml literals, but the use cases again didn't really need it, so i punted on it |
| 01:38 | <othermaciej> | if the tag representing an item property contains markup and not just text, is it flattened to text? |
| 01:38 | <Hixie> | othermaciej: yes |
| 01:39 | <Hixie> | (the goal is very much not to map rdf to html, but to solve specific problems that were raised) |
| 01:39 | <othermaciej> | sure, I don't dispute that goal |
| 01:39 | <iand> | Hixie: yes, I get that |
| 01:39 | <Hixie> | othermaciej: the parenthetical was to iand, not you, sorry :-) |
| 01:39 | <othermaciej> | I don't think being able to represent every feature of RDF is essential |
| 01:39 | <othermaciej> | ok |
| 01:40 | <othermaciej> | anyway, I think being able to map *from* microdata *to* RDF is the important direction |
| 01:40 | <iand> | Hixie: did you look at the erdf usage of <link rel="schema.foaf" href="http://xmlns.com/foaf/0.1/"; /> for abbreviation |
| 01:40 | <iand> | I borrowed it from dublin core conventions |
| 01:41 | <Hixie> | yeah, but it's still a prefix |
| 01:41 | <Philip`> | You could use suffixes instead |
| 01:41 | <Hixie> | the problem is with separating the identifier into two parts |
| 01:41 | <iand> | could you allow some sort of mapping of URIs to shortnames to be declared in the document? |
| 01:42 | <Hixie> | whether that's prefixes, or an import mechanism, the problem still exists |
| 01:42 | <Hixie> | i think long term the real solution will be the use of shorter vocab terms like com.example.foo and the use of predefined vocabs |
| 01:42 | <Hixie> | which use short names |
| 01:42 | <iand> | i.e. some way to declare that itemprop="name" maps to http://xmlns.com/foaf/0.1/name |
| 01:43 | <Hixie> | well for certain terms we can predefine them |
| 01:43 | <Hixie> | but in general import mechanisms have many of the same problems as prefixes |
| 01:44 | <Hixie> | maybe i should register term.md or some such, and let people register terms there on a first-come-first-served basis |
| 01:44 | <Hixie> | md.term.foo |
| 01:45 | <iand> | problem is that there are millions of possible predicates... |
| 01:46 | <Philip`> | Say that any name that doesn't contain a '.' should have the string "http://tinyurl.com/"; prepended and then be treated as a URL |
| 01:46 | <Hixie> | heh |
| 01:46 | <Hixie> | that's basically what we do now but with the w3.org prefix |
| 01:46 | <Philip`> | since they've already got the unique-identifier-to-URL mapping database set up |
| 01:47 | <Philip`> | so you still get the benefits of resolvable identifiers |
| 01:47 | <Hixie> | term.md is $150 |
| 01:47 | <Hixie> | that seems excessive |
| 01:47 | <Philip`> | The thing with the w3.org prefix has no mechanism for avoiding conflicts, whereas TinyURL guarantees a unique mapping |
| 01:48 | <Hixie> | well that's the same as getting a domain where people can register domains |
| 01:48 | <Hixie> | er |
| 01:48 | <Hixie> | terms |
| 01:48 | <Philip`> | Hixie: You could use that domain's name without bothering to register it |
| 01:49 | <iand> | I don't think RDF people will get much value out of the reverse dns shortening, com.xmlns.foaf.0.1.name isn't a lot different to http://xmlns.com/foaf/0.1/name |
| 01:49 | <iand> | so I woudnt do anything special for them |
| 01:49 | <iand> | er them includes me |
| 01:50 | <Philip`> | I don't fancy using identifiers like uk.ac.cam.cl.www.pjt47.desc |
| 01:50 | <iand> | as I said, the microdata spec works for me, barring a few wrinkles like languages |
| 01:51 | <Philip`> | (partly since it's awfully ugly, partly since it won't be applicable for the rest of eternity) |
| 01:52 | <Hixie> | iand: what's the languages wrinkle? |
| 01:52 | <Philip`> | (but I don't have any other domain names that are likely to be relevant for eternity (or the next decade, which is basically eternity) either) |
| 01:52 | <Dashiva> | Philip`: Isn't that problem the same whether you use URLs or rewerse domains? |
| 01:52 | <iand> | Hixie: I'd like to say the title of my blog is in french |
| 01:52 | <iand> | I tried adding a lang attribute on the span but it was ignored |
| 01:53 | <iand> | it should really create a literal object with that language |
| 01:53 | <Philip`> | Dashiva: Yes, so reverse domains don't provide any benefit but they're a bit harder to write (I have to think very carefully to avoid writing ac.uk.cam or uk.cam.ac etc) |
| 01:53 | <iand> | <span itemprop="http://purl.org/dc/terms/title"; lang="fr">Internet Alchemy</span> |
| 01:53 | <iand> | should give |
| 01:54 | <iand> | _:x <http://purl.org/dc/terms/title>; "Internet Alchemy"@fr |
| 01:54 | <iand> | I have no idea if that's idiomatic for html5 |
| 01:54 | Philip` | goes to bed before someone causes him to implement that language feature |
| 01:54 | <Hixie> | Philip`: hah |
| 01:54 | <Hixie> | Philip`: nn (again) |
| 01:55 | <Hixie> | iand: what's the magical phrase i should use to require that? Right now I say to "generate a triple" with a subject, predicate, object |
| 01:55 | <Hixie> | iand: do i just add "language" as one of the fields that the "triple" has? |
| 01:55 | <Hixie> | iand: (how does rdfa do it?) |
| 01:56 | <Hixie> | "if there is a value for [current language] then the value of the [plain literal] should include this language information" |
| 01:56 | <Hixie> | hm |
| 01:56 | <Hixie> | i can do that |
| 01:56 | <Hixie> | oh hey, a typed literal can't have a language? |
| 01:57 | <iand> | no |
| 01:57 | <iand> | they're exclusive |
| 01:57 | <iand> | "A plain literal is a string combined with an optional language tag" |
| 01:57 | <iand> | "A typed literal is a string combined with a datatype URI." |
| 01:57 | Hixie | tries to work out the difference between a url and a literal of some kind |
| 01:58 | <iand> | what do you need to know? |
| 01:59 | <iand> | when you generate a triple, the object is a URI ref if it has come from href/src attributes and a literal otherwise |
| 02:00 | <iand> | the literal may have a datatype of xsd:datetime if the datetime attribute is present |
| 02:00 | <iand> | otherwise it will be a plain literal with a language tag taken from the value of the enclosing lang attribute if any |
| 02:01 | <Dashiva> | Philip`: They have the benefit of not being URLs, and you save the http:// part too. |
| 02:07 | <iand> | ok, I'm off now- sleep calls |
| 02:07 | <Hixie> | nn |
| 02:07 | <Hixie> | and thanks for the help |
| 02:08 | <Hixie> | iand: ok, included language information |
| 02:08 | <Hixie> | i didn't do <time> because that would be much more complex than is reasonable |
| 02:09 | <Hixie> | (we'd have to check if it had a time, a date, a timezone, acting differently in each case; we'd have to reserialise, we'd have to handle invalid input cases, etc) |
| 02:55 | <tantek> | Hixie, what methodology are you using to choose new attribute names? (e.g. "property" vs. "prop" vs. "itemprop") |
| 02:56 | <tantek> | (and while you're at it, why not consider "iprop"? it's shorter, has that catchy "i-" start etc. you could even then rename your use of "typeof" to "itype" for some indication of it being related. or even "iroot" 1/2 ;) |
| 02:58 | <othermaciej> | iprop sounds pithy |
| 03:00 | <Dashiva> | "Spec things first, bikeshed later" |
| 03:11 | <tantek> | Dashiva - hence it helps to have a methodology (or at least principles to follow) for such things (like picking names) to avoid religious/bikeshed arguments. |
| 03:39 | <Dashiva> | tantek: You could also say that bikeshedding is probably going to happen anyway, for a feature like this. |
| 03:46 | <tantek> | Dashiva, indeed it is difficult to "avoid" 100% per se, one can only hope to reduce and perhaps somewhat minimize, especially over time. |
| 03:50 | <Dashiva> | Hmm, I suppose the design principles have worked like that. There are some arguments still, but they don't seem to last long. |
| 04:10 | <Hixie> | tantek: i use the "try to make things clear yet functional" methodology |
| 08:01 | <Hixie> | does anyone understand the proposal in http://www.w3.org/mid/9b3b213a0905111517o19503e0lea499ddd0547467⊙mgc ? |
| 08:05 | <othermaciej> | O_O |
| 08:05 | <othermaciej> | o_O |
| 08:06 | <othermaciej> | O_o |
| 08:07 | <Hixie> | that was my response |
| 08:07 | <Hixie> | glad it's not just me |
| 08:07 | <jgraham> | <aol>me too</aol> |
| 08:34 | <krijnh> | http://twitter.com/sandervdv/status/1765852544 - Hixie: you're not coming to Amsterdam? :) |
| 08:34 | <Hixie> | trying not to travel at all this year, so that i can get html5 done |
| 08:35 | <Hixie> | (i did eventually reply to sandervdv after i saw his twitter -- turns out his e-mail had looked too much like spam) |
| 08:35 | <Hixie> | (and i'd ignored it) |
| 08:38 | <krijnh> | Jammer :) |
| 08:49 | <Philip`> | Hixie: The new language thing shouldn't apply to 'object', but that's left out of the list |
| 08:51 | <Hixie> | really? i distinctly remember including <object> |
| 08:51 | <Hixie> | it's there |
| 08:51 | <Hixie> | between link and source |
| 08:52 | <Philip`> | Um... |
| 08:52 | <Philip`> | Good point |
| 08:53 | <Philip`> | Demo now does languages (with very simplified processing of lang attributes) |
| 08:53 | <Hixie> | is the processign hard? |
| 08:55 | <Philip`> | It would be harder if I cared about restricting it to HTML elements, or about handling xml:lang or Content-Language |
| 08:55 | <Philip`> | unless I'm missing something that makes it trivial |
| 08:55 | <Hixie> | ah ok |
| 08:55 | <Hixie> | unfortunately i don't think we expose the language magic to the dom yet |
| 09:09 | <Hixie> | hsivonen: you should coallesce any parse errors generated by an end tag having attributes into one error |
| 09:32 | <Philip`> | http://broadcast.oreilly.com/2009/05/the-bold-and-the-beautiful-two.html |
| 09:36 | <Philip`> | ("Two new drafts out at W3C from the HTML 5 effort: HTML 5: The Markup Language (hat-tip Micah) and HTML 5: A vocabulary and associated APIs for HTML and XHTML ... The first one is a model of the kinds of standards-writing we need ...") |
| 09:41 | Hixie | comments |
| 09:43 | <Philip`> | It's rare for me to find a blog post about HTML5 that you haven't already commented on |
| 09:44 | <Hixie> | heh |
| 09:59 | <othermaciej> | it "make simple objective statements that can be trivially implemented" eh? |
| 10:03 | <Hixie> | he means implemented in a schema |
| 10:03 | <Hixie> | for a lot of people, that's the only meaning of implementation they use |
| 10:05 | Philip` | wonders if many people are just allergic to writing code |
| 10:30 | <zcorpan_> | http://simon.html5.org/html5-elements - now with itemprop |
| 10:37 | <zcorpan_> | Philip`: you could place the <title> in the textarea to make the demo work correctly |
| 10:39 | <Philip`> | zcorpan_: Wouldn't that make the page invalid? |
| 10:40 | <zcorpan_> | Philip`: yes but it would make the demo work correctly |
| 10:40 | <Philip`> | Also, <title> is really boring so I can't imagine many people care about testing it much :-) |
| 10:40 | zcorpan_ | tested it |
| 10:41 | <zcorpan_> | Philip`: if you care about validation you can move elements around with script |
| 10:41 | <Philip`> | That would be a disgusting hack :-p |
| 10:41 | <zcorpan_> | isn't the whole thing a hack anyway? |
| 10:43 | <Philip`> | Yes, but not a disgusting hack |
| 10:47 | <Philip`> | zcorpan_: Changed it now so the <title> is in the textarea |
| 10:47 | <Philip`> | (which makes Firefox not use it as the title for the page) |
| 10:56 | <zcorpan_> | Philip`: file a bug :) |
| 11:05 | <zcorpan_> | "s2.2 I don't see what the need for gratuitously departing from SGML and XML is, allowing <!doctype html> rather than <!DOCTYPE html>." - isn't sgml case insensitive there? |
| 11:08 | <Philip`> | zcorpan_: I find it hard to care sufficiently to file a bug :-( |
| 11:09 | <zcorpan_> | Philip`: you could bug hsivonen to fix it while he's touching all other code related to the parser in some way |
| 11:10 | <zcorpan_> | Philip`: (i think there is magic glue between the parser and document.title in gecko) |
| 11:19 | <Philip`> | Is Opera Turbo meant to actually work? |
| 11:19 | <Philip`> | As far as I can see, it only works when I've got it switched off and am on a fast connection |
| 11:21 | <virtuelv> | young van kesteren's new name is apparently "Ann": http://www.oreillynet.com/xml/blog/2007/02/ecs_moving_from_wellformed_xml.html |
| 11:22 | <virtuelv> | Philip`: yes, it's supposed to work (and as far as I've been able to determine, it does, but it's still in alpha) |
| 11:23 | <virtuelv> | (And, even from Opera's rather fat pipes here, I'm seeing significant speedups on a site like http://db.no/ |
| 11:23 | <virtuelv> | ) |
| 11:23 | <Philip`> | virtuelv: I can tell when it's active because all the images turn into ugly JPEGs :-) |
| 11:25 | <Philip`> | It seems to be working now (when I'm on a wireless LAN), but I don't think I've been able to get it to do anything at all when I'm on a dialup (mobile broadband) connection |
| 11:25 | Philip` | will have to experiment more |
| 11:30 | <zcorpan_> | ECS doesn't seem to support the kind of markup people use on the web - nested divs |
| 11:31 | <zcorpan_> | it also doesn't whine when you make this mistake: <p>Foo <code>bar<code> baz.</p> |
| 12:20 | <Hixie> | hsivonen is going to hate me |
| 12:20 | <Hixie> | my next checkin introduces only about a bazillion conformance criteria |
| 12:20 | <Hixie> | (wip at http://www.whatwg.org/specs/web-apps/current-work/#md-vcard) |
| 12:21 | <Hixie> | ok i'll continue this tomorrow |
| 12:21 | <Hixie> | nn |
| 12:24 | <Philip`> | hsivonen should like having bazillions of conformance criteria - it significantly raises the barriers to entry for competing conformance checkers, thus ensuring he retains market dominance |
| 12:27 | Philip` | hopes predefined vocabularies will be moved out of the main spec document |
| 14:14 | <hsivonen> | Hmm. Why does N-Triples force everything to be ASCII instead of being UTF-8? |
| 14:14 | <hsivonen> | it seems annoying to have to escape all non-ASCII |
| 14:15 | <Philip`> | Does anyone use N-Triples? |
| 14:16 | <Philip`> | http://www.w3.org/DesignIssues/Notation3 says "N3 files are encoded in UTF-8 (See RFC2279), in normalized in Normalization Form C." |
| 14:16 | <Philip`> | http://www.dajobe.org/2004/01/turtle/ says "A Turtle document is a Unicode[UNICODE] character string encoded in UTF-8. Unicode codepoints only in the range U+0 to U+10FFFF inclusive are allowed." |
| 14:16 | <hsivonen> | I don't know, but escape for the requirement to escape non-ASCII, N-Triples seems like it's the cleanest format for expressing RDF |
| 14:17 | <hsivonen> | I wonder how one could produce a Unicode codepoint that isn't in that range |
| 14:19 | <jgraham> | hsivonen: Presumably using some higher version of the unicode standard that allows more codepoints |
| 14:19 | <hsivonen> | jgraham: ok |
| 14:20 | <hsivonen> | I was thinking of implementing the microdata RDF conversion by having Java model classes for microdata and making them expose Jena RDF interfaces, but the Jena RDF interfaces have way too much stuff to implement |
| 14:20 | Philip` | wonders how you represent literals' languages in N-Triples |
| 14:20 | <hsivonen> | Philip`: langString ::= '"' string '"' ( '@' language )? |
| 14:22 | <Philip`> | Oh, right, I was looking at http://www.w3.org/2001/sw/RDFCore/ntriples/ |
| 14:28 | <Philip`> | Hmm, if I click a fragment link in a page then the subjects of all the triples change |
| 14:28 | <Philip`> | (because they're set to the document's current address) |
| 14:36 | <hsivonen> | Also, it seems that an absolute URL is always ASCII per spec |
| 14:36 | <hsivonen> | so it seems IRIs that aren't also URIs can't be used as property names |
| 14:39 | <zcorpan_> | hsivonen: it could if they are ASCIIfied in the RDF output algorithm |
| 14:40 | <hsivonen> | zcorpan_: but RDF allows IRI-ish property names, right? |
| 14:42 | <zcorpan_> | hsivonen: dunno, i thought you were referring to the RDF spec |
| 14:42 | <hsivonen> | zcorpan_: I was referring to HTML5 microdata |
| 14:43 | <hsivonen> | zcorpan_: HTML5 defines 'absolute URL' via resolving the URL |
| 14:43 | <zcorpan_> | ok |
| 14:43 | <hsivonen> | zcorpan_: and resolving seems to URIfy |
| 14:44 | <zcorpan_> | does RDF make a difference between property names that use percent escaping and those that don't? |
| 14:45 | <hsivonen> | zcorpan_: my understanding is that they are different |
| 14:45 | <hsivonen> | zcorpan_: but I'm not an RDF expert |
| 14:46 | <hsivonen> | zcorpan_: IIRC, they are like XML namespaces: compared as strings |
| 14:46 | <zcorpan_> | hsivonen: btw, the n3 syntax allows \UHHHHHHHH escapes for unicode code points |
| 14:46 | <zcorpan_> | hsivonen: ok |
| 14:46 | <hsivonen> | zcorpan_: yes, but it's human-unfriendly if the text is mostly non-ASCII |
| 14:47 | <hsivonen> | (assuming a text editor--not a dedicated RDF editor) |
| 14:47 | <zcorpan_> | hsivonen: it was more re how to use characters above U+10FFFF |
| 14:47 | <hsivonen> | oh |
| 14:47 | <hsivonen> | but those aren't Unicode code points by definition :-) |
| 14:48 | <zcorpan_> | true |
| 14:49 | <zcorpan_> | still seems weird that it has eight instead of six "H"es |
| 14:49 | <Philip`> | It's just copying Python |
| 14:50 | zcorpan_ | didn't know python had the same weirdness |
| 14:52 | <Philip`> | I might be wrong |
| 14:53 | <Philip`> | Hmm, maybe I'm not; \Uxxxxxxxx works in Python 2.5 |
| 14:54 | Philip` | can't find when it was introduced |
| 14:56 | <hsivonen> | Hixie: my photostream on Flickr and set views are examples of pages that have multiple media items with different licenses |
| 14:56 | <hsivonen> | (my photos are either ARR or CC-by on a case-by-case basis) |
| 15:12 | <Philip`> | http://philip.html5.org/demos/microdata/demo.html - now with fancier and more readable (and hopefully syntactically valid and representing the correct triples) N3 output |
| 15:12 | <hsivonen> | I wonder what charter this artifact is being produced and published under: http://www.w3.org/MarkUp/DTD/html4-rdfa-1.dtd |
| 15:14 | <hsivonen> | Philip`: is there a way to feed content to your script using <textarea>? |
| 15:15 | <Philip`> | hsivonen: Uh... Copy-and-paste? |
| 15:15 | <Philip`> | Maybe I'm not sure what you mean |
| 15:15 | <hsivonen> | ooh. I see the textarea now |
| 15:15 | <jgraham> | Philip`: Your UI is not that obvious :) |
| 15:15 | <hsivonen> | the layout of the page is so cluttered that I missed it |
| 15:15 | <Philip`> | jgraham: Very true :-) |
| 15:15 | <jgraham> | Philip`: Especially in Firefox where the json doesn't wrap |
| 15:16 | <Philip`> | Suggestions and/or implementations of improved UIs would be welcome |
| 15:17 | <hsivonen> | Philip`: it would help if the JSON output didn't overlap the input |
| 15:18 | <Philip`> | It doesn't, when I look at it in Firefox 3.0 |
| 15:18 | <Philip`> | Is your screen 320 pixels wide? |
| 15:18 | <hsivonen> | 1650 px wide window |
| 15:19 | <Philip`> | How is the JSON wide enough to reach the input box? It should only be a few dozen characters wide... |
| 15:19 | <hsivonen> | layout code checked out of trunk a bit over a week ago |
| 15:20 | <jgraham> | Philip`: I guess the JSON in firefox 3.5 no longer has line breaks |
| 15:20 | <hsivonen> | Philip`: it's all on one line |
| 15:20 | <Philip`> | Oh |
| 15:20 | <Philip`> | That's not good |
| 15:20 | <Philip`> | Does it have a native implementation of window.JSON that differs from the scripted one? |
| 15:21 | <jgraham> | Philip`: Yes |
| 15:21 | <Philip`> | That's not good |
| 15:22 | <jgraham> | Philip`: Yes it is. Just not in this case |
| 15:23 | <Philip`> | So much for "don't break the web" |
| 15:23 | Philip` | is just using the standard JSON2.js |
| 15:24 | <Philip`> | Hmm, looks like ES3.1 specifies something that does support indentation |
| 15:24 | <Philip`> | Maybe FF3.5 just hasn't implemented it? |
| 15:25 | <Philip`> | Uploaded a new version that uses the non-native JSON implementation |
| 15:30 | <hsivonen> | Philip`: thanks |
| 15:31 | <hsivonen> | Philip`: your impl doesn't deal with <time> elements that have the datetime in element content |
| 15:31 | <Philip`> | "If the element is a time element with a datetime attribute: The value is the value of the element's datetime attribute." |
| 15:31 | <Philip`> | I think I'm doing what the spec says |
| 15:32 | <hsivonen> | oh. |
| 15:32 | <Philip`> | Maybe I'm not |
| 15:32 | <Philip`> | since I forgot the "with a datetime attribute" bit |
| 15:34 | <Philip`> | hsivonen: Fixed |
| 15:34 | <hsivonen> | thanks |
| 15:35 | <Philip`> | This N3 output is actually surprisingly readable now |
| 15:35 | <Philip`> | particularly for input like http://iandavis.com/2009/microdata/ |
| 15:37 | <jgraham> | Philip`: You have rather low standards for what is readable :) |
| 15:40 | <Philip`> | jgraham: I'm comparing it to the old non-nested version that was full of explicit blank nodes and a seemingly random ordering of triples, and I think it's a significant step up from that :-) |
| 15:45 | <jgraham> | Philip`: Oh well I aagree that it may not be the most unreadable syntax it is possible to imagine |
| 15:45 | <jgraham> | But the whole concept of using URIs to identify things other than webpages torpedos readability from the start |
| 15:47 | Philip` | can't easily imagine a syntax that would be much more readable, expressing the same data |
| 15:49 | <jgraham> | Philip`: Assuming the same underlying concepts, macro expansions would make it more readable like def:ian davis=><http://iandavis.com/id/me>; |
| 15:50 | <jgraham> | Ian Davis a <http://xmlns.com/foaf/0.1/Person>; |
| 15:50 | <jgraham> | (obviously you would need more syntax somehow to distinguish macros from other things) |
| 15:51 | <jgraham> | Like ref:(Ian Davis) a <http://xmlns.com/foaf/0.1/Person>; |
| 15:52 | <jgraham> | (and this would be bad for other reasons like copy and paste) |
| 16:02 | <Philip`> | jgraham: That should be rdf:type rather than a, based on the current implementation :-) |
| 16:02 | Philip` | wonders why they didn't use a keyword like "isa" so that it would actually make some intuitive sense |
| 16:03 | Philip` | wonders if jgraham is looking at an old version of the output... |
| 16:05 | <jgraham> | Philip`: Oh, I see. The page had the old output at the bottom, so I was looking at that instead of the new output further down the page |
| 16:05 | <jgraham> | s/The page/The page with the embedded microdata/ |
| 16:06 | <jgraham> | I guess the new version is a bit more readable |
| 16:06 | <Philip`> | Ah |
| 16:08 | <Philip`> | Evidence suggests my UI is rubbish :-( |
| 16:08 | <Philip`> | which is not too surprising since my entire UI design basically consists of style="width: 50%; float: right" |
| 16:09 | <hsivonen> | I wonder if the current microdata spec is too loose when it comes to ensuring that microdata can be mapped to RDF/XML |
| 16:09 | <hsivonen> | specifically, I don't see requirements of certain strings being limited to NCNames |
| 16:16 | <Philip`> | hsivonen: What strings need to be limited to that? |
| 16:17 | Philip` | thought everything could just be expressed as an unabbreviated URI in an attribute value |
| 16:17 | <hsivonen> | Philip`: oh. I thought properties needed to become qnames in RDF/XML |
| 16:18 | <Philip`> | hsivonen: Maybe they do; I know nothing about RDF |
| 16:22 | <Philip`> | hsivonen: (Even if that's the case, I don't see why it ought to be restricted to the subset that's mappable to RDF/XML) |
| 16:24 | <Philip`> | hsivonen: (Presumably RDF people don't like being restricted to that subset, since N3 and Turtle are intentionally and explicitly more expressive than RDF/XML) |
| 16:24 | <hsivonen> | ah, OK |
| 16:25 | <hsivonen> | I find that surprising |
| 16:26 | <Philip`> | (http://www.dajobe.org/2004/01/turtle/ - "The recommended XML syntax for RDF, RDF/XML ([RDF-XML]) has certain restrictions imposed by XML and the use of XML Namespaces that prevent it encoding all RDF graphs (some predicate URIs are forbidden and XML 1.0 forbids encoding some Unicode codepoints). These restrictions do not apply to Turtle.") |
| 16:26 | <Philip`> | (which makes it sound like it's a feature of Turtle rather than a bug or a hazard) |
| 16:28 | <hsivonen> | Hixie: it might be a good idea to note that the RDF graphs produces by the algorithm may not be serializable as RDF/XML |
| 16:28 | <Philip`> | They might not be serialisable as N3/Turtle either |
| 16:28 | <Philip`> | e.g. if you have lang="foo bar" |
| 16:29 | <Philip`> | or if you have itemprop=">" |
| 16:34 | Philip` | wonders why so much time has been spent discussing the RDF extraction of microdata, and very little about the JSON |
| 16:36 | <hsivonen> | I wonder what "html:abbr" is about in http://mxr.mozilla.org/mozilla-central/source/toolkit/components/microformats/src/Microformats.js#345 |
| 16:43 | <Philip`> | hsivonen: http://www.codingforums.com/archive/index.php/t-49227.html ? |
| 16:43 | <Philip`> | (several posts down) |
| 16:47 | <hsivonen> | Philip`: html:abbr as an IE workaround? that's sad |
| 16:50 | <Philip`> | Doesn't seem to be a commonly used pattern in practice, but maybe whoever was writing that code liked it or saw a site that relied on it |
| 17:02 | <Philip`> | http://waffle.wootest.net/2009/05/11/rdf-2/ - "The Microdata section of the HTML5 draft might be one of its finest moments." |
| 17:07 | <jgraham> | """I'm starting to tune out the HTML 5 meta-discussions [...] the emo-drama that people insist on manufacturing… “is such a buzz-kill.""" |
| 17:08 | <Philip`> | Emu drama? |
| 17:08 | <Philip`> | Oh |
| 17:11 | <jgraham> | Philip`: BTW, I expect the lack of discussion about the JSON format is because JSON is more interesting to people who just do things rather than people who architecture things |
| 17:12 | <Philip`> | Shouldn't there at least be someone complaining that 'item.properties.foo[0]' is much harder to type than 'item.foo' and in most cases will be equivalent? |
| 17:12 | <hsivonen> | jgraham: where's 'emo-drama' quoted from? |
| 17:12 | <Philip`> | hsivonen: http://shawn.medero.net/ |
| 18:23 | <tantek> | hsivonen, regarding "I wonder what html:abbr is about in Microformats.js" - see http://microformats.org/wiki/hcard-parsing#all_properties - and I invite you to #microformats for any additional comments. |
| 18:30 | <Philip`> | tantek: That seems to just talk about the normal element named "abbr", not the crazy element named "html:abbr" |
| 18:31 | <tantek> | Philp - is that some sort of oblique namespaces joke? I don't quite understand. |
| 18:33 | <Philip`> | tantek: No - it's about the element with localName == "html:abbr" |
| 18:34 | <Philip`> | (which is impossible to get when you parse XML, but is what you get if you parse "<html:abbr>" in a text/html parser that's not IE) |
| 19:13 | <Groovy> | since when google.com uses <!doctype html> ? |
| 19:32 | <Philip`> | Groovy: Since several months ago, at least |
| 19:33 | <Philip`> | Groovy: (though only on a few of their pages) |
| 19:56 | <Wolfman2000> | Afternoon. I'm trying to make some sense of the new HTML5 tags, and I want to be sure I understand their semantics. <nav> vs. <menu>: it seems that both are to be used for navigation links...and yet only <menu> directly accepts <li>. What is the proper way of using those tags? |
| 20:10 | <jgraham> | Wolfman2000: You probably want <nav> |
| 20:11 | <jgraham> | <menu> is designed for building application menus but it isn't really supported yet |
| 20:11 | jgraham | goes to check he isn't talking rubbish |
| 20:12 | <gsnedders> | nav is for primary navigation, menu is for something that I've never needed and thus can't remember what it is for |
| 20:12 | <Wolfman2000> | The next question then: <article> vs <section>. It seems that there are many sections per article, btu there can be many articles per page. Is an article supposed to represent an entire page, or just the content usually between <header> and <footer>? (I can rephrase if needed) |
| 20:14 | <jgraham> | Wolfman2000: You can have multiple <article>s per page |
| 20:15 | <jgraham> | e.g. <article><h1>My first news item</h1></article> <article><h1>My second news item</h1></article> |
| 20:15 | <Wolfman2000> | ...and what if the items are not really...well, news/blog related? |
| 20:15 | <jgraham> | No problem |
| 20:16 | <Wolfman2000> | My original understanding: using a two column layout, <header> at top, <article> for main column, <nav>/<menu> for navigation on secondary column, <footer> on bottom. Is this still valid thinking? |
| 20:16 | <jgraham> | That seems reasonable |
| 20:17 | <Wolfman2000> | ...long as I'm not required to have <header> and <footer> in <article>/<section>, I may be able to make something work. |
| 20:17 | <Wolfman2000> | I'm currently redesigning one of my websites, and I've been convinced to at least look into HTML5. It seems to reduce my need for IDs at least. |
| 20:21 | <Philip`> | http://google.com/support/webmasters/bin/answer.py?answer=146898 - someone should tell them about <hX> elements instead of <strong> |
| 20:22 | <Philip`> | Aren't their CURIEs resulting in URIs like "http://rdf.data-vocabulary.orgreview";? |
| 20:24 | <gsnedders> | Philip`: I suggest Philip`. |
| 20:25 | <Philip`> | gsnedders: Huh? |
| 20:25 | <gsnedders> | Philip`: To tell them about hX |
| 20:25 | <jgraham> | Philip`: If only there were a google employee around who could file a bug |
| 20:25 | <Philip`> | gsnedders: They don't seem to provide any way to provide feedback |
| 20:25 | <Philip`> | so complaining on IRC is the most effective thing to do |
| 20:37 | <gsnedders> | jgraham: I guess a polarizing filter darkens the sky because the light in unpolarized and hence polarizing it makes it less intense? |
| 20:41 | <Philip`> | Hah |
| 20:41 | <Philip`> | One example says xmlns:v="http://rdf.data-vocabulary.org/"; |
| 20:41 | <jgraham> | gsnedders: Well that is true |
| 20:41 | <Philip`> | All the others say xmlns:v="http://rdf.data-vocabulary.org"; |
| 20:42 | <jgraham> | But it's not really the relevant fact |
| 20:43 | <jgraham> | gsnedders: The point is that the light from the sky is partially polarised (because it is scattered light from the atmosphere and scattering polarises light in a way that depends on the angle of scattering) |
| 20:43 | <Philip`> | <spanspan property="v:locality">Springfield</span> |
| 20:43 | <Philip`> | I think they need to do a bit of QA on these help pages |
| 20:44 | <jgraham> | gsnedders: And as a consequence, with the polarizer set to the right angle you can eliminate almost all of the scattering from the sky |
| 20:44 | <jgraham> | s/scattering/light/ |
| 20:44 | <gsnedders> | jgraham: ah |
| 20:44 | <jgraham> | (or t least from those regions of the sky that are heavilly polarised) |
| 20:45 | <jgraham> | gsnedders: Is this a physics question or a photography question? |
| 20:45 | <gsnedders> | jgraham: a physics of photography question :) |
| 20:45 | <jgraham> | Philip`: But evryone knows that http://example.com/ === http://example.com |
| 20:45 | <gsnedders> | jgraham: (It's random curiosity, really, but from a physics POV) |
| 20:46 | <jgraham> | gsnedders: Oh that's OK. If it's curiosity I don't need to worry to much about being right |
| 20:46 | <Philip`> | jgraham: I do hope Google's implementation doesn't just look for the prefix "v:" |
| 20:46 | <gsnedders> | jgraham: Apart from generic URI parsers that don't know about what RFC2616 defines on-top about scheme specific normalization |
| 20:46 | <gsnedders> | jgraham: :P |
| 20:47 | <jgraham> | gsnedders: "parsers" fail to meet the definition of "everybody" since "body" here specifically means "human body" |
| 20:47 | <jgraham> | Philip`: Didn't Hixie say that the Google implementation of some microdata stuff just used regexps |
| 20:48 | <Wolfman2000> | ...if only the Tidy HTML Validator extension I had recognized HTML5, it would make things easier... |
| 20:48 | <gsnedders> | jgraham: yes |
| 20:48 | <jgraham> | Wolfman2000: http://validator.nu |
| 20:48 | <Wolfman2000> | jgraham: the page I'm working on is not live yet |
| 20:49 | <jgraham> | http://html5.validator.nu/ is better actually |
| 20:49 | <jgraham> | Wolfman2000: Either change the "Address" dropdown to "textarea" |
| 20:49 | <jgraham> | or go through some pain to get a local install |
| 20:49 | <Wolfman2000> | ...gotta love javascript powered fields |
| 20:50 | <Philip`> | jgraham: No |
| 20:50 | <Philip`> | jgraham: "Google's handling of RDF blocks for license declarations is all done with regular expressions instead of actually parsing the namespaces" |
| 20:53 | <jgraham> | Philip`: That sounds quite close if you s/microdata/license declarations/ |
| 20:56 | <Philip`> | jgraham: For some reason I thought you said "RDFa" in your statement |
| 20:56 | <Philip`> | but the evidence indicates that you didn't |
| 21:02 | <Wolfman2000> | ...and with the help of the new HTML5 tags (and some abuse of child selectors), I've trimmed out the <divs> and id=s from my main page. The other pages...will take some time. |
| 21:03 | <Philip`> | Wolfman2000: Has everything broken awfully in IE? :-) |
| 21:03 | <Wolfman2000> | Philip`: javascript workaround. :P |
| 21:04 | <Wolfman2000> | honestly, I don't really care about IE |
| 21:06 | <Philip`> | (Looking at http://rdf.data-vocabulary.org/rdf.xml, I guess xmlns:v="http://rdf.data-vocabulary.org"; and xmlns:v="http://rdf.data-vocabulary.org/"; are *both* wrong, and it ought to be xmlns:v="http://rdf.data-vocabulary.org/#";) |
| 21:07 | <Wolfman2000> | ...right, form elements should keep their IDs. That's fine. |
| 21:07 | <Philip`> | (but presumably Google can add some hacks in their parser to make it all work) |
| 21:10 | <Hixie> | hsivonen: yeah but all your photos have their own pages, so the photostreams and set views don't have to be machine-readable |
| 21:13 | <Wolfman2000> | I'd like confirmation via this picture. http://img509.imageshack.us/my.php?image=picture1kpe.png Left sidebar uses <nav> & <ul> for its links. Center, horizontal links use <ul> by itself, no <nav>. Am I using the tags properly? |
| 22:12 | <Hixie> | anyone remember where Philip`'s parser state diagram is? |
| 22:16 | <Dashiva> | I don't know if it's the most recent, http://canvex.lazyilluminati.com/misc/states10.png |
| 22:20 | <Hixie> | Dashiva: sweet, thanks |
| 22:22 | <Hixie> | oh hey, the very next comment where i needed those for was philip giving links to them |
| 22:22 | <Dashiva> | haha |
| 22:25 | <Hixie> | so when yahoo came out with their "rdfa support", some people on the rdfa list quickly poked holes in it showing it wasn't exactly following the specs |
| 22:26 | <Hixie> | i wonder how long it'll be before someone tries to test google's rdfa support |
| 22:35 | <roc> | not in SVG format? Shame! |
| 22:35 | <Hixie> | the one philip linked to was |
| 22:52 | <Hixie> | i like how shelley complains that the discussion on microdata is split between whatwg and public-html |
| 22:53 | <Hixie> | given that she was the one who split it |
| 22:53 | <Hixie> | (it was all on whatwg until she cross-posted it to public-html) |
| 22:59 | <KevinMarks> | @hixie, well it didn't take long: http://iandavis.com/blog/2009/05/googles-rdfa-a-damp-squib |
| 23:02 | <Philip`> | Today I have learnt that Gmail's basic HTML view completely ignores one's attempts to have multiple sender addresses |
| 23:02 | Philip` | switches to the expensive view and resends the message that got bounced... |
| 23:03 | <othermaciej> | Google inventing their own scheme is a demonstration of the main problem with RDF |
| 23:03 | <othermaciej> | it's a mechanism with no standard vocabulary, and tools won't really be able to do useful things with your data unless you agree on a vocabulary |
| 23:03 | <othermaciej> | thus defeating the goal of decentralized extensibility |
| 23:03 | <KevinMarks> | I thought that was the main advantage of RDF? That's what I'm told when I talk about microformats and agreement being key |
| 23:04 | <KevinMarks> | parsing is easy, agreement is hard |
| 23:05 | <othermaciej> | RDF doesn't require any agreement on vocabulary so long as you don't need to communicate information |
| 23:06 | <Philip`> | Hixie: It's hard to poke holes in Google's RDFa support when it seemingly provides no way to test it, other than owning a site which Google's algorithms and policies deem appropriate to be parsed |
| 23:07 | <roc> | It's useful to support multiparty agreements on vocabulary without going through a central registry |
| 23:07 | <roc> | *how* useful is unclear |
| 23:08 | <gsnedders> | KevinMarks: The problem is to communicate anything you need agreement. It's the hard part you need to get right, the easy part is less important. RDF gets the priority the wrong way around, IMO. |
| 23:09 | <jwalden> | lazyirc: what's the URL of the websockets spec? |
| 23:10 | <roc> | is it my imagination or is Ian Davis saying "They’ve ... thrown away the best [part of RDFa] – the decentralized vocabularies of terms." ... when his real problem is that they didn't use FOAF, i.e., that they *exploited* decentralization? |
| 23:10 | <KevinMarks> | gsnedders: exactly. Thats the point of the microformats process, to converge agreement. |
| 23:10 | <gsnedders> | jwalden: http://lmgtfy.com/?q=websockets+api&l=1 |
| 23:11 | <gsnedders> | roc: Yeah, I saw that too. |
| 23:11 | <jwalden> | gsnedders: there's only a w3.org version? no whatwg version that's latest-svn? |
| 23:11 | <gsnedders> | jwalden: No whatwg version |
| 23:11 | <othermaciej> | gsnedders: that site is awesome |
| 23:11 | <jwalden> | boo-urns |
| 23:12 | <gsnedders> | othermaciej: Fun fact: I had to Google to find its URL :) |
| 23:12 | <Philip`> | roc: They aren't exploiting decentralisation, because they're centralising everything to data-vocabulary.org |
| 23:13 | <roc> | I suppose that's one way of looking at it |
| 23:14 | <Philip`> | They're running everything in their own little walled garden, where you use Google's vocabularies to interact with Google's tools |
| 23:14 | <Philip`> | (Well, maybe not "little", more like "gigantic", but the point is otherwise similar) |
| 23:15 | <roc> | oh, Ian Davis is also suggesting that it's a deliberate attempt by Google to destroy RDFa |
| 23:15 | <Philip`> | Decentralisation would mean anybody could make their own vocabularies and have them interact usefully with Google's tools, I guess |
| 23:16 | <Philip`> | (e.g. I could define my own vocabulary that's a subclass of one Google supports, and then they'd parse the RDF that describes my vocabulary and support it too) |
| 23:16 | <Philip`> | (perhaps) |
| 23:16 | <Philip`> | (though actually I know basically nothing about RDF, so this might be entirely wrong) |
| 23:17 | <KevinMarks> | how? how on earth would they support displaying it in snippets if they don't know what you mean by it? |
| 23:19 | <Philip`> | KevinMarks: You can define your vocabulary to be a subclass of theirs, and then they can treat your data as if it was in their vocabulary |
| 23:19 | <Philip`> | I'm assuming that's kind of the point of using RDF to describe RDF vocabularies |
| 23:20 | <gsnedders> | Fun fact: the W3C TR list RDF didn't conform to its own RDFs |
| 23:20 | <KevinMarks> | this is the point in the conversation where I start thinking that RDF actually stands for Recursive Descent Forever |
| 23:26 | <Hixie> | Philip`: i assure you that whatever else we might be doing, we're not fetching the rdf vocab definitions and doing things with subclassing |
| 23:29 | <Philip`> | Surely it's not that hard - you can have "<#me> rdf:type :Man" and ":Man rdfs:subClassOf :Person" and then add some more triples saying that x rdf:type y and y rdfs:subClassOf z implies x rdf:type z |
| 23:29 | <Philip`> | and then you dump it all into your triple store and crank the handle and an answer comes out |
| 23:30 | <Philip`> | I just made up all that up so it's probably not true but that's how I'd do if I wasn't constrained by sanity |
| 23:31 | <Philip`> | Hixie: Indeed, so it just seems like a complex syntactic alternative to microformats and a bit pointless |
| 23:31 | <roc> | is http://www.whatwg.org/specs/web-apps/current-work/ loading for anyone else? |
| 23:31 | <Hixie> | wfm |
| 23:33 | <gsnedders> | et moi |
| 23:34 | <roc> | sigh |
| 23:35 | Hixie | is confused as to what the point of the "label" type in vcard is |
| 23:36 | <KevinMarks> | label is unstructured address |
| 23:38 | <Hixie> | right but what's the point? |
| 23:39 | <Hixie> | interestingly in norm's vcard ontology, he puts the label inside the address |
| 23:39 | <KevinMarks> | maybe you don't have a structured address, just a string |
| 23:40 | <KevinMarks> | thats how we mapped it into PortableContacts |
| 23:40 | <KevinMarks> | the original spec talks about using it to print an address label |
| 23:41 | <KevinMarks> | "This property specifies the addressing label for physical delivery to the person/object associated with the vCard. The property is intended to include the information necessary to create a formatted delivery address label." |
| 23:42 | <KevinMarks> | and has CR/LF's in it |
| 23:42 | <Philip`> | (Are RDFa property attributes case-sensitive? If so, the Google help pages got that wrong too ("dtreviewed" vs "dtReviewed")) |
