Chatlog 2010-07-22

From RDFa Working Group Wiki
Jump to: navigation, search

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

13:52:01 <RRSAgent> RRSAgent has joined #rdfa
13:52:01 <RRSAgent> logging to
13:54:30 <manu> trackbot, prepare telecon
13:54:32 <trackbot> RRSAgent, make logs world
13:54:34 <trackbot> Zakim, this will be 7332
13:54:34 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 6 minutes
13:54:35 <trackbot> Meeting: RDFa Working Group Teleconference
13:54:35 <trackbot> Date: 22 July 2010
13:54:39 <manu> Chair: Manu
13:55:20 <manu> Present: Ivan, Steven, Manu, Shane, MarkB, Knud
13:58:57 <Zakim> SW_RDFa()10:00AM has now started
13:59:04 <Zakim> + +1.540.961.aaaa
13:59:10 <manu> zakim, I am aaaa
13:59:10 <Zakim> +manu; got it
14:00:21 <Steven> zakim, dial steven-617
14:00:21 <Zakim> ok, Steven; the call is being made
14:00:22 <Zakim> +Steven
14:01:34 <ivan> zakim, dial ivan-voip
14:01:34 <Zakim> ok, ivan; the call is being made
14:01:35 <Zakim> +Ivan
14:01:48 <Zakim> +ShaneM
14:02:18 <Knud> Knud has joined #rdfa
14:02:25 <ShaneM> ShaneM has joined #rdfa
14:02:38 <Zakim> + +3539149aabb
14:03:29 <Steven> zakim, aabb is Knud
14:03:29 <Zakim> +Knud; got it
14:03:52 <manu> Regrets: Toby
14:04:01 <manu> zakim, who is on the call?
14:04:01 <Zakim> On the phone I see manu, Steven, Ivan, ShaneM, Knud
14:04:11 <markbirbeck> markbirbeck has joined #rdfa
14:04:46 <markbirbeck> zakim, code?
14:04:46 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+ tel:+44.203.318.0479), markbirbeck
14:05:58 <Zakim> +??P21
14:06:05 <markbirbeck> zakim, i am ?
14:06:05 <Zakim> +markbirbeck; got it
14:06:53 <manu> Scribe: Mark
14:07:13 <markbirbeck> TOPIC: Heartbeat working drafts by end July 2010.
14:07:35 <Steven> rrsagent, make minutes
14:07:35 <RRSAgent> I have made the request to generate Steven
14:08:28 <markbirbeck> Manu: We may be late on RDFa Core...need to publish every 3 months.
14:08:49 <markbirbeck> Steven: Technically, we need to publish /something/ every 3 months, but not necessarily each draft.
14:09:10 <markbirbeck> Ivan: Agree...according to process we're ok.
14:09:35 <markbirbeck> Shane: We can publish RDFa Core whenever we like, it's always up-to-date.
14:09:38 <Steven> zakim, who is on the phone?
14:09:38 <Zakim> On the phone I see manu, Steven, Ivan, ShaneM, Knud, markbirbeck
14:09:51 <markbirbeck> Manu: Not too worried about state of RDFa Core.
14:10:01 <markbirbeck> ... But we haven't done anything on the API document for a while.
14:10:17 <markbirbeck> ... Shane, could we have RDFa Core and XHTML+RDFa ready to go?
14:10:26 <markbirbeck> ... And then we could discuss the API document in the next month.
14:10:32 <markbirbeck> ... Everyone ok with that?
14:10:40 <markbirbeck> General nodding.
14:10:52 <ivan> q+
14:10:53 <markbirbeck> TOPIC: ISSUE-26 Error Reporting Mechanism
14:13:10 <manu> MarkB: I'm concerned that we're creating a technology that we may not be able to agree on, without using up a lot of time. There are ways to do error mechanisms w/o needing an RDFa error vocabulary.
14:13:38 <manu> MarkB: So the discussion may need to go back to whether or not we need to specify the error reporting mechanism in RDFa Core.
14:14:01 <manu> Ivan: Maybe we can keep the current formulation of processor graph and default graph.
14:14:09 <Steven> Agenda:
14:14:14 <Steven> rrsagent, make minutes
14:14:14 <RRSAgent> I have made the request to generate Steven
14:14:36 <manu> Ivan: We should not define the details of what goes into the processor graph.
14:14:41 <manu> q+ to discuss vocabulary
14:14:45 <manu> ack ivan
14:15:19 <manu> Ivan: If we do not put the error vocabulary into the document, maybe the community will give us feedback as to whether or not they want an error reporting mechanism.
14:15:23 <manu> ack manu
14:15:23 <Zakim> manu, you wanted to discuss vocabulary
14:15:30 <ShaneM> I don't care anymore
14:16:49 <markbirbeck> Manu: Problem is that each parser has a different mechanism for reporting errors.
14:16:49 <ivan> q+
14:17:08 <markbirbeck> ... Would be great if Firefox's technique was the same as Ivan's Distiller.
14:17:33 <markbirbeck> ... If we think that this would be useful not just to developers but end-users, then we should go to some lengths to define these values.
14:17:58 <markbirbeck> ... We don't necessarily need to put the error vocabulary into RDFa Core, but it would be good if we did create a vocabulary.
14:18:08 <manu> ack ivan
14:18:27 <markbirbeck> Ivan: The problem is that realistically this is where opinions differ.
14:18:55 <markbirbeck> ... So I have my version of the vocabulary...Benjamin wants an XML literal...Mark wants something EARL-based.
14:19:10 <manu> q+ to discuss consensus
14:19:18 <markbirbeck> ... So obtaining consensus is going to be time-consuming.
14:19:37 <markbirbeck> ... Agree with Mark that this isn't so central that it should take up so much time.
14:19:49 <manu> ack manu
14:19:49 <Zakim> manu, you wanted to discuss consensus
14:19:53 <markbirbeck> ... So for the time being feel that we should just leave it open for now.
14:20:08 <markbirbeck> Manu: Not saying that this vocabulary should be discussed in the WG - perhaps we could write it up as a best practice and have some test case coverage?
14:20:29 <markbirbeck> Ivan: Ok...happy to write that down.
14:21:20 <markbirbeck> Manu: Seems like something that is useful and warrants guidance.
14:24:20 <ShaneM> q+ to talk about how errors are handled in core
14:24:57 <manu> MarkB: I don't know if we need to have anything in RDFa Core about processor graphs. I think it makes sense in the RDFa API document.
14:25:01 <ivan> ack ShaneM 
14:25:01 <Zakim> ShaneM, you wanted to talk about how errors are handled in core
14:25:05 <ivan> q+
14:25:11 <markbirbeck> MarkB: Would prefer to not see this in there at all, because I have a general feeling that things are getting more complicated.
14:25:19 <manu> ack ivan
14:25:34 <markbirbeck> Shane: What do we say in the core document about processing errors?
14:25:49 <markbirbeck> Ivan: We should retain the processor graph idea, so we only need to refer to that.
14:25:57 <markbirbeck> ... We don't need to say what the triples look like.
14:26:19 <markbirbeck> Shane: If there is consensus on that then I'm fine.
14:26:37 <markbirbeck> Manu: There is other language in there about how to access this graph.
14:26:50 <ShaneM> The language is here:
14:29:17 <ivan> q+
14:30:08 <markbirbeck> Manu: It looks like section 7.6.2 is what should come out.
14:31:01 <markbirbeck> Ivan: Think that the final warning in the list shouldn't be a must.
14:31:15 <markbirbeck> ... (In the opening part of section 7.6.)
14:31:54 <ivan>
14:32:46 <markbirbeck> MarkB: Are we saying processors MUST implement all of this?
14:33:16 <markbirbeck> Manu: No. If you choose to implement this, then it must conform to this particular arrangement.
14:33:18 <manu> PROPOSAL: A general error reporting mechanism should be described by RDFa Core, but the specifics of the RDFa Error Vocabulary are out of scope for RDFa Core per
14:33:33 <ivan> +1
14:33:43 <manu> +1
14:33:50 <Knud> +1
14:33:56 <markbirbeck> MarkB: +0
14:34:05 <Steven> +1
14:34:28 <ShaneM> +1
14:34:45 <manu> Manu: Any particular reason for the +0, Mark?
14:35:12 <manu> MarkB: Not sure if this causes issues - not certain about it yet, but could go either way.
14:35:32 <manu> Manu: If it causes issues at LC or later, we'll have to take it out or modify it - we'll see if the implementers and the community can spot any issues.
14:36:14 <manu> RESOLVED: A general error reporting mechanism should be described by RDFa Core, but the specifics of the RDFa Error Vocabulary are out of scope for RDFa Core per
14:36:32 <markbirbeck> Ivan: Don't forget to update tracker.
14:36:41 <markbirbeck> TOPIC: ISSUE 24 Case-sensitive terms in HTML5
14:36:48 <Steven> issue-26?
14:36:48 <trackbot> ISSUE-26 -- Do we need an error reporting mechanism for RDFa? -- closed
14:36:48 <trackbot>
14:36:52 <markbirbeck> Manu: Shane put out a proposal in the last day or so.
14:37:03 <Steven> issue-24?
14:37:03 <trackbot> ISSUE-24 -- Should all terms be case-sensitive in HTML5 and XHTML? -- open
14:37:03 <trackbot>
14:37:16 <markbirbeck> Shane: This is actually Manu's proposal...I just provided the dextrous digits.
14:37:41 <markbirbeck> ... Upshot of the proposal is to treat all terms as being compared case-insensitively.
14:38:02 <markbirbeck> ... Solves the real problem I had which was that special-casing vocabularies seemed weird.
14:38:20 <markbirbeck> ... Comparison of terms is case-insensitive.
14:38:26 <markbirbeck> ... Languages can define terms.
14:38:45 <manu> q+ to discuss language documents that specify terms
14:38:46 <markbirbeck> ... A profile should be declared to contain the terms, but they can be hard-coded.
14:38:48 <manu> ack ivan
14:39:48 <markbirbeck> Ivan: Clarifications: It's not a core part of the proposal but relates to last week's discussion -- the default vocabulary goes away.
14:40:33 <markbirbeck> Shane: Disagree. The spec says that a language can define a default vocabulary.
14:41:12 <markbirbeck> Ivan: Second thing is what to do with CURIEs that have an empty prefix.
14:41:33 <markbirbeck> ... Shane's proposal resolves this, but would like to see a note in there to say that it's not a good idea.
14:41:58 <markbirbeck> ... Final thing is to say that the set of terms in the current profile is fixed.
14:42:07 <markbirbeck> ... I.e., if we add more terms then we need a new URI.
14:42:19 <markbirbeck> ... Not sure how that will go down with HTML 5 and others.
14:42:38 <markbirbeck> Manu: Want to make it easy for implementers to define one set of terms.
14:43:03 <markbirbeck> ... In the future HTML 5 will start adding terms, but it could take a while, so I don't think there will be an issue for a while.
14:43:49 <markbirbeck> ... So we say that this is the default document for all RDFa processors. Then in a year or two we discover that there are other terms needed, then it's not too much of an issue to just add them and create a new default profile document.
14:44:24 <ivan> q+
14:44:27 <manu> ack manu
14:44:27 <Zakim> manu, you wanted to discuss language documents that specify terms
14:44:30 <markbirbeck> ... However, if we need something dynamic for HTML 5 then we could create a document that contains a profile that must be loaded.
14:46:00 <manu> ack ivan
14:46:20 <markbirbeck> Ivan: I'm going to get into details here... I think we need to.
14:46:41 <markbirbeck> ... Conceptually XHTML will have its own profile document that lists the terms. Whether that's cached or not is beside the point.
14:47:15 <markbirbeck> ... What happens if I have an XHTML document that has a profile document at the top, in the HTML element?
14:47:20 <markbirbeck> Shane: That should override the default.
14:47:45 <markbirbeck> Ivan: Agree, but that should be made clear.
14:47:52 <markbirbeck> Shane: Have related question.
14:48:32 <markbirbeck> ... If I load a profile on one element, and then load another in a child element, we get the result of both?
14:48:38 <markbirbeck> General nodding.
14:48:56 <markbirbeck> Shane: Since this is correct, then we have no way to clear the collection.
14:49:40 <markbirbeck> ... @xml:lang="" clears the we want the same feature?
14:49:47 <markbirbeck> Ivan: Give me the use-case.
14:50:48 <markbirbeck> Shane: I'm bringing in a part of a document, and I want to ensure that only the triples I want get included.
14:50:56 <markbirbeck> ... Will raise this separately.
14:51:15 <markbirbeck> Ivan: If we're planning a new draft, we should also get the default profile document ready.
14:51:32 <markbirbeck> Manu: Isn't that the same as the XHTML Vocab document?
14:51:38 <markbirbeck> Shane: Yes...I'll update it.
14:51:53 <markbirbeck> Manu: Any objections to Shane's proposal?
14:52:25 <Steven>
14:52:41 <manu> PROPOSAL: Adopt proposal for addressing ISSUE-24 (case-sensitive terms in HTML5) as posted to the mailing list:
14:52:52 <ivan> +1
14:52:54 <markbirbeck> Mark: +1
14:52:55 <manu> +1
14:52:56 <Steven> +1
14:52:59 <Knud> +1
14:53:06 <manu> RESOLVED: Adopt proposal for addressing ISSUE-24 (case-sensitive terms in HTML5) as posted to the mailing list:
14:53:10 <ShaneM> +1
14:53:38 <markbirbeck> TOPIC: ISSUE 3 HTML5 Infoset coercion
14:53:43 <Steven> issue-3?
14:53:43 <trackbot> ISSUE-3 -- Updating HTML5 coercion to Infoset rules -- open
14:53:43 <trackbot>
14:54:00 <markbirbeck> Manu: Could either be very easy to resolve...or very difficult, depending on whether we involve the HTML WG.
14:55:02 <markbirbeck> ... Issue raised some time ago by Henri, when he said that if we don't specify how to coerce the document into an infoset, then people won't know how to get xmlns-based attribute values.
14:55:22 <markbirbeck> ... No-one had this problem, since many people had created JS parsers.
14:56:23 <markbirbeck> ... There's a proposal now that HTML 5 parsing should preserve namespace values.
14:57:17 <markbirbeck> Ivan: It's one of those things where I understood it when you were explaining it...then it vanished.
14:57:27 <markbirbeck> ... Is this something this WG has to deal with?
14:57:36 <markbirbeck> ... And is the HTML WG prepared to look at this?
14:58:06 <markbirbeck> Manu: If we specify it, it will make it easier to extract the xmlns values. It will simplify the algorithm.
14:58:43 <markbirbeck> ... If it's rejected from HTML 5, then we have another path which is to specify it ourselves, which is already done and it works reliably.
14:59:43 <markbirbeck> ... As to whether the HTML WG is open to this, I don't know; an issue would be whether this breaks backwards-compatibility, and to answer that we'd need to speak in more detail with browser vendors.
15:00:28 <markbirbeck> ... This is already in the spec and Henri hasn't raised any objections yet, but that may be because it's not on his (and/or Hixie's) radar.
15:00:59 <ShaneM> q+ to suggest a path
15:01:06 <manu> ack shanem
15:01:06 <Zakim> ShaneM, you wanted to suggest a path
15:01:26 <markbirbeck> ... If the coercion to infoset changes are not made to HTML 5 then we just do it the hard way, and look in both places for the values.
15:01:55 <markbirbeck> Shane: Admire your passion Erin Brokovich, but we have a solution, so not sure it's worth pushing on it.
15:02:19 <markbirbeck> ... Since browsers won't know whether this breaks anything, then they could well be reluctant to make this change.
15:02:33 <markbirbeck> ... "Let it go, Manu...let it go".
15:02:44 <markbirbeck> Manu: We can ensure backwards compatibility by placing "xmlns:foo" values in the null namespace like HTML5 does now and in addition, create the namespace tuple for Infoset-based parsers. It's the proper, non-hackish solution to this problem. I think I'm going to push a bit longer.
15:03:26 <markbirbeck> (Would like to point out that we all laughed when Manu first suggested that HTML 5 should support RDFa, and that he was going to make it happen.)
15:03:47 <Steven> Regrets for next 4 weeks
15:04:15 <markbirbeck> Ivan: Regrets for next 4 weeks.
15:04:24 <markbirbeck> Steven: Regrets for next 4 weeks.
15:05:14 <Zakim> -manu
15:05:15 <Zakim> -markbirbeck
15:05:15 <ivan> zakim, drop me
15:05:16 <Zakim> Ivan is being disconnected
15:05:16 <Zakim> -Ivan
15:05:18 <Zakim> -Knud
15:05:25 <Zakim> -ShaneM
15:05:46 <Steven> zakim, who is on the phone?
15:05:46 <Zakim> On the phone I see Steven
15:05:51 <Zakim> -Steven
15:05:52 <Zakim> SW_RDFa()10:00AM has ended
15:05:54 <Zakim> Attendees were +1.540.961.aaaa, manu, Steven, Ivan, ShaneM, +3539149aabb, Knud, markbirbeck
15:06:03 <Steven> rrsagent,make minutes
15:06:03 <RRSAgent> I have made the request to generate Steven
15:06:19 <markbirbeck> For information: I'm speaking at an event organised with Talis and NHS, on August 17th on Ontologies and Healthcare. Have invited Steven to speak on RDFa, since he's visiting at the time. :)