None.
14:59:25 <RRSAgent> logging to http://www.w3.org/2011/01/13-rdfa-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2011/01/13-rdfa-irc ←
14:59:28 <trackbot> RRSAgent, make logs world
Trackbot IRC Bot: RRSAgent, make logs world ←
14:59:30 <trackbot> Zakim, this will be 7332
Trackbot IRC Bot: Zakim, this will be 7332 ←
14:59:31 <trackbot> Meeting: RDFa Working Group Teleconference
14:59:31 <trackbot> Date: 13 January 2011
14:59:39 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 1 minute
Zakim IRC Bot: ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 1 minute ←
14:59:41 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0029.html
14:59:46 <manu> Chair: Manu
15:00:07 <manu> Present: Benjamin, Ivan, Manu, Nathan, ShaneM, Steven
15:00:07 <manu> Regrets: MarkB
15:00:47 <Zakim> SW_RDFa()10:00AM has now started
Zakim IRC Bot: SW_RDFa()10:00AM has now started ←
15:00:54 <Zakim> +??P22
Zakim IRC Bot: +??P22 ←
15:01:01 <webr3> Zakim, I am ?
Nathan Rixham: Zakim, I am ? ←
15:01:01 <Zakim> +webr3; got it
Zakim IRC Bot: +webr3; got it ←
15:01:09 <Zakim> +manu
Zakim IRC Bot: +manu ←
15:01:13 <ivan> zakim, dial ivan-voip
Ivan Herman: zakim, dial ivan-voip ←
15:01:13 <Zakim> ok, ivan; the call is being made
Zakim IRC Bot: ok, ivan; the call is being made ←
15:01:15 <Zakim> +Ivan
Zakim IRC Bot: +Ivan ←
15:01:33 <webr3> scribenick: Nathan
(Scribe set to Nathan Rixham)
15:01:42 <Zakim> +Benjamin
Zakim IRC Bot: +Benjamin ←
15:02:26 <webr3> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0052.html
15:03:22 <manu> zakim, who is on the phone?
Manu Sporny: zakim, who is on the phone? ←
15:03:22 <Zakim> On the phone I see webr3, manu, Ivan, Benjamin
Zakim IRC Bot: On the phone I see webr3, manu, Ivan, Benjamin ←
15:05:09 <manu> zakim, who is on the phone?
Manu Sporny: zakim, who is on the phone? ←
15:05:09 <Zakim> On the phone I see webr3, manu, Ivan, Benjamin, ShaneM
Zakim IRC Bot: On the phone I see webr3, manu, Ivan, Benjamin, ShaneM ←
15:05:34 <webr3> Manu: let's go ahead and start, any additions / changes to the agenda?
Manu Sporny: let's go ahead and start, any additions / changes to the agenda? ←
15:05:46 <manu> Topic: ISSUE-60: XMLLiteral context preservation
15:05:55 <manu> http://www.w3.org/2010/02/rdfa/track/issues/60
Manu Sporny: http://www.w3.org/2010/02/rdfa/track/issues/60 ←
15:06:27 <webr3> Manu: there are a number of things we can do to address this, some complicated
Manu Sporny: there are a number of things we can do to address this, some complicated ←
15:07:00 <webr3> ... all we need to do is preserve values in xmlns: and in no particular order, is that correct?
... all we need to do is preserve values in xmlns: and in no particular order, is that correct? ←
15:07:04 <ShaneM> The text currently reads:
Shane McCarron: The text currently reads: ←
15:07:04 <ShaneM> In order to maintain maximum portability of this literal, any children of the current node that are elements must have the current in scope profiles, default vocabulary, prefix mappings, and XML namespace declarations (if any) declared on the serialized element using their respective attributes. Since the child element node could also declare new prefix mappings or XML namespaces, t
Shane McCarron: In order to maintain maximum portability of this literal, any children of the current node that are elements must have the current in scope profiles, default vocabulary, prefix mappings, and XML namespace declarations (if any) declared on the serialized element using their respective attributes. Since the child element node could also declare new prefix mappings or XML namespaces, t ←
15:07:37 <webr3> Ivan: in my implementation, I can produce all the xml statements, are definitions from within a prefix allowed?
Ivan Herman: in my implementation, I can produce all the xml statements, are definitions from within a prefix allowed? ←
15:07:57 <webr3> Manu: some @prefix values may override xmlns values
Manu Sporny: some @prefix values may override xmlns values ←
15:08:27 <webr3> Ivan: its really quite simple because all of this goes in to a single table
Ivan Herman: its really quite simple because all of this goes in to a single table ←
15:08:47 <webr3> Ivan: if i forget about the xmlliteral then I can do that, perfectly valid and works
Ivan Herman: if i forget about the xmlliteral then I can do that, perfectly valid and works ←
15:09:16 <webr3> Manu: they need to be kept seperate for case insensitive searching
Manu Sporny: they need to be kept seperate for case insensitive searching ←
15:09:41 <webr3> shane: you can't put everything in lowercase
Shane McCarron: you can't put everything in lowercase ←
15:10:21 <webr3> shane: lets focus, i think it makes the msot sense to tell people to maintain different tables, regardless - did we agree that we weren't going to do what is currently in the draft
Shane McCarron: lets focus, i think it makes the msot sense to tell people to maintain different tables, regardless - did we agree that we weren't going to do what is currently in the draft ←
15:10:55 <webr3> Manu: i thought we decided against the text in the draft
Manu Sporny: i thought we decided against the text in the draft ←
15:11:30 <webr3> Ivan: i believe the core of what i said is true, it forces me to keep things seperate that at some point are not seperated
Ivan Herman: i believe the core of what i said is true, it forces me to keep things seperate that at some point are not seperated ←
15:12:25 <manu> This is the issue: xmlns:FOObar vs xmlns:foobar
Manu Sporny: This is the issue: xmlns:FOObar vs xmlns:foobar ←
15:13:12 <manu> prefix="FOObar: ..."
Manu Sporny: prefix="FOObar: ..." ←
15:13:24 <webr3> Manu: we need to keep these seperate because prefixes defined by xmlns are case insensitive, prefixes in @prefix are case sensitive
Manu Sporny: we need to keep these seperate because prefixes defined by xmlns are case insensitive, prefixes in @prefix are case sensitive ←
15:13:40 <webr3> shane: why? (are they case sensitive)
Shane McCarron: why? (are they case sensitive) ←
15:13:55 <manu> so - xmlns:Agent="..."
Manu Sporny: so - xmlns:Agent="..." ←
15:14:10 <webr3> shane: they should not be case sensitive in @prefix
Shane McCarron: they should not be case sensitive in @prefix ←
15:14:12 <manu> is the same as - term: "agent" => ...
Manu Sporny: is the same as - term: "agent" => ... ←
15:14:13 <webr3> Ivan: they should not be case sensitive in @prefix
Ivan Herman: they should not be case sensitive in @prefix ←
15:14:42 <manu> prefix="Agent: ... , agent: ..."
Manu Sporny: prefix="Agent: ... , agent: ..." ←
15:14:56 <webr3> Ivan: prefix and term are different
Ivan Herman: prefix and term are different ←
15:15:07 <webr3> Manu: there's another issue which means they are not so different
Manu Sporny: there's another issue which means they are not so different ←
15:15:39 <manu> Agent => Class, agent => property
Manu Sporny: Agent => Class, agent => property ←
15:15:55 <webr3> Ivan: term and prefixes are different
Ivan Herman: term and prefixes are different ←
15:16:06 <webr3> shane: prefixes are only prefixes if they are followed by a colon
Shane McCarron: prefixes are only prefixes if they are followed by a colon ←
15:16:29 <webr3> Manu: mark and I believe prefixes are valid without a colon, used as tokens
Manu Sporny: mark and I believe prefixes are valid without a colon, used as tokens ←
15:16:40 <manu> prefix="Agent: ... , agent: ..."
Manu Sporny: prefix="Agent: ... , agent: ..." ←
15:17:02 <Steven> zakim, dial steven-617
Steven Pemberton: zakim, dial steven-617 ←
15:17:02 <Zakim> ok, Steven; the call is being made
Zakim IRC Bot: ok, Steven; the call is being made ←
15:17:03 <Zakim> +Steven
Zakim IRC Bot: +Steven ←
15:17:07 <ShaneM> The text current reads: Otherwise, if a CURIE consists of a non-empty prefix and reference, and if there is an in-scope mapping for prefix (when compared case-insensitively), then the URI is created by using that mapping, and concatenating it with the reference.
Shane McCarron: The text current reads: Otherwise, if a CURIE consists of a non-empty prefix and reference, and if there is an in-scope mapping for prefix (when compared case-insensitively), then the URI is created by using that mapping, and concatenating it with the reference. ←
15:17:53 <Steven> zakim, who is on the phone?
Steven Pemberton: zakim, who is on the phone? ←
15:17:53 <Zakim> On the phone I see webr3, manu, Ivan, Benjamin, ShaneM, Steven
Zakim IRC Bot: On the phone I see webr3, manu, Ivan, Benjamin, ShaneM, Steven ←
15:18:02 <webr3> Ivan: I worry that we may over-complicate rdfa
Ivan Herman: I worry that we may over-complicate rdfa ←
15:18:20 <ShaneM> (to be clear, the xmlns syntax is NOT case insensitive - stupid browser implementations are)
Shane McCarron: (to be clear, the xmlns syntax is NOT case insensitive - stupid browser implementations are) ←
15:18:23 <webr3> Ivan: prefix and xmlns should behave the same
Ivan Herman: prefix and xmlns should behave the same ←
15:18:40 <manu> prefix="Agent: ... , agEnT: ..."
Manu Sporny: prefix="Agent: ... , agEnT: ..." ←
15:19:01 <webr3> Ivan: yes case insensitive
Ivan Herman: yes case insensitive ←
15:19:30 <webr3> shane: it leads to more room for error
Shane McCarron: it leads to more room for error ←
15:19:36 <webr3> general agreement
general agreement ←
15:20:46 <webr3> Manu: would we then have to encode all @prefix and @xmlns in XMLLiterals
Manu Sporny: would we then have to encode all @prefix and @xmlns in XMLLiterals ←
15:21:19 <webr3> Ivan: we should not go out of our way for an infrequently used feature
Ivan Herman: we should not go out of our way for an infrequently used feature ←
15:21:34 <webr3> Manu: Drupal 7 does this, it is quite common, 30k sites+
Manu Sporny: Drupal 7 does this, it is quite common, 30k sites+ ←
15:22:46 <webr3> Ivan: if we map prefixes on to xmlns in the literals then it will all work
Ivan Herman: if we map prefixes on to xmlns in the literals then it will all work ←
15:22:51 <webr3> Manu: seems a little strange
Manu Sporny: seems a little strange ←
15:23:05 <webr3> shane: i thought you were arguing that we sould only put xmlns on xmlliterals
Shane McCarron: i thought you were arguing that we sould only put xmlns on xmlliterals ←
15:23:09 <webr3> Manu: true
Manu Sporny: true ←
15:23:20 <webr3> shane: doesn't that conflict w/ drupal use case
Shane McCarron: doesn't that conflict w/ drupal use case ←
15:23:42 <webr3> Manu: are we making a decision to not allow deep processing of XMLLiterals
Manu Sporny: are we making a decision to not allow deep processing of XMLLiterals ←
15:24:44 <webr3> Manu: we can say 1: the only things that get preserved are xmlns statements (are prefixes included)
Manu Sporny: we can say 1: the only things that get preserved are xmlns statements (are prefixes included) ←
15:25:12 <webr3> Manu: or 2: we do not support deep processing of xmlliteral (w/ terms, profiles etc too)
Manu Sporny: or 2: we do not support deep processing of xmlliteral (w/ terms, profiles etc too) ←
15:26:03 <Steven> rrsagent, make minutes
Steven Pemberton: rrsagent, make minutes ←
15:26:03 <RRSAgent> I have made the request to generate http://www.w3.org/2011/01/13-rdfa-minutes.html Steven
RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2011/01/13-rdfa-minutes.html Steven ←
15:26:26 <webr3> Ivan: it complicates implementations in a way I'm not happy about, but..
Ivan Herman: it complicates implementations in a way I'm not happy about, but.. ←
15:26:45 <webr3> Manu: if we were to preserve everything it would complicate things even more
Manu Sporny: if we were to preserve everything it would complicate things even more ←
15:26:59 <webr3> Ivan: i can live with that (2)
Ivan Herman: i can live with that (2) ←
15:27:17 <webr3> Ivan: xmlns are pushed out to XMLLiteral and nothing else
Ivan Herman: xmlns are pushed out to XMLLiteral and nothing else ←
15:27:46 <webr3> Manu: does that include things defined in @prefix or not?
Manu Sporny: does that include things defined in @prefix or not? ←
15:27:56 <webr3> manu: any objections?
Manu Sporny: any objections? ←
15:28:32 <webr3> Manu: let's push it out to the list rather than strawpoll
Manu Sporny: let's push it out to the list rather than strawpoll ←
15:29:14 <webr3> Ivan: we have to answer Gregg Kellogg w/ proposal and ask if they are happy with the resolution, will be in tracker
Ivan Herman: we have to answer Gregg Kellogg w/ proposal and ask if they are happy with the resolution, will be in tracker ←
15:29:21 <webr3> no objections heard
no objections heard ←
15:29:22 <manu> Topic: ISSUE-62: @prefix processing order
15:29:31 <manu> http://www.w3.org/2010/02/rdfa/track/issues/62
Manu Sporny: http://www.w3.org/2010/02/rdfa/track/issues/62 ←
15:29:46 <manu> @prefix="a: http://a.b a: http://c.d"
Manu Sporny: @prefix="a: http://a.b a: http://c.d" ←
15:29:48 <manu> will end in a->http://c.d
Manu Sporny: will end in a->http://c.d ←
15:30:19 <webr3> Manu: order of prefix evaluation?
Manu Sporny: order of prefix evaluation? ←
15:31:02 <webr3> shane: prefixes are ordered from left to right, in the sequence, section 7.5 ..
Shane McCarron: prefixes are ordered from left to right, in the sequence, section 7.5 .. ←
15:31:29 <webr3> Ivan: need to specify this, no preference for which order
Ivan Herman: need to specify this, no preference for which order ←
15:32:27 <webr3> Ivan: problem I have is that we have decided that the processing order of @profile is specified, so @prefix should probably be defined too, and match @profile
Ivan Herman: problem I have is that we have decided that the processing order of @profile is specified, so @prefix should probably be defined too, and match @profile ←
15:33:34 <webr3> shane: @profile is age old and should be defined as @profile always has been - prefix does not have to be the same
Shane McCarron: @profile is age old and should be defined as @profile always has been - prefix does not have to be the same ←
15:33:58 <webr3> Ivan: within the same specification, they should be ordered the same to save errors
Ivan Herman: within the same specification, they should be ordered the same to save errors ←
15:34:03 <webr3> Manu: i agree
Manu Sporny: i agree ←
15:34:57 <webr3> Manu: seems like last defined should win in presendence ( @prefix="a: http://a.b a: http://c.d" )
Manu Sporny: seems like last defined should win in presendence ( @prefix="a: http://a.b a: http://c.d" ) ←
15:35:28 <webr3> Manu: where does it say in html4 how @profile values are given presedence
Manu Sporny: where does it say in html4 how @profile values are given presedence ←
15:35:42 <webr3> shane: common usage.. comes from css? some comment?
Shane McCarron: common usage.. comes from css? some comment? ←
15:35:52 <webr3> Ivan: i think it has something to do with css
Ivan Herman: i think it has something to do with css ←
15:36:02 <ShaneM> html4 says: profile = uri [CT] This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.
Shane McCarron: html4 says: profile = uri [CT] This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data. ←
15:36:23 <webr3> Manu: people are used to last declared wins
Manu Sporny: people are used to last declared wins ←
15:36:29 <webr3> Ivan: i agree
Ivan Herman: i agree ←
15:37:25 <webr3> Manu: shall we propose both profile and prefix are declared left to right, and last declared wins.
Manu Sporny: shall we propose both profile and prefix are declared left to right, and last declared wins. ←
15:37:36 <manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010May/0134.html
Manu Sporny: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010May/0134.html ←
15:40:23 <webr3> Ivan: it's more natural to say, processed from left to right, and has to be clearly documented
Ivan Herman: it's more natural to say, processed from left to right, and has to be clearly documented ←
15:40:26 <ShaneM> rdfa core says: If any conflict arises between two RDFa Profiles associated with URIs in the @profile value, the declaration from the RDFa Profile associated with the left-most URI takes precedence.
Shane McCarron: rdfa core says: If any conflict arises between two RDFa Profiles associated with URIs in the @profile value, the declaration from the RDFa Profile associated with the left-most URI takes precedence. ←
15:40:28 <manu> Toby explained that the XMDP approach is to say that profiles appearing first in the list are /more significant/ than those coming later. That already points to a way of conceptualising this that is 'left-to-right'.
Manu Sporny: Toby explained that the XMDP approach is to say that profiles appearing first in the list are /more significant/ than those coming later. That already points to a way of conceptualising this that is 'left-to-right'. ←
15:40:41 <Steven> I propose we say "in document order" and not "left-to-right"
Steven Pemberton: I propose we say "in document order" and not "left-to-right" ←
15:41:03 <webr3> Manu: i don't mind..
Manu Sporny: i don't mind.. ←
15:41:34 <webr3> Steven: "in document order" is what we say
Steven Pemberton: "in document order" is what we say ←
15:41:54 <webr3> shane: or "beginning to end" because languages have different directions
Shane McCarron: or "beginning to end" because languages have different directions ←
15:42:27 <webr3> Ivan: commenter is happy
Ivan Herman: commenter is happy ←
15:43:05 <webr3> all on call are happy with defining prefix and profile should follow in the same order, preference going to in document order
all on call are happy with defining prefix and profile should follow in the same order, preference going to in document order ←
15:44:00 <webr3> Manu: no objections?
Manu Sporny: no objections? ←
15:44:37 <webr3> Ivan: add a note to say right-to-left is more complicated than left-to-right
Ivan Herman: add a note to say right-to-left is more complicated than left-to-right ←
15:44:43 <manu> Implementation experience states that processing right to left is far more complicated than left-to-right
Manu Sporny: Implementation experience states that processing right to left is far more complicated than left-to-right ←
15:44:44 <manu> ISSUE-62 overturns decision made in ISSUE-23
Manu Sporny: ISSUE-62 overturns decision made in ISSUE-23 ←
15:44:49 <manu> Topic: ISSUE-64: Add rel=describedby to the XHTML vocab
15:44:57 <manu> http://www.w3.org/2010/02/rdfa/track/issues/64
Manu Sporny: http://www.w3.org/2010/02/rdfa/track/issues/64 ←
15:45:21 <webr3> Manu: i think that's fine
Manu Sporny: i think that's fine ←
15:45:56 <webr3> Ivan: there was a huge discussion about this on public lists, and sem web community "discovered" described by and that it should be used
Ivan Herman: there was a huge discussion about this on public lists, and sem web community "discovered" described by and that it should be used ←
15:46:19 <webr3> Ivan: we may have a seperate question about default profile - still undecided w/ an issue..
Ivan Herman: we may have a seperate question about default profile - still undecided w/ an issue.. ←
15:46:52 <webr3> Ivan: i think we decided we need a profile, not what it will contain
Ivan Herman: i think we decided we need a profile, not what it will contain ←
15:47:14 <webr3> Manu: yes issues are how do we decided what goes in, how it changes etc etc
Manu Sporny: yes issues are how do we decided what goes in, how it changes etc etc ←
15:47:31 <webr3> Ivan: I raised that because it would have to be in both profiles (xhtml and html)
Ivan Herman: I raised that because it would have to be in both profiles (xhtml and html) ←
15:48:32 <webr3> Manu: everyone okay with adding?
Manu Sporny: everyone okay with adding? ←
15:48:43 <webr3> Scribe notes that everyone thinks it's a good idea
Scribe notes that everyone thinks it's a good idea ←
15:48:49 <webr3> Manu: any objections
Manu Sporny: any objections ←
15:48:51 <webr3> none heard.
none heard. ←
15:48:51 <manu> Topic: ISSUE-65: Michael Hausenblas' LC Comments
15:49:28 <webr3> http://www.w3.org/2010/02/rdfa/track/issues/65
http://www.w3.org/2010/02/rdfa/track/issues/65 ←
15:49:44 <manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/0025.html
Manu Sporny: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/0025.html ←
15:50:05 <Zakim> -manu
Zakim IRC Bot: -manu ←
15:50:20 <Zakim> -ShaneM
Zakim IRC Bot: -ShaneM ←
15:50:38 <Zakim> +ShaneM
Zakim IRC Bot: +ShaneM ←
15:50:53 <Zakim> +manu
Zakim IRC Bot: +manu ←
15:51:17 <webr3> Ivan: it looks like Michaels comments are editorial
Ivan Herman: it looks like Michaels comments are editorial ←
15:51:40 <ivan> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/att-0031/RDFa_Object_Resolution.pdf
Ivan Herman: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/att-0031/RDFa_Object_Resolution.pdf ←
15:52:20 <webr3> Ivan: Michael suggests a diagram, I've sketched one out
Ivan Herman: Michael suggests a diagram, I've sketched one out ←
15:53:46 <webr3> Ivan: shane do you think this is something we should use, or will it over-complicate the document?
Ivan Herman: shane do you think this is something we should use, or will it over-complicate the document? ←
15:54:06 <webr3> shane: still unsure.. let's discuss as it's editorial
Shane McCarron: still unsure.. let's discuss as it's editorial ←
15:54:12 <webr3> Ivan: agreement
Ivan Herman: agreement ←
15:54:25 <webr3> Ivan: can you all go through the diagram to double check
Ivan Herman: can you all go through the diagram to double check ←
15:54:59 <webr3> consensus - all editorial issues, make a decision about the diagram and add + respond to Michael
consensus - all editorial issues, make a decision about the diagram and add + respond to Michael ←
15:55:34 <ivan> -> http://www.w3.org/2011/01/rdfa-wg-charter.html new charter
Ivan Herman: -> http://www.w3.org/2011/01/rdfa-wg-charter.html new charter ←
15:58:08 <manu> Charter looks good AFAICT, perhaps change the name of the WG
Manu Sporny: Charter looks good AFAICT, perhaps change the name of the WG ←
Formatted by CommonScribe