<manu> trackbot, setup meeting

<trackbot> Sorry, manu, I don't understand 'trackbot, setup meeting'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<manu> trackbot, start meeting

<trackbot> Date: 15 April 2010

<ShaneM> zakim is being stupid

<markbirbeck> thought so

<manu> scribenick: ivan

Admin issues

manu: a couple of resolutions should be on records,
... get the issues closed
... and have a resolution on getting fpwd-s

<manu> http://www.doodle.com/uqe9pxru7eu8n7d8

manu: we had a poll that we did not record
... this covered the four items that had a wide agreement
... first: supporting of @profiles
... looking at it there were 2 against, we covered their reasons
... we should not rehash that

<manu> PROPOSAL: Support the general concept of RDFa Profiles - an external document that specifies keywords for CURIEs.

+1

<manu> +1

<Benjamin> +1

<Knud> +1

<Steven> +1

<markbirbeck> +1

<Steven> This is not a vote

<ShaneM> +1

<manu> RESOLVED: Support the general concept of RDFa Profiles - an external document that specifies keywords for CURIEs.

<manu> PROPOSAL: Support the concept of having a default prefix mechanism without RDFS resolution.

+1

<manu> +1

<Benjamin> +1

<Knud> +1

<Steven> +1

<markbirbeck> +1

<ShaneM> +1

<manu> RESOLVED: Support the concept of having a default prefix mechanism without RDFS resolution.

<manu> PROPOSAL: Support expressing the RDFa Profile document in RDFa (for example: rdfa:prefix/rdfa:keyword, or rdfa:alias)

+1

<Steven> +1

<manu> +1

<Benjamin> +1

<Knud> +1

<ShaneM> +1

<markbirbeck> -1

steven: mark, do you oppose it

mark: if 'one of the possible mechanism would be rdfa'
... I think we can still have that discussion

manu: we had a bit of discussions with that wording and we had a general discussion based on that

<manu> RESOLVED: Support expressing the RDFa Profile document in RDFa (for example: rdfa:prefix/rdfa:keyword, or rdfa:alias)

manu: looking at the proposal and the +1-s I would resolve it and we can have a discussion at a later stage

<manu> PROPOSAL: Provide an alternate mechanism to express mappings that does not depend on xmlns: (for example: @token, @vocab or @map)

+1

<manu> +1

<Benjamin> +1

<Knud> +1

<Steven> -1

<markbirbeck> +1

ivan: same question to steven... does he oppose or can live with it?

steven: I was not sure whether I should say -1 or 0, an alternate means 'as well as'

<ShaneM> +1

manu: this is really for languages without xmlns:
... and html5 is debatable, but the html wg folks are claiming so
... the vast majority of our arguments revolved around that
... let us assume that there are languages that do not have xmlns:
... for them this makes it easier

<ShaneM> Moreover using xmlns pollutes the namespaces of a parser unnecessarily.

Steven: I do not agree that html5 does not fall into this category

<manu> RESOLVED: Provide an alternate mechanism to express mappings that does not depend on xmlns: (for example: @token, @vocab or @map)

ivan: what about deprecating xmlns?

xmlns: deprecation in RDFa 1.1

ivan: it is in the current version of the rdfa core

<manu> +1 for deprecation of xmlns:

<Steven> -1 for deprecation

<manu> Ivan: I can live with deprecation of xmlns:

<manu> Ivan: we need a resolution for this

shane: I did off-line doing this unilateraly
... I agree that this should be accepted by the wg
... having two is confusing

manu: the reason I thought we would be going
... the issue is confusing having two of them
... we had that discussion before

<Steven> I disagree more strongly on this one than the last

manu: we probably would have done differently

steven: I am against deprecating it
... I do not like breaking backward compatibility

manu: it does not
... deprecation means a strong a signal not to use

shane: technically it means it is not removed yet but it can be
... steven, if it said 'prefix is preferred, is that fine'?

steven: yes

mark: that means there is a decision to remove it
... we have to send a strong signal
... I do not agree that we would have done it differently
... at the time we used what w3c had an emphasis on at the time

<ShaneM> +1 to marks concern

<Zakim> manu, you wanted to clarify "we'd do it differently"

<Steven> +1 to Mark

<Knud> "xmlns is discouraged"?

<manu> is my audio breaking up?

<markbirbeck> +1 to Knud

PROPOSED: the FPWD should say something like "prefix is preferred" but not explicitly deprecate xmlns

PROPOSAL: the FPWD should say something like "prefix is preferred" but not explicitly deprecate xmlns

<ShaneM> +1

<manu> +1

+1

<Knud> +1

<Benjamin> +1

<Steven> I can live with that

<markbirbeck> 0

<manu> PROPOSAL: Remove mention of "xmlns: is deprecated" from the RDFa Core 1.1 FPWD

<manu> +1

+1

<markbirbeck> +1

<Knud> +1

<Benjamin> +1

<Steven> +1

RESOLUTION: Remove mention of "xmlns: is deprecated" from the RDFa Core 1.1 FPWD

<ShaneM> +1

Resolve to publish RDFa Core 1.1 and XHTML+RDFa 1.1 FPWD

manu: shane, an overview?

shane: as far as can see, modulo pubrules, the document is in agreement with the resolutions of the group
... fpwd does not have to be perfect
... xhtml did not have the same review than core, but that is all right, there is nothing there:-)
... i have concerns about the core
... as soon as we put it out to the public, we will have the public reacting

<ShaneM> http://www.w3.org/2010/02/rdfa/drafts/

<ShaneM> http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-core-20100414/

<ShaneM> http://www.w3.org/2010/02/rdfa/drafts/2010/ED-xhtml-rdfa-20100413/

<manu> PROPOSAL: Publish RDFa Core 1.1 as First Public Working Draft

<manu> Ivan: Are we going to publish RDFa DOM API now as well?

<manu> Ivan: I think people might misunderstand that publishing RDFa DOM API at a later date as something negative.

<manu> Ivan: I'm concerned that people may think we're not concerned about the RDFa DOM API

mark: I can understand where you get Ivan
... but I disagree
... the audience to this spec is very different
... my feeling is that the rdfa core and the xhtml will go unnoticed
... but the rdfa itself is the story
... however the dom api is a different audience
... we really think we should aim at the html authors

<Zakim> manu, you wanted to discuss RDFa DOM API publication

manu: I agree with mark
... i do not want us to get into mind set where we think that the different specs are tied together
... we should not create a binding among them
... suppose we get all of ivan's fears
... we have to have to courage to take the heat
... we are not talking about pushing the dom api by a couple of week
... if those weeks end up with nasty remarks
... we will publish the api document soon enough

<Knud> s/by a couple of weeks/by a couple of months

<markbirbeck> Fair point Ivan. I was bending the stick too far. :)

<Knud> argh

<manu> Ivan: I hope I'm being paranoid - and I wouldn't object to FPWD.

s/by couple of months/by a couple of weeks/

<markbirbeck> @Knud: We're only editing the record, not people's opinions!

<manu> Ivan: I think these are the same audiences - we've changed some pretty major stuff.

<manu> PROPOSAL: Publish RDFa Core 1.1 as First Public Working Draft

<manu> +1

+0.5

<markbirbeck> +1

<Benjamin> +1

<Knud> +1

<ShaneM> +1

<markbirbeck> :)

<Steven> +1

<manu> RESOLVED: Publish RDFa Core 1.1 as First Public Working Draft

<manu> PROPOSAL: Publish XHTML+RDFa 1.1 as First Public Working Draft

<manu> +1

<Steven> +1

<Benjamin> +1

<markbirbeck> +1

<Knud> +1

+0.5 (just to be consistent)

<markbirbeck> I was wondering what you'd do. :)

<ShaneM> +1

<manu> RESOLVED: Publish XHTML+RDFa 1.1 as First Public Working Draft

clap clap clap

wohooo

etc

<markbirbeck> Nice work Shane!

rdfa dom api

manu: I have not put the api on the focus on the agendas
... we are not prepared to publish already
... mark and and I had discussion on how to improve
... what we want to do is to focus solely on the dom api for the coming 2 weeks

<Benjamin> Current version of the RDFa DOM API document: http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/

mark: apologize for causing delay, I was away with no internet connection...

<Benjamin> And the latest version of the Javascript prototype: http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/rdfa_dom_api.js

mark: the key issue I am trying to push this towards
... we should give people an api to select the elements of the dom that resulted in a triple in the triple store
... I put something up today for us to discuss

manu: the concern I had is that I cannot implement that in ff using the parser
... i know we are talking about an rdfa api
... but it will be very difficult to implement that for implementers
... i do not know how to implement that in c and c++

mark: i think it is pretty easy

manu: i should see some code
... if we cannot implement it in the c and c++ then it is easy

mark: this raises the question what we want to achieve with this api
... just querying triples is not really useful

manu: that is not what i mean; if we want people to write ff extensions that modify the dom and give them an extra methods
... this is usually done is c and c++, mainly with @profile means this is the way to be done
... I do not think you can do it in pure javascript
... i do not care about, say, redland
... it is the restrictions of ff and chrome that puts on developers

mark: if we want to do something for the browser we have to see what is useful

<manu> +1 to what Mark just said.

mark: we may need an additional thing in the api
... maybe we need some events that get passed
... we have to try to solve this rather than drop it

manu: with that said, do you have examples of extending the Document object in FF not using javascript and not something else>?

markbirbeck: we had all kinds of things experimented with in our xforms work, there are lots of stuffs we are looking at

manu: are you opposed getting just triples in javascript?

markbirbeck: i do not have a problem with some kind of layering
... eg in sparql you have the notion of projection
... the result is the set of results with all kinds of properties
... you get back objects
... that is natural for js programmers

<Benjamin> The current API version may be easily extended to query DOM nodes with certain RDFa content.

<Zakim> markbirbeck, you wanted to apologise for causing delay on DOM API.

markbirbeck: i have not looked at other languages, we may have a language specific holes where objects can be used
... and languages should fill that in
... but all objects have a pointer at that element where the triple comes from
... we get both the semantics and the element that produced that

<Benjamin> -1 to Ivans proposal

<manu> Ivan: We don't have to provide a full implementation when doing FPWD

Benjamin: when you look at the document you can see that you cannot publish it
... I think we should reach a concensus about the general style of the document
... we should get a feeling for what the api would look like
... add mark's proposal to this and see how it works together

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

manu: mark, what would help us most is to give us examples
... see how we can have this happen

meeting adjurned

<Knud> +1 to what Shane just said

<markbirbeck> +1.5

<markbirbeck> (I'm using up the bits that Ivan didn't use. :))

<ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/that are not tied/are tied/
FAILED: s/by a couple of weeks/by a couple of months/
FAILED: s/by couple of months/by a couple of weeks/
Found ScribeNick: ivan
Inferring Scribes: ivan
Default Present: Benjamin, manu, Ivan, knud, markbirbeck, Steven, ShaneM
Present: Ivan Steven MarkB Benjamin
Regrets: BenA Toby
Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Apr/0062.html
Found Date: 15 Apr 2010
Guessing minutes URL: http://www.w3.org/2010/04/15-rdfa-minutes.html
People with action items: