Chatlog 2012-02-23

From RDFa Working Group Wiki
Jump to: navigation, search

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
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:
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>
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>
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: )
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="" datatype=""></a>
10:20:00 <niklasl> <> schema:email <> .
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 ""
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="" lang=""></a>
10:25:00 <niklasl> <a property="email" href="" datatype=""></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="" datatype=""></a>
10:31:00 <niklasl> <span property="email" about="" datatype=""></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>
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:
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>
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>
10:50:00 <niklasl> q+
10:50:00 <manu1> scor: At the 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 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>
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>
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>
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>
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, and then incorporating the RDFa Profile at"
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>
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
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>
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