Chatlog 2010-04-15

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

13:50:28 <RRSAgent> RRSAgent has joined #rdfa
13:50:28 <RRSAgent> logging to http://www.w3.org/2010/04/15-rdfa-irc
13:50:43 <manu> trackbot, start meeting
13:50:46 <trackbot> RRSAgent, make logs world
13:50:48 <trackbot> Zakim, this will be 7332
13:50:48 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 10 minutes
13:50:49 <trackbot> Meeting: RDFa Working Group Teleconference
13:50:49 <trackbot> Date: 15 April 2010
13:51:35 <manu> Present: Ivan, Steven, MarkB, Manu, Benjamin, Knud, Shane
13:51:41 <manu> Regrets: BenA, Toby
13:51:43 <manu> Chair: Manu
13:52:12 <manu> rrsagent, make logs public
13:53:24 <markbirbeck> markbirbeck has joined #rdfa
13:58:54 <Zakim> SW_RDFa()10:00AM has now started
13:59:01 <Zakim> +Benjamin
13:59:38 <Zakim> +??P9
13:59:48 <manu> zakim, I am ??P9
13:59:48 <Zakim> +manu; got it
14:00:17 <ivan> zakim, dial ivan-voip
14:00:17 <Zakim> ok, ivan; the call is being made
14:00:18 <Zakim> +Ivan
14:00:37 <ShaneM> ShaneM has joined #rdfa
14:01:15 <markbirbeck> zakim, code?
14:01:16 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), markbirbeck
14:01:27 <Knud> Knud has joined #rdfa
14:01:49 <Zakim> +knud
14:01:56 <Zakim> +markbirbeck
14:02:21 <Steven> zakim, dial steven-617
14:02:21 <Zakim> ok, Steven; the call is being made
14:02:22 <Zakim> +Steven
14:03:15 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Apr/0062.html
14:03:31 <Zakim> +ShaneM
14:04:08 <manu> scribenick: ivan
14:04:42 <ivan> Topic: Resolutions on FPWD Items
14:04:56 <ivan> manu: a couple of resolutions should be on records,
14:05:02 <ivan> ... get the issues closed
14:05:12 <ivan> ... and have a resolution on getting fpwd-s
14:05:27 <manu> http://www.doodle.com/uqe9pxru7eu8n7d8
14:05:28 <ivan> manu: we had a poll that we did not record 
14:05:41 <Knud> zakim, mute me
14:05:41 <Zakim> knud should now be muted
14:05:44 <ivan> manu: this covered the four items that had a wide agreement
14:05:53 <ivan> ... first: supporting of @profiles
14:06:13 <ivan> ... looking at it there were 2 against, we covered their reasons
14:06:21 <ivan> ... we should not rehash that
14:06:36 <manu> PROPOSAL: Support the general concept of RDFa Profiles - an external document that specifies keywords for CURIEs.
14:07:29 <ivan> ivan: +1
14:07:38 <manu> +1
14:07:38 <Benjamin> +1
14:07:41 <Knud> +1
14:07:47 <Steven> +1
14:07:50 <markbirbeck> +1
14:07:56 <Steven> This is not a vote - it's a straw poll that demonstrates rough consensus among the RDFa WG.
14:07:57 <ShaneM> +1
14:08:09 <manu> RESOLVED: Support the general concept of RDFa Profiles - an external document that specifies keywords for CURIEs.
14:08:38 <manu> PROPOSAL: Support the concept of having a default prefix mechanism without RDFS resolution.
14:08:41 <ivan> ivan: +1
14:08:50 <manu> +1
14:08:50 <Benjamin> +1
14:08:51 <Knud> +1
14:08:55 <Steven> +1
14:08:59 <markbirbeck> +1
14:09:16 <ShaneM> +1
14:09:26 <manu> RESOLVED: Support the concept of having a default prefix mechanism without RDFS resolution.
14:10:09 <manu> PROPOSAL: Support expressing the RDFa Profile document in RDFa (for example: rdfa:prefix/rdfa:keyword, or rdfa:alias)
14:10:16 <ivan> ivan: +1
14:10:18 <Steven> +1
14:10:19 <manu> +1
14:10:23 <Benjamin> +1
14:10:32 <Knud> +1
14:11:12 <ShaneM> +1
14:11:13 <markbirbeck> -1
14:12:19 <ivan> steven: mark, do you oppose this proposal?
14:12:37 <ivan> mark: I would be fine if we changed it to 'one of the possible mechanism would be rdfa'
14:12:49 <ivan> ... I think we can still have that discussion
14:13:10 <ivan> manu: we had a bit of discussions with that wording and we had a general discussion based on that - we don't want to change the proposal at this point because there is wide agreement to this wording and it could impact FPWD.
14:13:22 <ivan> ... looking at the proposal and the +1-s I would resolve it and we can have a discussion at a later stage
14:13:25 <manu> RESOLVED: Support expressing the RDFa Profile document in RDFa (for example: rdfa:prefix/rdfa:keyword, or rdfa:alias)
14:14:12 <manu> PROPOSAL: Provide an alternate mechanism to express mappings that does not depend on xmlns: (for example: @token, @vocab or @map)
14:14:20 <ivan> ivan: +1
14:14:25 <manu> +1
14:14:26 <Benjamin> +1
14:14:29 <Knud> +1
14:14:32 <Steven> -1
14:14:32 <markbirbeck> +1
14:14:50 <ivan> ivan: same question to steven... does he oppose or can live with it?
14:15:18 <ivan> steven: I was not sure whether I should say -1 or 0, an alternate means 'as well as'
14:15:27 <ShaneM> +1
14:15:27 <ivan> manu: this is really for languages without @xmlns: 
14:15:52 <ivan> ... and whether or not namespaces exist in html5 at the conceptual level is debatable, but the WHATWG folks are claiming so
14:16:03 <ivan> ... the vast majority of our arguments over namespaces and @xmlns: (RDFa doesn't require either) revolved around that
14:16:14 <ivan> ... we want RDFa to be used in languages that do not have @xmlns: or namespaced elements
14:16:20 <ivan> ... for those languages, @prefix makes more sense than @xmlns:
14:16:21 <ShaneM> Moreover using xmlns pollutes the namespaces of a parser unnecessarily.
14:16:40 <ivan> Steven: I do not agree that html5 does not fall into this category
14:16:43 <ivan> q+
14:16:48 <manu> ack ivan
14:17:58 <manu> RESOLVED: Provide an alternate mechanism to express mappings that does not depend on xmlns: (for example: @token, @vocab or @map)
14:18:12 <ivan> ivan: What about deprecating @xmlns:?
14:18:19 <manu> Topic: Deprecation of @xmlns: in RDFa 1.1
14:18:21 <ivan> ... it is in the current version of RDFa Core
14:18:42 <manu> +1 for deprecation of xmlns:
14:18:49 <Steven> -1 for deprecation
14:18:50 <manu> Ivan: I can live with deprecation of xmlns:
14:19:08 <manu> Ivan: we need a resolution for this if we are going to have it in RDFa Core 1.1 FPWD
14:19:16 <ivan> shane: I did this offline, asked Manu, he agreed and we added the text in there
14:19:32 <ivan> ... I agree that this should be discussed by the WG
14:19:38 <ivan> ... since having two is confusing
14:19:53 <ivan> manu: the reason I thought we would be going this direction is because we've had this discussion before in RDFa WG - Whether or not to deprecate xmlns:
14:20:02 <ivan> ... the issue is confusing - having two equal prefixing mechanisms
14:20:09 <ivan> ... we've also talked about the namespace issues - how RDFa doesn't need namespaces and how using xmlns: confuses a great number of people. 
14:20:10 <Steven> I disagree more strongly on this one than the last
14:20:20 <ivan> ... If we had known what we know now about the confusion xmlns: creates in regular web developers. Some people still think that RDFa requires namespaces (even though RDFa doesn't require namespaces). Back in RDFa 1.0, when we re-used xmlns:, we would have probably defined a new attribute instead of re-using @xmlns: if we know what we know now (which is impossible)... looks like we'll need to discuss this in much more depth, then.
14:20:30 <ivan> steven: I am against deprecating it
14:20:30 <markbirbeck> q+
14:20:44 <ivan> ... I do not like breaking backward compatibility
14:20:48 <ivan> manu: it does not break backward compatibility
14:21:01 <ivan> ... deprecation means a strong a signal not to use 
14:21:15 <ivan> shane: technically it means it is not removed yet but it can be
14:21:31 <manu> ack mark
14:21:36 <ivan> ... steven, if it said 'prefix is preferred, is that fine'?
14:21:38 <ivan> steven: yes
14:21:46 <ivan> mark: 'deprecated' means there is a decision to remove it in the future
14:21:56 <ivan> ... we have to send a strong signal
14:22:48 <ivan> ... I do not agree that we would have not used xmlns: - done it differently
14:23:01 <manu> q+ to clarify "we'd do it differently"
14:23:10 <ivan> ... at the time we used what w3c had an emphasis on at the time - xmlns: - now things have changed, not as much of an emphasis on namespaces and xmlns: - we made the right decision in the context of what was going on at the time.
14:23:20 <ShaneM> +1 to marks concern
14:23:54 <ivan> ack manu
14:23:54 <Zakim> manu, you wanted to clarify "we'd do it differently"
14:23:54 <Steven> +1 to Mark
14:24:59 <Knud> "xmlns is discouraged"?
14:25:09 <markbirbeck> +1 to Knud
14:25:46 <Zakim> -ShaneM
14:25:47 <Zakim> +ShaneM
14:26:06 <ivan> PROPOSAL: the FPWD should say something like "prefix is preferred" but not explicitly deprecate xmlns
14:26:20 <ShaneM> +1
14:26:21 <manu> +1
14:26:22 <ivan> ivan: +1
14:26:28 <Knud> +1
14:26:31 <Benjamin> +1
14:26:31 <Steven> I can live with that
14:28:31 <markbirbeck> 0
14:28:35 <ivan> markbirbeck: That doesn't send a very strong message, does it?
14:29:52 <manu> PROPOSAL: Remove mention of "xmlns: is deprecated" from the RDFa Core 1.1 FPWD
14:30:08 <manu> +1
14:30:08 <ivan> ivan: +1
14:30:10 <markbirbeck> +1
14:30:23 <Knud> +1
14:30:23 <Benjamin> +1
14:30:24 <Steven> +1
14:30:35 <ShaneM> +1
14:30:36 <ivan> RESOLVED: Remove mention of "xmlns: is deprecated" from the RDFa Core 1.1 FPWD
14:30:45 <ivan> manu: We will have to discuss this in more depth and reach some kind of consensus about deprecating xmlns: after the FPWDs are out there.
14:31:03 <manu> Topic: Resolve to Publish RDFa Core 1.1 and XHTML+RDFa 1.1 FPWD
14:31:16 <ivan> manu: shane, an overview?
14:31:46 <ivan> shane: as far as can see, modulo pubrules, the document is in agreement with the resolutions of the group
14:31:56 <ivan> ... fpwd does not have to be perfect
14:32:17 <ivan> ... xhtml did not have the same review as core, but that is all right, not much changed there since XHTML+RDFa 1.0 :-)
14:32:26 <ivan> Ivan: I have concerns about the core and not publishing RDFa DOM API at the same time
14:32:42 <ivan> ... as soon as we put it out to the public, we will have the public reacting negatively to not publishing RDFa DOM API with the other two documents.
14:32:40 <ivan> manu: Shane, got a link to the RDFa Core 1.1 and XHTML+RDFa 1.1 documents?
14:32:55 <ShaneM> http://www.w3.org/2010/02/rdfa/drafts/
14:33:11 <ShaneM> http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-core-20100414/
14:33:20 <ShaneM> http://www.w3.org/2010/02/rdfa/drafts/2010/ED-xhtml-rdfa-20100413/
14:33:25 <ivan> q+
14:33:34 <manu> ack ivan
14:34:08 <manu> PROPOSAL: Publish RDFa Core 1.1 as First Public Working Draft
14:34:53 <manu> Ivan: Are we going to publish RDFa DOM API now as well?
14:35:37 <manu> Ivan: I think people might misunderstand the publishing RDFa DOM API at a later date as something negative.
14:35:46 <manu> q+ to discuss RDFa DOM API publication
14:35:50 <markbirbeck> q+
14:36:19 <manu> Ivan: I'm concerned that people may think we're not concerned about the RDFa DOM API - we do care about it, very much.
14:36:23 <manu> ack markbirbeck
14:36:30 <ivan> mark: I can understand your concern, Ivan
14:36:33 <ivan> ... but I disagree
14:36:52 <ivan> ...the audience to this spec is very different
14:37:12 <ivan> .. my feeling is that the rdfa core and the xhtml will go unnoticed by general web developers.
14:37:21 <ivan> ... but RDFa itself is the story and it's evolved
14:37:30 <ivan> ... however the dom api is a different audience, different story - audience is parser developers
14:37:41 <ivan> ... RDFa DOM API is really aimed at web developers and we really think we should aim it at the html authors
14:37:42 <ivan> q+
14:37:46 <manu> ack manu
14:37:46 <Zakim> manu, you wanted to discuss RDFa DOM API publication
14:37:51 <ivan> manu: I agree with mark 
14:38:13 <ivan> ... i do not want us to get into mind set where we think that all of these specs must be published at the same time. 
14:38:23 <ivan> ... We shouldn't create artificial ties between the documents that do not exist.
14:38:33 <ivan> ... but, let's suppose that all of Ivan's fears come true - bad community backlash due to a misunderstanding of where our priorities are
14:38:41 <ivan> ... we have to have courage, and take the heat if that happens
14:38:54 <ivan> ... we are not talking about pushing the dom api by a couple of months, we are talking about slipping publication by two weeks.
14:39:07 <ivan> ... if slipping the date by two weeks ends up resulting in nasty remarks about the RDFa WG
14:39:19 <ivan> ... those nasty remarks will be invalidated after two weeks time - when we publish the RDFa DOM API document
14:39:22 <manu> ack ivan
14:40:15 <markbirbeck> Fair point Ivan. I was bending the stick too far. :)
14:41:35 <manu> Ivan: I hope I'm being paranoid - and I wouldn't object to FPWD.
14:41:52 <manu> Ivan: I think these are the same audiences - we've changed some pretty major stuff.
14:42:10 <Zakim> +knud
14:42:16 <manu> PROPOSAL: Publish RDFa Core 1.1 as First Public Working Draft
14:43:05 <manu> +1
14:43:05 <ivan> ivan: +0.5
14:43:06 <markbirbeck> +1
14:43:07 <Benjamin> +1
14:43:10 <Knud> +1
14:43:11 <ShaneM> +1
14:43:11 <markbirbeck> :)
14:43:22 <Steven> +1
14:43:36 <manu> RESOLVED: Publish RDFa Core 1.1 as First Public Working Draft
14:44:00 <manu> PROPOSAL: Publish XHTML+RDFa 1.1 as First Public Working Draft
14:44:04 <manu> +1
14:44:04 <Steven> +1
14:44:06 <Benjamin> +1
14:44:07 <markbirbeck> +1
14:44:09 <Knud> +1
14:44:13 <ivan> ivan: +0.5 (just to be consistent)
14:44:23 <markbirbeck> I was wondering what you'd do. :)
14:44:24 <ShaneM> +1
14:44:29 <manu> RESOLVED: Publish XHTML+RDFa 1.1 as First Public Working Draft
14:45:14 <ivan> manu: Great job guys on these FPWD! Many thanks to Shane who worked tirelessly to get these documents into shape over the past several weeks!
14:46:45 <ivan> clap clap clap
14:46:50 <ivan> wohooo
14:46:52 <ivan> etc
14:46:56 <markbirbeck> Nice work Shane!
14:47:08 <ivan> Topic: RDFa DOM API
14:47:25 <ivan> manu: I have not put the API on the focus on the agendas for the past two months and I'm afraid that has put us in this situation of not being able to publish RDFa DOM API FPWD along with RDFa Core and XHTML+RDFa - so let's put all of our focus on RDFa DOM API now... get it to FPWD quickly.
14:47:48 <ivan> ... Benjamin, Mark and and I had discussion on how to improve it
14:47:54 <markbirbeck> q+ To apologise for causing delay on DOM API.
14:48:02 <ivan> ... what we want to do is to focus solely on the dom api for the coming 2 weeks
14:48:21 <Benjamin> Current version of the RDFa DOM API document: http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/
14:48:29 <ivan> mark: apologize for causing delay, I was away with no internet connection...
14:48:44 <Benjamin> And the latest version of the Javascript prototype: http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/rdfa_dom_api.js
14:48:55 <ivan> ... the key issue I am trying to push this towards 
14:49:18 <ivan> ... we should give people an api to select the elements of the dom that resulted in a triple in the triple store
14:49:32 <ivan> ... I put something up today for us to discuss
14:49:47 <ivan> manu: the concern I had is that I cannot implement element tracking in Firefox using the librdfa parser
14:50:04 <ivan> ... i know we are talking about an rdfa api
14:50:22 <ivan> ... but it will be very difficult to implement that for implementers that don't have access to the core DOM document object
14:50:31 <ivan> ... i do not know how to implement that in c and c++ in Firefox.
14:50:38 <ivan> mark: i think it is pretty easy
14:50:46 <ivan> manu: i would like to see some code
14:50:58 <ivan> ... if we can implement it in the c and c++ in Firefox, then we should have the feature.
14:51:11 <ivan> mark: this raises the question what we want to achieve with this api
14:51:26 <ivan> ... just querying triples is not really useful
14:51:54 <ivan> manu: that is not what i mean; if we want people to write Firefox extensions that modify the dom and give them extra methods - if we can't do that in a Firefox extension, we have a problem.
14:52:12 <ivan> ... this is usually done is c and c++, and we especially have this issue with the new @profile attribute.
14:52:34 <ivan> ... I do not think you can do it in pure javascript - dereference external @profile documents.
14:52:41 <ivan> ... this is not about implementing it in Redland, you can do that easily.
14:52:57 <ivan> ... it is about the restrictions that Firefox and Chrome put on their extension writers
14:53:15 <ivan> mark: if we want to do something for the in-browser developers, we have to see what is useful to those developers - tying to elements is very useful.
14:53:18 <manu> +1 to what Mark just said.
14:53:28 <ivan> ... we may need an additional thing in the api
14:53:44 <ivan> ... maybe we need some events that get passed
14:53:54 <ivan> ... we have to try to solve this rather than drop it
14:54:30 <ivan> manu: with that said, do you have examples of extending the Document object in Firefox? Not using Javascript - but with C/C++?
14:55:02 <ivan> markbirbeck: we had all kinds of things experimented with in our xforms work, there are lots of stuff we looked at
14:55:18 <ivan> manu: are you opposed getting just triples in javascript?
14:55:44 <ivan> markbirbeck: i do not have a problem with some kind of layering
14:55:55 <ivan> ... eg in sparql you have the notion of projection
14:56:08 <ivan> ... the result is the set of results with all kinds of properties
14:56:16 <ivan> ... you get back objects
14:56:32 <ivan> ... that is natural for js programmers
14:56:34 <ivan> q+
14:56:37 <Benjamin> The current API version may be easily extended to query DOM nodes with certain RDFa content.
14:56:37 <ivan> ack markbirbeck 
14:56:37 <Zakim> markbirbeck, you wanted to apologise for causing delay on DOM API.
14:56:38 <manu> ack mark
14:57:07 <ivan> markbirbeck: i have not looked at other languages, we may have a language specific holes where objects can be used
14:57:22 <ivan> ... and languages should fill that in - use whatever makes sense natively - objects in object-oriented languages.
14:57:36 <ivan> ... but all objects should have a pointer at that element where the triple comes from
14:57:59 <Benjamin> q+
14:58:23 <ivan> ... we get both the semantics and the element that produced that
14:58:26 <manu> ack ivan
14:59:38 <manu> q+ to discuss triples-as-objects
14:59:41 <Benjamin> -1 to Ivans proposal
14:59:48 <manu> ack benjamin
15:00:04 <manu> Ivan: We don't have to provide every feature when doing a FPWD - do we really need this in there.
15:00:13 <ivan> Benjamin: The RDFa DOM API is not in a publish-able state right now - we cannot publish it today
15:00:26 <ivan> ... I think we should reach a concensus about the general style of the document
15:00:49 <ivan> ... we should get a feeling for what the api would look like
15:00:51 <manu> q-
15:00:55 <manu> q+ to end the telecon
15:01:04 <ivan> manu: we can add mark's proposal to this and see how it works together with the stuff that's already in there.
15:01:10 <ShaneM> Remember that published documents have their own momentum... Once it starts rolling in a certain direction it is hard to change.  The faster it rolls the harder it is to redirect.
15:01:40 <ivan> manu: mark, what would help us most is to give us examples
15:01:47 <ivan> ... see how we can have this happen
15:01:53 <ivan> meeting adjourned
15:02:10 <Zakim> -markbirbeck
15:02:12 <Zakim> -Steven
15:02:14 <Zakim> -knud
15:02:20 <Zakim> -Benjamin
15:02:31 <Knud> +1 to what Shane just said
15:02:50 <markbirbeck> +1.5
15:03:00 <markbirbeck> (I'm using up the bits that Ivan didn't use. :))
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000315