| 00:06 | <jwalden> | gsnedders: note that & doesn't necessarily mean implicitly-pointer, consider inlined functions may never even move a value into memory |
| 00:06 | gsnedders | points out his knowledge of C++ is for most intents non-existant |
| 00:09 | <Philip`> | Explicit pointers with * might not even move the value into memory, so there's no difference :-) |
| 00:10 | <jwalden> | true enough |
| 00:10 | <jwalden> | although it may require a smarter compiler to notice that, with references you get it for free |
| 00:11 | <Philip`> | I'd except references vs pointers to be purely a frontend feature, and the code that's passed to the optimiser would be identical |
| 00:11 | <Philip`> | *expect |
| 00:15 | Philip` | discovers the Status: header in CGI, and wonders where it's meant to be documented |
| 00:15 | <Philip`> | (Actually FastCGI but I think it's meant to be the same) |
| 09:06 | <williamcwilliams> | Oh man. I just want to thank you good people for cutting HTML 5's doctype declaration to <!DOCTYPE html>. And thank you for helping to phase out DTDs so I don't have to learn its convoluted syntax. |
| 09:07 | <Hixie> | our pleasure :-) |
| 10:40 | <Hixie> | wow, json allows duplicate names in an object |
| 10:40 | <Hixie> | i had no idea |
| 10:40 | <Hixie> | (well, they're a SHOULD NOT, but that's it) |
| 11:03 | <williamcwilliams> | I can only see trouble coming out of such a thing. |
| 11:03 | <Hixie> | i expect it's a mistake, people seem to say SHOULD in specs when they mean MUST all the time |
| 11:03 | <Philip`> | Do they say "SHOULD" or "should"? |
| 11:03 | <Hixie> | SHOULD in this case |
| 11:05 | Philip` | likes the HTML5 style of SHOULD/MUST/etc usage, since it makes it clear what behaviour needs to be tested |
| 11:08 | <Philip`> | Sometimes I think other specifications are mostly written for users (who want to know how they can expect their implementations to behave) and implementors (who want to know how their implementations should behave), neither of whom care much about the difference between 'should' and 'must' |
| 11:08 | <Philip`> | whereas something like HTML5 is also written for test writers, who do care about subtle differences between conformance requirements |
| 11:09 | <Hixie> | in practice, both of those groups (users and implementors) are hurt by the should/must confusion |
| 11:09 | <Hixie> | but yes, in general you are right |
| 11:11 | <Philip`> | I'd expect they're hurt mostly by the lack of defined error handling when there's duplicate names, rather than by the use of should/must |
| 11:18 | <Hixie> | i just mean they're hurt by lack of interop in general |
| 11:19 | <Philip`> | That seems largely independent of any should/must confusion |
| 11:20 | <Philip`> | e.g. the JSON spec requires quotes around keys, but lots of JSON implementations let you turn that off because it saves some bytes and it works in some parsers |
| 11:20 | <Philip`> | and it seems they don't really care about interoperability |
| 11:20 | <jgraham> | should/must confusion that prevents you writing tests hampers interop |
| 11:21 | <jgraham> | (also: in the case of JSON there is/was a clause that said roughly 'implementations may have any other behaviour they like'. Which rather undermines the rest of the specification) |
| 11:24 | <Philip`> | On an unrelated topic: Automated tests are great, but running them on a wide variety of web browsers is time-consuming. What we could do is sign up to an online ad system that lets you put arbitrary HTML in your ads, and then immediately get hundreds of thousands of testers with no effort and very low financial cost |
| 11:25 | <jgraham> | Then we'd have to pay to write tests |
| 11:26 | <jgraham> | It would be much better to create our own ad network so that we could inject html tests into other people's ads, and make money at the same time |
| 11:26 | <Philip`> | (and the HTML we put in the ads would be executing the tests and then sending the results (plus UA strings etc) back to the central server) |
| 11:26 | <Philip`> | jgraham: Uh, not quite sure what you mean |
| 11:27 | Hixie | gets into his flame-proof bunker and sends an e-mail to the list |
| 11:27 | <jgraham> | Philip`: Instead of running the tests on some other ad network, set up our own ad network |
| 11:27 | <jgraham> | Sell ads on the network -> make money |
| 11:28 | <Philip`> | jgraham: But that would be extremely hard |
| 11:28 | <jgraham> | Also run tests on the network -> get useful data |
| 11:28 | <Philip`> | and would take years to build up |
| 11:28 | <Hixie> | abarth has done tests on an ad network |
| 11:28 | <Philip`> | and to get on enough sites to get significant numbers of visitors |
| 11:28 | <Hixie> | you might want to speak to him |
| 11:28 | <zcorpan_> | http://blog.whatwg.org/media/vim-checker.png is a 404 (referenced from http://blog.whatwg.org/vim-checker ) |
| 11:28 | <jgraham> | Philip`: Hard yes, extremely hard presumably not. And we have 'till 2022 :) |
| 11:29 | Philip` | was inspired by abarth's work on this :-) |
| 11:32 | <Philip`> | Hixie: Haven't you seen any World War 2 movies? Bunkers are the worst place to be if you're expecting flames, because someone will break down the door and you'll be trapped and will burn to death and it won't be very nice at all |
| 11:32 | <Hixie> | crap |
| 11:32 | <Hixie> | where should i hide then? |
| 11:32 | <Philip`> | You could go scuba diving |
| 11:32 | Hixie | goes scuba diving in a hurry |
| 11:33 | <Hixie> | ahblblublublbolbullblubloblub? |
| 11:34 | <williamcwilliams> | Say, I'm peering at the JSON specification via http://www.ietf.org/rfc/rfc4627.txt and it mentions in section 1.1 that it uses "MUST" and "SHOULD" as described in RFC2119. This leads me to believe that Mr. Crockford definitely intended such specific uses of those terms... Sorry if this is a crazy blast from the past here. |
| 11:35 | <Hixie> | a lot of spec writers put that boilerplate there without really understanding it, sad to say |
| 11:35 | <Hixie> | dunno if this is the case is doug's case |
| 11:36 | <Hixie> | but if he really meant SHOULD there, that's mighty odd |
| 11:37 | <zcorpan_> | " The names within an object SHOULD be unique." |
| 11:37 | <Philip`> | HTML5 had the same boilerplate and then proceeded to use the terms in ways that were not described in RFC2119 |
| 11:37 | <Hixie> | indeed |
| 11:37 | <Philip`> | so it's a common problem :-) |
| 11:38 | <williamcwilliams> | That is pretty funny! Yet frustratrating at times, I'm sure. |
| 11:38 | <jgraham> | Hixie: Just skimming your new email; is it really necessary to do <span item id=a><span property="com.example.name">a</span></span> rather than something like <span id=a property="com.example.name>a</span>? |
| 11:39 | <zcorpan_> | Philip`: in HTML5's case it was more because of RFC2119 not expecting the classes of products that HTML5 was having, right? |
| 11:39 | Philip` | is thinking of the use of phrases like "must only", which have meaning only in English and not in RFC2119 |
| 11:39 | <Hixie> | jgraham: you need the item="" attribute to declare the new group of name-value pairs |
| 11:40 | <jgraham> | Hixie: At the very least it would be good if <span item property> acted like <span item><span property> |
| 11:40 | <Hixie> | jgraham: you can't do item="" property="" on the same element in this case, because when you do that it means the new group is the value of the given property on whatever the corresponding "parent" item is |
| 11:40 | <zcorpan_> | Philip`: ah, ok |
| 11:41 | <Hixie> | jgraham: e.g. <span item="vcard"> <span property="agent" item="vcard"> <span property="...">...</span> </span> </span> |
| 11:41 | <Hixie> | jgraham: the middle one there is saying that "agent" is a property of the outer item, whose value is itself an item. |
| 11:41 | <Hixie> | luckily, that's basically as complex as this stuff gets. |
| 11:41 | <jgraham> | Hixie: Hmm. I will think about this more when I have understood the proposal beter, but my initial reaction is that people will get this wrong and be surprised |
| 11:42 | <Hixie> | i don't think the case of those bulbs will be a common case |
| 11:43 | <jgraham> | OK. |
| 11:43 | <jgraham> | I'll see what other people say |
| 11:46 | <williamcwilliams> | Hixie: Do you mean that if, in your example, the second tag didn't have the the item attribute explicitly set, it would still have item="vcard" like its parent? |
| 11:47 | <Hixie> | if the second tag didn't have the item attribute explicitly set, the third one would set a "..." property on the first one, instead of the second |
| 11:47 | <Hixie> | so the first one would have two properties, "agent" and "..." |
| 11:47 | <Hixie> | instead of the first one having a property "agent" which itself has a property "..." |
| 11:54 | <Philip`> | Reversed domain names aren't sufficient for people with shared hosting on a single domain |
| 11:54 | <Philip`> | which seems a bit of a pain |
| 11:54 | <Hixie> | why not? |
| 11:54 | <Hixie> | just stick your path components on the end |
| 11:54 | <Philip`> | If everyone on Geocities uses com.geocities.* then there's no convention to avoid conflicts |
| 11:55 | <Hixie> | if everyone on Geocities uses microdata, I will hand in my spec editor's badge. |
| 11:55 | <Philip`> | If two people on Geocities use com.geocities.* then there's no convention to avoid conflicts |
| 11:55 | <Philip`> | and s/Geocities/something like Geocities that isn't dead yet/ |
| 11:55 | <Hixie> | so buy a domain |
| 11:55 | <Hixie> | it's like $5 a year |
| 11:55 | <Hixie> | or hope for the best and use com.geocities.philip.foo |
| 11:56 | <Hixie> | (or use a uri, those are still allowed too, for teh crazy people who think uris are better!) |
| 12:00 | <Philip`> | I haven't read the spec so I don't know what it suggests; I'm just thinking that if it suggests a convention, it should suggest a convention that can work for independent people who share a domain name, even if it's something vague like adding a unique-in-that-domain identifier onto the end |
| 12:00 | <Hixie> | the spec doesn't have any informative text on that topic yet |
| 12:01 | <Hixie> | i'll make a note to add something to the intro section though |
| 12:01 | <Hixie> | thanks |
| 12:04 | <Philip`> | If I want to write a page containing data about two cats, and say that cat A is the parent of cat B, and cat B is a child of cat A, can I do that nicely? |
| 12:05 | <Hixie> | not yet. I have considered a a <ref> element to do that in a future version, but none of the use cases I had actually needed it, so I punted on it for now. |
| 12:05 | <Philip`> | It looks like the new microdata stuff is purely tree-shaped and can't do graphs, and there isn't any way for one item to refer to another |
| 12:05 | <Philip`> | since items don't have identifiers |
| 12:05 | <Hixie> | items have id="" attributes like any other html element |
| 12:05 | <Hixie> | but yes, there's no way to make arbitrary graphs yet |
| 12:07 | <Philip`> | Hmm, I suppose the API could be extended to expose $item->id() and $microdata->get_item_by_id('...') |
| 12:07 | <Philip`> | but then it won't work if I put each cat on a separate page, and want them to refer to each other |
| 12:07 | <Philip`> | (i.e. being in separate items of @docs) |
| 12:08 | <Hixie> | none of the use cases needed that |
| 12:08 | <Philip`> | so one would have to refer to items by a full URI instead |
| 12:08 | <Hixie> | but yeah, if we really wanted to support that, we could just have <ref> support cross-document references too |
| 12:09 | <Hixie> | usemap="" showed that wasn't too hot, though |
| 12:15 | <Hixie> | ok i just checked in a brief intro section. bed time now. I'm sure when I wake up I'll have record amounts of mail. |
| 12:15 | <Hixie> | nn |
| 12:19 | <jgraham> | Hixie: It would be nice if the corresponding item algorithm was written in priority order rahter than reverse priority order |
| 12:19 | <jgraham> | also: gn |
| 12:31 | <Philip`> | Hixie: s/desireable/desirable/ |
| 12:34 | <Philip`> | Hixie: "Properties can also have values that are URLs. This is achieved using the a element and its href attribute." - but the example uses <img src> instead |
| 13:45 | <Philip`> | Is there some DOM API that will return a resolved URL? |
| 13:45 | <Philip`> | (and that works in real browsers) |
| 13:45 | <Philip`> | given a relative URL as input |
| 14:09 | <Philip`> | http://philip.html5.org/demos/microdata/demo.html |
| 14:10 | krijnh | likes the proposal |
| 14:11 | <Philip`> | Hmph, Gmail's 'basic HTML' UI doesn't let you select your From address :-( |
| 14:22 | <Philip`> | At least the proposal is easy to implement |
| 14:22 | <Philip`> | though JQuery is a bit rubbish because its attribute selectors only work half the time |
| 14:22 | <krijnh> | They do? |
| 14:23 | <Philip`> | $('[item]') finds <div item> in Opera (10) but not in Firefox (3.0); $(...).parents('[item]') doesn't find it in either |
| 14:23 | <krijnh> | Weird |
| 14:23 | Philip` | presumes it's to do with optimising some cases with querySelector or whatever it's called |
| 14:23 | <krijnh> | Yeah |
| 14:24 | <krijnh> | But JohnResig might know :) |
| 14:24 | <Philip`> | $('*').filter(function() { return this.getAttribute('item') !== null }) makes me unhappy |
| 14:24 | <krijnh> | http://james.padolsey.com/javascript/a-better-data-selector-for-jquery/ - just extend the selector, and create an :item selector |
| 14:25 | <Philip`> | That sounds even less efficient |
| 14:25 | <krijnh> | It probably is |
| 14:26 | <krijnh> | But jQuery users don't care too much about efficiency ;) *runs* |
| 14:26 | <Philip`> | I think my code is already O(n^2) but I don't want to make it slower |
| 14:27 | <krijnh> | (I'm a jQuery user as well btw) |
| 14:28 | <Philip`> | (I think I could make it O(n) without too much trouble, but I'm lazy and this way works) |
| 14:29 | <Philip`> | ((The problem is finding the properties with a specific corresponding item)) |
| 14:37 | <Philip`> | Oh, and JQuery's node.is('time') fails in (at least) Opera 10 |
| 14:54 | <gsnedders> | Woah. Kinda big commits. |
| 15:01 | <Philip`> | gsnedders: I suggest complaining about the solution without bothering to read it first |
| 15:02 | <gsnedders> | Philip`: That means not revising for exams that start on Friday |
| 15:03 | <Philip`> | gsnedders: Exams happen every year, HTML5 is only going to happen once in the whole of human civilisation |
| 15:03 | <Philip`> | You need to get your priorities right |
| 15:03 | <gsnedders> | However, HTML 5 will still be ongoing after my exams. |
| 15:31 | <jgraham> | Philip`: Ah, you beat me. I have a somewhat working html5lib based implementation which allowed me to conclude that the api is easy to implement |
| 15:31 | <jgraham> | But went for a bike ride rather thank finishing it |
| 15:32 | <Philip`> | You need to get your priorities right |
| 15:32 | <jgraham> | You would have won anyway :) |
| 15:33 | <Philip`> | You could still win at producing RDF output |
| 15:34 | <jgraham> | Yeah I might do that. Or I might not bother. Who know |
| 15:34 | <jgraham> | s |
| 15:39 | <Philip`> | http://news.bbc.co.uk/1/hi/programmes/click_online/8040863.stm - "These TV sets are not equipped with full web browsers, as some sites involve lots of small writing that would be difficult to read from a distance." - someone should tell them about the abilities of modern browsers to zoom and change the text size |
| 15:40 | <Philip`> | (Sounds like more attempts at walled gardens) |
| 17:07 | <jgraham> | """If there is exactly one element whose corresponding item is item and that has as one of its property names the string "about"""". Does that mean (there is one element whose corresponding item is item) and (the corresponding item has a property called about)" |
| 17:08 | <jgraham> | or (of the elements whose corresponding item is item, there is exactly one called about) |
| 17:09 | <jgraham> | s/called/with a property called/ |
| 17:10 | Philip` | wonders if jgraham is implementing the same thing he's implementing |
| 17:13 | <jgraham> | Philip`: Possibly. |
| 17:14 | <Philip`> | I hope you're implementing it in your Python version |
| 17:15 | <jgraham> | Philip`: Indeed |
| 17:15 | <jgraham> | Although the RDF stuff is much more tedious than the whole rest of the microdata section, so I am tempted to stop and just implement the frontend |
| 17:16 | <jgraham> | (where by "much more tedious" I mean "I can't be bothered to work out the anser to the question above") |
| 17:17 | <jgraham> | (or implement any of the url functions) |
| 17:17 | <jgraham> | (although those are really needed anyway) |
| 17:37 | <gsnedders> | 8:24 from Southampton Central to Stirling by train, with a 45 minute stop-over in London. Yay :\ |
| 17:40 | <gsnedders> | Or I could fly Southampton to Edinburgh, then go on by train, which would save me a bit of time but would add hassle… |
| 18:27 | <gsnedders> | jgraham: you still around? |
| 18:28 | <gsnedders> | Anyone else who knows physics: you around? |
| 18:28 | <gsnedders> | Ah, Wikipedia helps. |
| 18:28 | <jgraham> | gsnedders: Yes |
| 18:28 | <gsnedders> | (i.e., nvm) |
| 18:28 | <gsnedders> | (Though I may still need help at some other time) |
| 18:40 | <gsnedders> | Anyone got any sane way of remembering which way around the ± is for the Doppler effect (i.e., within equations like f = f_s(\frac{v}{v±v_s}))? |
| 18:41 | gsnedders | should probably conclude he can work this out by thinking about it. |
| 18:46 | <gsnedders> | Peh. The |
| 18:46 | <gsnedders> | So if the source and observer and getting closer, f must increase, and then it can be worked out from that. |
| 18:48 | <gsnedders> | Is that right? |
| 18:52 | <jgraham> | gsnedders: Yeah, things comping toward you go high pitched. If your answer doesn't give that you did it wrong |
| 18:52 | <gsnedders> | From Wikipedia: "Craig Bohren pointed out in 1991 that some physics textbooks erroneously state that the observed frequency increases as the object approaches an observer and then decreases only as the object passes the observer." — Huh? |
| 18:59 | <jgraham> | gsnedders: They're saying that the frequency doesn't get higher and higher as the object approaches you |
| 19:01 | <gsnedders> | OK, that's basically what I concluded after staring at that for five minutes. |
| 19:01 | <jgraham> | In unrelated news, I hate easy_install and whatever they call the braindead system it runs on |
| 19:03 | <Philip`> | You should be thankful that they didn't call it ezinstall |
| 19:04 | <jgraham> | Why the fuck is it trying to extract archives to my web server directory? |
| 19:06 | jgraham | notices Shelly's email from earlier |
| 20:23 | <Hixie> | jgraham: is that sentence in the rdf section clearer now? |
| 20:27 | <Hixie> | Philip`: to resolve URLs, just use the DOM attributes, the browser will then do it for you |
| 20:28 | <jgraham> | Hixie: I don't understand why there must only be a single element with item item |
| 20:29 | <Hixie> | then it's still not clear, hold on let me fix it more |
| 20:30 | <Hixie> | regenning, look in a few seconds |
| 20:30 | <jgraham> | OK |
| 20:30 | <jgraham> | (I assume that the actul condition is that for each item there is a single value of a property called about, right?) |
| 20:31 | <Hixie> | right |
| 20:31 | <Hixie> | regenned |
| 20:32 | <jgraham> | Yes, that makes sense now |
| 20:32 | <jgraham> | Thanks |
| 20:32 | <Hixie> | cool |
| 20:32 | <Hixie> | i'm very confused by shelley's e-mails |
| 20:33 | <Hixie> | was she wanting me to stop working on the use cases while she redid them? |
| 20:35 | <takkaria> | Hixie: I like the microdata draft, seems like it's far more understandable than RDFa |
| 20:35 | <Hixie> | sweet |
| 20:35 | <Hixie> | i've gotten far more positive feedback (mostly off-list or on IRC) than I expected |
| 20:35 | <Hixie> | and virtuall no negative feedback so far |
| 20:35 | <gsnedders> | Hixie: It sucks. |
| 20:36 | <Philip`> | It's easy to make something more understandable than RDFa; the problem is to make it sufficiently expressive to handle enough of what people want to do with it |
| 20:36 | <gsnedders> | (Because it's too long for me to have time to look at now.) |
| 20:36 | <gsnedders> | (See, I do actually have a reason!) |
| 20:36 | <Hixie> | gsnedders: dude it's actually surprisingly short |
| 20:36 | <Hixie> | gsnedders: there's even an incomplete intro section now too |
| 20:37 | <gsnedders> | Hixie: OK, the diff was long :P |
| 20:37 | <gsnedders> | The fact it renumbered half the TOC didn't helop |
| 20:37 | <gsnedders> | *help |
| 20:37 | <Hixie> | Philip`: yeah... it handles all the use cases i listed (i checked by making examples for most of them), but i'm sure there are things people didn't mention that will be harder |
| 20:37 | <Philip`> | gsnedders: Read the new section rather than the diff |
| 20:37 | <Hixie> | gsnedders: oh you want to look at the /source diff not the /index diff |
| 20:37 | <Hixie> | gsnedders: and the diff included all kinds of random stuff |
| 20:37 | <Hixie> | gsnedders: e.g. new interfaces and stuff |
| 20:37 | <Hixie> | gsnedders: which you don't need to read to get the microdata stiff |
| 20:37 | <Hixie> | stuff |
| 20:37 | <gsnedders> | Hixie: I know. But the email includes both, and /index is always first :P |
| 20:38 | gsnedders | goes back to question 11 of the 2004 exam paper |
| 20:38 | <takkaria> | I wonder how hard it would be to transplant hcard into the microdata thing |
| 20:38 | <Philip`> | I suppose an obvious complaint is that people who've already put a lot of work into defining RDF-based vocabularies would have to start over again defining a whole new naming system for the vocabulary |
| 20:38 | <Hixie> | gsnedders: hah |
| 20:39 | <Hixie> | takkaria: surprisingly easy, that's next on my list of things to mail about :-) |
| 20:39 | <Philip`> | (and it'd be nice to have a stronger mapping between them) |
| 20:39 | <Hixie> | Philip`: nah, they can use uris with this |
| 20:39 | <jgraham> | http://james.html5.org/microdata/ |
| 20:39 | <jgraham> | Work in progress, if it gives the right result it is pure serendipity |
| 20:40 | <Hixie> | man you guys rock |
| 20:40 | <Philip`> | jgraham: Charset is wrong on test page |
| 20:40 | <Hixie> | it's barely been 12 hours and you've already made two separate implementations |
| 20:41 | <Philip`> | jgraham: JSON output needs indentation |
| 20:42 | Philip` | almost implemented RDF output too, but discovered it was not trivial to generate N3 when there's blank nodes, and gave up and ate biscuits instead |
| 20:42 | <Hixie> | it's not that hard is it? you just do _:nodeN where N is a globally increasing number per blank node |
| 20:43 | <Hixie> | basically each time you make a blank node you call it _:nodeN and then pretend it's not blank |
| 20:43 | <Philip`> | That's ugly |
| 20:43 | <gsnedders> | Hixie: See, it's all work and no µdata :P |
| 20:43 | <gsnedders> | s/µdata/play/ |
| 20:44 | <jgraham> | Philip`: Fixed the pretty printing thing |
| 20:44 | <Hixie> | Philip`: it's rdf baby |
| 20:44 | <jgraham> | Oh, I think I fixed the other thing too but I'm not sure |
| 20:44 | <Philip`> | I wanted to do it like '<> custom:band [ custom:name "Jazz Band"; custom:size "12" ]' |
| 20:44 | <Philip`> | (I think that's possibly the right syntax) |
| 20:45 | <jgraham> | I got part of the way through doing the RDF thing at which point it became obvious that RDF was going to be more work than the whole microdata section so far |
| 20:46 | <jgraham> | So I stopped |
| 20:46 | <gsnedders> | rdflib++ |
| 20:46 | <Philip`> | I suppose I need to generate a graph and then serialise it, rather than printing out a line each time I find a property |
| 20:46 | gsnedders | just tells Philip` to stop implementing RDF himself, as it isn't nice to implement |
| 20:46 | <gsnedders> | Also, see #swig |
| 20:46 | jgraham | was hoping it would work to make a list of triples and have something that took a list of triples and printed N3 |
| 20:47 | <jgraham> | But maybe RDFLib is the way forward |
| 20:47 | <Philip`> | gsnedders: I'm not implementing RDF, I'm just implementing something that output text that happens to be a subset of RDF |
| 20:48 | <jgraham> | Implementing all the URL munging stuff is still a massive pain though |
| 20:48 | <jgraham> | (which I need anyway) |
| 20:48 | <jgraham> | (so I can't blame on RDF) |
| 20:48 | <Hixie> | URL munging stuff? |
| 20:49 | <gsnedders> | Hixie: For less favourable comments, see #swig :P |
| 20:49 | <Hixie> | is that archived anywhere? |
| 20:50 | <gsnedders> | Hixie: It is, but logs appear to be down |
| 20:50 | <gsnedders> | http://swig.xmlhack.com/ is the URL |
| 20:50 | <gsnedders> | no idea if it'll come back up |
| 20:50 | <Hixie> | can you paste us any feedback then? :-) |
| 20:51 | <gsnedders> | Hixie: That's effort :P |
| 20:51 | <Philip`> | jgraham: I took the approach of ignoring any URL stuff that wasn't trivial, because I was trying to make a rough proof-of-concept to see how the thing worked, rather than making an actual proper implementation :-) |
| 20:51 | <Hixie> | -_- |
| 20:51 | <gsnedders> | Hixie: I can, if you help me wit physics! :P |
| 20:51 | <Hixie> | objects with mass attract each other |
| 20:51 | <Philip`> | What about objects without mass? |
| 20:51 | <Hixie> | everything else is complicated |
| 20:51 | <gsnedders> | Hixie: I need more complex help :P |
| 20:52 | <Hixie> | Philip`: they go at the speed of light so from their perspective time doesn't move so they can't do anything |
| 20:52 | <Philip`> | gsnedders: You need to specify your problem in a more complex way than "help me wit[h] physics" if you want more complex help :-p |
| 20:52 | <gsnedders> | Hixie: http://pastebin.com/m332bac12 |
| 20:53 | <gsnedders> | "Calculate the time for the wave to travel between these points (at x = 3.0m and x = 4.0m)" where we have a transverse wave given by y = 8.0 sin(12t-0.50x) |
| 20:53 | <Hixie> | gsnedders: let me know if they have any actual feedback :-) |
| 20:54 | <Hixie> | correct me if i'm wrong but that wave doesn't move |
| 20:54 | <Philip`> | It does if t does, surely |
| 20:54 | <Hixie> | since it has a constant amplitude |
| 20:54 | <Hixie> | no, that just changes the phase of the wave |
| 20:54 | <Hixie> | the wave itself doesn't move |
| 20:55 | <gsnedders> | Well, the answer is 0.04°s. |
| 20:55 | <gsnedders> | But how do you get there? :P |
| 20:55 | <Philip`> | That's just being pedantic :-p |
| 20:55 | <Hixie> | it's not pedanticism, it's physics! |
| 20:55 | <gsnedders> | But that is true :P |
| 20:55 | <Hixie> | if you have waves in water, and you have a buoy on that water, it just bobs up and down |
| 20:55 | <Philip`> | I assume the idea is to calculate how long it takes for the peaks to 'travel', or something |
| 20:55 | <gsnedders> | It doesn't help me get me to the answer. |
| 20:55 | <Hixie> | it doesn't go tearing down the wave like a surfer headed to the beach |
| 20:55 | <Philip`> | because it couldn't mean anything else |
| 20:56 | <Hixie> | sounds like it's asking the wavelength then |
| 20:56 | <Hixie> | or equivalently the frequency |
| 20:57 | <Hixie> | which of course you can link using LF = c (wavelength * frequency = propagation speed) |
| 20:57 | <Hixie> | er |
| 20:57 | <Hixie> | phase speed |
| 20:57 | <Hixie> | not propagation speed |
| 20:57 | <Philip`> | I guess you simply want sin(12*t1 - 0.5*3) = sin(12*t2 - 0.5*4), so 12*dt = 0.5 and dt=1/24 sec ( = 0.042ish) |
| 20:59 | <Philip`> | kind of skipping all the ideas about phase and sin not being invertable, because they make life complex |
| 20:59 | <Philip`> | *invertible |
| 21:02 | <Philip`> | (Perhaps it's more precise to state that the phase is 12t-0.5x and you want the phases to be equal at the two xs, rather than unjustifiedly asserting that the sins are equal) |
| 21:02 | <gsnedders> | Hixie: LF? |
| 21:02 | <Hixie> | lambda * f |
| 21:02 | <gsnedders> | Ah |
| 21:03 | gsnedders | is probably meant to do this from the phase difference, seeming the first part of this subquestion was working that out |
| 21:05 | <gsnedders> | Actually, can it not be done more simply through v = f*lamba and v = s/t? |
| 21:09 | <Philip`> | gsnedders: Why do you doubt that it could be? |
| 21:09 | <gsnedders> | Philip`: That seems so much simpler than what you and Hixie were saying :P |
| 21:12 | <Philip`> | gsnedders: How is it simpler than saying 12*t1-0.5*3 = 12*t2-0.5*4? :-) |
| 21:13 | gsnedders | shrugs |
| 21:14 | <jgraham> | Hixie: converting relative urls to absolute urls |
| 21:19 | <Philip`> | http://philip.html5.org/demos/microdata/demo.html - now with ugly buggy RDF output |
| 21:21 | <Philip`> | Hixie: "property value" is defined with "If the element also has an item attribute: The value is the item created by the element." |
| 21:21 | <Philip`> | Hixie: and the JSON thing says "Let value be the property value of element. If value is an element, then get the object for the element value, ..." |
| 21:22 | <Philip`> | which seems inconsistent; the first bit would have to say "The value is the element" instead, or something |
| 21:26 | <gsnedders> | Philip`: It can't have RDF output as RDF is an abstract concept :P |
| 21:35 | gsnedders | has an awful lot of learn before the exam |
| 21:53 | <Hixie> | jgraham: oh. in JS or server-side? |
| 21:53 | <Hixie> | Philip`: yeah, i'll fix that, hold on |
| 21:56 | <Hixie> | Philip`: fixed (should be regenned in a few seconds) |
| 21:57 | Philip` | discovers that it's a bad idea to leave Wireshark running in the background, collecting half a million packets and storing them all in RAM |
| 21:57 | <jgraham> | Hixie: Server side |
| 21:57 | <Hixie> | jgraham: ah. good luck. :-) |
| 21:57 | <jgraham> | :( |
| 21:59 | <Philip`> | Surely there's a standard Python library for manipulating URIs? |
| 21:59 | <jgraham> | Philip`: Yes, but it's getting the right base uri to resolve against and that sort of thing |
| 22:00 | <jgraham> | Also, I think in principle to conform with html5 I might need to implement document encoding dependent stuff |
| 22:00 | <jgraham> | which is a pity since I have no idea what the document encoding was |
| 22:01 | <jgraham> | (alhough I guess I can ind out if necessary) |
| 22:01 | <jgraham> | *find |
| 22:01 | <Philip`> | Hixie: If I have <link rel="alternate alternate stylesheet stylesheet">, should *all* the tokens get removed and replaced with "alternate-stylesheet"? |
| 22:02 | <Philip`> | jgraham: Hmm, I suggest not bothering with those details :-) |
| 22:02 | <Hixie> | Philip`: yes; i'll clarify |
| 22:02 | <jgraham> | I think I will ignore the encoding-dependant stuff for now |
| 22:03 | gsnedders | doesn't like the µdata proposal |
| 22:03 | <gsnedders> | I'll send email when I have time, with some sort of alternative proposal |
| 22:03 | <jgraham> | Hixie: In general if I have <link rel="a a b b"> should it be handled the same as <link rel="a b"> |
| 22:04 | <Hixie> | yeah |
| 22:04 | <jgraham> | if a,b!=up |
| 22:04 | <jgraham> | Oh that's good because that's what I implemented |
| 22:05 | <Philip`> | Nothing in the spec says to remove duplicates, as far as I can see, but I suppose RDF defines a graph with duplicate triples to be equivalent to one with the duplicates removed |
| 22:05 | <gsnedders> | Hixie: Short version: I'd prefer something closer to RDFa than the current draft, just without the insanity of RDFa. |
| 22:06 | <Hixie> | jgraham: updated the spec -- note the rel=up removal happens before duplicate removal |
| 22:06 | <Hixie> | jgraham: and duplicate removal, as Philip` points out, only matters for alternate stylesheet links |
| 22:06 | <Hixie> | gsnedders: your feedback or #swig's? |
| 22:06 | <gsnedders> | Hixie: mine |
| 22:06 | <Hixie> | what do you think is missing? |
| 22:07 | <gsnedders> | Hixie: There's nothing missing, it just seems to be reinventing the wheel for no reason. |
| 22:07 | <Philip`> | Hixie: If it contains >1 'up', then remove *all* 'up'? (Surely it should keep one?) |
| 22:07 | <Hixie> | gsnedders: i tried to stick as closely to RDFa as possible while fixing the problems mentioned in my e-mail |
| 22:08 | <Hixie> | Philip`: i can't see how to express the semantic of rel="up up" in rdf |
| 22:08 | <Hixie> | Philip`: without a complex set of bnodes |
| 22:08 | <gsnedders> | Hixie: As I said, I'll send something more substantial later |
| 22:08 | <Hixie> | gsnedders: cool |
| 22:08 | <Philip`> | Hixie: Oh, so it's intentionally ignored instead of being made equivalent to rel="up"? |
| 22:08 | <Hixie> | Philip`: yeah |
| 22:08 | <Philip`> | I suppose that makes some kind of sense |
| 22:08 | <jgraham> | gsnedders: I like the current draft in that I can imagine actually being able to author in it without wanting to kill people and then getting everything wrong anyway |
| 22:09 | <gsnedders> | Hixie: … that'll probably end up being an entire counter-proposal that nobody will agree with (SWIG people because it isn't RDFa and people here because you didn't write it :P) |
| 22:09 | <Hixie> | gsnedders: if you come up with something better, i'll agree with it :-) |
| 22:10 | <Hixie> | gsnedders: one of the difficult parts of designing the microdata syntax was getting the DOM API right |
| 22:10 | <Hixie> | still not sure i have it quite spot on |
| 22:10 | <gsnedders> | Hixie: See, I don't care about the DOM API :P |
| 22:10 | <jgraham> | gsnedders: So if you are going to write a counter-proposal please don't add lots of URIs and ways of marking up graphs of data |
| 22:10 | <jgraham> | gsnedders: Because they make everything too complicated |
| 22:10 | <gsnedders> | jgraham: How do we do anything related to RDF without doing the latter? |
| 22:11 | <Hixie> | what's RDF got to do with anything |
| 22:11 | <jgraham> | gsnedders: Like the current proposal? |
| 22:11 | <Hixie> | very few of these use cases involved having to do RDF |
| 22:11 | <Hixie> | and those that did are handled adequately by the RDF conversion section as far as I can tell |
| 22:11 | <jgraham> | gsnedders: I would much prefer a solution that hits the 80/20 point now and gets used than one that hits the 99/1 point now bu doesn't get used |
| 22:12 | gsnedders | does find it odd that the proponents of RDF have always given specific use-cases for what they want to do, and not use-cases for generic semantics basically |
| 22:12 | <gsnedders> | s/basically. |
| 22:12 | <gsnedders> | s#.#//# |
| 22:12 | <jgraham> | Especially if the current solution can be extended to do more of the 20 later |
| 22:13 | <Hixie> | gsnedders: as far as i can tell, they only do the latter :-) |
| 22:13 | <Hixie> | (with a few exceptions) |
| 22:14 | <Hixie> | (like Manu) |
| 22:14 | <gsnedders> | Hixie: No, they say, "we want RDF", they don't give use-cases for wanting generic semantics |
| 22:14 | <Hixie> | (and some of the people on Shelley's blog) |
| 22:14 | <Hixie> | gsnedders: oh, right, yes |
| 22:14 | <Hixie> | i see what you mean |
| 22:14 | <gsnedders> | Hixie: If they want RDF and you ask for use-cases, I'd expect them to give use-cases for generic semantics, not for specific uses of these generic semantics |
| 22:15 | <Hixie> | yeah |
| 22:15 | <Hixie> | i have heard basically no reason for "generic semantics" as you put it |
| 22:15 | <gsnedders> | Generic semantics isn't a very good term… |
| 22:15 | <gsnedders> | Extensible semantics? |
| 22:15 | <Hixie> | microdata is extensible :-) |
| 22:15 | <gsnedders> | Needless to say, you know what I mean :P |
| 22:18 | gsnedders | is unlikely to have time to really write any proposal until after at least his physics exam (in just under three weeks) |
| 22:18 | Philip` | wonders why his router vanishes at 22:13, and doesn't come back until 07:14, and has done this for the past few days |
| 22:19 | <Philip`> | Hixie: You could make rel="up up" equivalent to rel="up-up" (and similar for "up up up" etc), so that it doesn't lose data |
| 22:25 | <Hixie> | Philip`: *shrug* |
| 22:25 | <Hixie> | Philip`: not really the right semantic. and i don't want to make rel="up-up" equivalent. And what do you do with rel="up-up up"... |
| 22:26 | <Hixie> | really the right thing is to have a bnode |
| 22:26 | <Hixie> | <> <xhv:up> <_:a> . <_:a> <xhv:up> (href) . |
| 22:26 | <Philip`> | You do the same thing you do with rel="alternate-stylesheet stylesheet" |
| 22:26 | <Hixie> | true |
| 22:27 | <Hixie> | and with rel="http://www.w3.org/.../vocab#stylesheet"; |
| 22:27 | <Hixie> | sigh |
