Chatlog 2010-05-13

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

13:56:42 <RRSAgent> RRSAgent has joined #rdfa
13:56:42 <RRSAgent> logging to http://www.w3.org/2010/05/13-rdfa-irc
13:57:10 <manu> trackbot, setup meeting
13:57:10 <trackbot> Sorry, manu, I don't understand 'trackbot, setup meeting'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
13:57:26 <manu> trackbot, prepare telecon
13:57:28 <trackbot> RRSAgent, make logs world
13:57:30 <trackbot> Zakim, this will be 7332
13:57:30 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 3 minutes
13:57:31 <trackbot> Meeting: RDFa Working Group Teleconference
13:57:31 <trackbot> Date: 13 May 2010
13:57:47 <manu> Chair: Manu Sporny
13:58:03 <tinkster1> tinkster1 has joined #rdfa
13:58:46 <manu> Present: Manu, Ivan, Toby, Shane
13:58:53 <manu> Regrets: BenA, Steven, Benjamin, MarkB
13:59:54 <Zakim> SW_RDFa()10:00AM has now started
14:00:01 <Zakim> + +1.734.995.aaaa
14:00:13 <manu> zakim, aaaa is manu
14:00:13 <Zakim> +manu; got it
14:00:15 <ivan> zakim, dial ivan-voip
14:00:15 <Zakim> ok, ivan; the call is being made
14:00:16 <Zakim> +Ivan
14:01:14 <Zakim> + +0785583aabb
14:01:24 <tinkster> zakim, aabb is me
14:01:24 <Zakim> +tinkster; got it
14:02:14 <Zakim> +ShaneM
14:02:18 <tinkster> zakim, mute me
14:02:18 <Zakim> tinkster should now be muted
14:02:27 <ivan> scribenick: ivan
14:04:25 <tinkster> zakim, unmute me
14:04:25 <Zakim> tinkster should no longer be muted
14:08:59 <ivan> Topic: Possible new issues from mailing list
14:09:05 <ivan> manu: ivan contacted me off line
14:09:12 <ivan> ... two possible issues
14:09:16 <manu> - not-parsing if @profile cannot be accessed (Jeni's mail)
14:09:18 <manu> - do we need an error reporting mechanism in rdfa
14:09:45 <ivan> manu: anybody who thinks we should not turn these into issues?
14:09:58 <ivan> manu: any other issues that we missed?
14:10:22 <ivan> tinkster: not at the moment
14:10:31 <ivan> manu: we have to document all these well
14:10:46 <ivan> ... if anybody things of any other issues then send a mail to the mailing list
14:10:52 <ivan> ... i will add those two after the call
14:15:29 <ivan> Topic: Review RDFa DOM API Progress
14:15:44 <ivan> manu: mark sent a mail to the list that he does not have anything for us yet
14:16:03 <ivan> ... toby what are your thoughts on the progress?
14:16:11 <ivan> tinkster: i must admit I did not look at it last week...
14:16:17 <ivan> manu: nothing changed
14:16:33 <ivan> tinkster: it is fragmented between a triple space and a resource space apis
14:16:44 <ivan> ... would be good to have a combined version of those two
14:16:57 <ivan> manu: in an extended call last week this is the direction we have decided to go to
14:17:08 <ivan> ... my concern is that the document has not progressed in the past few weeks
14:17:22 <ivan> ... i will volunteer to integerate mark's changes into the dom api 
14:17:29 <ivan> q+
14:17:34 <manu> ack ivan
14:17:37 <ivan> ivan: i agree, 
14:17:53 <manu> Ivan: We have to move on - the writing needs to be in one document, they need to be merged
14:17:56 <Zakim> +[MIT528]
14:18:00 <manu> Ivan: This has been dragging on for way too long.
14:18:58 <dongmei> dongmei has joined #rdfa
14:19:12 <ivan> ShaneM: I am abstaining on that
14:19:25 <ivan> manu: meaning we should really move forwards?
14:20:35 <ivan> manu: I will go ahead
14:20:58 <ivan> tinkster: if you look at triples, the different views are not that disconnected
14:21:12 <ivan> manu: everyone agrees that this is a good thing to have
14:21:17 <ivan> ... i will start this
14:21:25 <ivan> topic: ISSUE-22: Case-sensitive prefixes
14:21:49 <manu> http://www.w3.org/2010/02/rdfa/track/issues/22
14:22:31 <ivan> manu: the problem is that in rdfa1.0 we say that prefixes are case sensitive
14:22:38 <ivan> ShaneM: we just defer to xmlns
14:22:44 <ivan> ... and xmlns is case sensitive
14:23:04 <ivan> manu: in rdfa1.1 i think what we want to say that prefixes must be converted to lowercase
14:23:09 <ivan> ShaneM: and it says that
14:23:19 <ivan> ... and we put it in the errata
14:23:36 <ivan> manu: previously we said use lower case
14:23:45 <ivan> ... now we say convert it
14:23:56 <ShaneM> Section 4.1. Document Conformance - In the future it is 	possible that RDFa will also be defined in the context of HTML. 	Consequently document authors SHOULD use lower-case prefix names 	in order to be compatible with current and potential future 	processors. 
14:24:02 <ivan> q+
14:24:12 <manu> ack ivan
14:24:23 <manu> Ivan: We're still talking about prefixes and not terms, correct?
14:24:51 <manu> Ivan: Do we have a separate issue with terms?
14:24:56 <manu> Manu: I don't think this would apply to terms.
14:25:43 <ivan> ivan: what about HTML5?
14:26:24 <tinkster> in html5, rel and rev values are case-insensitive, unless they contain a colon.
14:26:44 <ivan> manu: why is that?
14:27:11 <ivan> manu: from what I remember, browsers preserve case for @rel and @rev
14:27:36 <ivan> ... we could say that terms that are not in the reserved list (license, etc) are case sensitive
14:28:20 <manu> trackbot, create issue Case-sensitive terms in HTML5
14:28:20 <trackbot> Sorry, manu, I don't understand 'trackbot, create issue Case-sensitive terms in HTML5'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
14:28:41 <manu> trackbot, ISSUE: Case-sensitive terms in HTML5
14:28:41 <trackbot> Sorry, manu, I don't understand 'trackbot, ISSUE: Case-sensitive terms in HTML5'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
14:28:51 <manu> ISSUE: Case-sensitive terms in HTML5
14:28:51 <trackbot> Created ISSUE-24 - Case-sensitive terms in HTML5 ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/24/edit .
14:29:18 <ivan> manu: for xmlns we should have case sensitivity
14:29:26 <ivan> ... as well as for @prefix
14:29:53 <manu> PROPOSAL: For prefixes defined via xmlns: and @prefix, the prefix text should be converted to lowercase by the RDFa Processor.
14:30:04 <ivan> +1
14:30:04 <manu> +1
14:30:06 <ShaneM> +1
14:30:08 <tinkster> +0
14:30:31 <ivan> RESOLVED: For prefixes defined via xmlns: and @prefix, the prefix text should be converted to lowercase by the RDFa Processor.
14:30:34 <ShaneM> Here is what the spec says now:  Mappings are defined via @prefix.              For backward compatibility, some Host Languages may also permit the             definition of mappings via @xmlns. In this case, the value to be mapped is             set by the XML namespace             prefix, and the value to map is the value of the attribute — a URI.              Regardless of how the mapping is declared,              the value to be mapped must be converted to l
14:31:18 <ShaneM>  lower case,              and the URI is not processed in any way; in             particular if it is a relative path it is not resolved             against the current base. Authors should not              use relative paths as the URI.      
14:31:27 <ivan> manu: note on the vote that toby is concerned about backward compatibility issue
14:31:32 <manu> Toby: I'm concerned about the backwards incompatible change, but could go either way on it.
14:31:42 <ivan> topic: ISSUE-19: Default generation of XMLLiterals
14:31:59 <manu> http://www.w3.org/2010/02/rdfa/track/issues/19
14:32:09 <ivan> manu: this is another backward incompatible changes
14:32:33 <ivan> ... by default rdfa1.0 generates xml literal if there is an element within the element being processed
14:33:02 <ivan> ... based on the markup that we have seen lots of people are generating xml literals when they intend plain literal
14:33:51 <ivan> tinkster: there are two related issues (1) do we want to generate xml literals by default (2) do we recursively go down 
14:34:01 <ivan> manu: we have split those into two issues
14:34:10 <ivan> tinkster: i do not have any strong opinion, 
14:34:18 <ivan> ... it is one thing we should consider
14:35:16 <manu> Ivan: This is the one thing that we listed in the charter, so there seems to be consensus that we wanted to address this.
14:35:41 <ivan> ShaneM: i do not have a problem with this, we should have fixed it in the errata
14:36:21 <ivan> manu: the general idea is that then people are adding datatypes they generally do not mark up markup
14:36:34 <ivan> .... i do not think the vast majority of people will try to expose markup on their pages
14:36:46 <ivan> ... and that is where people would use xml literal in their markup
14:36:56 <ivan> ... there is stuff like mathml
14:36:59 <ivan> ... or svg
14:37:03 <ivan> q+
14:37:13 <ivan> ... chemical compounds, etc
14:37:15 <manu> ack ivan
14:37:47 <manu> Ivan: Just to be fair - I see one area where people might want to do that, and that might be multi-lingual things.
14:37:57 <manu> Ivan: That being said, that's not a majority use case.
14:38:18 <manu> Manu: So, Ruby markup?
14:38:55 <manu> Manu: and what we're saying is you can still do that, but you have to do it explicitly datatype="rdf:XMLLiteral"
14:39:09 <manu> Toby: There are plenty of use cases, just not as common as Plain Literals.
14:39:15 <ivan> tinkster: there are use cases, but just not as common
14:40:05 <manu> PROPOSAL: By default RDFa 1.1 should generate Plain Literals even when there are elements in a subtree, unless datatype="rdf:XMLLiteral" is specified.
14:40:25 <manu> Toby: What about datatype="xml"
14:40:56 <ivan> +1
14:40:57 <manu> +1
14:41:01 <tinkster> +1
14:41:12 <ShaneM> +1
14:41:14 <ivan> RESOLVED: By default RDFa 1.1 should generate Plain Literals even when there are elements in a subtree, unless datatype="rdf:XMLLiteral" is specified.
14:41:26 <ivan> q+
14:41:34 <manu> ack ivan
14:41:52 <manu> Ivan: There is a more general thing that we started to discuss - do we have an open issue on default vocabularies and terms?
14:42:31 <manu> Manu: This one http://www.w3.org/2010/02/rdfa/track/issues/11 ?
14:42:52 <manu> Ivan: Not the same issue - Should we have default terms in RDFa Core?
14:43:52 <manu> We also need to consider whether or not there would be default terms in RDFa Core. Things like datatype="xml" instead of needing to specify datatype="rdf:XMLLiteral".
14:44:10 <ivan> (added to issue 11)
14:44:14 <ivan> topic: ISSUE-10: @lang and @xml:lang Processing
14:44:16 <manu> http://www.w3.org/2010/02/rdfa/track/issues/10
14:44:31 <ivan> ShaneM: why is this an issue
14:44:42 <ivan> manu: it is in our queue
14:44:43 <ShaneM> This specification also adds the lang attribute to the I18N  attribute collection as defined in [XHTML-MODULARIZATION11-2e].  The lang attribute is defined in [HTML401]. When this attribute and the xml:lang attribute are specified on the same element, the xml:lang attribute takes precedence.  When both lang and xml:lang are specified on the same element, they should have the same value. 
14:45:10 <ivan> ShaneM: this is already in xhtml+rdfa
14:45:21 <ivan> ... and we should be sure that this is the same as in html5
14:45:23 <ivan> q+
14:45:50 <manu> ack ivan
14:46:16 <ivan> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Feb/0092.html
14:46:58 <manu> http://dev.w3.org/html5/spec/Overview.html#the-lang-and-xml:lang-attributes
14:48:47 <ivan> q+
14:49:02 <manu> Manu: I don't think the HTML5 spec says this... it says ignore xml:lang
14:50:47 <ivan> manu: the problem is when somebody uses both xml:lang and lang with different values, if run as xhtml and in html5 the generated triples will be different
14:50:54 <ivan> ... is this a problem?
14:51:03 <ivan> ... it is a corner corner case
14:51:24 <ivan> ... one way is to put a strong warning in the xhtml+rdfa text about the dangers
14:51:47 <ivan> ... ie, a proposed way forward is to defer to the language
14:51:56 <ivan> ... in xml and xhtml what counts is xml:lang
14:52:01 <ivan> ... in html5 it is lang
14:52:02 <ivan> q+
14:52:06 <manu> ack ivan
14:52:34 <ivan> ShaneM: we do not know what mode we are in
14:52:41 <ivan> manu: we have version
14:52:47 <ivan> ... but people do not want version
14:52:53 <ivan> ... it is a should
14:52:58 <ivan> q_
14:52:59 <ivan> q+
14:53:17 <manu> ack ivan
14:53:20 <ivan> ShaneM: in the absence of an announcement mechanism I would object
14:53:28 <tinkster> q+
14:55:00 <manu> Ivan: My parser figures out what mode to be in by looking at the document type - text/html means HTML5 mode
14:55:12 <manu> ack tinkster
14:55:14 <ShaneM> q+ to talk about media type
14:55:25 <ShaneM> q-
14:55:27 <ivan> tinkster: the annoucement mechanism might be media type
14:55:39 <ivan> ShaneM: not all processors have access to the document type
14:56:31 <ivan> tinkster: is there a way for javascript to find out the content type?
14:56:39 <ivan> ShaneM: not in a portable way :-(
14:57:43 <ivan> ShaneM: there is a hack, I create an element in the dom in lower case then I retrieve and if this is lower case
14:58:05 <ivan> ShaneM: i am not against the resolution, but we do have a problem
14:58:10 <ShaneM> How about requiring that the values are the same if both are specified?
14:58:12 <ivan> manu: this is really really a corner case
14:58:41 <tinkster> ShaneM, html5 already does.
14:58:51 <ivan> ... we can say that if you want portability, use both cases and really really not use different
14:59:32 <ivan> ShaneM: I have always said we do not define the processing rules for invalid content
14:59:46 <manu> PROPOSAL: RDFa 1.1 defers to the Host Language to determine the language of the node.
14:59:57 <tinkster> +1
14:59:58 <manu> +1
15:00:03 <ShaneM> +1
15:00:19 <manu> PROPOSAL: RDFa Core 1.1 defers to the Host Language to determine the language of the node.
15:00:22 <ivan> +1
15:00:22 <manu> +1
15:00:24 <ShaneM> +1
15:00:24 <tinkster> +1
15:00:36 <manu> RESOLVED: RDFa Core 1.1 defers to the Host Language to determine the language of the node.
15:01:16 <ShaneM> When both lang and xml:lang are specified on the same element, they MUST have the same value.
15:01:27 <manu> PROPOSAL: When both lang and xml:lang are specified on the same element, they MUST have the same value.
15:01:32 <manu> +1
15:01:34 <ivan> +1
15:01:40 <ShaneM> +1
15:01:46 <manu> Manu: That means that it is a validation error if they are not the same.
15:01:48 <tinkster> +0 : this should not be our responsibility
15:01:48 <ivan> RESOLVED: When both lang and xml:lang are specified on the same element, they MUST have the same value
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000208