Warning:
This wiki has been archived and is now read-only.
Chatlog 2011-01-13
From RDFa Working Group Wiki
See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.
14:59:25 <RRSAgent> RRSAgent has joined #rdfa 14:59:25 <RRSAgent> logging to http://www.w3.org/2011/01/13-rdfa-irc 14:59:28 <trackbot> RRSAgent, make logs world 14:59:29 <Zakim> Zakim has joined #rdfa 14:59:30 <trackbot> 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 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 15:00:54 <Zakim> +??P22 15:01:01 <webr3> Zakim, I am ? 15:01:01 <Zakim> +webr3; got it 15:01:09 <Zakim> +manu 15:01:13 <ivan> zakim, dial ivan-voip 15:01:13 <Zakim> ok, ivan; the call is being made 15:01:15 <Zakim> +Ivan 15:01:33 <webr3> scribenick: Nathan 15:01:42 <Zakim> +Benjamin 15:01:52 <ShaneM> ShaneM has joined #rdfa 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? 15:03:22 <Zakim> On the phone I see webr3, manu, Ivan, Benjamin 15:05:09 <manu> zakim, who is on the phone? 15:05:09 <Zakim> 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? 15:05:46 <manu> Topic: ISSUE-60: XMLLiteral context preservation 15:05:55 <manu> 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 15:07:00 <webr3> ... 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: 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 15:07:37 <webr3> Ivan: 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 15:08:27 <webr3> Ivan: 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 15:09:16 <webr3> Manu: they need to be kept seperate for case insensitive searching 15:09:41 <webr3> shane: 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 15:10:55 <webr3> Manu: 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 15:12:25 <manu> This is the issue: xmlns:FOObar vs xmlns:foobar 15:13:12 <manu> 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 15:13:40 <webr3> shane: why? (are they case sensitive) 15:13:55 <manu> so - xmlns:Agent="..." 15:14:10 <webr3> shane: they should not be case sensitive in @prefix 15:14:12 <manu> is the same as - term: "agent" => ... 15:14:13 <webr3> Ivan: they should not be case sensitive in @prefix 15:14:42 <manu> prefix="Agent: ... , agent: ..." 15:14:56 <webr3> Ivan: prefix and term are different 15:15:07 <webr3> Manu: there's another issue which means they are not so different 15:15:39 <manu> Agent => Class, agent => property 15:15:55 <webr3> Ivan: term and prefixes are different 15:16:06 <webr3> shane: 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 15:16:40 <manu> prefix="Agent: ... , agent: ..." 15:16:53 <Steven> Steven has joined #rdfa 15:17:02 <Steven> zakim, dial steven-617 15:17:02 <Zakim> ok, Steven; the call is being made 15:17:03 <Zakim> +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. 15:17:53 <Steven> zakim, who is on the phone? 15:17:53 <Zakim> On the phone I see webr3, manu, Ivan, Benjamin, ShaneM, Steven 15:18:02 <webr3> Ivan: 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) 15:18:23 <webr3> Ivan: prefix and xmlns should behave the same 15:18:40 <manu> prefix="Agent: ... , agEnT: ..." 15:19:01 <webr3> Ivan: yes case insensitive 15:19:30 <webr3> shane: it leads to more room for error 15:19:36 <webr3> general agreement 15:20:46 <webr3> Manu: 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 15:21:34 <webr3> Manu: 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 15:22:51 <webr3> Manu: seems a little strange 15:23:05 <webr3> shane: i thought you were arguing that we sould only put xmlns on xmlliterals 15:23:09 <webr3> Manu: true 15:23:20 <webr3> shane: 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 15:24:44 <webr3> Manu: 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) 15:26:03 <Steven> 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 15:26:26 <webr3> Ivan: 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 15:26:59 <webr3> Ivan: i can live with that (2) 15:27:17 <webr3> Ivan: xmlns are pushed out to XMLLiteral and nothing else 15:27:46 <webr3> Manu: does that include things defined in @prefix or not? 15:27:56 <webr3> manu: any objections? 15:28:32 <webr3> Manu: 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 15:29:21 <webr3> 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 15:29:46 <manu> @prefix="a: http://a.b a: http://c.d" 15:29:48 <manu> will end in a->http://c.d 15:30:19 <webr3> Manu: order of prefix evaluation? 15:31:02 <webr3> shane: 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 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 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 15:33:58 <webr3> Ivan: within the same specification, they should be ordered the same to save errors 15:34:03 <webr3> Manu: i agree 15:34:57 <webr3> Manu: 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 15:35:42 <webr3> shane: common usage.. comes from css? some comment? 15:35:52 <webr3> Ivan: 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. 15:36:23 <webr3> Manu: people are used to last declared wins 15:36:29 <webr3> Ivan: i agree 15:37:25 <webr3> Manu: 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 15:40:23 <webr3> Ivan: 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. 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'. 15:40:41 <Steven> I propose we say "in document order" and not "left-to-right" 15:41:03 <webr3> Manu: i don't mind.. 15:41:34 <webr3> Steven: "in document order" is what we say 15:41:54 <webr3> shane: or "beginning to end" because languages have different directions 15:42:27 <webr3> Ivan: 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 15:44:00 <webr3> Manu: no objections? 15:44:37 <webr3> Ivan: 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 15:44:44 <manu> 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 15:45:21 <webr3> Manu: 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 15:46:19 <webr3> Ivan: 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 15:47:14 <webr3> Manu: 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) 15:48:32 <webr3> Manu: everyone okay with adding? 15:48:43 <webr3> Scribe notes that everyone thinks it's a good idea 15:48:49 <webr3> Manu: any objections 15:48:51 <webr3> 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 15:49:44 <manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/0025.html 15:50:05 <Zakim> -manu 15:50:20 <Zakim> -ShaneM 15:50:38 <Zakim> +ShaneM 15:50:53 <Zakim> +manu 15:51:17 <webr3> Ivan: 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 15:52:20 <webr3> Ivan: 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? 15:54:06 <webr3> shane: still unsure.. let's discuss as it's editorial 15:54:12 <webr3> Ivan: agreement 15:54:25 <webr3> Ivan: 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 15:55:34 <ivan> -> 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 # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000233