edit

RDF Web Applications Working Group Teleconference

Minutes of 08 December 2011

Agenda
http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0025.html
Seen
Gregg Kellogg, Manu Sporny, Niklas Lindström, Shane McCarron, Ted Thibodeau
Guests
Niklas Lindström
Scribe
Manu Sporny
IRC Log
Original
Resolutions
  1. 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. link
  2. 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. link
  3. Do not support @datatypeLibrary proposal due to lack of compelling use cases. link
  4. The @id attribute MUST NOT be used to identify a subject in RDFa. link
  5. Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011. link
  6. Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011. link
Topics
15:02:28 <RRSAgent> logging to http://www.w3.org/2011/12/08-rdfa-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2011/12/08-rdfa-irc

15:02:30 <trackbot> RRSAgent, make logs world

Trackbot IRC Bot: RRSAgent, make logs world

15:02:32 <trackbot> Zakim, this will be 7332

Trackbot IRC Bot: Zakim, this will be 7332

15:02:32 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start 2 minutes ago

Zakim IRC Bot: 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

Ted Thibodeau: Zakim, this is 7332

15:03:38 <Zakim> ok, MacTed; that matches SW_RDFa()10:00AM

Zakim IRC Bot: ok, MacTed; that matches SW_RDFa()10:00AM

15:03:39 <Zakim> +??P17

Zakim IRC Bot: +??P17

15:03:41 <MacTed> Zakim, who's here?

Ted Thibodeau: Zakim, who's here?

15:03:41 <Zakim> On the phone I see ??P21, ??P18, OpenLink_Software, ??P17

Zakim IRC Bot: 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

Zakim IRC Bot: On IRC I see RRSAgent, niklasl, MacTed, bergie, danbri_, gkellogg, SebastianGermesin, trackbot, manu, manu1

15:03:43 <manu1> zakim, I am ??P17

Manu Sporny: zakim, I am ??P17

15:03:43 <Zakim> +manu1; got it

Zakim IRC Bot: +manu1; got it

15:03:51 <MacTed> Zakim, OpenLink_Software is temporarily me

Ted Thibodeau: Zakim, OpenLink_Software is temporarily me

15:03:51 <Zakim> +MacTed; got it

Zakim IRC Bot: +MacTed; got it

15:03:57 <MacTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

15:03:57 <Zakim> MacTed should now be muted

Zakim IRC Bot: MacTed should now be muted

15:04:01 <niklasl> zakim, I am ??P18

Niklas Lindström: zakim, I am ??P18

15:04:01 <Zakim> +niklasl; got it

Zakim IRC Bot: +niklasl; got it

15:04:05 <MacTed> Zakim, unmute me

Ted Thibodeau: Zakim, unmute me

15:04:05 <Zakim> MacTed should no longer be muted

Zakim IRC Bot: MacTed should no longer be muted

15:04:26 <gkellogg> zakim, who's here?

Gregg Kellogg: zakim, who's here?

15:04:26 <Zakim> On the phone I see ??P21, niklasl, MacTed, manu1

Zakim IRC Bot: 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

Zakim IRC Bot: On IRC I see RRSAgent, niklasl, MacTed, bergie, danbri_, gkellogg, SebastianGermesin, trackbot, manu, manu1

15:04:40 <gkellogg> zakim, I am  ??P21

Gregg Kellogg: zakim, I am ??P21

15:04:40 <Zakim> +gkellogg; got it

Zakim IRC Bot: +gkellogg; got it

15:04:45 <MacTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

15:04:49 <Zakim> MacTed should now be muted

Zakim IRC Bot: MacTed should now be muted

15:09:33 <MacTed> Zakim, unmute me

Ted Thibodeau: Zakim, unmute me

15:09:33 <Zakim> MacTed should no longer be muted

Zakim IRC Bot: MacTed should no longer be muted

15:09:48 <MacTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

15:09:48 <Zakim> MacTed should now be muted

Zakim IRC Bot: MacTed should now be muted

15:09:59 <manu1> Scribe: manu1

(Scribe set to Manu Sporny)

15:10:17 <manu1> Any updates/changes to Agenda? None.

Any updates/changes to Agenda? None.

15:10:20 <manu1> Topic: ISSUE-114: HTML5 coerces @href/@src values to URLs instead of IRIs

1. 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

http://www.w3.org/2010/02/rdfa/track/issues/114

15:11:36 <niklasl> q+

Niklas Lindström: 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.

Manu Sporny: 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?

Niklas Lindström: Is it viable to de-percent encode?

15:12:29 <manu1> manu1: I think so

Manu Sporny: I think so

15:12:46 <manu1> niklasl: If somebody uses a percent-encoded URI in triples... how does that work out?

Niklas Lindström: 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.

Manu Sporny: Our strategy to this point has been to just copy the data from the attribute w/o processing.

15:14:40 <gkellogg> q+

Gregg Kellogg: q+

15:14:46 <manu1> ack niklasl

ack niklasl

15:15:04 <Zakim> +??P35

Zakim IRC Bot: +??P35

15:15:18 <ShaneM> zakim, ??P35 is ShaneM

Shane McCarron: zakim, ??P35 is ShaneM

15:15:18 <Zakim> +ShaneM; got it

Zakim IRC Bot: +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.

Niklas Lindström: 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.

Manu Sporny: 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.

Niklas Lindström: Encountering both in data, expecting them both to be IRIs is a possibility, I think.

15:16:20 <manu1> ack gkellogg

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.

Gregg Kellogg: 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?

Gregg Kellogg: 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...

Gregg Kellogg: 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.

Gregg Kellogg: 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.

Gregg Kellogg: 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.

Manu Sporny: 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.

Gregg Kellogg: 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.

Manu Sporny: 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+

Gregg Kellogg: 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.

PROPOSED: 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

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.

Gregg Kellogg: 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+

Shane McCarron: q+

15:24:28 <manu1> gkellogg: We should note that that is a potential issue.

Gregg Kellogg: We should note that that is a potential issue.

15:24:32 <manu1> ack ShaneM

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.

Shane McCarron: 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+

Niklas Lindström: q+

15:25:31 <manu1> gkellogg: HTML5 spec is pretty specific, it has different rules for scheme, query, host portions - it's not simple.

Gregg Kellogg: HTML5 spec is pretty specific, it has different rules for scheme, query, host portions - it's not simple.

15:25:40 <manu1> ack niklasl

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.

Niklas Lindström: 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?

Manu Sporny: Do we want to implement this across everything that could contain an IRI?

15:27:29 <manu1> ShaneM: absolutely.

Shane McCarron: 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?

Manu Sporny: 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.

Gregg Kellogg: 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.

Gregg Kellogg: 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.

Shane McCarron: 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".

Shane McCarron: 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

Ted Thibodeau: Zakim, unmute me

15:31:46 <Zakim> MacTed should no longer be muted

Zakim IRC Bot: MacTed should no longer be muted

15:32:10 <manu1> MacTed: That's a bug in the HTML5 spec.

Ted Thibodeau: That's a bug in the HTML5 spec.

15:32:35 <manu1> MacTed: It's presuming that the input wasn't percent-encoded.

Ted Thibodeau: It's presuming that the input wasn't percent-encoded.

15:33:08 <MacTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

15:33:08 <Zakim> MacTed should now be muted

Zakim IRC Bot: 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?

Shane McCarron: 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.

Manu Sporny: Shane, yes - that is what the output should be.

15:35:37 <niklasl> q+

Niklas Lindström: q+

15:35:50 <manu1> ack niklasl

ack niklasl

15:35:53 <niklasl> <http://example.org/å> = <http://example.org/%C3%A5>

Niklas Lindström: <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.

Niklas Lindström: 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.

Niklas Lindström: So, that's an argument against.

15:37:08 <ShaneM> can we just defer to the RDF working group on this?

Shane McCarron: 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.

Gregg Kellogg: 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.

Gregg Kellogg: 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.

Gregg Kellogg: 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

PROPOSED: 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

Gregg Kellogg: +1

15:42:20 <manu1> manu1: +1

Manu Sporny: +1

15:42:26 <niklasl> +1

Niklas Lindström: +1

15:42:32 <ShaneM> +1

Shane McCarron: +1

15:42:45 <MacTed> +1

Ted Thibodeau: +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.

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>

2. 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

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>

Shane McCarron: 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.

Shane McCarron: 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

Shane McCarron: 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?

Gregg Kellogg: How common is it to have @typeof on HEAD and BODY without an @about or a @resource?

15:46:19 <niklasl> q+

Niklas Lindström: q+

15:46:32 <manu1> manu1: This issue isn't causing any damage right now, it also doesn't implement any new use cases.

Manu Sporny: 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

Shane McCarron: 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.

Niklas Lindström: One possible issue is examples of this gives the impression that @typeof doesn't create bnodes.

15:46:57 <manu1> ack niklasl

ack niklasl

15:48:11 <ShaneM> q+

Shane McCarron: q+

15:49:21 <niklasl> … <html about="/b"><h1 property="dc:title">B?</h1>

Niklas Lindström: … <html about="/b"><h1 property="dc:title">B?</h1>

15:49:59 <ShaneM> ... <html about="/b"><head typeof="foaf:Document"> ...

Shane McCarron: ... <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?

Gregg Kellogg: 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+

Niklas Lindström: q+

15:51:36 <manu1> ack ShaneM

ack ShaneM

15:53:10 <MacTed> inheritance preservation does feel like the right way to express this

Ted Thibodeau: 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.

Shane McCarron: 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

ack niklasl

15:54:14 <niklasl> <body about="">

Niklas Lindström: <body about="">

15:54:38 <ShaneM> q+

Shane McCarron: q+

15:54:43 <niklasl> … <html about="/b"><body about=""><h1 property="dc:title">B?</h1>

Niklas Lindström: … <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

Niklas Lindström: 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.

Shane McCarron: 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.

Shane McCarron: 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.

Shane McCarron: 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

Shane McCarron: 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.

PROPOSED: 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

Gregg Kellogg: +1

16:00:50 <manu1> manu1: +1

Manu Sporny: +1

16:00:52 <MacTed> +1

Ted Thibodeau: +1

16:00:53 <ShaneM> +1

Shane McCarron: +1

16:00:55 <niklasl> +0.5

Niklas Lindström: +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.

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

3. ISSUE-122: @datatypeLibrary attribute

16:03:39 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/122

https://www.w3.org/2010/02/rdfa/track/issues/122

16:03:45 <manu1> manu1: Anyone in support of this proposal?

Manu Sporny: Anyone in support of this proposal?

16:04:20 <niklasl> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0030.html

Niklas Lindström: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0030.html

16:04:51 <Zakim> -MacTed

Zakim IRC Bot: -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.

Gregg Kellogg: 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+

Niklas Lindström: q+

16:05:38 <manu1> manu1: I agree with that sentiment.

Manu Sporny: I agree with that sentiment.

16:05:47 <manu1> ack niklasl

ack niklasl

16:05:57 <manu1> niklasl: I agree - we pre-define xsd as a prefix, no need for this.

Niklas Lindström: I agree - we pre-define xsd as a prefix, no need for this.

16:06:12 <manu1> q?

q?

16:06:22 <manu1> ack shanem

ack shanem

16:06:24 <manu1> ack niklasl

ack niklasl

16:06:59 <ShaneM> ack

Shane McCarron: ack

16:07:23 <manu1> manu1: I see no compelling use cases for this.

Manu Sporny: 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.

PROPOSED: Do not support @datatypeLibrary proposal due to lack of compelling use cases.

16:07:59 <manu1> manu: +1

Manu Sporny: +1

16:08:00 <niklasl> +1

Niklas Lindström: +1

16:08:12 <manu1> +1 (from Ivan via mailing list)

+1 (from Ivan via mailing list)

16:08:18 <gkellogg> +1

Gregg Kellogg: +1

16:08:21 <ShaneM> +1

Shane McCarron: +1

16:08:28 <manu1> RESOLVED: Do not support @datatypeLibrary proposal due to lack of compelling use cases.

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

4. ISSUE-121: Use @id to set the subject in RDFa

16:08:49 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/121

http://www.w3.org/2010/02/rdfa/track/issues/121

16:08:55 <gkellogg> q+

Gregg Kellogg: q+

16:09:08 <manu1> manu1: The issue with this suggestion is that we tread very heavily into HTTPRange-14 issues...

Manu Sporny: The issue with this suggestion is that we tread very heavily into HTTPRange-14 issues...

16:09:18 <niklasl> q+

Niklas Lindström: q+

16:09:24 <manu1> gkellogg: No compelling use case for it - very dangerous because it would break many documents that already use @id.

Gregg Kellogg: 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.

Gregg Kellogg: 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">

Niklas Lindström: … <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.

Niklas Lindström: 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.

Niklas Lindström: 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

ack gkellogg

16:11:23 <ShaneM> q+ just to mention the role attribute

Shane McCarron: q+ just to mention the role attribute

16:11:25 <manu1> ack niklasl

ack niklasl

16:11:30 <manu1> niklasl: Too complicated, don't support it.

Niklas Lindström: Too complicated, don't support it.

16:11:31 <ShaneM> ack just

Shane McCarron: ack just

16:11:31 <Zakim> just, you wanted to mention the role attribute

Zakim IRC Bot: 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.

Shane McCarron: 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.

PROPOSED: The @id attribute MUST NOT be used to identify a subject in RDFa.

16:13:33 <gkellogg> +1

Gregg Kellogg: +1

16:13:34 <manu1> manu1: +1

Manu Sporny: +1

16:13:43 <manu1> +1 (from Ivan via mailing list)

+1 (from Ivan via mailing list)

16:13:48 <niklasl> +0.95

Niklas Lindström: +0.95

16:13:51 <ShaneM> +1

Shane McCarron: +1

16:14:05 <manu1> RESOLVED: The @id attribute MUST NOT be used to identify a subject in RDFa.

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 ;)

Niklas Lindström: (.. the 0.05 is for my dream of a good working solution ;)

16:14:45 <manu1> Topic: ISSUE-123: HTML Literals

5. ISSUE-123: HTML Literals

16:14:53 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/123

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

Gregg Kellogg: 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.

Gregg Kellogg: 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...

Gregg Kellogg: 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.

Gregg Kellogg: 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.

Manu Sporny: 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?

Gregg Kellogg: Maybe the value should be the Infoset?

16:20:47 <niklasl> q+

Niklas Lindström: 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.

Gregg Kellogg: 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

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.

Niklas Lindström: 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.

Gregg Kellogg: If we just use innerHTML, the lexical representation is potentially tag soup. Presumably the value is an infoset.

16:25:11 <niklasl> q+

Niklas Lindström: q+

16:25:50 <manu1> ack niklasl

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.

Niklas Lindström: 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

6. 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

Manu Sporny: 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?

Manu Sporny: Any objections to publication?

16:28:21 <manu1> PROPOSAL: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.

PROPOSED: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.

16:28:24 <gkellogg> +1

Gregg Kellogg: +1

16:28:25 <manu1> manu1: +1

Manu Sporny: +1

16:28:27 <niklasl> +1

Niklas Lindström: +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

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

Shane McCarron: +1

16:30:16 <manu1> RESOLVED: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.

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

7. 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

Manu Sporny: 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?

Manu Sporny: Any objections to publication?

16:30:49 <manu1> PROPOSAL: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.

PROPOSED: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.

16:30:50 <manu1> manu1: +1

Manu Sporny: +1

16:30:52 <niklasl> +1

Niklas Lindström: +1

16:30:54 <gkellogg> +1

Gregg Kellogg: +1

16:30:59 <ShaneM> +1

Shane McCarron: +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

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.

RESOLVED: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.

16:33:39 <Zakim> -ShaneM

Zakim IRC Bot: -ShaneM

16:33:40 <Zakim> -manu1

Zakim IRC Bot: -manu1

16:33:43 <Zakim> -niklasl

Zakim IRC Bot: -niklasl

16:33:44 <Zakim> -gkellogg

Zakim IRC Bot: -gkellogg

16:33:44 <Zakim> SW_RDFa()10:00AM has ended

Zakim IRC Bot: SW_RDFa()10:00AM has ended

16:33:45 <Zakim> Attendees were manu1, MacTed, niklasl, gkellogg, ShaneM

Zakim IRC Bot: Attendees were manu1, MacTed, niklasl, gkellogg, ShaneM



Formatted by CommonScribe