14:03:18 <RRSAgent> logging to http://www.w3.org/2011/10/27-rdfa-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2011/10/27-rdfa-irc ←
14:03:21 <gkellogg> zakim, I am ??P11
Gregg Kellogg: zakim, I am ??P11 ←
14:03:22 <Zakim> +gkellogg; got it
Zakim IRC Bot: +gkellogg; got it ←
14:03:41 <Zakim> +Steven
Zakim IRC Bot: +Steven ←
14:04:43 <Zakim> +scor
Zakim IRC Bot: +scor ←
14:05:13 <manu1> zakim, who is on the call?
Manu Sporny: zakim, who is on the call? ←
14:05:17 <Zakim> On the phone I see ShaneM, gkellogg, manu1, niklasl, Steven, scor
Zakim IRC Bot: On the phone I see ShaneM, gkellogg, manu1, niklasl, Steven, scor ←
14:05:46 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Oct/0115.html
14:07:11 <manu1> scribenick: gkellogg
(Scribe set to Gregg Kellogg)
14:07:34 <manu1> Topic: RDFa Lite 1.1 as Editors Draft?
14:07:34 <manu1> Guest: Niklas (lindstream) Lindström
14:07:34 <manu1> Guest: Dan (danbri) Brickley
14:07:42 <manu1> http://manu.sporny.org/rdfa/lite/
Manu Sporny: http://manu.sporny.org/rdfa/lite/ ←
14:07:50 <Zakim> -Steven
Zakim IRC Bot: -Steven ←
14:08:46 <Zakim> +Steven
Zakim IRC Bot: +Steven ←
14:10:38 <gkellogg> manu: do we want to publish RDFa 1.1 Lite as an Editor's Draft to signal to the broader community that we're working on it?
Manu Sporny: do we want to publish RDFa 1.1 Lite as an Editor's Draft to signal to the broader community that we're working on it? ←
14:11:09 <gkellogg> … It's as a subset of RDFa 1.1 - but written in a way to bring out the simplicity of RDFa and make it easily accessible for beginners.
… It's as a subset of RDFa 1.1 - but written in a way to bring out the simplicity of RDFa and make it easily accessible for beginners. ←
14:11:21 <niklasl> q+
Niklas Lindström: q+ ←
14:11:27 <manu1> ack niklasl
Manu Sporny: ack niklasl ←
14:11:56 <gkellogg> niklasl: seems like a good idea. Like the insight that people can be overwhelmed by reading a full spec.
Niklas Lindström: seems like a good idea. Like the insight that people can be overwhelmed by reading a full spec. ←
14:12:13 <ShaneM> q+ to ask about conformance requirements
Shane McCarron: q+ to ask about conformance requirements ←
14:12:35 <gkellogg> manu: over the years, people have asked for a simpler introduction, but we've said it's not the W3C's job, but that of other sites. But W3C's getting more and more such demands, so maybe this can be a trial run.
Manu Sporny: over the years, people have asked for a simpler introduction, but we've said it's not the W3C's job, but that of other sites. But W3C's getting more and more such demands, so maybe this can be a trial run. ←
14:12:37 <manu1> ack shanem
Manu Sporny: ack shanem ←
14:12:37 <Zakim> ShaneM, you wanted to ask about conformance requirements
Zakim IRC Bot: ShaneM, you wanted to ask about conformance requirements ←
14:13:09 <gkellogg> shanem: We want to be sure of conformance requirements. The doc reads like a rec-track spec, but in my mind a conforming processor must support all of RDFa 1.1
Shane McCarron: We want to be sure of conformance requirements. The doc reads like a rec-track spec, but in my mind a conforming processor must support all of RDFa 1.1 ←
14:13:09 <gkellogg> manu1: That is the intent - there is no subset of RDFa 1.1 processors, just a subset of the language that holds together cohesively.
Manu Sporny: That is the intent - there is no subset of RDFa 1.1 processors, just a subset of the language that holds together cohesively. ←
14:13:50 <manu1> gkellogg: I don't think Facebook/Google quite care about the conformance aspect?
Gregg Kellogg: I don't think Facebook/Google quite care about the conformance aspect? [ Scribe Assist by Manu Sporny ] ←
14:14:18 <gkellogg> scor: even if there is a full spec, Google and Facebook will only implement what they need, and we can't force them to. Publishing RDFa Lite won't make a difference in that regard.
Stéphane Corlosquet: even if there is a full spec, Google and Facebook will only implement what they need, and we can't force them to. Publishing RDFa Lite won't make a difference in that regard. ←
14:14:33 <niklasl> q+ to ask about partial implementation
Niklas Lindström: q+ to ask about partial implementation ←
14:14:39 <gkellogg> … an extra RDFa 1.1 Lite document needs more work, but it seems like it's pretty close to being ready.
… an extra RDFa 1.1 Lite document needs more work, but it seems like it's pretty close to being ready. ←
14:14:43 <manu1> q+ to talk about the size of the RDFa Lite document
Manu Sporny: q+ to talk about the size of the RDFa Lite document ←
14:14:48 <manu1> ack niklasl
Manu Sporny: ack niklasl ←
14:14:48 <Zakim> niklasl, you wanted to ask about partial implementation
Zakim IRC Bot: niklasl, you wanted to ask about partial implementation ←
14:15:37 <gkellogg> niklasl: I agree that it shouldn't be a spec indicating that implementing a subset is acceptable. It might be interesting to see if there is some amount of detail that is required, so that people implementing a subset might be on reasonable ground.
Niklas Lindström: I agree that it shouldn't be a spec indicating that implementing a subset is acceptable. It might be interesting to see if there is some amount of detail that is required, so that people implementing a subset might be on reasonable ground. ←
14:15:47 <Zakim> -manu1
Zakim IRC Bot: -manu1 ←
14:16:12 <gkellogg> … important that they support chaining. I wonder if there is some way to write it so that we can give advice to subset implementations. "a skimming parser"
… important that they support chaining. I wonder if there is some way to write it so that we can give advice to subset implementations. "a skimming parser" ←
14:16:14 <Zakim> +manu1
Zakim IRC Bot: +manu1 ←
14:17:06 <gkellogg> manu: Don't know if we can write a spec in that way. If Google only implements half the spec, they should understand that they could mess something up.
Manu Sporny: Don't know if we can write a spec in that way. If Google only implements half the spec, they should understand that they could mess something up. ←
14:17:19 <gkellogg> … don't need to call out in the spec, but may broadcast on the mailing list.
… don't need to call out in the spec, but may broadcast on the mailing list. ←
14:17:36 <gkellogg> … nothing we can really do to require them to do a complete implementation.
… nothing we can really do to require them to do a complete implementation. ←
14:18:08 <gkellogg> … Google's main issue right now is in the complexity of authoring, not in their ability to parse. They care about simplified markup for authors more then implementation.
… Google's main issue right now is in the complexity of authoring, not in their ability to parse. They care about simplified markup for authors more then implementation. ←
14:18:23 <niklasl> q+
Niklas Lindström: q+ ←
14:18:27 <gkellogg> manu: I don't think we need to say anything more about implementing non-conformant processors.
Manu Sporny: I don't think we need to say anything more about implementing non-conformant processors. ←
14:18:44 <gkellogg> … want to keep document about current length, but should probably add some examples.
… want to keep document about current length, but should probably add some examples. ←
14:18:45 <manu1> ack manu
Manu Sporny: ack manu ←
14:18:45 <Zakim> manu, you wanted to talk about the size of the RDFa Lite document
Zakim IRC Bot: manu, you wanted to talk about the size of the RDFa Lite document ←
14:18:48 <manu1> ack niklasl
Manu Sporny: ack niklasl ←
14:19:16 <gkellogg> niklasl: we might want to indicate that @rel has more power than is realized.
Niklas Lindström: we might want to indicate that @rel has more power than is realized. ←
14:19:16 <manu1> q+ to say we don't need to say everything about RDFa.
Manu Sporny: q+ to say we don't need to say everything about RDFa. ←
14:19:44 <gkellogg> scor: disagree, most people won't care about power. They're go on Google WebMaster/Rich Snippet to get snippet recipes.
Stéphane Corlosquet: disagree, most people won't care about power. They're go on Google WebMaster/Rich Snippet to get snippet recipes. ←
14:19:55 <gkellogg> … 98% of schema.org implementations will just follow Google documentation.
… 98% of schema.org implementations will just follow Google documentation. ←
14:20:15 <gkellogg> … people who are hard core will read the full spec.
… people who are hard core will read the full spec. ←
14:20:18 <manu1> ack manu
Manu Sporny: ack manu ←
14:20:18 <Zakim> manu, you wanted to say we don't need to say everything about RDFa.
Zakim IRC Bot: manu, you wanted to say we don't need to say everything about RDFa. ←
14:20:46 <gkellogg> manu: agree with stephane - we don't need to go into detail about what you can and can't do with RDFa Lite.
Manu Sporny: agree with stephane - we don't need to go into detail about what you can and can't do with RDFa Lite. ←
14:21:38 <danbri> Manu said "Google's main issue right now is in the complexity of authoring, not in their ability to parse. They care about simplified markup for authors more then implementation." - that is correct.
Dan Brickley: Manu said "Google's main issue right now is in the complexity of authoring, not in their ability to parse. They care about simplified markup for authors more then implementation." - that is correct. ←
14:21:47 <gkellogg> niklasl: Indicating from Lite that more features are available in the full Core spec would probably be adequate.
Niklas Lindström: Indicating from Lite that more features are available in the full Core spec would probably be adequate. ←
14:22:09 <danbri> I've been watching the usability videos made around microdata; simplicity for authors is the main concern. Google know how to parse stuff.
Dan Brickley: I've been watching the usability videos made around microdata; simplicity for authors is the main concern. Google know how to parse stuff. ←
14:22:22 <gkellogg> manu: is this rec-track, or a note? We don't know right now.
Manu Sporny: is this rec-track, or a note? We don't know right now. ←
14:22:39 <gkellogg> … If Google is really adamant about it being a rec-track, we should figure out how to do it... but changes to RDFa Core 1.1 and a W3C Note about RDFa Lite may be enough.
… If Google is really adamant about it being a rec-track, we should figure out how to do it... but changes to RDFa Core 1.1 and a W3C Note about RDFa Lite may be enough. ←
14:23:50 <niklasl> q+
Niklas Lindström: q+ ←
14:24:05 <manu1> ack niklasl
Manu Sporny: ack niklasl ←
14:24:43 <gkellogg> niklasl: If critics have the opinion that @rel is _too_ much power, we still may get objections.
Niklas Lindström: If critics have the opinion that @rel is _too_ much power, we still may get objections. ←
14:25:22 <gkellogg> manu: I haven't seen them objecting to the existence of more advanced features, just the use of them.
Manu Sporny: I haven't seen them objecting to the existence of more advanced features, just the use of them. ←
14:26:21 <gkellogg> scor: it seems that the do a pretty good job parsing if prefixes are specified. It's definitely more than RDFa Lite. They want to promote simplicity for authors.
Stéphane Corlosquet: it seems that the do a pretty good job parsing if prefixes are specified. It's definitely more than RDFa Lite. They want to promote simplicity for authors. ←
14:26:46 <gkellogg> manu: ideal case is that RDFa 1.1 core is completely implemented.
Manu Sporny: ideal case is that RDFa 1.1 core is completely implemented. ←
14:27:02 <gkellogg> manu: any opposition to publishing as an editor's draft?
Manu Sporny: any opposition to publishing as an editor's draft? ←
14:27:23 <manu1> PROPOSAL: Publish RDFa Lite 1.1 as an Editors Draft in W3C-space.
PROPOSED: Publish RDFa Lite 1.1 as an Editors Draft in W3C-space. ←
14:27:24 <Steven> +1
Steven Pemberton: +1 ←
14:27:25 <manu1> +1
Manu Sporny: +1 ←
14:27:28 <scor> +1
Stéphane Corlosquet: +1 ←
14:27:28 <gkellogg> gkellogg: +1
Gregg Kellogg: +1 ←
14:27:29 <ShaneM> +1
Shane McCarron: +1 ←
14:27:36 <niklasl> +1
Niklas Lindström: +1 ←
14:27:42 <ShaneM> Note that the published space should be rdfa/drafts/2011...
Shane McCarron: Note that the published space should be rdfa/drafts/2011... ←
14:27:50 <manu1> RESOLVED: Publish RDFa Lite 1.1 as an Editors Draft in W3C-space.
RESOLVED: Publish RDFa Lite 1.1 as an Editors Draft in W3C-space. ←
14:28:02 <manu1> ACTION: Manu to publish RDFa Lite 1.1 as an Editors Draft.
ACTION: Manu to publish RDFa Lite 1.1 as an Editors Draft. ←
14:28:06 <danbri> yay :)
Dan Brickley: yay :) ←
14:28:27 <manu1> Topic: Gregg's @property proposal
14:28:37 <manu1> http://www.w3.org/2010/02/rdfa/wiki/RDFaLiteWithProperty
Manu Sporny: http://www.w3.org/2010/02/rdfa/wiki/RDFaLiteWithProperty ←
14:28:41 <manu1> scribenick: manu1
(Scribe set to Manu Sporny)
14:29:04 <manu1> Gregg: I've been working a good bit w/ Microdata and convergence - got familiar w/ processing rules.
Gregg Kellogg: I've been working a good bit w/ Microdata and convergence - got familiar w/ processing rules. ←
14:29:41 <manu1> Gregg: I use the Microdata API extensively - Microdata can use @itemprop for literals and URIs - in their case, they do it by knowing exactly which HTML attributes matter (@href, @data, @src, etc.)
Gregg Kellogg: I use the Microdata API extensively - Microdata can use @itemprop for literals and URIs - in their case, they do it by knowing exactly which HTML attributes matter (@href, @data, @src, etc.) ←
14:30:18 <manu1> Gregg: My proposal is to have @property do effectively the same thing - if there is an element that has @property and @src, @href or @data, it would generate an IRI ref, otherwise, it would pick up the literal.
Gregg Kellogg: My proposal is to have @property do effectively the same thing - if there is an element that has @property and @src, @href or @data, it would generate an IRI ref, otherwise, it would pick up the literal. ←
14:30:35 <manu1> Gregg: If there is a @rel and @property on the same element, it acts as it does in RDFa 1.0 now
Gregg Kellogg: If there is a @rel and @property on the same element, it acts as it does in RDFa 1.0 now ←
14:31:10 <manu1> Gregg: A separate part of the proposal is to allow chaining via: @about or @typeof + @property - explicit chaining... vs. the implicit chaining in @rel
Gregg Kellogg: A separate part of the proposal is to allow chaining via: @about or @typeof + @property - explicit chaining... vs. the implicit chaining in @rel ←
14:31:56 <Steven> q+
Steven Pemberton: q+ ←
14:32:07 <manu1> Gregg: We could come to a 1-to-1 equivalence w/ RDFa and Microdata with this approach - it gets rid of much of the rationale for Microdata.
Gregg Kellogg: We could come to a 1-to-1 equivalence w/ RDFa and Microdata with this approach - it gets rid of much of the rationale for Microdata. ←
14:32:15 <manu1> Steven: This makes RDFa less simple than more simple. It adds complexity.
Steven Pemberton: This makes RDFa less simple than more simple. It adds complexity. ←
14:32:23 <niklasl> q+ to ask about itemscope
Niklas Lindström: q+ to ask about itemscope ←
14:32:57 <manu1> Steven: All of a sudden, a different attribute does different things based on context... I like the simplicity of @property and @rel - they each do one job and one job well. If there is a 1-to-1 mapping between MD and RDFa, then you could make the counter point - why have RDFa?
Steven Pemberton: All of a sudden, a different attribute does different things based on context... I like the simplicity of @property and @rel - they each do one job and one job well. If there is a 1-to-1 mapping between MD and RDFa, then you could make the counter point - why have RDFa? ←
14:33:10 <manu1> Gregg: Well, not one to one - RDFa is a strict superset of Microdata.
Gregg Kellogg: Well, not one to one - RDFa is a strict superset of Microdata. ←
14:33:42 <manu1> Gregg: If we were to do RDFa again - we'd probably not use @rel.
Gregg Kellogg: If we were to do RDFa again - we'd probably not use @rel. ←
14:34:09 <manu1> Gregg: Danbri has made the point that people misuse @rel. I've also said that people get confused with @rel when used with @about.
Gregg Kellogg: Danbri has made the point that people misuse @rel. I've also said that people get confused with @rel when used with @about. ←
14:34:18 <manu1> ack Steven
ack Steven ←
14:34:26 <manu1> ack niklasl
ack niklasl ←
14:34:26 <Zakim> niklasl, you wanted to ask about itemscope
Zakim IRC Bot: niklasl, you wanted to ask about itemscope ←
14:34:39 <manu1> niklasl: Do you need itemscope for chaining in Microdata?
Niklas Lindström: Do you need itemscope for chaining in Microdata? ←
14:34:41 <manu1> Gregg: yes, you do.
Gregg Kellogg: yes, you do. ←
14:34:46 <danbri> Not concerned so much about mis-use, as confusion; if I go a few months without writing RDFa, I'm guaranteed to mix the two attributes up.
Dan Brickley: Not concerned so much about mis-use, as confusion; if I go a few months without writing RDFa, I'm guaranteed to mix the two attributes up. ←
14:34:51 <manu1> niklasl: Well, that's a difference from this suggestion.
Niklas Lindström: Well, that's a difference from this suggestion. ←
14:35:27 <manu1> Gregg: You could remove itemscope and get the same results - it is a difference, but RDFa doesn't need something like itemscope.
Gregg Kellogg: You could remove itemscope and get the same results - it is a difference, but RDFa doesn't need something like itemscope. ←
14:36:16 <manu1> Gregg: Microdata does have a different processing model - it's not a graph, it produces items. Things aren't coalesced like they are in RDFa. With the processing rule changes I'm proposing, however, we are more or less functionally equivalent.
Gregg Kellogg: Microdata does have a different processing model - it's not a graph, it produces items. Things aren't coalesced like they are in RDFa. With the processing rule changes I'm proposing, however, we are more or less functionally equivalent. ←
14:36:23 <manu1> niklasl: I wasn't thinking of adding itemscope
Niklas Lindström: I wasn't thinking of adding itemscope ←
14:36:45 <manu1> niklasl: One could view this change as more complex - you could argue that it's not as complex as Microdata because you don't need @itemscope.
Niklas Lindström: One could view this change as more complex - you could argue that it's not as complex as Microdata because you don't need @itemscope. ←
14:37:06 <manu1> scor: I echo Gregg's comment - people get @property and @rel mixed up.
Stéphane Corlosquet: I echo Gregg's comment - people get @property and @rel mixed up. ←
14:38:28 <manu1> manu1: Gregg's proposal can really be broken into two parts. The first is allowing @property to apply to @href and @src if @rel isn't on the same element. The second is allowing @property to kick-start chaining, which is a little more controversial.
Manu Sporny: Gregg's proposal can really be broken into two parts. The first is allowing @property to apply to @href and @src if @rel isn't on the same element. The second is allowing @property to kick-start chaining, which is a little more controversial. ←
14:43:59 <niklasl> q+
(No events recorded for 5 minutes)
Niklas Lindström: q+ ←
14:46:06 <manu1> ack niklasl
ack niklasl ←
14:46:33 <gkellogg> scor: If we look at the big picture, we should be happy Google's still considering RDFa.
Stéphane Corlosquet: If we look at the big picture, we should be happy Google's still considering RDFa. [ Scribe Assist by Gregg Kellogg ] ←
14:46:37 <manu1> Manu: I'm concerned that we make a bunch of semi-complex changes to RDFa and then Google decides to not adopt it anyway.
Manu Sporny: I'm concerned that we make a bunch of semi-complex changes to RDFa and then Google decides to not adopt it anyway. ←
14:48:16 <gkellogg> scribenick: gkellogg
(Scribe set to Gregg Kellogg)
14:46:56 <gkellogg> … we have the choice of making their changes, or ignoring the changes if there is no data to backup the request for changes.
… we have the choice of making their changes, or ignoring the changes if there is no data to backup the request for changes. ←
14:47:29 <gkellogg> niklasl: can they really say they won't support RDFa now?
Niklas Lindström: can they really say they won't support RDFa now? ←
14:47:43 <gkellogg> manu: We should assume that Google has the best interest of developers in mind.
Manu Sporny: We should assume that Google has the best interest of developers in mind. ←
14:48:15 <niklasl> q+ on the nature/direction of a smarter @property
Niklas Lindström: q+ on the nature/direction of a smarter @property ←
14:48:16 <gkellogg> manu: We should do everything we can to address developer concerns... that should be our focus.
Manu Sporny: We should do everything we can to address developer concerns... that should be our focus. ←
14:48:40 <gkellogg> … if Gregg's proposal helps, based on a data analysis, we should move forward with it.
… if Gregg's proposal helps, based on a data analysis, we should move forward with it. ←
14:49:16 <gkellogg> … Depends on if Google is committed to adopting RDFa 1.1 Lite, if they want more changes, it needs to be backed up by data, based on markup in the wild.
… Depends on if Google is committed to adopting RDFa 1.1 Lite, if they want more changes, it needs to be backed up by data, based on markup in the wild. ←
14:49:37 <danbri> re "I'm concerned that we make a bunch of semi-complex changes to RDFa and then Google decides to not adopt it anyway.", best thing is to get a clear target for review written down asap. http://manu.sporny.org/rdfa/lite/ is excellent start imho.
Dan Brickley: re "I'm concerned that we make a bunch of semi-complex changes to RDFa and then Google decides to not adopt it anyway.", best thing is to get a clear target for review written down asap. http://manu.sporny.org/rdfa/lite/ is excellent start imho. ←
14:49:48 <gkellogg> … if we can point to a dataset that would be objectively improved with the @property changes, we should move forward.
… if we can point to a dataset that would be objectively improved with the @property changes, we should move forward. ←
14:50:29 <danbri> For a non-Google web crawl data, perhaps http://www.commoncrawl.org/ is worth a look? I know nothing beyond having found the link this week...
Dan Brickley: For a non-Google web crawl data, perhaps http://www.commoncrawl.org/ is worth a look? I know nothing beyond having found the link this week... ←
14:50:31 <gkellogg> scor: please read Henri Sivonen's email about breaking backwards compat based on implementation experience:
Stéphane Corlosquet: please read Henri Sivonen's email about breaking backwards compat based on implementation experience: ←
14:51:10 <manu1> Henri's e-mail: http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0266.html
Manu Sporny: Henri's e-mail: http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0266.html ←
14:51:34 <manu1> niklasl: I'm not opposed to the @property change - it does make RDFa more about figuring out what the author means...
Niklas Lindström: I'm not opposed to the @property change - it does make RDFa more about figuring out what the author means... [ Scribe Assist by Manu Sporny ] ←
14:51:35 <gkellogg> niklasl: it does complicate processing, but it makes @property smarter, which gets closer to user's meaning.
Niklas Lindström: it does complicate processing, but it makes @property smarter, which gets closer to user's meaning. ←
14:51:48 <niklasl> .. <meta property="foaf:homepage" content="http://example.org/about-me">
Niklas Lindström: .. <meta property="foaf:homepage" content="http://example.org/about-me"> ←
14:52:11 <gkellogg> … if it's a good way to go...
… if it's a good way to go... ←
14:52:49 <gkellogg> niklasl: if property is made smarter, should we also make @content smarter: figure out if it's a link, date, etc.
Niklas Lindström: if property is made smarter, should we also make @content smarter: figure out if it's a link, date, etc. ←
14:52:57 <gkellogg> q+
q+ ←
14:53:07 <manu1> ack niklasl
Manu Sporny: ack niklasl ←
14:53:07 <Zakim> niklasl, you wanted to comment on the nature/direction of a smarter @property
Zakim IRC Bot: niklasl, you wanted to comment on the nature/direction of a smarter @property ←
14:53:09 <manu1> ack gkellogg
Manu Sporny: ack gkellogg ←
14:53:58 <manu1> gkellogg: @datetime going away in favor of something else - explicit datatyping of literals is a problem as well - people expect to get it out of their vocabs. There is some chance that you can do a part of that via post-processing.
Gregg Kellogg: @datetime going away in favor of something else - explicit datatyping of literals is a problem as well - people expect to get it out of their vocabs. There is some chance that you can do a part of that via post-processing. [ Scribe Assist by Manu Sporny ] ←
14:54:24 <manu1> gkellogg: You can't know if it is rdf:XMLLiteral - perhaps having some rules in @content where you do lexical analysis might be useful.
Gregg Kellogg: You can't know if it is rdf:XMLLiteral - perhaps having some rules in @content where you do lexical analysis might be useful. [ Scribe Assist by Manu Sporny ] ←
14:54:30 <manu1> q+ to talk about lexical analysis.
Manu Sporny: q+ to talk about lexical analysis. ←
14:55:03 <gkellogg> niklasl: argument against implicit processing is the title "1984" as a novel, not a number.
Niklas Lindström: argument against implicit processing is the title "1984" as a novel, not a number. ←
14:55:03 <manu1> niklasl: Lexical analysis in @content would be okay?
Niklas Lindström: Lexical analysis in @content would be okay? [ Scribe Assist by Manu Sporny ] ←
14:55:08 <manu1> ack manu
Manu Sporny: ack manu ←
14:55:09 <Zakim> manu, you wanted to talk about lexical analysis.
Zakim IRC Bot: manu, you wanted to talk about lexical analysis. ←
14:55:45 <gkellogg> manu: previous discussions on literal processing had a pretty strong feeling against this, and nothing's really changed.
Manu Sporny: previous discussions on literal processing had a pretty strong feeling against this, and nothing's really changed. ←
14:56:08 <gkellogg> … these things tend to be application dependent, and the application does this if they need to.
… these things tend to be application dependent, and the application does this if they need to. ←
14:56:47 <gkellogg> … there is a desire for automatic data typing, but it seems to be worth separating this into an application specific structure.
… there is a desire for automatic data typing, but it seems to be worth separating this into an application specific structure. ←
14:57:19 <gkellogg> … considering recipes, e.g., temperatures use different units in different parts of the world.
… considering recipes, e.g., temperatures use different units in different parts of the world. ←
14:57:29 <niklasl> q+
Niklas Lindström: q+ ←
14:57:41 <gkellogg> … specifying the units in the vocabulary creates problems.
… specifying the units in the vocabulary creates problems. ←
14:58:11 <gkellogg> … we decided before not to do lexical analysis and really shouldn't re-visit.
… we decided before not to do lexical analysis and really shouldn't re-visit. ←
14:58:22 <manu1> ack niklasl
Manu Sporny: ack niklasl ←
14:58:53 <niklasl> .. <meta property="og:type" content="recipebox:recipe" />
Niklas Lindström: .. <meta property="og:type" content="recipebox:recipe" /> ←
14:58:53 <gkellogg> niklasl: would like to revisit lexical analysis on mailing list.
Niklas Lindström: would like to revisit lexical analysis on mailing list. ←
14:59:24 <gkellogg> … meta processing is an example, as this represents a type, not a string.
… meta processing is an example, as this represents a type, not a string. ←
15:00:17 <gkellogg> manu: we might want to say something about @property, but we could indicate that the group has interest in the change.
Manu Sporny: we might want to say something about @property, but we could indicate that the group has interest in the change. ←
15:00:56 <gkellogg> niklasl: if there's imperial evidence, we should do it, otherwise not.
Niklas Lindström: if there's imperial evidence, we should do it, otherwise not. ←
15:01:22 <manu1> PROPOSAL: If there is empirical evidence that we should support @property applying to @href, and @src if there is no @rel on the element, then we should think very strongly about doing it.
PROPOSED: If there is empirical evidence that we should support @property applying to @href, and @src if there is no @rel on the element, then we should think very strongly about doing it. ←
15:01:27 <gkellogg> gkellogg: +1
Gregg Kellogg: +1 ←
15:01:29 <manu1> +1
Manu Sporny: +1 ←
15:01:35 <Steven> +0
Steven Pemberton: +0 ←
15:01:37 <niklasl> +1
Niklas Lindström: +1 ←
15:01:43 <ShaneM> +0
Shane McCarron: +0 ←
15:02:19 <scor> +1
Stéphane Corlosquet: +1 ←
15:02:23 <manu1> RESOLVED: If there is empirical evidence that we should support @property applying to @href, and @src if there is no @rel on the element, then we should think very strongly about doing it.
RESOLVED: If there is empirical evidence that we should support @property applying to @href, and @src if there is no @rel on the element, then we should think very strongly about doing it. ←
15:03:47 <gkellogg> manu: next week's call is 1 hour earlier for EU, which is going on DST.
Manu Sporny: next week's call is 1 hour earlier for EU, which is going on DST. ←
15:03:52 <Zakim> -ShaneM
Zakim IRC Bot: -ShaneM ←
15:03:56 <Zakim> -Steven
Zakim IRC Bot: -Steven ←
15:03:58 <Zakim> -scor
Zakim IRC Bot: -scor ←
15:04:02 <Zakim> -manu1
Zakim IRC Bot: -manu1 ←
15:04:03 <Zakim> -niklasl
Zakim IRC Bot: -niklasl ←
15:04:32 <Zakim> -gkellogg
Zakim IRC Bot: -gkellogg ←
15:04:33 <Zakim> SW_RDFa()10:00AM has ended
Zakim IRC Bot: SW_RDFa()10:00AM has ended ←
15:04:36 <Zakim> Attendees were manu1, ShaneM, niklasl, gkellogg, Steven, scor
Zakim IRC Bot: Attendees were manu1, ShaneM, niklasl, gkellogg, Steven, scor ←
Formatted by CommonScribe
This revision (#2) generated 2011-10-28 12:33:34 UTC by 'ivan', comments: None