Warning:
This wiki has been archived and is now read-only.
Chatlog 2012-02-23
From RDFa Working Group Wiki
See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.
14:54:11 <RRSAgent> RRSAgent has joined #rdfa 14:54:11 <RRSAgent> logging to http://www.w3.org/2012/02/23-rdfa-irc 14:54:13 <trackbot> RRSAgent, make logs world 14:54:13 <Zakim> Zakim has joined #rdfa 14:54:15 <trackbot> Zakim, this will be 7332 14:54:15 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 26 minutes 14:54:16 <trackbot> Meeting: RDF Web Applications Working Group Teleconference 14:54:16 <trackbot> Date: 23 February 2012 14:54:38 <Steven> Steven has joined #rdfa 14:57:12 <niklasl> niklasl has joined #rdfa 14:58:01 <Zakim> SW_RDFa()10:00AM has now started 14:58:08 <Zakim> +??P43 14:58:11 <niklasl> zakim, I am ??P43 14:58:11 <Zakim> +niklasl; got it 15:00:10 <danbri> danbri has joined #rdfa 15:00:41 <Zakim> +??P58 15:00:46 <gkellogg> zakim, I am ??P58 15:00:46 <Zakim> +gkellogg; got it 15:01:14 <Zakim> +??P62 15:01:17 <ShaneM> ShaneM has joined #rdfa 15:01:41 <manu1> zakim, I am ??P62 15:01:42 <Zakim> +manu1; got it 15:02:27 <manu1> Scribe: manu1 15:02:52 <manu1> Manu: Any updates or changes to the Agenda? 15:03:12 <Zakim> +??P67 15:03:18 <Zakim> +scor 15:03:19 <ShaneM> zakim, ??P67 is ShaneM 15:03:19 <Zakim> +ShaneM; got it 15:03:53 <manu1> Niklasl: Should we put Item #1 later in the Agenda? 15:05:17 <scor> scor has joined #rdfa 10:05:00 <Zakim> +Steven 10:05:00 <Zakim> +OpenLink_Software 10:05:00 <MacTed> Zakim, OpenLink_Software is temporarily me 10:05:00 <MacTed> Zakim, mute me 10:05:00 <manu1> Manu: Yes, we can, but we have to get through all of these issues anyway. 10:05:00 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0058.html 10:06:00 <Zakim> +MacTed; got it 10:06:00 <Zakim> MacTed should now be muted 10:06:00 <manu1> Topic: ISSUE-131: @href overrides @content 10:06:00 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/131 10:07:00 <niklasl> q+ 10:07:00 <manu1> Manu: I think this was a mistake - we never meant @property to bind to @href when @content is on the same element. 10:08:00 <manu1> Niklas: There is an issue with b/c in either case... 10:08:00 <manu1> ack niklasl 10:09:00 <manu1> Niklas: I think that @property binds to @href in RDFa 1.0 10:09:00 <ivan> zakim, dial ivan-voip 10:09:00 <gkellogg> http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0046.html 10:10:00 <Zakim> ok, ivan; the call is being made 10:10:00 <Zakim> +Ivan 10:10:00 <manu1> Manu: I disagree, I don't think we meant this to happen at all... 10:10:00 <ivan> q+ 10:11:00 <manu1> Shane: That's correct, in RDFa 1.0, if you have @href, @property and @content on an element - then @href becomes the subject, @property becomes the predicate, and @content becomes the object. 10:12:00 <gkellogg> q+ My processor has the same result in RDFa 1.0 10:12:00 <manu1> Niklas: From what I gather, I don't think we can do anything about this... if @href is present, it becomes both the subject and the object... 10:12:00 <manu1> ack ivan 10:13:00 <manu1> Ivan: The point is that that was the behavior of @property in RDFa 1.0 - if there is an attribute in an element which refers to a literal object, then @property switches back to its old self in RDFa 1.0. 10:13:00 <manu1> Ivan: If there is a content attribute, @property behaves in the same way as it does in RDFa 1.0... @href is the subject, etc. 10:13:00 <manu1> Ivan: We can be stricter - even if @content and @datatype is on the element, @property behaves like @rel - @datatype can be ignored... that's awkward. 10:14:00 <niklasl> q+ 10:14:00 <gkellogg> q+ 10:14:00 <manu1> Ivan: If we begin to fiddle around with this stuff too much, we could create a huge incompatiability w/ RDFa 1.0 10:14:00 <manu1> ack niklasl 10:15:00 <manu1> Niklas: Fiddling w/ this too much opens up bad consequences... if we did this change, the other opposing point of view is that @content would override @href. Combination of @property and @content is more significant. 10:15:00 <manu1> Ivan: Yes, that's what happens, though - @href becomes the subject, though. 10:15:00 <ivan> q+ 10:15:00 <manu1> ack gkellogg 10:16:00 <manu1> Gregg: The principle of least change is what we should go with here... we can't know what types of things depended on that behavior... 10:16:00 <manu1> gkellogg: When you do markup, you need to test to make sure you're getting the right results. 10:16:00 <manu1> ack ivan 10:17:00 <manu1> Ivan: Something that came out in this discussion - we do have the Primer, it might be worth having some sort of page/document on do's and don'ts. There are combinations that one shouldn't do... this is one of them. 10:18:00 <manu1> Ivan: There are many ways to put tons of RDFa attributes on an element to generate a ton of triples... but people shouldn't do that... even if it is legal. 10:18:00 <niklasl> .. (these advice of Ivan's are also captured in this mail: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0044.html ) 10:18:00 <manu1> Ivan: It's effectively spaghetti programming w/ RDFa - we should document these things. 10:19:00 <niklasl> q+ 10:20:00 <niklasl> <a property="email" href="mailto:peter@peterkrantz.se" datatype="">peter@peterkrantz.se</a> 10:20:00 <niklasl> <mailto:peter@peterkrantz.se> schema:email <mailto:peter@peterkrantz.se> . 10:21:00 <niklasl> in "7.5 Sequence", step 5. 10:21:00 <ShaneM> q+ to ask about @datatype and @property 10:22:00 <manu1> ack niklasl 10:22:00 <gkellogg> 5.1 If the current element contains the @property attribute, but does not contain either the @content or @datatype attributes, then 10:22:00 <manu1> Ivan: In RDFa 1.1, the object should be "peter@peterkrantz.se" 10:23:00 <manu1> ack shaneM 10:23:00 <Zakim> ShaneM, you wanted to ask about @datatype and @property 10:24:00 <niklasl> q+ 10:24:00 <manu1> Manu: My understanding was that we only bind @property to @href when those are the /only/ RDFa attribute on the element. 10:24:00 <manu1> Ivan: That is correct... maybe this is a spec bug. 10:24:00 <manu1> ack niklasl 10:25:00 <niklasl> <a property="email" href="mailto:peter@peterkrantz.se" lang="">peter@peterkrantz.se</a> 10:25:00 <niklasl> <a property="email" href="mailto:peter@peterkrantz.se" datatype="">peter@peterkrantz.se</a> 10:27:00 <niklasl> q+ 10:27:00 <manu1> Niklas: Maybe looking at this, the reasonable thing to do is ignore datatype? 10:27:00 <manu1> Gregg: I'm worried about complexity of the processing rules. 10:28:00 <manu1> Manu: Our intent was always that @property and @href being on the same element would bind @property to @href, otherwise, property does not bind to @href. 10:29:00 <gkellogg> Second bullet i 11: "as a plain literal if @datatype is present and is empty ..." 10:31:00 <niklasl> <a property="email" href="mailto:peter@peterkrantz.se" datatype="">peter@peterkrantz.se</a> 10:31:00 <niklasl> <span property="email" about="mailto:peter@peterkrantz.se" datatype="">peter@peterkrantz.se</span> 10:35:00 <manu1> PROPOSAL: Fix the specification bug that ignores @datatype in step #11. 10:35:00 <MacTed> +1 10:35:00 <ivan> +1 10:35:00 <niklasl> +1 10:35:00 <manu1> manu: +1 10:35:00 <gkellogg> +1 10:35:00 <scor> +1 10:36:00 <Steven> +1 10:36:00 <manu1> RESOLVED: Fix the specification bug that ignores @datatype in step #11. (non-substantive) 10:37:00 <manu1> ACTION: Niklas to add test case to the test suite covering ISSUE-131. 10:37:00 <trackbot> Created ACTION-113 - Add test case to the test suite covering ISSUE-131. [on Niklas Lindström - due 2012-03-01]. 10:37:00 <manu1> Topic: ISSUE-132: Is @src allowed everywhere? 10:37:00 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/132 10:38:00 <Steven> I agree 10:38:00 <gkellogg> q+ 10:38:00 <manu1> manu: My reading on this was that we never intended @src to be put everywhere. 10:38:00 <manu1> Ivan: I agree 10:39:00 <manu1> ack niklas 10:39:00 <manu1> ack gkellogg 10:39:00 <ShaneM> q+ to say we should mark them as optional again 10:40:00 <manu1> Gregg: I never really liked @href and @src in core... it was conflating XHTML+RDFa with RDFa itself. I think that wrt @href and @src, I'd rather see the usage of that deferred to the Host Language. 10:40:00 <ivan> q+ 10:40:00 <manu1> Gregg: @href and @src are not necessary... 10:40:00 <manu1> ack ShaneM 10:40:00 <Zakim> ShaneM, you wanted to say we should mark them as optional again 10:40:00 <manu1> Shane: It's not that I don't agree with you, we've had this debate - the core problem is that where @href gets injected into the processing rules is complex enough that it's difficult to remove it in a way that is not backwards incompatible. 10:41:00 <manu1> Gregg: I'm not proposing a change - I think the proposal should be something more flexible for Core. 10:42:00 <manu1> ack ivan 10:42:00 <gkellogg> Proposal: core RDFa attributes are required on any element in host languages supporting RDFa 1.1. Host languages may restrict the use of @href and @src to be consistent with their content models. Or, to add synonyms for RDFa attributes, such as @data in HTML5. 10:42:00 <manu1> Ivan: Let's move ahead... I think Shane's offer was that @href and @src are optional. 10:42:00 <niklasl> shane disagrees with jeni on this issue here: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0057.html 10:43:00 <manu1> Ivan: In HTML5+RDFa and maybe in XHTML+RDFa - @href and @src are used wherever the host language allows it to be used. 10:44:00 <manu1> Shane: Same with @rel and @rev - @href allows it to be used everywhere. 10:45:00 <manu1> PROPOSAL: The @src attribute is only allowed on elements defined by the Host Language. 10:45:00 <ivan> +1 10:45:00 <gkellogg> +1 10:45:00 <manu1> manu: +1 10:45:00 <Steven> +0 [not worried either way] 10:45:00 <ShaneM> +1 (it is not a required component of the content model) 10:46:00 <niklasl> +1 10:46:00 <MacTed> +0 10:46:00 <scor> +1 10:46:00 <manu1> RESOLVED: The @src attribute is only allowed on elements defined by the Host Language. (non-substantive) 10:47:00 <manu1> Topic: ISSUE-119: RDFa Lite 1.1 and @resource 10:47:00 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/119 10:47:00 <scor> +q 10:48:00 <manu1> Manu: The basic idea here is to replace @about with @resource. 10:49:00 <niklasl> … <div about="stehpane"><span property="knows" resource="niklas">Niklas</span> 10:49:00 <manu1> scor: Having @resource enables you to not have to add another wrapping element. If you have @resource, you can replace @about with @resource. 10:49:00 <niklasl> … <div resource="stehpane"><span property="knows" resource="niklas">Niklas</span> 10:49:00 <manu1> Gregg: You can use @src or @href and have the same effect. 10:49:00 <scor> https://raw.github.com/gkellogg/rdf-rdfa/master/example-files/schema-person.html 10:50:00 <niklasl> q+ 10:50:00 <manu1> scor: At the schema.org workshop - one of his points was that RDFa requires extra HTML elements... if we can avoid that, it's good. I don't care if it is @href or @src... we should be able to mimic what Microdata is allowed to do here. 10:50:00 <manu1> ack scor 10:51:00 <manu1> scor: Linking a person and an address in schema.org... the trick here is to use @resource. 10:52:00 <manu1> scor: If we can keep the same structure as Microdata - that would be a huge win for us. 10:52:00 <manu1> q+ 10:53:00 <manu1> scor: This will make markup cleaner, replacing @about with @resource. 10:53:00 <gkellogg> q+ 10:53:00 <manu1> ack niklasl 10:53:00 <ivan> ack niklasl 10:54:00 <manu1> ack manu1 10:54:00 <scor> manu1: I've never seen that 10:55:00 <scor> manu1: could you give pointers to @href in all elements? (now or after the call) 10:56:00 <scor> q+ 10:56:00 <Steven> I agree with Manu 10:56:00 <manu1> ack gkellogg 10:57:00 <manu1> Gregg: My thought was not to replace @about with @resource, but to add @resource to RDFa 1.1 Lite. 10:57:00 <manu1> Gregg: That would allow you to do RDFa to Microdata translator... 10:57:00 <manu1> s/RDFa to Microdata/Microdata to RDFa/ 10:57:00 <niklasl> q+ 10:57:00 <manu1> q+ to say why not just use RDFa 1.1? 10:58:00 <ivan> +1 to Gregg 10:58:00 <manu1> ack scor 10:58:00 <manu1> scor: We should hear back from the stake holders on this issue... 10:58:00 <manu1> scor: I think adding @about and @resource to RDFa 1.1 Lite would confuse people. 10:59:00 <manu1> scor: I don't think this is a big deal wrt. education - we shouldn't break b/c - this is a new version of RDFa - people will have to adjust their mind... most people don't know RDFa at all... they won't be affected by this. 11:00:00 <ivan> q+ 11:00:00 <manu1> Niklas: This is about RDFa Lite 1.1, not about RDFa 1.1 Full - any example using attributes... @href anywhere... if HTML5 doesn't allow @href anywhere, we shouldn't allow that. If we add this as an annotational attribute, then HTML6 adds @href and makes it actionable - entire regions of the document could be click-able. 11:01:00 <manu1> ack niklasl 11:01:00 <ivan> ack niklasl 11:01:00 <niklasl> q+ 11:01:00 <ivan> ack manu1 11:02:00 <niklasl> .. it's a marketing issue (currently "everybody" wants to conform to Lite) 11:02:00 <ivan> ack manu1 11:02:00 <manu1> scor: Anything that we take from RDFa 1.1 Full could be used as a stick to beat us... 11:02:00 <Zakim> manu1, you wanted to say why not just use RDFa 1.1? 11:02:00 <manu1> scor: If they take up taking @resource from Full... they won't be able to say they use RDFa 1.1 Lite. 11:03:00 <manu1> scor: I think we want @resource in RDFa Lite... 11:04:00 <manu1> Ivan: I have the same issue as Stephane and Niklas have... @resource seems to be really, really, important - more important than @about. 11:05:00 <manu1> Ivan: The education argument isn't an issue - we're trying to get to a different audience that needs to use RDFa... @resource works better. 11:05:00 <manu1> Ivan: I don't think we should allow @href everywhere in HTML5. 11:06:00 <manu1> Ivan: For HTML5, we are opening up the same sort of endless discussion with things like @xmlns and @version - let's not go there. 11:06:00 <manu1> ack ivan 11:07:00 <manu1> niklas: Yes, what they've said - I agree with that... most people want to conform to Lite - Jeni, James - they want to conform to RDFa Lite only... 11:07:00 <manu1> niklas: We've seen that it works like @about - @about is the most magical attribute considering the changes in RDFa 1.1. 11:08:00 <manu1> niklas: @property and @resource - @href, @src, or @resource is the one thing where we want to combine two attributes to create a link. 11:08:00 <Steven> -1 11:08:00 <manu1> ack ivan 11:08:00 <manu1> ack niklasl 11:08:00 <ivan> +1 11:09:00 <Steven> Manu said "The proposal is ..." 11:09:00 <Steven> I voted on that 11:10:00 <manu1> PROPOSAL: Add @resource to RDFa Lite 1.1. 11:10:00 <ShaneM> -1 11:10:00 <manu1> Manu: -1 11:10:00 <Steven> +0 11:10:00 <niklasl> +0 11:10:00 <gkellogg> -0 11:10:00 <scor> -1 11:10:00 <ivan> -1 11:10:00 <niklasl> ;) 11:11:00 <manu1> RESOLVED: Do not add @resource to RDFa Lite 1.1, but possibly replace @about with @resource. (non-substantive) 11:11:00 <manu1> PROPOSAL: Replace @about with @resource in RDFa Lite 1.1. 11:11:00 <Steven> -1 11:11:00 <ivan> +1 11:11:00 <niklasl> +1 11:11:00 <gkellogg> +1 11:11:00 <manu1> Manu: -1 (but I will not block the group if that's what they want to do ) 11:11:00 <scor> +1 11:11:00 <MacTed> +0 11:11:00 <ShaneM> +0 11:13:00 <scor> timeline? 11:14:00 <scor> q+ 11:14:00 <manu1> Manu: it's close, we don't have consensus... would anyone formally object to a resolution allowing this? 11:15:00 <manu1> Steven: I don't think this is a good idea. 11:15:00 <manu1> Manu: Me neither. 11:16:00 <manu1> Gregg: RDFa 1.1 Lite is a response to Microdata... it's not necessarily a best practices... this addresses concerns raised by particular folks about RDFa 1.1... 11:16:00 <manu1> ack scor 11:17:00 <manu1> scor: If it helps, re: education, you could still present tutorials using @about... it wouldn't apply for RDFa 1.1 Lite. 11:17:00 <MacTed> Zakim, unmute me 11:17:00 <Zakim> MacTed should no longer be muted 11:17:00 <niklasl> q+ 11:17:00 <manu1> niklasl: This seems to imply that we should describe that @resource behaves like this in the primer. 11:18:00 <manu1> RESOLVED: Replace @about with @resource in RDFa Lite 1.1. (non-substantive) 11:18:00 <MacTed> Zakim, mute me 11:18:00 <Zakim> MacTed should now be muted 11:18:00 <manu1> Topic: ISSUE-127: Empty Lists? 11:18:00 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/127 11:18:00 <gkellogg> q+ 11:18:00 <manu1> ack niklasl 11:18:00 <manu1> ack gkellogg 11:19:00 <ivan> q+ 11:19:00 <manu1> gkellogg: The concern is that by specifying @inlist, w/o any properties, it creates a list that might be considered unexpected. 11:19:00 <manu1> gkellogg: If we create a list, don't put anything in it, we have meant to create an empty list. Doing it otherwise would add special logic that we don't need. 11:19:00 <manu1> ack ivan 11:19:00 <manu1> Ivan: I propose to withdraw the issue with no change. 11:20:00 <manu1> PROPOSAL: There is no issue, the specification is correct, @inlist specified w/o any content still generates an empty list. 11:20:00 <manu1> manu: +1 11:20:00 <gkellogg> +1 11:20:00 <niklasl> +1 11:20:00 <ivan> +1 11:20:00 <ShaneM> +1 11:20:00 <MacTed> +1+1 11:20:00 <ShaneM> (and sooo don't care) 11:20:00 <scor> +1 11:21:00 <Steven> +1 11:21:00 <manu1> RESOLVED: There is no issue, the specification is correct, @inlist specified w/o any content still generates an empty list. (non-substantive) 11:21:00 <niklasl> .. now that's consensus ;) 11:21:00 <manu1> Topic: ISSUE-128: empty list of TERMorCURIEorAbsIRIs 11:21:00 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/128 11:21:00 <niklasl> q+ 11:22:00 <manu1> Ivan: This was raised by the validator team - we allow @datatype to have empty attribute. 11:22:00 <manu1> Shane: I don't think there is an issue. 11:22:00 <manu1> Ivan: The specification claims to have an empty value... 11:22:00 <manu1> Shane: Spec allows for attributes with no values. 11:22:00 <manu1> There are two potential approaches to this problem: 11:22:00 <manu1> PROPOSAL: An empty string for the value of all RDFa attributes MUST be allowed as conforming. 11:22:00 <manu1> OR 11:22:00 <manu1> PROPOSAL: An empty string for the value of @typeof, @datatype, @about, @resource, @href, @vocab, @content, @src, @rel, @rev, and @inlist is conforming. 11:22:00 <manu1> PROPOSAL: An empty string for the value of @property and @prefix is not conforming. 11:23:00 <niklasl> The syntax for CURIEs allows for *empty* CURIE! 11:24:00 <manu1> Shane: The XSD may be incorrect... but we do allow empty strings in values. 11:25:00 <niklasl> q+ 11:25:00 <manu1> ack niklasl 11:26:00 <manu1> niklasl: What is the effect of an empty property combined with @rel? The @rel is turned off? 11:26:00 <manu1> Ivan: I check the existence of a property... which is different from looking at the content... this is in the spec, let's move on. 11:26:00 <niklasl> yes 11:28:00 <manu1> Shane: What happens when an empty string is hit when processing? 11:28:00 <manu1> Ivan: You get back no URIs. 11:28:00 <manu1> Gregg: ok. 11:29:00 <niklasl> that expands to xhv: I think (for some legacy reason) 11:30:00 <manu1> Gregg: So, is ":" the same as ""? 11:30:00 <niklasl> RDFa Host Languages must not define a 'no prefix' mapping. 11:30:00 <niklasl> "It's also possible to omit both the prefix and the colon, and so create a CURIE that contains just a reference which makes use of the 'no prefix' mapping. This specification does not define a 'no prefix' mapping. RDFa Host Languages must not define a 'no prefix' mapping." 11:31:00 <gkellogg> Does 11:31:00 <gkellogg> Does "" == "xhv:" 11:31:00 <gkellogg> Does "[]" == "xhv:" ? 11:32:00 <manu1> Gregg: There is a tiny amount of ambiguity here... 11:32:00 <manu1> Gregg: We need to make it clear that the empty string does not resolve to an IRI 11:33:00 <manu1> Niklas: The syntax allows for empty CURIEs, but RDFa does not allow for empty CURIEs... 11:33:00 <niklasl> TERMorCURIEorAbsIRI 11:34:00 <ShaneM> Otherwise, the value is ignored. 11:34:00 <manu1> Shane: Do we need to add text? It's in section 7.4 - since "" is not a CURIE, processing then goes to IRI. "" as an IRI? 11:34:00 <niklasl> definition of TERMorCURIEorAbsIRI ends with: "Otherwise, the value is ignored." 11:35:00 <manu1> Manu: We have had a long discussion about it, we need to add some text, right? 11:35:00 <manu1> Shane: When there is no prefix mapping defined, you can use "" - but we don't allow that. 11:36:00 <manu1> Niklas: I agree that it's not, but this is really hard to see this. 11:36:00 <manu1> EmptyorTERMorCURIEorAbsIRI 11:36:00 <manu1> Ivan: The definition of the datatype - that definition would allow empty strings. 11:37:00 <niklasl> "a white space separated list of *zero or more* TERMorCURIEorAbsIRIs". 11:37:00 <niklasl> .. is what is proposed in this issue. 11:37:00 <niklasl> 7.4.2 General Use of CURIEs in Attributes 11:39:00 <manu1> PROPOSAL: For the purposes of conformance, an empty string for the value of any RDFa attribute MUST be allowed as conforming. 11:39:00 <Steven> +0 11:39:00 <gkellogg> +1 11:39:00 <manu1> manu: +1 11:39:00 <niklasl> +1 11:39:00 <MacTed> +1 11:39:00 <ShaneM> +1 11:39:00 <ivan> +1 11:39:00 <scor> +1 11:40:00 <manu1> RESOLVED: For the purposes of conformance, an empty string for the value of any RDFa attribute MUST be allowed as conforming. (non-substantive) 11:40:00 <manu1> Topic: ISSUE-129: Power of @vocab 11:40:00 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/129 11:40:00 <ShaneM> q+ to discuss host language conformance 11:41:00 <manu1> Manu: I think we always intended @vocab to override everything, including terms in the default context. 11:41:00 <ShaneM> The Host Language may specify an initial context (e.g., the definition of terms, IRI mappings, and/or a default vocabulary IRI). Such an initial context should be defined using the conventions defined in RDFa Initial Contexts. 11:42:00 <niklasl> q+ 11:42:00 <ivan> ack ShaneM 11:42:00 <Zakim> ShaneM, you wanted to discuss host language conformance 11:43:00 <manu1> Shane: I think we wanted @vocab and Terms to work at the same time... if the proposal is when there is @vocab, terms don't work... I want to be able to reference license and know what it means... if I can't rely on terms to work, then I can't do that. 11:44:00 <manu1> Shane: Could we make the best practice suggestion that when you want to use "license" you use ":license"? 11:44:00 <manu1> Manu: yes, I think we could do that. 11:44:00 <ivan> q+ 11:44:00 <manu1> Shane: This is important for snippets. 11:44:00 <manu1> ack niklasl 11:44:00 <manu1> niklas: If you're going to create a snippet, you should use the vocab, a full IRI, or ":license" - doing anything else opens you up to issues... you don't know if anyone else would rebind the prefix. 11:45:00 <manu1> ack ivan 11:46:00 <manu1> Ivan: I had this discussion via e-mail w/ Niklas - for the HTML5 case, we don't care because there are barely any terms. 11:46:00 <manu1> Ivan: They're all pretty special - describedby, etc. 11:47:00 <manu1> Ivan: I don't think anyone in practice would have an issue if we kept these... in XHTML1, it bothers me a bit more - for XHTML1, we kept all terms around, so all of them would be overriden if one used @vocab. 11:47:00 <manu1> Ivan: These may nto be used in practice 11:47:00 <manu1> q+ 11:47:00 <niklasl> q+ 11:47:00 <manu1> Ivan: Is it so that the current text doesn't say clearly what changes? 11:47:00 <ShaneM> are you suggesting that you use <span vocab="" rel="license" about="" resource="cc:license">my license</span> or something? 11:48:00 <niklasl> ShaneM: yes, that's the pedantic, entirely safe approach 11:49:00 <niklasl> (well, e.g. @resource="/CC-BY") 11:49:00 <manu1> ack manu1 11:49:00 <manu1> Manu: @vocab was supposed to be simple - it wasn't supposed to make the author think about initial context terms. 11:50:00 <ivan> PROPOSED: @vocab nukes everything 11:50:00 <gkellogg> +1 11:50:00 <manu1> Niklas: We don't want people to think that "not all terms work uniformly when using @vocab" 11:50:00 <niklasl> +1 11:50:00 <ShaneM> q+ to ask why we have terms at all 11:50:00 <ivan> +1 11:51:00 <MacTed> +1 11:51:00 <manu1> manu: +1 11:51:00 <MacTed> Zakim, unmute me 11:51:00 <Zakim> MacTed should no longer be muted 11:51:00 <ShaneM> -1 this is a bad idea 11:51:00 <manu1> ack niklasl 11:51:00 <manu1> ack shanem 11:51:00 <Zakim> ShaneM, you wanted to ask why we have terms at all 11:51:00 <Steven> +0 11:52:00 <manu1> Shanem: I think we're abdicating our responsibility - but I won't stand in the way. 11:53:00 <manu1> RESOLVED: @vocab nukes everything (that is, when @vocab is used, it overrides all terms defined in the initial context) (non-substantive) 11:53:00 <niklasl> q+ 11:56:00 <niklasl> https://www.w3.org/2010/02/rdfa/track/issues/129 11:56:00 <manu1> Shane: Is this a difficult change? 11:56:00 <manu1> Niklas: No, it's just switching around the bullet points in 7.4.3 General Use of Terms in Attributes 11:57:00 <manu1> Ted: What does local default vocabulary mean in this case...? 11:57:00 <manu1> Shane: Happy to do that, but what's the issue. 11:58:00 <manu1> Ted: We should be clear about it... 11:59:00 <niklasl> q+ 11:59:00 <manu1> ack niklasl 11:59:00 <manu1> Niklas: The phrase used - the 'local default vocabulary' seems confusing - it's the local vocabulary. 12:01:00 <manu1> Ivan: In RDFa Core - we don't define an initial context. 12:01:00 <manu1> Shane: Yes, XHTML defines the initial context. 12:05:00 <manu1> Ivan: There is an editorial bug - in HTML5+RDFa or XHTML+RDFa - there is no predefined prefix for foaf - that's because HTML5 or XHTML5 takes RDFa Core... RDFa Core does not have initial context defined. 12:05:00 <manu1> "HTML+RDFa uses two profiles by default - first incorporating the XML+RDFa profile document http://www.w3.org/profile/rdfa-1.1, and then incorporating the RDFa Profile at http://www.w3.org/profile/html-rdfa-1.1." 12:05:00 <Zakim> -Steven 12:07:00 <niklasl> In section 9, it says: or it is loaded as external documents and processed 12:07:00 <gkellogg> test-cases/0206: Tests whether the default RDFa 1.1 context (which contains prefix definitions, among others, to the Semantic Web Standard vocabularies) is properly handled."; 12:07:00 <niklasl> key word: documents! plural 12:07:00 <gkellogg> What about this - rdfatest:hostLanguage "xml1", "xhtml1", "html4", "html5", "xhtml5"; 12:09:00 <manu1> Discussion about intitial contexts 12:09:00 <niklasl> .. well, not *everything* ;P 12:09:00 <manu1> Topic: ISSUE-130: HREF, REL and REV everywhere 12:09:00 <niklasl> .. only terms ;) 12:10:00 <manu1> https://www.w3.org/2010/02/rdfa/track/issues/130 12:10:00 <ivan> q+ 12:10:00 <manu1> ack ivan 12:10:00 <ShaneM> q+ to discuss required vs. optional attributes and content model requirements for host languages 12:10:00 <manu1> Manu: The issue is if we allow @href, @rel and @rev everywhere... 12:11:00 <manu1> Ivan: May be don't need @href everywhere... but we do need @rel and @rev everywhere. 12:11:00 <manu1> q+ 12:12:00 <manu1> Ivan: @href everywhere leads to a FO from Henri - months of discussion about this... 12:12:00 <manu1> Ivan: We don't want that. 12:12:00 <manu1> q? 12:12:00 <manu1> ack ShaneM 12:12:00 <Zakim> ShaneM, you wanted to discuss required vs. optional attributes and content model requirements for host languages 12:12:00 <manu1> ShaneM: There are a number of steps we can take here - host language conformance vs. host language development. 12:13:00 <manu1> ShaneM: Is @href allowed everywhere? It always was - in XHTML+RDFa - it's very explicit. 12:13:00 <manu1> ShaneM: This is black and white... would this matter to HTML5 folks? 12:13:00 <manu1> Ivan: HTML5 folks don't care about XHTML1 12:14:00 <manu1> ShaneM: You think it's important that we need to keep the two languages in sync, correct Manu? 12:14:00 <manu1> Manu: Correct. 12:14:00 <manu1> ShaneM: We can't make the change in XHTML1. 12:15:00 <manu1> ShaneM: What can Host Languages include / not include which RDFa attributes. I think we can include @href everywhere, and @rel and @rev everywhere. XHTML1 and HTML5. 12:16:00 <manu1> Ivan: What about XHTML1 and HTML5? 12:16:00 <manu1> Manu: What about SVG and XML? 12:16:00 <ShaneM> q? 12:16:00 <ShaneM> ack manu1 12:17:00 <niklasl> q+ 12:18:00 <manu1> Manu: We can say that it's up to the Host Language 12:18:00 <manu1> Shane: We already do 12:19:00 <manu1> Manu: We can do two things - have the host language kick out validation warnings for @href, @rel and @rev on elements that don't traditionally support it. We could only allow @href where they're traditionally used, @rel and @rev must be allowed everywhere. 12:20:00 <manu1> Ivan: I propose that for HTML5+RDFa - @href is restricted to elements that allow it in HTML5... @rel and @rev are allowed everywhere. 12:20:00 <manu1> Ivan: We should modify RDFa Core - @href is just as optional as @src is... 12:20:00 <manu1> ack niklasl 12:21:00 <manu1> niklasl: I fully understand why a formal objection may be raised on this - @href is actionable... let's not override HTML5 on that. 12:21:00 <ShaneM> q+ to discuss what we say in core about host language conformance (after this resolution) 12:22:00 <gkellogg> what about html4? 12:23:00 <niklasl> .. see http://www.w3.org/TR/html4/index/attributes.html 12:23:00 <niklasl> (only in a, area, link and base) 12:23:00 <manu1> PROPOSAL: In RDFa Core, @href should be specified as an optional RDFa attribute. In HTML+RDFa, @href is only allowed on elements that it has traditionally been allowed on. In XHTML+RDFa, @href is allowed on all elements. In XHTML+RDFa, XML+RDFa and HTML+RDFa, @rel and @rev are allowed on all elements. 12:24:00 <ivan> +1 12:24:00 <niklasl> +1 12:24:00 <ShaneM> +1 12:24:00 <manu1> manu: +1 12:24:00 <gkellogg> +1 12:24:00 <MacTed> +1 12:24:00 <scor> +1 12:25:00 <manu1> RESOLVED: In RDFa Core, @href should be specified as an optional RDFa attribute. In HTML+RDFa, @href is only allowed on elements that it has traditionally been allowed on. In XHTML+RDFa, @href is allowed on all elements. In XHTML+RDFa, XML+RDFa and HTML+RDFa, @rel and @rev are allowed on all elements. (non-substantive) 12:25:00 <manu1> Topic: Host Language Conformance in RDFa Core 12:25:00 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#hostlangconf 12:26:00 <manu1> Shane: In section 4.2 - we say that all attributes and facilities must be included. We should change this - the required attributes in the specification should be allowed. We mark @src and @href as optional - editorial changes. 12:26:00 <manu1> Shane: Do we have any requirement where the rest of the attributes must occur in a content model. 12:27:00 <manu1> Manu: no... as long as the attributes are put somewhere in the host language. 12:27:00 <manu1> Shane: This is already dealt with in the previous resolution. 12:29:00 <manu1> Topic: Going to Candidate Recommendation 12:29:00 <manu1> Manu: Ok, all issues are done. 12:30:00 <manu1> Ivan: We will meet next week and then decide to go to CR if we're ready... 12:33:00 <manu1> Manu: Just to be clear - all decisions we made today were editorial changes. 12:33:00 <manu1> Ivan: Yes, they were 12:33:00 <manu1> Shane: Yes. 12:34:00 <manu1> General agreement that no non-editorial changes were made today... we will proceed to Candidate Recommendation when the new Editor's Drafts are ready. 12:35:00 <Zakim> -scor 12:35:00 <Zakim> -manu1 12:35:00 <Zakim> -ShaneM 12:35:00 <Zakim> -MacTed 12:35:00 <Zakim> -gkellogg 12:35:00 <Zakim> -Ivan 12:35:00 <Zakim> -niklasl 12:35:00 <Zakim> SW_RDFa()10:00AM has ended 12:35:00 <Zakim> Attendees were niklasl, gkellogg, manu1, scor, ShaneM, Steven, MacTed, Ivan # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000090