13:18:17 RRSAgent has joined #rdfa 13:18:17 logging to http://www.w3.org/2012/09/06-rdfa-irc 13:18:19 RRSAgent, make logs world 13:18:19 Zakim has joined #rdfa 13:18:21 Zakim, this will be 7332 13:18:21 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 42 minutes 13:18:22 Meeting: RDF Web Applications Working Group Teleconference 13:18:22 Date: 06 September 2012 13:32:43 MacTed has joined #rdfa 13:46:17 ShaneM has joined #rdfa 14:00:15 zakim, dial ivan-voip 14:00:18 ok, ivan; the call is being made 14:00:23 SW_RDFa()10:00AM has now started 14:00:26 +Ivan 14:00:43 niklasl has joined #rdfa 14:01:00 +scor 14:01:24 +??P36 14:01:27 zakim, I am ??P36 14:01:32 +niklasl; got it 14:01:55 +??P0 14:01:57 zakim, I am ??P0 14:01:57 +manu1; got it 14:02:44 +[OpenLink] 14:02:51 Zakim, [OpenLink] is temporarily me 14:02:52 zakim, who is on the phone? 14:02:52 Zakim, mute me 14:02:56 scor has joined #rdfa 14:03:08 +MacTed; got it 14:03:12 On the phone I see Ivan, scor, niklasl, manu1, MacTed 14:03:14 MacTed should now be muted 14:04:25 scribenick: ivan 14:04:29 scribe: Ivan 14:04:32 chair: Manu 14:04:34 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Sep/0000.html 14:05:05 q+ 14:05:37 Topic: FPWD for HTML+RDFa 1.1 14:05:41 q+ (after FPWD) 14:05:44 +McCarron 14:05:47 ivan: new charter is approved 14:06:24 ivan: Since this is a new charter with new deliverables, with patent policy issues - everyone is required to rejoin the group within 45 days. 14:06:26 ack ivan 14:06:50 ivan: It's an administrative issue, but we need to do this. 14:07:53 New draft for HTML+RDFa that is ready for FPWD: http://www.w3.org/2010/02/rdfa/drafts/2012/WD-rdfa-in-html-20120911/ 14:08:16 ack (after, FPWD) 14:09:14 ivan: I need to look at the status section, I'll do that later today. 14:14:32 ivan: Well, I just looked at the status of the document, it's fine as-is. So, next step is to do a formal transition request. 14:14:48 ivan: I already talked with Thomas, we can use the same short name, so that's clear. 14:16:51 PROPOSAL: Publish HTML+RDFa 1.1 ( http://www.w3.org/2010/02/rdfa/drafts/2012/WD-rdfa-in-html-20120911/ ) as a First Public Working Draft on Tuesday, September 11th 2012. 14:16:54 +1 14:16:55 +1 14:16:56 +1 14:16:57 +1 14:17:11 +1 14:17:14 +1 14:17:16 RESOLVED: Publish HTML+RDFa 1.1 ( http://www.w3.org/2010/02/rdfa/drafts/2012/WD-rdfa-in-html-20120911/ ) as a First Public Working Draft on Tuesday, September 11th 2012. 14:17:24 Topic: Open issues 14:17:39 ISSUE-140? 14:17:39 ISSUE-140 -- How is the OBJECT element processed when containing the @data attribute? -- pending review 14:17:39 http://www.w3.org/2010/02/rdfa/track/issues/140 14:17:41 Topic: ISSUE-140: OBJECT and @data attribute 14:17:48 http://www.w3.org/2010/02/rdfa/track/issues/140 14:18:06 manu1: whether or not we should process @data on the object element 14:18:11 … if yes, what are the results 14:18:19 … gregg did an overview 14:18:35 … he said last year we resolved 14:18:46 …. not to support the attribute 14:18:54 … the test manifest comments this one out 14:18:59 q+ 14:19:12 ack ivan 14:19:14 ack 14:19:20 ack (after, 14:19:22 q? 14:19:33 q- (after FPWD) 14:19:36 :-) 14:20:17 ivan: is the @data/object still out? 14:20:30 manu: the idea was to use different media elements in the browsers 14:20:46 … today we have audio and video elements, those are the attributes that take over the object 14:20:52 … it is still used for plugins 14:21:00 … but with the big push against plugins 14:21:12 … then I think that still holds 14:21:23 … so html5 is getting rid of objects this way 14:21:31 q+ 14:21:33 … anyone knows anything else? 14:21:35 ivan: The argument that we used to not support @data - the usage of the @data attribute and OBJECT element is on its way out - argument made by you, Manu. 14:21:41 ack niklasl 14:21:42 ack niklasl 14:22:05 niklasl: I think it makes sense, the @data attribute was around for a long time and we did not need it in xhtml1.1 either 14:22:11 +1 to niklasl 14:22:24 PROPOSAL: Do not support the @data attribute in HTML+RDFa 1.1. 14:22:25 +1 14:22:27 +1 14:22:28 +1 14:22:29 +1 14:22:31 +1 14:22:32 +1 14:22:34 +1 14:22:38 RESOLVED: Do not support the @data attribute in HTML+RDFa 1.1. 14:22:48 close issue-140 14:22:49 ISSUE-140 How is the OBJECT element processed when containing the @data attribute? closed 14:22:56 issue-141? 14:22:56 ISSUE-141 -- How many of the possible datatypes for @datetime should be supported? -- open 14:22:56 http://www.w3.org/2010/02/rdfa/track/issues/141 14:23:14 Topic: ISSUE-141: Datatypes for @datetime 14:23:44 -McCarron 14:23:49 http://www.w3.org/2010/02/rdfa/track/issues/141 14:24:06 manu: these are the time related types that we support 14:24:18 … gregg mentioned a number of resolutions 14:24:40 -> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Aug/0002.html Gregg's analysis and list of types 14:25:04 … we also resolved that the text content in the absence of a day-time attribute is used 14:25:13 … the test suite has all the necessary tests already 14:25:20 … it is consistent with html5 14:25:40 … the suite also looks also at the inner text of the elements 14:25:50 … 3 out of 4 passes these tests, too 14:26:05 … the issue seems to be resolved 14:26:12 … any other input on this? 14:26:15 ... 14:26:17 ... 14:26:19 ... 14:26:27 (silence all over the board) 14:27:04 PROPOSAL: Support processing the @datetime attribute and the contents of the TIME element. Support the following datatypes: xsd:date, xsd:time, xsd:dateTime, xsd:duration, xsd:gYear, and xsd:gYearMonth. 14:27:12 +1 14:27:13 +1 14:27:14 +1 14:27:17 +1 14:27:31 +1 14:27:40 RESOLVED: Support processing the @datetime attribute and the contents of the TIME element. Support the following datatypes: xsd:date, xsd:time, xsd:dateTime, xsd:duration, xsd:gYear, and xsd:gYearMonth. 14:27:53 gkellogg: +1 14:28:13 ISSUE-137? 14:28:13 ISSUE-137 -- HTML+RDFa should normatively declare media types and describe how to identify relative to XHTML+RDFa 1.1 -- open 14:28:13 http://www.w3.org/2010/02/rdfa/track/issues/137 14:28:32 Topic: ISSUE-126: Can xmlns: be reported as a warning? 14:28:32 +McCarron 14:28:45 ISSUE-137? 14:28:45 ISSUE-137 -- HTML+RDFa should normatively declare media types and describe how to identify relative to XHTML+RDFa 1.1 -- open 14:28:45 http://www.w3.org/2010/02/rdfa/track/issues/137 14:28:50 Topic: ISSUE-137: Normative media types for HTML+RDFa 14:29:00 http://www.w3.org/2010/02/rdfa/track/issues/137 14:29:52 manu: shane made a quick review, the current text already says that html+rdfa1 should be labeled text/html 14:30:11 … there is also a text on the usage of @version (even if it is non comforting per html5) 14:30:48 … processors must read the content of @version and use it to switch; if the value is not correct then the latest version of rdfa1.1 should be used 14:30:58 … a non-normative text should be added: 14:31:19 "Note: Some processors may not be able to detect the media type of the 14:31:19 document being processed because of system limitations. In these cases 14:31:20 the default processing rules in [RDFA-CORE] [2] section 4.1 - RDFa 14:31:21 Processor Conformance - take precedence." 14:32:08 manu: the problem is that this may not answer axel's concern 14:32:18 … but the previous texts may answer 14:32:36 .. the spec says something about non-xml mode 14:32:44 … does it say something about xhtml5? 14:32:57 (manu looking up) 14:32:57 s 14:33:06 shane: I do not think there is a text there 14:33:21 … I wanted to avoid normative text 14:33:42 manu: do we actually state this in rdfa1.1 mode 14:33:47 s/mode/core/ 14:34:02 ivan: I do not think so 14:34:34 manu: going back to the original issue 14:34:48 … the spec specifies for text/html 14:35:03 … but there is no mention for application/xhtml+xml 14:35:14 … alex proposes a text: 14:35:23 "HTML+RDFa documents should be labeled with Internet Media Types "text/html" or "application/xhtml+xml" as defined in [RFC3236]." 14:35:37 q+ 14:36:10 manu: the problem is with xhtml 14:36:28 … can we say something about the choice xhtml1.1 and xhtml5 14:36:42 shane: core says you must use a media type 14:36:59 … if you cannot use a media type then you can do something else 14:37:10 from rdfa 1.1. core: A conforming RDFa Processor may use additional mechanisms (e.g., the DOCTYPE, a file extension, the root element, an overriding user-defined parameter) to attempt to determine the Host Language if the media type is unavailable. These mechanisms are unspecified. 14:37:13 ack ivan 14:38:33 ivan: RDFa 1.1 Core does say what Niklas' put in IRC. I can understand Alex's issue because I've hit this issue myself. What I do right now is I try to look at the DOCTYPE of the XHTML5 document, if the doctype is one of the DTDs that we have specified for RDFa 1.0 or RDFa 1.1, then I fall back on that type of document, otherwise I do XHTML5. The @version attribute is a different question... 14:38:35 ...here, it may switch between RDFa 1.0 and RDFa 1.1. 14:39:43 ivan: However, that's not what we're talking about... we're talking about what the host language is. The text that Alex proposes is fine, but it's not enough. 14:41:51 ivan: for XHTML - first, we need to look at the Media Type and see that it's 'application/xhtml+xml'. Second, we look at the DTD, if there is one - if it's one we have defined for XHTML1+RDFa 1.1 or XHTML1+RDFa 1.0, we use that. If that does not match, it is XHTML5. 14:42:04 ivan: I think that's an unambiguous algorithm, that's what we should say. 14:43:04 shane: the core spec is consistent with this 14:43:30 … this extra detail sounds normative to me 14:43:41 … would it change the behavior of an existing document? 14:44:05 q+ 14:44:41 ack ivan 14:45:54 ivan: I can live with the rules that are above - if you have a document that uses the correct DTD, there won't be any change for those documents. 14:46:03 ivan: We are fine as far as that's concerned. 14:47:49 q+ 14:48:32 shane: What happens when a badly authored XHTML+RDFa 1.1 document (without a doctype or @version) that is using XHTML1 terms gets processed with these new rules? 14:48:40 manu: The terms are dropped. 14:48:45 shane: Yes, that's my concern. 14:49:06 ivan: Well, the sad truth is that this is not defined behavior today, I spent some time figuring out how to do this correctly. 14:49:40 Zakim, unmute me 14:49:40 MacTed should no longer be muted 14:49:41 shane: As long as we're doing this with out eyes open, I'm okay with it. These badly authored documents will have their terms dropped. 14:50:04 ack niklasl 14:50:04 Zakim, mute me 14:50:05 MacTed should now be muted 14:50:06 ted: if you were sloppy generating the document, that is what you get, so do not be sloppy... 14:50:16 niklasl: that sounds adequate to me as well 14:51:54 niklasl: what about using xmlns as a switch? 14:52:03 ivan: that is legal in xhml5 14:52:20 shane: what about @version attribute 14:52:27 … that has defined values for our processor 14:53:20 manu: that would allow authors to use a non-dtd based mechanism for switching 14:53:41 … but we are getting into rathole a.k.a. sniffing 14:53:54 … would anyone object to use ivan's attribute? 14:54:03 s/attribute/algorithm/ 14:54:13 manu1: we cannot use the @version, 14:54:44 … if we put in value for xhtml5+rdfa.1.1 for the value, that would lead to problems with the html wg, because we'd add a new attribute 14:55:03 … if we refer to the value referring to xhtml1.1 14:55:45 shane: you suggest that we do not have the option to define a string for the @version attribute to define xhtml5 14:56:14 … I always thought we could do that... 14:56:45 manu: I wonder whether this is an issue for javascript processors at all 14:56:56 … is there a difference between that 14:56:57 .. according to this, js can get at the doctype: http://stackoverflow.com/questions/6088972/get-doctype-of-an-html-as-string-with-javascript 14:57:16 q+ 14:57:40 ack ivan 14:59:48 ShaneM has joined #rdfa 15:00:50 PROPOSAL: Add normative text that specifies how to detect an XHTML+RDFa document in HTML+RDFa 1.1. The algorithm is to first, look at the Media Type and see that it's 'application/xhtml+xml'. Second, look at the DTD, if there is one - if it's one we have defined for XHTML1+RDFa 1.1 or XHTML1+RDFa 1.0, we use that. If that does not match, it is XHTML5. Place a warning in the spec stating that... 15:00:52 ...documents that don't contain a DTD, don't have @version, and are served as XHTML will default to XHTML5. 15:01:07 +1 15:01:09 +1 15:01:12 +1 15:01:16 +1 15:01:17 +1 15:01:22 +1 15:01:31 shane: Make sure to point this back to the relevant sections of RDFa Core 1.1 15:01:35 gkellogg: +1 15:01:37 RESOLVED: Add normative text that specifies how to detect an XHTML+RDFa document in HTML+RDFa 1.1. The algorithm is to first, look at the Media Type and see that it's 'application/xhtml+xml'. Second, look at the DTD, if there is one - if it's one we have defined for XHTML1+RDFa 1.1 or XHTML1+RDFa 1.0, we use that. If that does not match, it is XHTML5. Place a warning in the spec stating that... 15:01:38 RESOLVED: Add normative text that specifies how to detect an XHTML+RDFa document in HTML+RDFa 1.1. The algorithm is to first, look at the Media Type and see that it's 'application/xhtml+xml'. Second, look at the DTD, if there is one - if it's one we have defined for XHTML1+RDFa 1.1 or XHTML1+RDFa 1.0, we use that. If that does not match, it is XHTML5. Place a warning in the spec stating that... 15:01:38 17:00manu1: 15:01:39 ...documents that don't contain a DTD, don't have @version, and are served as XHTML will default to XHTML5. 15:01:39 ...documents that don't contain a DTD, don't have @version, and are served as XHTML will default to XHTML5. 15:02:33 bye guys 15:02:36 -Ivan 15:02:51 q+ to talk about the Role Attribute 15:03:07 Topic: RDFa to JSON-LD implementation 15:03:26 -MacTed 15:04:01 niklasl: My implementation (in CoffeeScript) of an RDFa to JSON-LD processor is going well. Not too complicated to implement. 15:04:14 niklasl: It ties what you ask for back to elements in the DOM, which is what the Microdata API does. 15:04:26 niklasl: So, it computes views for the data in the document. 15:04:48 https://github.com/niklasl/rdfa-lab/wiki 15:05:22 manu: When will it be production-ready? 15:06:13 niklasl: Well, the issue is that the API is something I've created... it will be production ready once four test cases are fixed. The body of the logic and the API shouldn't be considered stable - the outer parts will be just as usable as green turtle implementation. Really, we need to hammer out the RDFa DOM API. 15:06:22 Topic: Role Attribute spec 15:07:05 shaneM: The @role attribute spec went into CR and has come out without receiving any comments. There are a number of RDFa processors that have done @role attribute processing. I want to encourage implementers to add support for it. There are tests for it in the RDFa Test Suite. I'm doing an implementation report now. 15:07:23 shanem: So, there are enough implementations that do it to get out of CR. 15:07:36 manu: I intend to add support when I can. 15:07:44 shanem: PyRDFa and Ruby distiller support it. 15:08:05 shanem: Who did the clojure one? Niklas. 15:08:15 shanem: If you want to add support, that would be great. 15:08:54 tinkster has joined #rdfa 15:09:00 -McCarron 15:09:02 -manu1 15:09:03 -scor 15:09:07 -niklasl 15:09:07 SW_RDFa()10:00AM has ended 15:09:07 Attendees were Ivan, scor, niklasl, manu1, MacTed, McCarron 15:09:09 niklasl: since this is element-centric, it makes most sense to put it there. You can navigate the DOM by @role, which is exactly what it's used for. 15:13:04 niklasl has left #rdfa 15:16:55 gkellogg has joined #rdfa 17:14:58 Zakim has left #rdfa 17:37:58 ShaneM has joined #rdfa 17:43:03 ShaneM has left #rdfa 18:04:50 rdfa has joined #rdfa 18:04:50 [rdfa-website] scor pushed 3 new commits to master: https://github.com/rdfa/rdfa-website/compare/de3dec0120d4...1b7e93a937b3 18:04:50 [rdfa-website/master] Update README.markdown - Stephane Corlosquet 18:04:51 [rdfa-website/master] Update README.markdown - Stephane Corlosquet 18:04:53 [rdfa-website/master] Update README.markdown - Stephane Corlosquet 18:04:56 rdfa has left #rdfa 19:23:32 tinkster has joined #rdfa 21:00:03 ShaneM has joined #rdfa