15:02:28 RRSAgent has joined #rdfa 15:02:28 logging to http://www.w3.org/2011/12/08-rdfa-irc 15:02:30 RRSAgent, make logs world 15:02:30 Zakim has joined #rdfa 15:02:32 Zakim, this will be 7332 15:02:32 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start 2 minutes ago 15:02:33 Meeting: RDF Web Applications Working Group Teleconference 15:02:33 Date: 08 December 2011 15:02:40 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0025.html 15:03:38 Zakim, this is 7332 15:03:38 ok, MacTed; that matches SW_RDFa()10:00AM 15:03:39 +??P17 15:03:41 Zakim, who's here? 15:03:41 On the phone I see ??P21, ??P18, OpenLink_Software, ??P17 15:03:42 On IRC I see RRSAgent, niklasl, MacTed, bergie, danbri_, gkellogg, SebastianGermesin, trackbot, manu, manu1 15:03:43 zakim, I am ??P17 15:03:43 +manu1; got it 15:03:51 Zakim, OpenLink_Software is temporarily me 15:03:51 +MacTed; got it 15:03:57 Zakim, mute me 15:03:57 MacTed should now be muted 15:04:01 zakim, I am ??P18 15:04:01 +niklasl; got it 15:04:05 Zakim, unmute me 15:04:05 MacTed should no longer be muted 15:04:26 zakim, who's here? 15:04:26 On the phone I see ??P21, niklasl, MacTed, manu1 15:04:27 On IRC I see RRSAgent, niklasl, MacTed, bergie, danbri_, gkellogg, SebastianGermesin, trackbot, manu, manu1 15:04:40 zakim, I am ??P21 15:04:40 +gkellogg; got it 15:04:45 Zakim, mute me 15:04:49 MacTed should now be muted 15:09:33 Zakim, unmute me 15:09:33 MacTed should no longer be muted 15:09:48 Zakim, mute me 15:09:48 MacTed should now be muted 15:09:59 Scribe: manu1 15:10:17 Any updates/changes to Agenda? None. 15:10:20 Topic: ISSUE-114: HTML5 coerces @href/@src values to URLs instead of IRIs 15:10:29 http://www.w3.org/2010/02/rdfa/track/issues/114 15:11:36 q+ 15:11:43 manu1: We have two alternatives... 15:11:52 niklasl: Is it viable to de-percent encode? 15:12:29 manu1: I think so 15:12:46 niklasl: If somebody uses a percent-encoded URI in triples... how does that work out? 15:13:11 manu1: Our strategy to this point has been to just copy the data from the attribute w/o processing. 15:13:37 ShaneM has joined #rdfa 15:14:40 q+ 15:14:46 ack niklasl 15:15:04 +??P35 15:15:18 zakim, ??P35 is ShaneM 15:15:18 +ShaneM; got it 15:15:31 = 15:15:34 manu1: We could keep doing that - and just warn people that they can't express all IRIs in HTML5 in @href and @src. 15:16:07 niklasl: Encountering both in data, expecting them both to be IRIs is a possibility, I think. 15:16:20 ack gkellogg 15:16:45 gkellogg: If we do percent decoding, we're the only ones that do - they do escape decoding of literals/URIs in order to remove the escapes... but they don't do the same for percent-encoding. 15:17:05 gkellogg: What is the least harm? Is it really likely that authors are going to try to represent two URIs differently? 15:17:16 gkellogg: percent-decoding might get to authors original intent... 15:17:34 gkellogg: Graph produced by RDFa may be different from the one generated from TURTLE... no silver bullet to this problem. 15:18:07 gkellogg: If @href and @src is not percent-decoded... we need to include @resource in RDFa Lite... otherwise, no way to express unicode object in HTML5. 15:18:37 manu1: Or, we could say that RDFa Lite cannot solve this particular use case. 15:18:56 gkellogg: I wonder if percent-decoding was considered in other groups. 15:20:36 manu1: We could provide both options in the RDFa Core spec... mark it up with a warning, then get feedback from HTML WG, WHAT WG, RDF WG, etc. 15:21:43 q+ 15:23:23 PROPOSAL: In the HTML+RDFa spec, de-percent encode values retrieved from @href and @src in HTML5 before generating a triple based on those values. Include a warning that this feature is at risk during the Last Call. 15:23:30 ack gkellogg 15:24:20 gkellogg: I'm concerned about inter-operability... my library will not translate from IRI to URI... this concerns JavaScript implementations... anything using an infoset will get different results. 15:24:28 q+ 15:24:28 gkellogg: We should note that that is a potential issue. 15:24:32 ack ShaneM 15:24:58 ShaneM: I appreciate what you're talking about wrt. percent-decoding - but what about URIs that have percents in them, happens all the time. 15:25:03 q+ 15:25:31 gkellogg: HTML5 spec is pretty specific, it has different rules for scheme, query, host portions - it's not simple. 15:25:40 ack niklasl 15:26:37 niklasl: Section 3.2 in the IRI spec might provide a means to lift items from URI to IRIs in a predictable manner. We may want to look at that more. If you do this in an HTML+RDFa parser, you have to check to make sure the input is UTF-8 decoded as well. 15:27:22 manu1: Do we want to implement this across everything that could contain an IRI? 15:27:29 ShaneM: absolutely. 15:28:27 manu1: If we do a percent-decoding across @href, @src, @about, @resource - will we get back what HTML5 expects as well? 15:28:31 gkellogg: I think so, yes. 15:29:31 gkellogg: For consistency's sake - it might be strange if you had @about not do percent-decoding, but did have percent-decoding in @href. 15:30:09 ShaneM: String comparisons wouldn't match between @about and @href, even if you dereference it, it refers to the same resource. 15:31:10 For instance if url was "//example.com/a^b☺c%FFd%z/?e", then the  component's substring would be "/a^b☺c%FFd%z/" and the two characters that would have to be escaped would be "^" and "☺". The result after this step was applied would therefore be that url now had the value "//example.com/a%5Eb%E2%98%BAc%FFd%z/?e". 15:31:46 Zakim, unmute me 15:31:46 MacTed should no longer be muted 15:32:10 MacTed: That's a bug in the HTML5 spec. 15:32:35 MacTed: It's presuming that the input wasn't percent-encoded. 15:33:08 Zakim, mute me 15:33:08 MacTed should now be muted 15:34:48 so we would transform http://www.example.com/foobar%2cblat to http://www.example.com/foobar,blat right? 15:35:09 manu1: Shane, yes - that is what the output should be. 15:35:37 q+ 15:35:50 ack niklasl 15:35:53 = 15:36:35 niklasl: I tried out the example above for both values, I get different IRIs internally from it. 15:37:02 niklasl: So, that's an argument against. 15:37:08 can we just defer to the RDF working group on this? 15:38:27 gkellogg: I don't think we want to make a spec change at this point. 15:39:07 gkellogg: I don't think anyone from the HTML WG have responded on this particular issue to Jeni's bug report on the problem. Issues should be raised on this in the HTML WG. 15:40:16 gkellogg: We should put a note in the HTML+RDFa spec notifying authors that this is the behavior for IRIs in @href, @src and @data. 15:41:38 PROPOSAL: Place a note in the HTML+RDFa specification notifying authors that IRIs placed into @href, @src and @data could be transformed if access via the DOM 15:42:18 +1 15:42:20 +1 15:42:26 +1 15:42:32 +1 15:42:45 +1 15:42:49 RESOLVED: Place a note in the HTML+RDFa specification notifying authors that IRIs placed into @href, @src and @data could be transformed if access via the DOM. 15:43:25 Topic: ISSUE-117: Do not automatically define @about on and 15:43:31 http://www.w3.org/2010/02/rdfa/track/issues/117 15:44:30 ShaneM: We do specify a default @about on the HTML element already - current subject is set to 15:45:08 ShaneM: The implicit ones on HEAD and BODY is so that you could have a @typeof on the HEAD and BODY and have it refer to the document. 15:45:19 toby said: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0106.html 15:45:40 gkellogg: How common is it to have @typeof on HEAD and BODY without an @about or a @resource? 15:46:19 q+ 15:46:32 manu1: This issue isn't causing any damage right now, it also doesn't implement any new use cases. 15:46:32 mark makes a good argument here: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0151.html 15:46:53 niklasl: One possible issue is examples of this gives the impression that @typeof doesn't create bnodes. 15:46:57 ack niklasl 15:48:11 q+ 15:49:21

B?

15:49:59 ... ... 15:50:42 gkellogg: This is an issue - how do you deal with documents that are malformed being processed via an XML-based processor that are HTML5 documents? 15:51:13 q+ 15:51:36 ack ShaneM 15:53:10 inheritance preservation does feel like the right way to express this 15:53:14 ShaneM: I agree with Gregg - in the example above, we don't want to change the @subject for our author. 15:53:23 ack niklasl 15:54:14 15:54:38 q+ 15:54:43

B?

15:55:06 niklasl: I agree - @property is applied to whatever the current subject is in the current rules... for @typeof 15:57:24 Original text: In section 7.5, processing step 5, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if there is an empty @about present, and process it according to the rule for @about. 15:58:33 Revised text: In section 7.5, processing step 5, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if new subject is set to parent object. 15:59:25 and: In section 7.5, processing step 6, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if new subject is set to parent object. 15:59:52 I note that this has a (very minor) backward compatibility concern 16:00:31 PROPOSAL: Modify HTML+RDFa and XHTML+RDFa to modify processing steps #5 and #6 from assuming an empty @about value to assuming that new subject is set to the parent object. 16:00:49 +1 16:00:50 +1 16:00:52 +1 16:00:53 +1 16:00:55 +0.5 16:01:19 RESOLVED: Modify HTML+RDFa and XHTML+RDFa to modify processing steps #5 and #6 from assuming an empty @about value to assuming that new subject is set to the parent object. 16:03:30 Topic: ISSUE-122: @datatypeLibrary attribute 16:03:39 https://www.w3.org/2010/02/rdfa/track/issues/122 16:03:45 manu1: Anyone in support of this proposal? 16:04:20 http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0030.html 16:04:51 -MacTed 16:05:02 From ivan: I am not convinced that the use cases warrant an additional level of complication in the RDFa definition. I would prefer not to take this. 16:05:19 q+ 16:05:38 manu1: I agree with that sentiment. 16:05:47 ack niklasl 16:05:57 niklasl: I agree - we pre-define xsd as a prefix, no need for this. 16:06:12 q? 16:06:22 ack shanem 16:06:24 ack niklasl 16:06:59 ack 16:07:23 manu1: I see no compelling use cases for this. 16:07:55 PROPOSAL: Do not support @datatypeLibrary proposal due to lack of compelling use cases. 16:07:59 +1 16:08:00 +1 16:08:12 Ivan: +1 16:08:18 +1 16:08:21 +1 16:08:28 RESOLVED: Do not support @datatypeLibrary proposal due to lack of compelling use cases. 16:08:40 Topic: ISSUE-121: Use @id to set the subject in RDFa 16:08:49 http://www.w3.org/2010/02/rdfa/track/issues/121 16:08:55 q+ 16:09:08 manu1: The issue with this suggestion is that we tread very heavily into HTTPRange-14 issues... 16:09:18 q+ 16:09:24 gkellogg: No compelling use case for it - very dangerous because it would break many documents that already use @id. 16:09:49 gkellogg: HTTPRange-14 is a huge issue as well... @id is in a different namespace as @about - I'm against including this feature in RDFa processing. 16:10:07
16:10:36 niklasl: I'm against it as well... it's always been something I would've liked, my primary use case for RDFa is for legal information, where we refer to document fragments more often than not. 16:11:11 niklasl: I have to use @resource on the same DIV... however, I'm still against doing what is proposed... very tricky to get what Sebastian is proposing right. 16:11:23 ack gkellogg 16:11:23 q+ just to mention the role attribute 16:11:25 ack niklasl 16:11:30 niklasl: Too complicated, don't support it. 16:11:31 ack just 16:11:31 just, you wanted to mention the role attribute 16:12:24 ShaneM: I think it's a bad idea - @role attribute spec uses the value of @id as the subject... but you need both. 16:13:30 PROPOSAL: The @id attribute MUST NOT be used to identify a subject in RDFa. 16:13:33 +1 16:13:34 +1 16:13:43 +1 (from Ivan) 16:13:48 +0.95 16:13:51 +1 16:14:05 RESOLVED: The @id attribute MUST NOT be used to identify a subject in RDFa. 16:14:12 (.. the 0.05 is for my dream of a good working solution ;) 16:14:45 Topic: ISSUE-123: HTML Literals 16:14:53 https://www.w3.org/2010/02/rdfa/track/issues/123 16:15:18 gkellogg: The RDF WG has been looking at an HTML Literal - recent discussion on changes to XMLLiteral 16:15:41 gkellogg: My issue with XML Literals have always been the canonicalization rules - they're not valid to use in HTML. 16:16:05 gkellogg: Ivan's issue is that he doesn't know how an HTML Literal vs. an XML Literal would look... 16:16:43 gkellogg: The purpose of XMLLiteral support in RDFa is to capture markup, and not to look for document equivalence, then I think something like an HTML LIteral or relaxed requirements for canonicalization is more in keeping with RDFa usage patterns. 16:20:17 manu1: I wonder if there is any solution that we could create that would work both in XML-based and HTML-based parsers... I don't think there is. 16:20:28 gkellogg: Maybe the value should be the Infoset? 16:20:47 q+ 16:22:00 gkellogg: Exclusive canonicalization does more in terms of namespaces.... we may not want to do that sort of processing. wrt. an HTML document - there can be no namespaces... the effect may be equivalent. To say we coerce to Infoset, we are allowing the HTML parser to normalize the tagsoup and get a valid XHTML type representation of that content. 16:22:04 ack niklasl 16:22:45 niklasl: I think what we might be after is a way, given that we're in HTML, to use an equivalent to XHTML parsers - by using innerHTML property. I think that's spec'ed out in HTML5 spec. 16:23:41 gkellogg: If we just use innerHTML, the lexical representation is potentially tag soup. Presumably the value is an infoset. 16:25:11 q+ 16:25:50 ack niklasl 16:26:35 niklasl: Looking at the issue, this should be an HTML+RDFa issue... doesn't apply to RDFa Core - maybe we should wait for RDF WG to work through this issue. 16:27:52 Topic: Publication of RDFa Core 1.1 16:28:21 PROPOSAL: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011. 16:28:24 +1 16:28:25 +1 16:28:27 +1 16:29:35 We will also get +1s from the RDF Web Apps WG mailing list. 16:30:14 +1 16:30:16 RESOLVED: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011. 16:30:31 Topic: Publication of XHTML+RDFa 1.1 16:30:47 PROPOSAL: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011. 16:30:49 +1 16:30:52 +1 16:30:54 +1 16:30:59 +1 16:31:17 We will also get +1s from the RDF Web Apps WG mailing list. 16:31:20 RESOLVED: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011. 16:33:39 -ShaneM 16:33:40 -manu1 16:33:43 -niklasl 16:33:44 -gkellogg 16:33:44 SW_RDFa()10:00AM has ended 16:33:45 Attendees were manu1, MacTed, niklasl, gkellogg, ShaneM 16:38:56 trackbot, make logs public 16:38:56 Sorry, manu1, I don't understand 'trackbot, make logs public'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 16:39:04 RRSAgent, make logs public 16:50:05 niklasl has left #rdfa 18:06:25 RRSAgent, draft minutes 18:06:25 I have made the request to generate http://www.w3.org/2011/12/08-rdfa-minutes.html MacTed 18:06:35 RRSAgent, make logs public 18:06:38 trackbot, end meeting 18:06:38 Zakim, list attendees 18:06:38 sorry, trackbot, I don't know what conference this is 18:06:39 RRSAgent, please draft minutes 18:06:39 I have made the request to generate http://www.w3.org/2011/12/08-rdfa-minutes.html trackbot 18:06:40 RRSAgent, bye 18:06:40 I see no action items