13:53:51 RRSAgent has joined #rdfa 13:53:51 logging to http://www.w3.org/2010/09/16-rdfa-irc 13:53:53 RRSAgent, make logs world 13:53:53 Zakim has joined #rdfa 13:53:55 Zakim, this will be 7332 13:53:55 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 7 minutes 13:53:56 Meeting: RDFa Working Group Teleconference 13:53:56 Date: 16 September 2010 13:53:59 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Sep/0081.html 13:54:02 Chair: Manu 13:54:14 Present: Steven, Manu 13:56:42 Regrets: Ivan, Benjamin 13:57:41 markbirbeck has joined #rdfa 13:58:11 zakim, codes? 13:58:11 I don't understand your question, markbirbeck. 13:58:13 tinkster has joined #rdfa 13:58:17 zakim, code? 13:58:18 the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), markbirbeck 13:58:25 Present+ Toby, MarkB 13:59:01 "All circuits are busy now". :-( 13:59:02 Knud has joined #rdfa 13:59:42 will try again in a few minutes - probably a telecon finishes at 3. 14:00:03 (via SIP) 14:00:24 SW_RDFa()10:00AM has now started 14:00:32 +??P27 14:00:40 zakim, I am ??P27 14:00:40 +manu1; got it 14:00:41 I've got a cheap SIP outgoing call package but that would require finding my headphones, microphone, etc. 14:01:58 zakim, dial steven-617 14:01:58 ok, Steven; the call is being made 14:01:59 +Steven 14:03:30 +Knud 14:03:32 zakim, mute me 14:03:45 Knud should now be muted 14:04:19 +ShaneM 14:04:21 ShaneM has joined #rdfa 14:06:57 if mark can't make it, i can scribe 14:07:06 Coming...just trying to dial in. :( 14:07:27 Knud...if you don't mind, would appreciate it. :) 14:07:39 alright! 14:08:23 +??P2 14:08:31 zakim, i am ? 14:08:31 +markbirbeck; got it 14:08:56 I only got in through the US number... 14:09:09 Topic: RDFa API Heartbeat publication 14:09:10 Same here. 14:09:11 TOPIC: RDFa API Heartbeat publication 14:09:28 http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/ 14:10:00 manu: this version includes all of Ivan's comments, incl. two class diagrams 14:10:15 http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/#the-rdf-interfaces 14:10:31 http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/#the-linked-data-interfaces 14:11:07 ... still not 100% perfect, need to be adapted 14:11:12 q+ 14:11:58 ack mark 14:12:06 ... diff still needs to be created 14:12:17 mark: document looks pretty good! 14:12:56 manu: for certain things, there are still issue markers in the document 14:14:04 PROPOSAL: Publish the latest RDFa draft as a heartbeat draft, adding diff-marked version: http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/ 14:14:14 +1 14:14:14 +1 14:14:17 +1 14:14:19 +1 14:14:32 +1 14:14:35 +1 14:14:38 s/RDFa draft/RDFa API draft 14:14:50 RESOLVED: Publish the latest RDFa draft as a heartbeat draft, adding diff-marked version: http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-api-20100912/ 14:15:06 Topic: Signal RDF/SemWeb/Linked Data of RDFa Heartbeat publication 14:15:12 TOPIC: Signal RDF/SemWeb/Linked Data of RDFa Heartbeat publication 14:16:18 manu: we need to involve the RDF community into the RDFa API, because they feel we are in fact creating an RDF API 14:17:07 ... groups to contact: SWIG, RDF-Core, browser vendors, ... 14:17:44 q+ 14:17:48 ... LOD community 14:18:33 webapps wg! 14:19:46 steven: possible problem: our charter doesn't ask us to do anything more general than an RDFa API 14:20:25 ack mark 14:21:30 mark: see last call, Ivan: changing the name should be discussed internally 14:22:19 ... publish heartbeat first, then carefully find out what the community thinks: is the general nature of our API a problem? 14:22:54 ... if we get pushback, we might think about what we could remove from the API 14:23:24 ... we have a good architecture in place, now we can possible factor out some things 14:23:30 q+ to discuss extending the charter re: RDFa API 14:23:40 ... we should leave as is for now 14:23:41 ack 14:24:05 manu: extending the charter is possible, but probably the last thing we want to do 14:24:22 q+ 14:24:37 ack 14:24:39 ack 14:24:42 ... we have a good story about integrating things like microdata, etc. 14:24:44 ack manu1 14:24:44 manu1, you wanted to discuss extending the charter re: RDFa API 14:24:48 ack markbirbeck 14:24:52 ... so maybe we _do_ want to change the charter? 14:25:04 mark: maybe we should let the community ask us to do this? 14:25:50 ... then we would have a discussion, and a good argument for changing the charter 14:27:49 manu: judging from respnse to sandro h's questionnaire, there is a lot of interest in where RDF goes next 14:28:11 ... but no indication of a big interest in an RDF API (yet)? 14:28:56 ... anyway, we should start getting a lot of feedback for the RDFa API 14:29:27 TOPIC: Processing remote documents via RDFa API 14:29:27 Topic: Processing remote documents via RDFa API 14:29:37 http://www.w3.org/2010/02/rdfa/track/issues/44 14:30:13 manu: concern is: how do we make sure the API can process triples from external/remote documents 14:30:37 ... security issues 14:31:52 ... CORS might solve this in the future 14:32:07 (http://www.w3.org/TR/cors/) 14:32:46 ... this discussion is important e.g. for getting RDFa profile document 14:35:32 q+ 14:35:38 ack mark 14:35:57 ... we could be bold and suggest a special kind of communication policy for fetching RDFa documents 14:36:33 mark: maybe suport some other formats 14:36:55 ... don't think security is our concern (at the spec level) 14:37:10 ... don't talk about http requests, cookies, CORS, etc. at the spec level 14:37:14 q+ to discuss CORS vs. no cookies. 14:38:51 ... we could move away from expressing profiles in RDFa and then use a policy such as for iframes, css, etc. 14:39:28 I agree with Mark - rely upon other specs. 14:39:38 ack manu1 14:39:38 manu1, you wanted to discuss CORS vs. no cookies. 14:39:56 but I wouldn't object to an implementors guide 14:40:11 manu: I don't think there is any particular other spec we can rely on for the cookie problem 14:40:48 ... what makes RDFa unique is that currently, there isn't a whole lot of RDFa out there 14:41:28 ... this gives us the opportunity to start from a blank slate. We can establish policies, best practices. 14:41:45 q+ 14:42:00 q+ to ask why this is more serious for us? 14:42:35 ack mark 14:44:14 q+ to discuss creating a wall for the developer 14:44:32 ack shanem 14:44:32 ShaneM, you wanted to ask why this is more serious for us? 14:45:34 shanem: it might be good to provide implementation guidance as non-normative text ... 14:45:54 ... but be probably can really defer this to other specs 14:45:56 ack manu 14:45:56 manu1, you wanted to discuss creating a wall for the developer 14:46:17 ... yes, we have an opportunity here, but I don't want one. I don't see why. 14:46:21 agree with ShaneM 14:47:44 manu: if the developer were to fetch a remote documents, they would not have access to that complete document, but only to the extracted triples 14:49:45 q+ to say that we can "violate" the security model. 14:50:06 mark: but we have to rely on xml-http request anyway - we can't add any other ways of accessing documents 14:50:21 ack manu1 14:50:21 manu1, you wanted to say that we can "violate" the security model. 14:50:24 ... we have to build on the existing stack, which has its own rules, which we inherit 14:51:30 q+ to talk about data in RDFa 14:51:36 q+ 14:51:42 ack shane 14:51:42 ShaneM, you wanted to talk about data in RDFa 14:51:47 manu: again: we might be in the position to actually establish a _new_ security model for RDFa, which could be different than for HTML pages 14:51:53 For in-browser JS implementations, we have to build on XHR, so must inherit its limitations. For native browser implementations, and non-browser implementations, we needn't inherit those limitations. 14:52:50 ack mark 14:52:56 mark: this sounds a bit naive. Just because the data is in RDFa, it doesn't mean it's not sensitive! 14:53:06 s/mark/shanem 14:53:18 I agree with tinkster - but I think that means we need to appreciate the limitations of the minimum. 14:53:50 q+ to disagree that it's not desirable. 14:54:51 mark: we don't need to discuss CORS, cookies, etc. We just need to rely on the security stack in the browser. 14:54:56 I agree with mark on this. native browser implementations should adhere to the stack just like a JS implementation would. 14:54:57 ack manu 14:54:57 manu1, you wanted to disagree that it's not desirable. 14:56:04 q+ 14:56:37 Definitely agree with that. 14:56:58 ack mark 14:57:11 manu: maybe get some browser implementers input to see what they think 14:57:51 q+ to discuss research at our company on bypassing CORS. 14:58:34 mark: yes, getting things from other places (remote documents) is desirable. Something has to be done about it. But probably not in our spec. 14:59:21 shanem: "What, does the Semantic Web require a Web?!" 15:02:29 ack manu1 15:02:29 manu1, you wanted to discuss research at our company on bypassing CORS. 15:02:36 q+ to end the telecon 15:04:00 PROPOSAL: RDFa API heartbeat draft to be published next Thursday. 15:04:08 +1 15:04:09 +1 15:04:11 +1 15:04:13 +1 15:04:40 RESOLVED: RDFa API heartbeat draft to be published next Thursday. 15:07:14 http://www.w3.org/WAI/PF/role-attribute/#using-role-in-conjunction-with-rdfa 15:07:38 bye 15:07:38 -ShaneM 15:07:39 -markbirbeck 15:07:41 -Steven 15:07:41 -manu1 15:10:21 ShaneM has left #rdfa 15:12:41 disconnecting the lone participant, Knud, in SW_RDFa()10:00AM 15:12:44 SW_RDFa()10:00AM has ended 15:12:46 Attendees were manu1, Steven, Knud, ShaneM, markbirbeck 15:37:18 trackbot, bye 15:37:18 trackbot has left #rdfa 15:37:19 zakim, bye 15:37:19 Zakim has left #rdfa 15:45:41 manu1 has left #rdfa