Chatlog 2012-04-26

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

13:18:30 <RRSAgent> RRSAgent has joined #rdfa
13:18:30 <RRSAgent> logging to http://www.w3.org/2012/04/26-rdfa-irc
13:18:32 <trackbot> RRSAgent, make logs world
13:18:32 <Zakim> Zakim has joined #rdfa
13:18:34 <trackbot> Zakim, this will be 7332
13:18:34 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 42 minutes
13:18:35 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:18:35 <trackbot> Date: 26 April 2012
13:40:25 <MacTed> MacTed has joined #rdfa
13:48:42 <Steven_> Steven_ has joined #rdfa
13:59:43 <niklasl> niklasl has joined #rdfa
14:00:05 <Zakim> SW_RDFa()10:00AM has now started
14:00:13 <Zakim> +??P5
14:00:20 <gkellogg> zakim, I am ??P5
14:00:21 <Zakim> +gkellogg; got it
14:00:32 <ivan> zakim, dial ivan-voip
14:00:41 <Zakim> ok, ivan; the call is being made
14:00:43 <Zakim> +Ivan
14:01:14 <Zakim> +??P11
14:01:16 <niklasl> zakim, I am ??P11
14:01:16 <Zakim> +??P15
14:01:16 <manu1> zakim, I am ??P11
14:01:20 <Steven_> Steven_ has joined #rdfa
14:01:23 <Zakim> +niklasl; got it
14:01:24 <Zakim> sorry, manu1, I do not see a party named '??P11'
14:01:29 <manu1> zakim, I am ??P15
14:01:38 <Zakim> +manu1; got it
14:01:54 <Zakim> +??P13
14:02:41 <Zakim> +OpenLink_Software
14:02:53 <MacTed> Zakim, OpenLink_Software is temporarily me
14:02:54 <Zakim> +MacTed; got it
14:02:56 <MacTed> Zakim, mute me
14:03:06 <Zakim> MacTed should now be muted
14:04:20 <Zakim> +McCarron
14:04:29 <Zakim> +??P26
14:04:45 <Steven_> zakim, I am ??P26
14:04:45 <Zakim> +Steven_; got it
14:06:16 <ShaneM> ShaneM has joined #rdfa
14:06:35 <ShaneM> zakim, who is here?
14:06:35 <Zakim> On the phone I see gkellogg, Ivan, niklasl, manu1, ??P13, MacTed (muted), McCarron, Steven_
14:06:38 <Zakim> On IRC I see ShaneM, Steven_, niklasl, MacTed, Zakim, RRSAgent, trackbot, ivan, manu, manu1, gkellogg
14:06:44 <ShaneM> zakim, McCarron is ShaneM
14:06:44 <Zakim> +ShaneM; got it
14:10:20 <MacTed> Zakim, unmute me
14:10:20 <Zakim> MacTed should no longer be muted
14:10:45 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Apr/0061.html
14:10:55 <ivan> scribenick: ivan
14:11:01 <ivan> scribe: ivan
14:11:05 <ivan> manu: Any changes to the agenda?
14:13:06 <scor> scor has joined #rdfa
14:13:37 <niklasl> We should discuss the CURIE regex in the RDFa Core spec - it's not quite correct.
14:13:37 <niklasl> Issue: fix regexp in the xsd:simpleType definition of CURIE (it's too lax, matching e.g. "pfx://abc")
14:13:37 <trackbot> Created ISSUE-138 - Fix regexp in the xsd:simpleType definition of CURIE (it's too lax, matching e.g. "pfx://abc") ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/138/edit .
14:13:56 <manu1> Topic: High-level Overview of May and June re: RDFa 1.1
14:14:59 <Steven> Steven has joined #rdfa
14:15:47 <ivan> manu: Our goal during this call is to try to suggest to the Director that RDFa 1.1 should be moved to the Proposed Recommendation (PR) status - as long as the issues for today do not create any problems.
14:15:59 <ivan> … We want to make an announcement at SemTechBiz in San Francisco in early June 2012 on the REC publications.
14:16:06 <ivan> q+
14:16:15 <manu1> ack ivan
14:16:30 <manu1> ivan: To make it very clear - this means that we have to publish the PR in a week.
14:17:16 <manu1> ivan: Procedural description - we have to have a transition call - I have already started to find a time to do that (next Wednesday, probably). We have to start the process of members voting - at the minimum, they are given 4 weeks.
14:17:40 <manu1> ivan: If we start the process formally, on Thursday, it will end on the Thursday before the conference. If there are no objections during the voting period, moving to REC becomes an automatic thing.
14:17:54 <manu1> ivan: We can publish the REC the Tuesday after... this is a very tight schedule.
14:18:21 <Steven_> Steven_ has joined #rdfa
14:18:28 <manu1> ivan: We can shift a little bit because the conference ends on Thursday, we could formally announce on Thursday... but that's not ideal - let's try for Tuesday of the conference.
14:18:39 <ivan> manu1: any question on the process or objections on proceeding with this goal in mind?
14:18:51 <ivan> No objections or questions.
14:18:54 <manu1> Topic: Exiting Candidate Recommendation Phase
14:19:19 <ivan> manu1: We have some editorial issues and some open issues that we should discuss today that came up during the Candidate Recommendation period.
14:19:19 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/open
14:19:30 <ivan> manu1: Let's deal with what affects the REC-track documents first
14:19:32 <manu1> Subtopic: ISSUE-138: CURIE regex is not restrictive enough (editorial change)
14:19:38 <ivan> issue-138?
14:19:38 <trackbot> ISSUE-138 -- Fix regexp in the xsd:simpleType definition of CURIE (it's too lax, matching e.g. "pfx://abc") -- open
14:19:38 <trackbot> http://www.w3.org/2010/02/rdfa/track/issues/138
14:20:14 <ivan> manu1: Niklas, do you have an alternative regex?
14:20:26 <ivan> … What we could do is to resolve to fix the regex and come up with the regex later - it's pretty clear why we need to change this - to prevent URLs like "http://" from accidentally being detected as a CURIE.
14:20:59 <niklasl> Current CURIE simpleType pattern is: (([\i-[:]][\c-[:]]*)?:)?[^\s]+ - which doesn't prevent "://" in a URL after the prefix
14:21:12 <ivan> q+
14:21:15 <manu1> ack ivan
14:21:33 <manu1> ivan: Where does this regex come from? Does it come from the xsd:simpleType definition?
14:22:00 <ivan> shane: No, it doesn't - it's something in RDFa Core 1.1 that we defined for CURIEs.
14:22:31 <ivan> ShaneM: it is the definition in A.1, which is informative
14:22:38 <ivan> … i.e., we can change it - it's editorial...
14:23:17 <ivan> ShaneM: it is too lax right now, and what is the problem with that?
14:23:45 <ivan> manu1: It allows "://", which we decided to not allow in RDFa 1.1 to ensure that URLs aren't accidentally interpreted as CURIEs.
14:23:52 <ivan> ShaneM: Oh, right! Yes, we should fix this.
14:24:04 <manu1> PROPOSAL: Fix the regular expression for the definition of a CURIE in RDFa Core 1.1, Appendix A.1 to not allow "://" as a valid CURIE.
14:24:08 <ivan> ivan: +1
14:24:08 <manu1> +1
14:24:10 <ShaneM> +1
14:24:11 <niklasl> +1
14:24:18 <gkellogg> +1
14:24:18 <Steven_> +1
14:24:35 <MacTed> +1
14:24:39 <scor> +1
14:24:42 <manu1> RESOLVED: Fix the regular expression for the definition of a CURIE in RDFa Core 1.1, Appendix A.1 to not allow "://" as a valid CURIE.
14:25:02 <manu1> Subtopic: ISSUE-136: RDFa Lite 1.1 Document Conformance regarding @href/@src and @rel/@rev
14:25:07 <ivan> issue-136?
14:25:07 <trackbot> ISSUE-136 -- RDFa Lite 1.1 Conformance Section - host language attributes -- open
14:25:07 <trackbot> http://www.w3.org/2010/02/rdfa/track/issues/136
14:25:08 <manu1> Next up: https://www.w3.org/2010/02/rdfa/track/issues/136
14:25:33 <ivan> manu: Alex Milowski brought it up - RDFa Lite 1.1 conformance concerning @href/@src and @rel/@rev
14:25:42 <ivan> … We need to do some minor editorial changes
14:25:47 <ivan> q+
14:25:51 <manu1> ack ivan
14:26:28 <manu1> ivan: If you follow the thread, I have some text which is relatively obvious for adding a reference to @href and @src - there is the @rel/@rev issue. I'm not sure how to address that.
14:26:34 <gkellogg> Proposed text from Ivan: It must not use any additional RDFa attributes other than vocab, typeof, property, resource, and prefix; it may also use href and src, in case the Host Language authorizes their usage. The usage of rel and rev, if authorized by the Host Language, should be restricted to non-RDFa usage patterns, as defined by the Host Language.
14:27:00 <manu1> ivan: If somebody uses @rel with one of those attributes not meant for RDFa - they are conformant RDFa Lite.
14:27:57 <Steven_> Steven_ has joined #rdfa
14:31:23 <MacTed> "It must not use any additional RDFa attributes other than vocab, typeof, property, resource, and prefix; it may also use href and src, when the Host Language authorizes their usage. However, even if authorized by the Host Language, the usage of rel and rev should be restricted to non-RDFa usage patterns, as defined by the Host Language."
14:31:37 <ivan> Discussion ensuring that proposal wording doesn't tie us to specific spec text - editor's decision on what works.
14:31:53 <MacTed> Zakim, unmute me
14:31:53 <Zakim> MacTed was not muted, MacTed
14:33:09 <manu1> PROPOSAL: Update the RDFa Lite 1.1 specification using something to the effect of: "It must not use any additional RDFa attributes other than vocab, typeof, property, resource, and prefix; it may also use href and src, when the Host Language authorizes their usage. However, even if authorized by the Host Language, the usage of rel and rev should be restricted to non-RDFa usage patterns, as defined by the Host Language."
14:33:22 <manu1> +1
14:33:23 <MacTed> +1
14:33:23 <gkellogg> +1
14:33:24 <ivan> ivan: +1
14:33:26 <ShaneM> +1
14:33:26 <scor> +1
14:33:39 <Steven> +1
14:33:50 <niklasl> +1
14:33:54 <manu1> RESOLVED: Update the RDFa Lite 1.1 specification using something to the effect of: "It must not use any additional RDFa attributes other than vocab, typeof, property, resource, and prefix; it may also use href and src, when the Host Language authorizes their usage. However, even if authorized by the Host Language, the usage of rel and rev should be restricted to non-RDFa usage patterns, as defined by the Host Language."
14:33:59 <scor> It seems these pure editorial changes were not made to RDFa Lite yet: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Mar/0002.html - we might not need to straw poll on them, but I want to double check.
14:33:59 <ivan> manu1: Yes, I do intend on merging those editorial changes into the RDFa Lite document.
14:34:15 <manu1> Subtopic: ISSUE-134: RDFa Core 1.1, Section 7.5, Step 11 wording ambiguity
14:34:21 <ivan> issue-134?
14:34:21 <trackbot> ISSUE-134 -- Section 7.5, Step 11 Ambiguity in RDFa Core 1.1 -- open
14:34:21 <trackbot> http://www.w3.org/2010/02/rdfa/track/issues/134
14:34:37 <manu1> Next up is: https://www.w3.org/2010/02/rdfa/track/issues/134
14:35:40 <scor> q+
14:35:50 <ivan> manu1: we could say that 'while the wording could be more clear, we have four interoperable implementations already and therefore we should not change it at this point since the wording resulted in interoperable implementations'. We are also very concerned about changing the wording and introducing a bug at this late in the game.
14:35:51 <ivan> q+
14:35:54 <manu1> ack scor
14:36:02 <ivan> scor: These changes are not substantive, why not make them?
14:36:32 <ivan> manu: the danger is that we would make changes and introduce bugs, or make changes and introduce confusion. It's clear that using the current spec results in interoperable implementations.
14:37:07 <manu1> ack ivan
14:37:32 <manu1> ivan: If I want to be fair, your argumentation doesn't hold, Manu - all four implementations are from people in this WG, so there may be some pre-conceived knowledge that all of us used. Alex is not in this group and has a different reading on the spec.
14:37:36 <manu1> q+
14:38:27 <manu1> ivan: Alex is the first person that implemented this w/o being a part of the discussion. You could refute the argument you're using that way. That being said, I am very worried about making changes to the processing rules at this point. We could address Alex's issue at this point, but it becomes a bit scary to make this change at this point.
14:38:28 <gkellogg> q+
14:38:29 <manu1> ack manu1
14:38:55 <manu1> MacTed: Could we make this change as a note?
14:38:58 <manu1> ivan: Not really, we'd still be modifying the processing rules in a normative way.
14:39:30 <ivan> manu1: To be clear, when I implemented my processor, I implemented the processing steps literally - meaning, I did exactly what the processing steps said and my implementation worked out.
14:39:43 <manu1> ack gkellogg
14:39:43 <ivan> … but ivan is right, the people in the group have more knowledge of the intent that somebody that hasn't been here for the discussions.
14:39:57 <ivan> gkellogg: I attempted to do same thing, i.e., reading the document literally and implement from that.
14:40:05 <Steven_> Steven_ has joined #rdfa
14:40:09 <ivan> … I implemented 1.0 without being in the group, the most important tool for getting a proper implementation were the test cases.
14:40:20 <niklasl> +1
14:40:34 <ivan> … I would be worried to make any change that could ripple through the document.
14:41:38 <ivan> manu: We agree that it would be nice to make the processing steps a little bit more clear, but we are concerned about the ripple effects of this mainly when we already have implementations that followed the processing steps and that do work.
14:42:01 <ivan> niklasl: I was mainly driven by the test cases, and in case we had a problem i went back to the text.
14:42:02 <niklasl> We could change it to this - "… "otherwise, if the @rel, @rev, and @content attributes are not present, as a resource obtained from one of the following:""
14:42:30 <scor> q+
14:42:46 <ivan> niklasl: I can see Alex' point if he did not have a return statement in his text
14:42:56 <niklasl> … we could change it to this: "otherwise, if the @rel, @rev, and @content attributes are not present, and a resource is obtained from one of the following:"
14:43:13 <manu1> ack scor
14:43:43 <ivan> scor: Grant's mail says that we should not change this and he outlines good rationale for not doing so.
14:44:18 <ivan> scor: We could say the group agrees not to change using Grant's reasoning.
14:44:28 <ivan> manu: I do not think we should make any change at this point for all of the reasons stated during this call.
14:44:37 <ivan> … I think that Alex would understand if we do not make the change
14:44:44 <ivan> … the positive upside is small and the potential downside is large
14:44:54 <ivan> … we do not really have a consensus that we really need the change, especially when it comes to the wording that we should use.
14:45:53 <ivan> manu: I think we are talking this to death and should move on.
14:46:06 <Steven_> Yes, let's move on.
14:46:07 <ivan> manu: I have not heard anybody who feels very strongly that we should make this change. Does anybody feel strongly about making the change?
14:46:30 <ivan> Scribe notes silence, no strong feelings to make the change.
14:47:49 <MacTed> While the text is not as clear as it might be, implications of a change are potentially more problematic than the present inclarity.
14:48:32 <niklasl> I believe that Core section "8.1.1.3.1 Chaining with @property and @typeof" <http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#chaining-with--property-and--typeof> wouldn't work with the wrong implementation of this step. Can anyone verify?
14:49:10 <manu1> PROPOSAL: Regarding Section 7.5, Step 11, while the text is not as clear as it should be, making a change at this point could be more problematic than leaving the text as is.
14:49:17 <gkellogg> +1
14:49:19 <ivan> ivan: +1
14:49:29 <manu1> +1
14:49:40 <scor> +1
14:49:42 <niklasl> +1
14:49:52 <MacTed> +1
14:50:08 <ShaneM> +1
14:50:15 <Steven> +1
14:50:17 <manu1> RESOLVED: Regarding Section 7.5, Step 11, while the text is not as clear as it should be, making a change at this point could be more problematic than leaving the text as is.
14:50:59 <manu1> Additionally, the group believes that making a change right before REC is a bad idea, especially when the potential upside is difficult to ascertain.
14:51:16 <niklasl> q+
14:51:34 <manu1> ack niklasl
14:51:43 <ivan> niklasl: Should we discuss ISSUE-135 next?
14:51:50 <ivan> … it almost brought us to a halt...
14:52:03 <ivan> manu: yes, we should discuss it, but we have to finalize the move to PR first.
14:52:36 <scor> q+
14:53:04 <scor> It seems these pure editorial changes were not made to RDFa Lite yet: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Mar/0002.html - we might not need to vote, but I want to double check 
14:53:27 <ivan> manu: I intend to merge those into the document as soon as possible.
14:53:32 <ivan> … Everything in there is editorial, I intend to make the changes you request to RDFa Lite 1.1.
14:53:50 <ivan> manu: Is there any member of this working group that feels that there are any outstanding issues related to RDFa Core 1.1, RDFa Lite 1.1 and XHTML+RDFa 1.1? Would any member of this group object to moving these documents to the Proposed Recommendation stage?
14:54:45 <ivan> No objections are noted.
14:55:09 <manu1> PROPOSAL: The RDF Web Apps Working Group requests that the Director move RDFa Core 1.1, RDFa Lite 1.1, and XHTML+RDFa 1.1 to the Proposed Recommendation status modulo any changes that may be required before April 30th. The group requests that the documents are published on May 3rd 2012.
14:55:24 <scor> +1
14:55:25 <gkellogg> +1
14:55:26 <Steven> +1
14:55:26 <ivan> ivan: +1
14:55:27 <niklasl> +1
14:55:27 <manu1> +1
14:55:34 <MacTed> +1
14:55:46 <ShaneM> +1
14:55:48 <manu1> RESOLVED: The RDF Web Apps Working Group requests that the Director move RDFa Core 1.1, RDFa Lite 1.1, and XHTML+RDFa 1.1 to the Proposed Recommendation status modulo any changes that may be required before April 30th. The group requests that the documents are published on May 3rd 2012.
14:56:47 <ShaneM> This is what the CURIE regex should be: (([\i-[:]][\c-[:]]*)?:)?(/[^\s/]|[^\s/])[^\s]*
14:57:22 <manu1> ivan: Practicalities - Manu - you should send out an e-mail to the chairs requesting PR... it should go out on Monday (that's the 30th). Maybe sending it out before to Ralph, Thomas, Ivan would be good. We should have this on the record. There should be some sort of a report on what changes have happened on the document, including an implementation report.
14:57:55 <gkellogg> q+
14:57:59 <manu1> ack scor
14:58:06 <manu1> ack gkellogg
14:58:21 <ivan> gkellogg: The EARL report, should it be a working group note?
14:58:23 <gkellogg> http://rdfa.info/earl-reports/
15:00:05 <ivan> manu1: I will put a time-stamped document into W3C space.
15:00:23 <ivan> … I will send out the info to ralph, thomas, and an official mail with chairs on Monday.
15:00:45 <manu1> Topic: ISSUE-135: RDFa Lite and non-RDFa @rel values
15:00:58 <Zakim> -MacTed
15:01:50 <ShaneM> q+
15:02:26 <manu1> ack shanem
15:02:34 <manu1> Issue is here: http://www.w3.org/2010/02/rdfa/track/issues/135
15:40:34 <ivan> Very long discussion about sending a strong message that RDFa 1.1 is complete. The group intends to ask large implementers if they feel that ISSUE-135 is actually an issue, and if it is, address it. If large implementers do not feel it is an issue, then no changes will be made. If large implementers feel that it is an issue, there are two proposals that the group could adopt.
15:44:27 <manu1> What does the group favor? Straw poll: There are two options to address this issue: 1) In HTML5+RDFa - when using @vocab, authors MUST use CURIEs or IRIs in @rel (terms are ignored), and 2) In HTML5+RDFa, authors MUST use CURIEs or IRIs in @rel - no terms are allowed.
15:44:43 <ivan> ivan: +1 +1
15:44:47 <scor> +1 for either
15:44:51 <gkellogg> +0, +1
15:44:57 <ShaneM> -1 +1
15:45:07 <manu1> manu: -1 -1 (but if I had to pick), -1 +1
15:45:57 <Steven> +0 +0
15:45:58 <niklasl> +0.75 +0.75 (I'd prefer opt. 2 + "only if @property is present in the same element")
15:46:03 <ivan> Ivan: The group seems to prefer option #2 with some minor tweaks for corner cases.
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000275