Chatlog 2011-01-13

From RDFa Working Group Wiki
Jump to: navigation, search

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
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:
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:
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>
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 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>
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>
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>
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>
15:49:44 <manu>
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>
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> -> new charter
15:58:08 <manu> Charter looks good AFAICT, perhaps change the name of the WG