Chatlog 2011-12-08

See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.

15:02:28 <RRSAgent> RRSAgent has joined #rdfa
15:02:28 <RRSAgent> logging to http://www.w3.org/2011/12/08-rdfa-irc
15:02:30 <trackbot> RRSAgent, make logs world
15:02:30 <Zakim> Zakim has joined #rdfa
15:02:32 <trackbot> Zakim, this will be 7332
15:02:32 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start 2 minutes ago
15:02:33 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
15:02:33 <trackbot> Date: 08 December 2011
15:02:40 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0025.html
15:02:43 <manu1> Guest: Niklas (niklasl) Lindström
15:03:38 <MacTed> Zakim, this is 7332
15:03:38 <Zakim> ok, MacTed; that matches SW_RDFa()10:00AM
15:03:39 <Zakim> +??P17
15:03:41 <MacTed> Zakim, who's here?
15:03:41 <Zakim> On the phone I see ??P21, ??P18, OpenLink_Software, ??P17
15:03:42 <Zakim> On IRC I see RRSAgent, niklasl, MacTed, bergie, danbri_, gkellogg, SebastianGermesin, trackbot, manu, manu1
15:03:43 <manu1> zakim, I am ??P17
15:03:43 <Zakim> +manu1; got it
15:03:51 <MacTed> Zakim, OpenLink_Software is temporarily me
15:03:51 <Zakim> +MacTed; got it
15:03:57 <MacTed> Zakim, mute me
15:03:57 <Zakim> MacTed should now be muted
15:04:01 <niklasl> zakim, I am ??P18
15:04:01 <Zakim> +niklasl; got it
15:04:05 <MacTed> Zakim, unmute me
15:04:05 <Zakim> MacTed should no longer be muted
15:04:26 <gkellogg> zakim, who's here?
15:04:26 <Zakim> On the phone I see ??P21, niklasl, MacTed, manu1
15:04:27 <Zakim> On IRC I see RRSAgent, niklasl, MacTed, bergie, danbri_, gkellogg, SebastianGermesin, trackbot, manu, manu1
15:04:40 <gkellogg> zakim, I am  ??P21
15:04:40 <Zakim> +gkellogg; got it
15:04:45 <MacTed> Zakim, mute me
15:04:49 <Zakim> MacTed should now be muted
15:09:33 <MacTed> Zakim, unmute me
15:09:33 <Zakim> MacTed should no longer be muted
15:09:48 <MacTed> Zakim, mute me
15:09:48 <Zakim> MacTed should now be muted
15:09:59 <manu1> Scribe: manu1
15:10:17 <manu1> Any updates/changes to Agenda? None.
15:10:20 <manu1> Topic: ISSUE-114: HTML5 coerces @href/@src values to URLs instead of IRIs
15:10:29 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/114
15:11:36 <niklasl> q+
15:11:43 <manu1> manu1: We have three alternatives... 1) add a note in HTML+RDFa specifying that IRIs could be mangled if accessed via JavaScript, 2) Percent decode values from @href and @src in HTML, 3) Percent decode all values that could be IRIs in RDFa Core.
15:11:52 <manu1> niklasl: Is it viable to de-percent encode?
15:12:29 <manu1> manu1: I think so
15:12:46 <manu1> niklasl: If somebody uses a percent-encoded URI in triples... how does that work out?
15:13:11 <manu1> manu1: Our strategy to this point has been to just copy the data from the attribute w/o processing.
15:13:37 <ShaneM> ShaneM has joined #rdfa
15:14:40 <gkellogg> q+
15:14:46 <manu1> ack niklasl
15:15:04 <Zakim> +??P35
15:15:18 <ShaneM> zakim, ??P35 is ShaneM
15:15:18 <Zakim> +ShaneM; got it
15:15:31 <niklasl> This can happen in RDF: <http://example.org/å> and <http://example.org/%C3%A5> are generated in the same graph. 
15:15:34 <manu1> 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 <manu1> niklasl: Encountering both in data, expecting them both to be IRIs is a possibility, I think.
15:16:20 <manu1> ack gkellogg
15:16:45 <manu1> 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 <manu1> gkellogg: What is the least harm? Is it really likely that authors are going to try to represent two URIs differently?
15:17:16 <manu1> gkellogg: percent-decoding might get to authors original intent...
15:17:34 <manu1> gkellogg: Graph produced by RDFa may be different from the one generated from TURTLE... no silver bullet to this problem.
15:18:07 <manu1> 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> manu1: Or, we could say that RDFa Lite cannot solve this particular use case.
15:18:56 <manu1> gkellogg: I wonder if percent-decoding was considered in other groups.
15:20:36 <manu1> 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 <gkellogg> q+
15:23:23 <manu1> 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 <manu1> ack gkellogg
15:24:20 <manu1> 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 <ShaneM> q+
15:24:28 <manu1> gkellogg: We should note that that is a potential issue.
15:24:32 <manu1> ack ShaneM
15:24:58 <manu1> 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 <niklasl> q+
15:25:31 <manu1> gkellogg: HTML5 spec is pretty specific, it has different rules for scheme, query, host portions - it's not simple.
15:25:40 <manu1> ack niklasl
15:26:37 <manu1> 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> manu1: Do we want to implement this across everything that could contain an IRI?
15:27:29 <manu1> ShaneM: absolutely.
15:28:27 <manu1> manu1: If we do a percent-decoding across @href, @src, @about, @resource - will we get back what HTML5 expects as well? 
15:28:31 <manu1> gkellogg: I think so, yes.
15:29:31 <manu1> 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 <manu1> ShaneM: String comparisons wouldn't match between @about and @href, even if you dereference it, it refers to the same resource.
15:31:10 <ShaneM> For instance if url was "//example.com/a^b☺c%FFd%z/?e", then the <path> 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 <MacTed> Zakim, unmute me
15:31:46 <Zakim> MacTed should no longer be muted
15:32:10 <manu1> MacTed: That's a bug in the HTML5 spec.
15:32:35 <manu1> MacTed: It's presuming that the input wasn't percent-encoded.
15:33:08 <MacTed> Zakim, mute me
15:33:08 <Zakim> MacTed should now be muted
15:34:48 <ShaneM> so we would transform http://www.example.com/foobar%2cblat to http://www.example.com/foobar,blat right?
15:35:09 <manu1> manu1: Shane, yes - that is what the output should be.
15:35:37 <niklasl> q+
15:35:50 <manu1> ack niklasl
15:35:53 <niklasl> <http://example.org/å> = <http://example.org/%C3%A5>
15:36:35 <manu1> niklasl: I tried out the example above for both values, I get different IRIs internally from it.
15:37:02 <manu1> niklasl: So, that's an argument against.
15:37:08 <ShaneM> can we just defer to the RDF working group on this?
15:38:27 <manu1> gkellogg: I don't think we want to make a spec change at this point.
15:39:07 <manu1> 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 <manu1> 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 <manu1> 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 <gkellogg> +1
15:42:20 <manu1> manu1: +1
15:42:26 <niklasl> +1
15:42:32 <ShaneM> +1
15:42:45 <MacTed> +1
15:42:49 <manu1> 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 <manu1> Topic: ISSUE-117: Do not automatically define @about on <body> and <head>
15:43:31 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/117
15:44:30 <manu1> ShaneM: We do specify a default @about on the HTML element already - current subject is set to <base>
15:45:08 <manu1> 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 <ShaneM> toby said: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0106.html
15:45:40 <manu1> gkellogg: How common is it to have @typeof on HEAD and BODY without an @about or a @resource?
15:46:19 <niklasl> q+
15:46:32 <manu1> manu1: This issue isn't causing any damage right now, it also doesn't implement any new use cases.
15:46:32 <ShaneM> mark makes a good argument here: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0151.html
15:46:53 <manu1> niklasl: One possible issue is examples of this gives the impression that @typeof doesn't create bnodes.
15:46:57 <manu1> ack niklasl
15:48:11 <ShaneM> q+
15:49:21 <niklasl> … <html about="/b"><h1 property="dc:title">B?</h1>
15:49:59 <ShaneM> ... <html about="/b"><head typeof="foaf:Document"> ...
15:50:42 <manu1> 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 <niklasl> q+
15:51:36 <manu1> ack ShaneM
15:53:10 <MacTed> inheritance preservation does feel like the right way to express this
15:53:14 <manu1> ShaneM: I agree with Gregg - in the example above, we don't want to change the @subject for our author.
15:53:23 <manu1> ack niklasl
15:54:14 <niklasl> <body about="">
15:54:38 <ShaneM> q+
15:54:43 <niklasl> … <html about="/b"><body about=""><h1 property="dc:title">B?</h1>
15:55:06 <manu1> niklasl: I agree - @property is applied to whatever the current subject is in the current rules... for @typeof
15:57:24 <ShaneM> 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 <ShaneM> 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 <ShaneM> 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 <ShaneM> I note that this has a (very minor) backward compatibility concern
16:00:31 <manu1> 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 <gkellogg> +1
16:00:50 <manu1> manu1: +1
16:00:52 <MacTed> +1
16:00:53 <ShaneM> +1
16:00:55 <niklasl> +0.5
16:01:19 <manu1> 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 <manu1> Topic: ISSUE-122: @datatypeLibrary attribute
16:03:39 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/122
16:03:45 <manu1> manu1: Anyone in support of this proposal?
16:04:20 <niklasl> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0030.html
16:04:51 <Zakim> -MacTed
16:05:02 <gkellogg> 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 <niklasl> q+
16:05:38 <manu1> manu1: I agree with that sentiment.
16:05:47 <manu1> ack niklasl
16:05:57 <manu1> niklasl: I agree - we pre-define xsd as a prefix, no need for this.
16:06:12 <manu1> q?
16:06:22 <manu1> ack shanem
16:06:24 <manu1> ack niklasl
16:06:59 <ShaneM> ack
16:07:23 <manu1> manu1: I see no compelling use cases for this.
16:07:55 <manu1> PROPOSAL: Do not support @datatypeLibrary proposal due to lack of compelling use cases.
16:07:59 <manu1> manu: +1
16:08:00 <niklasl> +1
16:08:12 <manu1> +1 (from Ivan via mailing list)
16:08:18 <gkellogg> +1
16:08:21 <ShaneM> +1
16:08:28 <manu1> RESOLVED: Do not support @datatypeLibrary proposal due to lack of compelling use cases.
16:08:40 <manu1> Topic: ISSUE-121: Use @id to set the subject in RDFa
16:08:49 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/121
16:08:55 <gkellogg> q+
16:09:08 <manu1> manu1: The issue with this suggestion is that we tread very heavily into HTTPRange-14 issues...
16:09:18 <niklasl> q+
16:09:24 <manu1> gkellogg: No compelling use case for it - very dangerous because it would break many documents that already use @id.
16:09:49 <manu1> 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 <niklasl> … <div id="p_1" property="paragraf" resource="#p_1" typeof="Paragraf">
16:10:36 <manu1> 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 <manu1> 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 <manu1> ack gkellogg
16:11:23 <ShaneM> q+ just to mention the role attribute
16:11:25 <manu1> ack niklasl
16:11:30 <manu1> niklasl: Too complicated, don't support it.
16:11:31 <ShaneM> ack just
16:11:31 <Zakim> just, you wanted to mention the role attribute
16:12:24 <manu1> 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 <manu1> PROPOSAL: The @id attribute MUST NOT be used to identify a subject in RDFa.
16:13:33 <gkellogg> +1
16:13:34 <manu1> manu1: +1
16:13:43 <manu1> +1 (from Ivan via mailing list)
16:13:48 <niklasl> +0.95
16:13:51 <ShaneM> +1
16:14:05 <manu1> RESOLVED: The @id attribute MUST NOT be used to identify a subject in RDFa.
16:14:12 <niklasl> (.. the 0.05 is for my dream of a good working solution ;)
16:14:45 <manu1> Topic: ISSUE-123: HTML Literals
16:14:53 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/123
16:15:18 <manu1> gkellogg: The RDF WG has been looking at an HTML Literal - recent discussion on changes to XMLLiteral
16:15:41 <manu1> gkellogg: My issue with XML Literals have always been the canonicalization rules - they're not valid to use in HTML.
16:16:05 <manu1> gkellogg: Ivan's issue is that he doesn't know how an HTML Literal vs. an XML Literal would look...
16:16:43 <manu1> 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> 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 <manu1> gkellogg: Maybe the value should be the Infoset?
16:20:47 <niklasl> q+
16:22:00 <manu1> 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 <manu1> ack niklasl
16:22:45 <manu1> 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 <manu1> gkellogg: If we just use innerHTML, the lexical representation is potentially tag soup. Presumably the value is an infoset.
16:25:11 <niklasl> q+
16:25:50 <manu1> ack niklasl
16:26:35 <manu1> 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 <manu1> Topic: Publication of RDFa Core 1.1
16:27:52 <manu1> manu1: Latest copy is here: http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html
16:27:56 <manu1> manu1: Any objections to publication?
16:28:21 <manu1> PROPOSAL: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.
16:28:24 <gkellogg> +1
16:28:25 <manu1> manu1: +1
16:28:27 <niklasl> +1
16:29:35 <manu1> Additional +1s on mailing list: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0034.html http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0035.html http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0036.html
16:30:14 <ShaneM> +1
16:30:16 <manu1> RESOLVED: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.
16:30:31 <manu1> Topic: Publication of XHTML+RDFa 1.1
16:30:47 <manu1> manu1: Latest copy is here: http://www.w3.org/2010/02/rdfa/sources/xhtml-rdfa/Overview-src.html
16:30:48 <manu1> manu1: Any objections to publication?
16:30:49 <manu1> PROPOSAL: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.
16:30:50 <manu1> manu1: +1
16:30:52 <niklasl> +1
16:30:54 <gkellogg> +1
16:30:59 <ShaneM> +1
16:30:59 <manu1> Additional +1s on mailing list: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0034.html http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0035.html http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0036.html
16:31:20 <manu1> RESOLVED: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.
16:33:39 <Zakim> -ShaneM
16:33:40 <Zakim> -manu1
16:33:43 <Zakim> -niklasl
16:33:44 <Zakim> -gkellogg
16:33:44 <Zakim> SW_RDFa()10:00AM has ended
16:33:45 <Zakim> Attendees were manu1, MacTed, niklasl, gkellogg, ShaneM
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000227