[00:19:38] mmm, xml [01:18:06] Why are people set on re-hashing XLink in JSON? Haven't we learned? What have we learned? [01:18:34] https://plus.google.com/u/0/118148240205592032989/posts/bsnruogBxAU [01:41:43] mogsie: I'm not trying to do that [01:42:12] mine's a media type, not a mixin [02:42:18] KevBurnsJr (~kevburnsj@c-76-126-10-63.hsd1.ca.comcast.net) left irc: [03:31:15] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) left irc: Quit: Textual IRC Client: http://www.textualapp.com/ [03:53:25] ssedano (~ssedano@unaffiliated/ssedano) left irc: Read error: Connection reset by peer [04:06:37] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest. [04:17:06] ivanfi (~ivanfi@62.159.77.164) joined #rest. [05:21:47] hmm [05:21:55] this form-like stuff keeps rearing it's annoying ugly head [05:52:24] ssedano (~ssedano@unaffiliated/ssedano) joined #rest. [05:52:45] mamund: that Jeo Gregorio post is bizarre [05:52:52] heh [05:53:12] json is a data format, therefore extending it with links is not allowed [05:53:28] am I missing something there? [05:53:31] does 'data format' have some certain meaning? are html and atom not 'data format's? [05:53:37] arent' links data? [05:53:50] indeed. [05:53:50] i mean, it wont be JSON [05:53:57] it'd be someextension+juson [05:53:58] json [05:54:07] but i'm not sure why it's inherently _wrong_ [05:54:13] right, [B[Bwell [05:54:22] [B[A[Bsome asdasdasdasd [05:54:22] wtf is going on [05:54:32] :) [05:54:38] hahaha [05:54:38] sorry. [05:54:42] no worries. [05:54:50] i thought you were making a ^W^W joke [05:54:59] yeah some people seem to be talking about includable constructs for json [05:55:06] which I think is kind of wrong, personally [05:55:22] why? [05:55:31] (I'm just curious, i dont really have a dog in this fight.) [05:55:41] (other than convincing rubyists that xml-based formats aren't evil ;) ) [05:55:43] yeah I do, obvioulsy, I'm not sure what the argument is [05:55:48] that's fair [05:56:08] personally I think a bit of positive constraint from a media type is a good thing [05:56:13] it's even in the dissertation :| [05:56:34] + we've seen the benefits first hand with html [05:57:03] so with non-hypermedia formats. they'd have to end up in rel=alternate links, basically, right? [05:57:12] html is not exactly perfect but the fact that it is a generic hypertext interface has carried it through [05:57:14] since they can't actually drive the api. [05:57:31] well I have no idea where Joe's coming from but I guess so [05:57:38] and 'discovery docs' and the like [05:57:46] i think that's the reason everyone's driving towards this [05:57:58] like, if most of your api has to be in xhtml (or something), why bother with json [05:58:02] at the terminal points [05:58:11] people want one serealization format. [05:58:25] which displays a flaw in reasoning about how apis are built, I think. [05:58:29] well xhtml is shockingly bad for doing shit like embedding the state of other resoruces [05:58:33] (restful ones, obviously) [05:58:35] which is a really common requirement in HTTP based apis [05:58:49] you have like.. iframes I guess [05:58:58] but the semantics are dodgey [05:59:04] Action: steveklabnik nods [05:59:31] it's just clunky as hell, and it definitely doesn't make sense if you know your application is primarily consumed by automated agents [05:59:42] there's a massive overhead with html that is completely redundant [06:00:12] I can't see the advantage of xhtml (in comparing to say, xml) [06:00:21] IMO xhtml is too restricting [06:00:31] Jarda: i personally like it because it allows a human to browse it in a browser [06:00:33] (if you want to make your xhtml look pretty and readable) [06:00:42] steveklabnik: the one thing I think HAL has going for it (other than the link convention) is this recursive resource/embedded resource model [06:00:46] not that this is super full-fledged, but http://api.hackety-hack.com/ [06:00:51] for example [06:00:53] that actually clears up a lot of issues with partials etc rendering stuff server side [06:00:58] mikekell1: that makes sense. [06:01:39] imo when talking about generic media types it's more about what you *don't* add than what youdo [06:02:06] and that is one of my main issues with atom [06:02:28] is that is included a tonne of shit to do with 'publishing' which was just confusing and unnecessary fora generic hypertext interface [06:03:40] right [06:03:46] that confused me for a looong time [06:03:52] you could build atom/atompub with hal by establishing a set of link relations [06:04:02] 'atom isn't just an rss replacement' was super confusing to me [06:05:58] so, yeah - I think HAL has a better shot than atom purely because there's no application in there [06:06:23] its purely a hypertext interface based in terms of resources [06:06:33] not collections or items or whatever [06:08:03] sure [06:09:50] has hal seen a lot of uptake? [06:10:03] for certain values of 'a lot' of course. ;) [06:12:44] well over the last couple of months people are getting more interested [06:12:57] but previously it's been mostly on the xml format [06:13:06] but recently the json stuff seems to have people interested [06:13:25] I wrote a blog post about the JSON variant on friday which seems to have had decent reception [06:14:33] got a link? [06:15:13] i'm still finding my way around the REST scene on the web. ;) [06:17:15] mikekell1: I had a bit of time during my vacation to work more on my hal based API sample. Hopefully, in a few weeks I'll be able to push it out. [06:17:44] you're the man!! :D you still pimping hal then ? ;) [06:17:59] steveklabnik: http://blog.stateless.co/post/13296666138/json-linking-with-hal [06:18:00] Big time hal pimp. That's me. [06:18:17] safe. [06:18:31] darrelmiller: HAL ain't easy? [06:18:58] mikekell1: I'm curious to see what comes of this "link relations should carry purpose but not meaning" [06:20:04] steveklabnik: Hal is both simple and easy ;-) [06:20:29] :) [06:20:49] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove [06:22:30] darrelmiller: hey! [06:22:41] darrelmiller: you seem to follow microsoft development quite a lot? [06:23:05] steveklabnik: And just so you don't think I'm a mikekell1 ass-kisser, he is wrong about about hal being just for automated clients. It is awesome for user driven clients too :-) [06:23:14] darrelmiller: hahah [06:23:15] jarda: I do live in that world. [06:23:51] darrelmiller: I'm curious to know if WPF is the way to go, is Metro a completely different technique and what should I choose if I got to choose now (you don't have to answer but pointers to resources would be appreciated) [06:23:57] it's going to get a mention in the book, for sure. which i'm gonna end up renaming to something with 'hypermedia' rather than 'rest' [06:24:00] incidentally [06:24:05] to help push that meme [06:24:16] I'm developing a WPF app in it's early stages and interested to know, if it's the wrong choice atm.. [06:24:20] (sorry ofr the off topic) [06:24:23] I really need to get something up on my hypermediaapi.com site. [06:24:43] jarda: WPF is the right choice for certain types of apps. [06:24:54] darrelmiller: this is a "business" app [06:24:58] Metro is a design style, not really a tech. [06:25:13] a little bit like a CRM or ERP [06:25:24] rails [06:25:26] the XAML stack in WinR/T is the new tech that powers Win8 [06:25:34] mikekell1: Shut up. [06:25:37] :D [06:25:37] :-P [06:25:38] mikekell1: :D [06:25:48] darrelmiller: yeah, that'd be great. [06:25:50] (the backend is PHP based, but it doesn't matter atm) [06:26:12] However, at the moment, you cannot access the new XAML WinR/T stack from a desktop app. [06:26:17] I believe that will change in the future. [06:26:25] darrelmiller: well XAML was the reason I chose WPF. I just hate doing styling etc in a WinForms app [06:26:38] but then I heard people saying WPF and Silverlight are dead.. [06:26:51] Right. However, there are now at least four implementations of UI on XAML. [06:27:03] yeah, silverlight is basically over [06:27:07] from what i understand [06:27:10] There is WPF, Silverlight, Windows Phone 7 and now Win8 metro apps. [06:27:22] XAML just makes me think of david blaine [06:27:22] There will be a grand unification at some point. [06:27:32] as in like.. sha-XAML [06:27:33] i'm actually wearing a tshirt from a big silveright consulting company right now [06:27:35] ssedano (~ssedano@unaffiliated/ssedano) left irc: Ping timeout: 260 seconds [06:27:44] ... and they asked me to come in and demo ruby for them. [06:27:47] They all use the same xml namespace, the only difference is the underlying implementation and the different feature sets. [06:27:51] darrelmiller: but if you needed to write a complex desktop app, whould you choose (WPF) [06:28:04] steveklabnik: green eyed monstare came out ? [06:28:04] where did those parentheses come from.. [06:28:06] not because they're moving to open source. but because of the same stuff that that article Jarda is referring to . [06:28:16] I currently am in the process of developing WPF stuff for our ERP app. So yes. [06:28:37] darrelmiller: cool [06:28:46] Just a bit worried I'm developing for dead technology [06:28:59] it's microsoft [06:29:03] microsoft is walking dead [06:29:07] rails. [06:29:09] rails rails rails. [06:29:13] 'nuff said. [06:29:19] The implementation has a limited life, but the XAML you create will be easily migrated to future better implementations. [06:29:20] We are eventually going to develop something for mobile devices in the future. Maybe I should then check if Metro or WP7 is the way to go [06:29:39] "eventually" being after a year or something [06:30:03] That's hard to say. I would guess at least 18 months. [06:30:04] darrelmiller: mmkay, nice to know. Thanks.. [06:30:23] np. BTW, I'm just speculating, so YMMV. [06:30:31] ... [06:30:41] I'm getting a Nokia WP7 phone when they arrive in stores here in FInland [06:30:46] Nick change: mikekell1 -> mikeRAILSkelly [06:31:01] Nick change: mikeRAILSkelly -> mikekelly [06:31:05] I'm btw typing atm on a mac [06:31:07] I have a LG one and I really like it. [06:31:17] so I'm no Microsoft lover purely [06:31:22] or apple hater or anything [06:31:27] I just choose the best tool for the job [06:31:33] (rails may be it for the backend) [06:31:38] yeeeeaaah [06:31:41] I hear you, but rails is definitely not it. [06:31:45] bwaha [06:32:17] ok, but now I have to stop the off topic [06:32:32] It shouldn't have been called Ruby on Rails, it should have been called Ruby on Training Wheels. [06:32:53] darrelmiller: you should have a look at rails man [06:32:57] it's pretty snazzy these days [06:33:09] plus, chicks totally dig rails developers [06:33:27] darrelmiller: that is not even true [06:33:31] mikekelly: that is absolutely true [06:33:32] I bet they love ESI too :-) [06:33:38] YES [06:33:50] and generic hypermedia interfaces [06:33:55] seriously, 'rails is ruby on training wheels' shows that you dont know rails [06:34:00] rails is really effing complicated. [06:34:03] :p [06:34:28] of course, you're talking about stumbling through a web app easily [06:34:31] since the merge with merb it's a totally different stack [06:34:36] and all the rack shit [06:34:37] steveklabnik: Just FYI, my bigotry is only for mikekelly's benefit [06:34:53] :) [06:34:58] i'm also just teasing. [06:35:01] I know this but I still play to it anyway [06:35:08] totally. :D [06:35:11] mikekelly: This one? www.merb.ca ? [06:35:14] ... there's a lot of bad in rails [06:35:24] hahahahahah [06:35:31] http://www.merbivore.com/ [06:38:21] it's a shame visual studio (and openrasta & friends) don't run on os x [06:38:30] web devs love macs [06:38:46] C# as a language kicks so much ass [06:38:56] eww, static typing. [06:38:57] I hear windows runs nicely on a mac! [06:38:58] ;) [06:39:02] without hindley-milner! [06:39:05] darrelmiller: it does! [06:39:33] haskell <3 [06:39:34] steveklabnik: I don't think static typing is so restricting, if you do things the right way [06:39:53] Jarda: right, hence the hindley-milner [06:40:11] you can of course shoot yourself to your leg with "now my var1 might be boolean, string or integer.." [06:40:28] but this is going towards flamewars [06:40:31] :D [06:40:33] where is mamund to calm things down [06:40:46] he'll just tell you to REST [06:41:07] C# is a fine statically typed language. Too bad it's all MSFT-y. [06:41:34] and too bad all the good stuff was added in those versions Mono doesn't support [06:41:44] so you can't really even say "but it runs on linux too" [06:41:48] ssedano (~ssedano@unaffiliated/ssedano) joined #rest. [06:41:52] One of the best things about this IRC channel is that you have people from every different tech scene. The diversity of opinions is its strength. [06:41:59] darrelmiller: +1 [06:42:12] I have used about everything [06:42:18] even a bit of ruby, but not rails [06:42:23] I like Erlang :-) [06:42:30] actors <3 [06:42:32] (ruby only for cucumber driving selenium-webdriver) [06:42:37] Jarda: have you tried f# for anything useful? [06:42:52] trygvis: no, I implemented some mathematical functions [06:42:55] I really want to learn F#. [06:42:56] and then gave up [06:42:57] :) [06:43:19] darrelmiller: can you mix&match C# and F# via class libraries [06:43:31] would be so cool to implement all recursive functions etc in F# :) [06:43:36] You should look at Ryan Riley's Frank. It is a F# web framework. [06:44:15] It's starting to really shape up into something nice. [06:44:41] is it this annoying handler model [06:44:45] instaed of resources ? [06:45:50] handler, controller , resource.... potato, potato, tomato, tomato [06:46:05] looks a bit like node.js apps [06:47:09] I also love the fact that IronJS is written in F# https://github.com/fholm/IronJS [06:48:43] fu-manchu (~fumanchu@adsl-99-30-180-185.dsl.sfldmi.sbcglobal.net) joined #rest. [06:49:28] darrelmiller: once again something I have been meant to try out, F# that is [06:49:37] but the problem is, I don't have time for cool side projects atm [06:49:52] and I can't just say "ok so now I try to convert our backend to F#, ok?" [06:50:05] +1 [06:50:39] Hakon|mbp (~hakon1@81.0.156.226) joined #rest. [07:07:30] Action: mamund slides in [07:08:14] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest. [07:38:06] grove_ (~grove@aggw006.cappelendamm.no) joined #rest. [07:40:41] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Ping timeout: 252 seconds [07:40:41] Nick change: grove_ -> grove [07:40:43] ivanfi (~ivanfi@62.159.77.164) left #rest. [07:48:46] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [08:24:17] Hakon|mbp (~hakon1@81.0.156.226) left irc: Quit: Leaving... [08:48:46] Hakon|mbp (~hakon1@84.202.136.151) joined #rest. [09:20:33] KevBurnsJr (~kevburnsj@c-76-126-10-63.hsd1.ca.comcast.net) joined #rest. [09:46:19] bigbluehat (~bigblueha@adsl-74-177-120-132.gsp.bellsouth.net) joined #rest. [09:46:33] KevBurnsJr (~kevburnsj@c-76-126-10-63.hsd1.ca.comcast.net) left irc: [10:00:57] vmil86 (~vmil86@88.118.38.91) joined #rest. [10:01:06] wtf [10:01:10] https://plus.google.com/u/0/113701541741306361978/posts/hDHVnJ6EUMP [10:01:20] mamund darrelmiller , anyone [10:01:31] I started reading and then.... [10:01:37] please can you explain what the problem is here [10:01:44] I figured I would save it for later :-) [10:06:12] :@ [10:06:30] "links are bad because thye're bad" [10:06:43] "we really need metadata though, that's really important becaus eit' simportant" [10:06:50] That whole comment thread makes me pretty sad. [10:07:34] ".. and that there's a fine line between Generic Standards and Fucking Useless Crap" .. haha [10:07:41] we've been through a whole shit tonne of this already here it's annoying going back over it all and having people make dumb + condescending statmeents [10:09:42] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest. [10:12:01] Really not sure why people think creating "unwritten" conventions to augment a media type like application/json is better than having a new media type that explicitly calls out the linking semantics. [10:12:15] +1000 [10:16:52] Seems to me that link references are a form of metadata, so the 'Link' header is the appropriate solution. [10:19:25] jmkeyes: What advantage is there to keeping metadata out of the payload? [10:20:05] darrelmiller: clarity in some cases, but you can also retrieve references through a HEAD request. [10:20:44] However you can't compress links when they are in the header. [10:20:51] mephju (~mephju@dslb-188-106-190-010.pools.arcor-ip.net) joined #rest. [10:20:52] it denies "Save Page As..." from ever being usable ;) [10:21:10] ... how, exactly? [10:22:45] ? my browser doesn't store response headers with the response body [10:23:29] jmkeys: Link headers are also a bit more tricky to use when you need the links to have some context within the document. RFC5988 does define a anchor tag, but some media types do not have any clearly defined fragment identifier. [10:23:34] *shrug*. That's a failing of your browser. [10:23:56] darrelmiller: That I can agree with, but in that case, you can also prefix the like relation name. [10:24:00] Action: fu-manchu toddles off to boil an ocean [10:24:22] s/like/link/ [10:24:37] :| [10:24:46] ie, 'post:add' or some other thing [10:24:50] there's a lot of reasons using link headers for that is not a good idea. [10:25:05] mikekelly: Do explain. [10:25:19] jmkeyes: That's not really compliant with RFC5988 rules on defining link relations. [10:27:37] ref 4.1 Registered Relation Types: "...if the semantics are highly specific to a particular application, the name should reflect that..." [10:27:43] I would say link headers should be used when a) your media type is not a text based format, b) you want the links to be visible to intermediaries. [10:29:10] 01Registered Relation Types01 need to be registered with IANA. You can hardly register a different link relation with a prefix for every possible context. [10:30:05] But i'd agree. rel="post:add" isn't structly conforming. Use an extension rel type or use a vendor-specific one [10:30:36] jmkeyes: headers get stripped by proxies [10:30:43] jmkeyes: header size limits [10:30:50] mikekelly: True, I hadn't though about that. [10:30:52] Consider a collection document with a list of items. Each item has an edit rel. How would you define the relation name for each of those items? [10:31:15] jmkeyes: perissting a representation in tooling tends to exclude headers [10:31:25] an external relation type, which is a URI [10:31:38] if you have embedded resources [10:31:52] you have to piece together which links refer to what bit of the representatin [10:32:02] that's true [10:32:16] it's horrible on the server and the client side, really [10:32:40] there are uses for link headers but it's mostly for intermediary stuff [10:32:47] imo [10:33:02] Yeah, I hadn't thought about it that way. [10:33:13] back in a sec [10:33:31] otoh, I can see them being useful for non-text media types [10:34:16] absolutely. [10:35:13] I can also make a case for using them with a generic format like application/xml that has no standard syntax for specifying links [10:35:59] It seems to me that they could be a good fallback for data interchange media types that don't support hypertext references [10:38:36] Action: mamund has been away [10:39:03] mikekelly: as i scrolled through James Snell's last post on that thread... [10:39:07] @mamund: and your pay will be docked appropriately. [10:39:30] the thing that struck me is... [10:39:54] it seems most on the list simply think in terms of local code, not shared media types. [10:40:37] yup. [10:40:50] Action: mamund nods to darrelmiller and drops a couple quarters in the kitty [10:40:56] Is it "legal" to modify a response body based on a the content of the "via" link relation? [10:41:06] s/a // [10:42:04] for example, it surprises me that James Snell argues for "convention" (implying code patterns applied to messages) instead of arguing for establishing a media type (i.e. bringing HAL in line w/ 5988) [10:46:04] mikekelly: seems to me rel="edit URI" to edit a document in a collection would work [10:46:34] or maybe I've misunderstood the external relation [10:46:55] maybe it should be something like rel="{URI}/edit" [10:47:32] but it also seems kind of odd to edit a specific document from a collection without descending down to that scope [10:49:48] basically, it boils down to link relations for a collection should be related to that collection as a whole, not the individual documents within it [10:50:33] jmkeyes: That seems pretty limiting [10:50:59] Action: jmkeyes thinking limited domain application [10:51:02] Atom makes extensive use of this type of links and so does HTML. [11:07:46] jmkeyes: personally I don't like edit links [11:08:29] unless it's some form resource [11:10:35] mamund: I guess I'm just not a big fan of these meta-metadata initiatives [11:10:42] particualrly in json [11:10:56] mikekelly: same here [11:11:34] and he's saying it hasn't but I think it has been railroaded into some suspicioulsy-looking-RDF'ish dsicussion about metadata [11:11:42] when the whole dialogue started off about linking specifically [11:12:00] yes, the point is "let's add links in an agreed way" [11:12:26] then it gets into all sorts of things (sorry, i contributed to some of the wayward flow there) [11:13:05] nah no way it wasn't you [11:13:06] IMO, mont's request is modest and reasonable. [11:13:20] s/mont/mnot [11:13:20] I'm just interested where HAL falls short [11:13:44] IMO, the only things HAL doesn't provide are the "control-data" aspects of links.... [11:13:55] accept-lang, type-hint, etc. [11:14:10] yeah I need to add this in [11:14:13] seems a small thing to just do an extension for that (one-off to start) [11:14:21] i left that stuff out of my designs, too. [11:14:44] otherwise, i think HAL overs the space well. [11:15:03] BTW - does HAML support URItemplates in hrefs on link and resource? [11:15:21] s/HAML/HAL (sheesh!) [11:19:52] mamund: not resource, it does on link [11:19:59] cool [11:21:02] makes sense, i guess [11:22:15] mikekelly: the assumption is an href on a resouce is "immutable", right? [11:23:16] btw - mikekelly, still enjoying your PNG http://stateless.co/info-model.png [11:23:35] love the subtle message regarding the href attributes [11:23:37] :) [11:36:55] technoweenie (~technowee@host-86-220-9-69.midco.net) joined #rest. [11:44:47] :) [11:45:26] mamund: immutable in what sense ? [11:46:11] oh - do you mean could you PUT the resource with an href changed and the server 'move' the resource ? [11:46:37] I wouldnt' have a problem with people doing that, but that's not up to HAL [11:55:30] ok so I just posted my current elevator pitch/rationale for a generic media type: [11:55:34] "mo, a common interface for expressing links promotes re-usable tooling server/client side. A media type for linking can enforce positive constraints which benefit the web, like guiding publishers to follow the web linking spec, and it can help publishers lift focus away from unnecessary considerations (i.e. how to link to or embed another resource) and increase the focus on the application itself (i.e. the application's link relations and traversals between resou [11:56:56] mikekelly: Is Tim Bray really questioning the value of hypermedia, or just hypermedia in an API that uses JSON? [11:57:09] a generalised way of expressing links [11:57:24] i.e. [11:57:40] why can't I just do { widget: "http://..." } [11:58:13] seems pretty obvious to me [11:59:30] i must confess, i've grown tired of that thread. [12:00:37] sorry :| [12:02:29] mamund: I got asked for a real world use-case [12:02:44] so I said a DSL like selenium for writing automated clients [12:02:45] hey, you're doin' fine. [12:02:50] dunno if that counts :/ [12:02:53] as George Constanza once said... [12:03:04] "It's not you, it's me." [12:03:29] mamund: I think the thing that's most frustrating about it is it's actually ground we've covered here a while ago [12:03:40] yeah, i guess that's it [12:03:52] i am impatient, i guess [12:07:20] mamund: I'm still not really sure what the point of that thread actually is in the first place.. [12:07:30] something about json being a 'data format' [12:07:45] I am right in thinking Joe was one of the atom guys right? [12:08:20] there's an easy way to check that of coure :) [12:08:25] yeah he was. [12:08:27] :) [12:09:18] mamund: did you see the RDF -> HAL converter ian davis built yesterday ? [12:09:58] wow, no [12:10:01] how is it? [12:10:22] http://iandavis.com/apps/hal/?uri=http%3A%2F%2Fsws.geonames.org%2F5391959%2F [12:10:54] he needs sometihng for namespaces, really [12:11:13] but still.. really cool [12:11:20] did you see his blog post over the weekend ? [12:11:23] oh, is that why you floated the NS idea in the list this weekend? [12:11:23] what is a good library to get JSONObject in Java [12:11:44] mamund: that and mark brought it up too and people seem keen on it [12:11:58] yeah, been avoiding that in my work. [12:12:02] personally I won't have as use for it but if that's jus tme [12:12:03] hopefully i can continue to do so [12:12:08] right :) [12:12:09] yep [12:12:36] apparently the RDF graph can't make statements about itself [12:12:51] which seems pretty crap to me [12:14:23] mamund: did you see ian's blog post ? [12:14:36] nope [12:14:43] about 'resketching' RDF in terms of resources? [12:14:51] oh, i saw the headline [12:14:56] that's how he came to HAL [12:15:00] it's an interesting idea [12:15:15] ian seems quite ready to re-think whenever needed and seems to be a creative guy [12:15:34] IMO, RDF needs to be treated as a representation format, but that's another discussion. [12:15:55] anyway, it's good to see some folks from the RDF space looking at your HAL [12:16:03] that's encouraging [12:16:28] ian is a big voice in RDF world, too. [12:17:18] yeah he's a cool dude, I went over to see them a year or so ago [12:17:24] oh [12:17:27] very cool [12:17:46] yeah they have a cool team over there, they're smaaat peoples :) [12:18:33] I might be moving back to the UK next year \o/ [12:19:13] woah! you are full of intersting news today! [12:57:27] mamund (mamund@69.163.32.100) left irc: Ping timeout: 260 seconds [13:13:40] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [13:38:16] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [13:48:53] Why are always these pressures to standardize things that shouldn't be to be standardized and then ruin another perfectly simplistic exchange format? There are plenty of ways to implement all the "meta" requirements you need without layering the kind of kludge that's effectively killed XML ( from many perspectives ) onto JSON as well. [13:49:02] that's from the Google+ post [13:49:13] sounds like a anti-XML guy [13:49:30] I don't get why poeple think of XML as "too verbose" [13:49:35] IMO human readability is great [13:49:57] Jarda: It's hard to get "right". [13:50:11] Which is sadly, absurd, because it's really not that hard to get right. [13:50:11] bigbluehat (~bigblueha@adsl-74-177-120-132.gsp.bellsouth.net) left irc: Quit: Leaving. [13:50:20] Law of averages, et al. [13:50:39] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [13:50:40] and I wouldn't say xml is dead.. [13:51:27] (often also the guys who complain about XML are the ones trying to parse it with regexps and substrings because they don't understand how to use good tools like DOM and XPath etc.. [13:51:52] I think the persistence of the DOM model has frustrated a lot of people. SAX is great, but you need to *know* how they work, as opposed to the fact that they do. [13:52:08] So that makes copypasta a lot harder. [13:52:23] Hence, people hate it because the barrier to entry isn't that of PHP. [13:53:00] well yes, I get that JSON is easy (especially with languages like php and ruby where the transformation is one function away) [13:53:31] but I can't see what's bad in _deriving_ a new data-exhange type from json would be so bad [13:53:45] it isn't like it would ruin the simple JSON the simple people want to use.. [13:54:02]