Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On Feb 2, 2007, at 2:57 PM, Ara Pehlivanian wrote: On 2/1/07, John Allsopp [EMAIL PROTECTED] wrote: use case - sure - for example, at our conference sites, we markup speakers with hCard, and this often includes a link to their blog etc. In this case, a link to an authoritative (or perhaps, to be even less strict detailed) hCard may be somethign that is very useful. If I understand the spec correctly, since a rel=me is symmetric, shouldn't the hCard you're pointing to also be pointing back? If that's true, then the authoritative hCard will quickly get unmanageable since it will contain tens if not hundreds of reciprocal links to partial hCards (imagine if you're listed in several different locale directories marked up with hCard). You're right, rel=me requires symmetry in order to be trusted at all. For this reason, and others XFN is not the simplest way to do Authoritative hCards. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On 2/7/07, Ryan King [EMAIL PROTECTED] wrote: You're right, rel=me requires symmetry in order to be trusted at all. For this reason, and others XFN is not the simplest way to do Authoritative hCards. I guess the real question is, who will be creating the partial hCards that will be referring to the authoritative hCard? If the answer is, the owner of the authoritative hCard then the scenario is manageable and the owner can update the authoritative hCard at their leisure to reflect the partial ones created. However, if the answer is, anyone then the spec is impossible to support because the author of the authoritative hCard has absolutely no way of tracking all of the partial cards referring to the authoritative one. A prime example is if you're a speaker at a conf. and the organizers put together a simple hCard with your name in it and point to your authoritative hCard. Worse still, if a phone directory site marks up their results with hCard, how would you ever know to link to it? Which page would you link to (as results tend to have multiple views). The worst part of either scenario is the idea that your authoritative hCard will keep growing with all this unsightly references to lesser cards. It's a maintenance and aesthetic nightmare. I say we should find a better way of doing this. A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On 2/7/07, Ara Pehlivanian [EMAIL PROTECTED] wrote: On 2/7/07, Ryan King [EMAIL PROTECTED] wrote: You're right, rel=me requires symmetry in order to be trusted at all. For this reason, and others XFN is not the simplest way to do Authoritative hCards. I guess the real question is, who will be creating the partial hCards that will be referring to the authoritative hCard? If the answer is, the owner of the authoritative hCard then the scenario is manageable and the owner can update the authoritative hCard at their leisure to reflect the partial ones created. However, if the answer is, anyone then the spec is impossible to support because the author of the authoritative hCard has absolutely no way of tracking all of the partial cards referring to the authoritative one. A prime example is if you're a speaker at a conf. and the organizers put together a simple hCard with your name in it and point to your authoritative hCard. Worse still, if a phone directory site marks up their results with hCard, how would you ever know to link to it? Which page would you link to (as results tend to have multiple views). The worst part of either scenario is the idea that your authoritative hCard will keep growing with all this unsightly references to lesser cards. It's a maintenance and aesthetic nightmare. I think you're missing a stage: - fragment hcard (anywhere on the net by anybody) - points to home page, using class=url - home page, using class=something rel=something-else, points to authoritative hcard e.g. Ryan King hCards in the wild point to http://www.ryanking.com; http://www.ryanking.com (somehow) points to http://www.ryanking.com/contact/ which has his authoritative hCard. At most one back reference is required. Regard, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On 2/7/07, David Janes [EMAIL PROTECTED] wrote: I think you're missing a stage: - fragment hcard (anywhere on the net by anybody) - points to home page, using class=url - home page, using class=something rel=something-else, points to authoritative hcard e.g. Ryan King hCards in the wild point to http://www.ryanking.com; http://www.ryanking.com (somehow) points to http://www.ryanking.com/contact/ which has his authoritative hCard. At most one back reference is required. Is that the intended use though? Just managing the authoritative hCard within a domain? A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On 2/7/07, Ara Pehlivanian [EMAIL PROTECTED] wrote: On 2/7/07, David Janes [EMAIL PROTECTED] wrote: I think you're missing a stage: - fragment hcard (anywhere on the net by anybody) - points to home page, using class=url - home page, using class=something rel=something-else, points to authoritative hcard e.g. Ryan King hCards in the wild point to http://www.ryanking.com; http://www.ryanking.com (somehow) points to http://www.ryanking.com/contact/ which has his authoritative hCard. At most one back reference is required. Is that the intended use though? Just managing the authoritative hCard within a domain? No, Ryan King could have his authoritative hCard on LinkedIn (hypothetical example). He still, however, refers to himself in his hCards as url=http://www.ryanking.com (real example). -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On Feb 7, 2007, Ryan King wrote: 2. We have prior art that is being ignored. Publishers are already using a class=url uid ../a to do this. However, UID is not a field that takes a URL for its value, just a string, so therefore: a class=url uid href=http://ryancannon.com/;Ryan/a Should be parsed as URL: http;//ryancannon.com/ UID: Ryan Right? So while UID seems like the right value to use, according to my reading of the spec, UID has to sit in visible text, and could be any sort of number--like an American social security number or a mobile phone number with country code--both of those are usually globally unique individual identifiers. -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On Feb 7, 2007, at 1:44 PM, Ryan Cannon wrote: On Feb 7, 2007, Ryan King wrote: 2. We have prior art that is being ignored. Publishers are already using a class=url uid ../a to do this. However, UID is not a field that takes a URL for its value, just a string, so therefore: a class=url uid href=http://ryancannon.com/;Ryan/a Should be parsed as URL: http;//ryancannon.com/ UID: Ryan Right? So while UID seems like the right value to use, according to my reading of the spec, UID has to sit in visible text, and could be any sort of number--like an American social security number or a mobile phone number with country code--both of those are usually globally unique individual identifiers. Indeed, in vcard UID is just a string, but my proposal is that we make it by default a URL. It's a simple change (which may already be implemented in X2V). -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On Feb 2, 2007, at 2:57 PM, Ara Pehlivanian wrote: On 2/1/07, John Allsopp [EMAIL PROTECTED] wrote: use case - sure - for example, at our conference sites, we markup speakers with hCard, and this often includes a link to their blog etc. In this case, a link to an authoritative (or perhaps, to be even less strict detailed) hCard may be somethign that is very useful. If I understand the spec correctly, since a rel=me is symmetric, shouldn't the hCard you're pointing to also be pointing back? If that's true, then the authoritative hCard will quickly get unmanageable since it will contain tens if not hundreds of reciprocal links to partial hCards (imagine if you're listed in several different locale directories marked up with hCard). Indeed, it seems the me attribute from xfn may not be entirely desirable. Is it even needed for a master/authoritative hCards to recognize their children? -Colin ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On 2/4/07, Colin Barrett [EMAIL PROTECTED] wrote: Indeed, it seems the me attribute from xfn may not be entirely desirable. Is it even needed for a master/authoritative hCards to recognize their children? -Colin I can see a use for it. For example, I'd like to primarily identify myself with a single URI [1]. From that starting point, I could (for example) point to my own hand constructed hCard elsewhere or I could use a professional service, such as LinkedIn. On the authorative hCard, I could then backlink to [1] and this would provide protection against one form (and I know there's many others) of identity hijacking. Regards, etc... [1] http://www.davidjanes.com -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On Feb 4, 2007, at 2:45 AM, David Janes wrote: On 2/4/07, Colin Barrett [EMAIL PROTECTED] wrote: Indeed, it seems the me attribute from xfn may not be entirely desirable. Is it even needed for a master/authoritative hCards to recognize their children? -Colin I can see a use for it. For example, I'd like to primarily identify myself with a single URI [1]. From that starting point, I could (for example) point to my own hand constructed hCard elsewhere or I could use a professional service, such as LinkedIn. On the authorative hCard, I could then backlink to [1] and this would provide protection against one form (and I know there's many others) of identity hijacking. Regards, etc... I should have reworded: Is it necessary for authoritative hCards to recognize ALL their children? It might also be semantically wrong to put rel=me on a link to an hCard that isn't on a site that's your own, anyway. -Colin ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
In message [EMAIL PROTECTED], John Allsopp [EMAIL PROTECTED] writes me self can't be anything but tautological; nor is it appropriate when referring to third parties. so: in English, it is tautological. But restricting the words to their roles in XFN and Atom, they mean quite different things - so I'd respectfully argue that the construction isn't in this context tautological. for people first ? The third party issue (I take it to mean that you can't refer to an authoritative third party hCard for someone else using m, which is quite correct). I think that's a separate and more complex issue - how, if at all, can you link to an authoritative hCard for someone else. Is there a use case - sure - for example, at our conference sites, we markup speakers with hCard, and this often includes a link to their blog etc. In this case, a link to an authoritative (or perhaps, to be even less strict detailed) hCard may be somethign that is very useful. I think you just answered your own question. -- Andy Mabbett http://www.pigsonthewing.org.uk/uFsig/ Welcome to the 30-day week! ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
Andy, (apologies for the tardiness, I'm in one of those old fashioned, unconnected airomoplanes) me self can't be anything but tautological; nor is it appropriate when referring to third parties. so: in English, it is tautological. But restricting the words to their roles in XFN and Atom, they mean quite different things - so I'd respectfully argue that the construction isn't in this context tautological. The third party issue (I take it to mean that you can't refer to an authoritative third party hCard for someone else using m, which is quite correct). I think that's a separate and more complex issue - how, if at all, can you link to an authoritative hCard for someone else. Is there a use case - sure - for example, at our conference sites, we markup speakers with hCard, and this often includes a link to their blog etc. In this case, a link to an authoritative (or perhaps, to be even less strict detailed) hCard may be somethign that is very useful. -1 but isn't this sort of voting better done on the wiki than in a mailing list? rough consensus - many more people see this mailing list regularly than visit the wiki frequently (I'd suggest) so for gaining a sense of rough consensus in a shortish timeframe (my original +1 was informal) the mailing list does seem to me to be an appropriate location for such straw polls. j ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
Ara, the point is that with rel/rev in particular, it has confused *even the people that are supposed to be experts*. As Ryan points out, I myself got it wrong when I initially proposed to Kevin Marks that we use 'rel' for VoteLinks instead of their initial idea of using a new HTML attribute 'vote'. In fact I can say that *everyone* (without exception) I have spoken with who has tried to use rel/rev has made this mistake at some point, including a lot of the people on this list. The 'rel' / 'rev' distinction is perhaps one of *the most* confusing things in HTML4 (if not *the most confusing*). It is an outlier in the extent of confusion caused. Tantek/Ryan, So how would you suggest that I mark up the link on the page that was voted for that's pointing back to the voter? After all this back and forth, I'm really curious because I have yet to receive a concrete example. Thanks! A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On Jan 22, 2007, at 12:24 PM, Ara Pehlivanian wrote: This is a very, very common mistake. So common, in fact, that the current HTML5 draft drops @rev. In the interest of keeping vote-links future compatible, we should rely on using both rel and rev. See the rel-faq [http://microformats.org/wiki/rel-faq#Should_.27rev. 27_even_be_used]. See, now THAT doesn't make sense. I just understood the difference between rev and rel in relation to a Vote Link, and you need both. In fact, any HTML spec should keep it--and doing away with it because it's a common mistake is plain silly. It's too bad that the folks doing HTML5 are cutting it out. Maybe we can convince them otherwise. They'll be hobbling the spec if they do. I disagree. First of all, you don't need both @rel and @rev for votelinks. Right now you just need @rev to declare votes. Linking in the opposite direction doesn't add anything, as it is a 3rd party assertion (or hearsay). Secondly, if people can't figure out how to use it properly, they'll use it improperly. Then people building tools will have to deal with that confusion. It's better to just make the technology simpler and unambiguous. Removing @rev is not hobbling HTML5. Very few people who use it properly and even more use it improperly. See Google Web Authoring statistics for more data [1]. -ryan 1. http://code.google.com/webstats/index.html -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
I disagree. First of all, you don't need both @rel and @rev for votelinks. Right now you just need @rev to declare votes. Linking in the opposite direction doesn't add anything, as it is a 3rd party assertion (or hearsay). Secondly, if people can't figure out how to use it properly, they'll use it improperly. Then people building tools will have to deal with that confusion. It's better to just make the technology simpler and unambiguous. Removing @rev is not hobbling HTML5. Very few people who use it properly and even more use it improperly. See Google Web Authoring statistics for more data [1]. As I'm sure you're already aware, two discreet bits of data are communicated via the rev/rel attributes. The attribute itself communicates the direction of the relationship while the value states the type of relationship. By dropping one of the directions, you introduce ambiguity in the data. At least one real world example for the implementation of a rev/rel relationship exists: my previously stated site of the month scenario. A vote using rev is made for a site of the month. That site in turn will link back to the originator via an icon with a rel. This would properly describe the forward/reverse relationships between sites. To a machine crawling the vote icon (rel), it will properly pick up the URL of as the source for the vote and not a site that's being voted for. Similarly, if a machine were to crawl the site where the sites of the month are picked, it would know that this is the originator who is voting (rev). The ambiguity caused by ignoring the direction of the vote could really throw off stats when tallying votes. And that's just one example. I don't agree that rev should be dropped in order to fall in line with the way rel is being (badly) used today. Rather, if a change is to be made to the spec, it would make more sense to revisit the entire attribute set so as to come up with something that is easier to use/understand while still being able to define a direction for the relationship as well as a type. Either that, or we should stick with the existing spec and simply require developers to understand and use it correctly. Nobody dumbs down compilers because of thick coders, why is this any different? It took me a couple of posts on this list and I ended up learning. If the spec just ends up bending to the popular usage, then what's the point behind the standards movement? We may as well invest our time writing better error correction. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On Jan 23, 2007, at 10:44 AM, Ara Pehlivanian wrote: I disagree. First of all, you don't need both @rel and @rev for votelinks. Right now you just need @rev to declare votes. Linking in the opposite direction doesn't add anything, as it is a 3rd party assertion (or hearsay). Secondly, if people can't figure out how to use it properly, they'll use it improperly. Then people building tools will have to deal with that confusion. It's better to just make the technology simpler and unambiguous. Removing @rev is not hobbling HTML5. Very few people who use it properly and even more use it improperly. See Google Web Authoring statistics for more data [1]. As I'm sure you're already aware, two discreet bits of data are communicated via the rev/rel attributes. The attribute itself communicates the direction of the relationship while the value states the type of relationship. By dropping one of the directions, you introduce ambiguity in the data. I understand that the attributes, as defined specify the direction of the relationship. However, it has been found in practice that people confuse these and misuse the two attributes. So, that ambiguity is already there in practice, but not reflected in the specification. HTML5 is a step towards having the spec better line up with the real world. At least one real world example for the implementation of a rev/rel relationship exists: my previously stated site of the month scenario. A vote using rev is made for a site of the month. That site in turn will link back to the originator via an icon with a rel. This would properly describe the forward/reverse relationships between sites. To a machine crawling the vote icon (rel), it will properly pick up the URL of as the source for the vote and not a site that's being voted for. Similarly, if a machine were to crawl the site where the sites of the month are picked, it would know that this is the originator who is voting (rev). The ambiguity caused by ignoring the direction of the vote could really throw off stats when tallying votes. And that's just one example. I'm not saying we should ignore the direction of links. I'm saying that we can only really annotate them in one direction. As someone who works for a search engine, I can safely say that third-party assertions (eg, that site over there voted for me) are unhelpful and usually ignored. I don't agree that rev should be dropped in order to fall in line with the way rel is being (badly) used today. Rather, if a change is to be made to the spec, it would make more sense to revisit the entire attribute set so as to come up with something that is easier to use/understand while still being able to define a direction for the relationship as well as a type. WHATWG's mission is to make HTML5 backwards compatible with the way that HTML4 is deployed today. Revisiting the entire attribute set would be out of the question. But, of course, I can't speak for them. To reiterate my main point, @rel and @rev are often confused by web authors today, which means that people writing consuming applications must treat them as such. When a web page says link rev=stylesheet .../ you can't take it at it's word. That's just the way things are, and it'd be unreasonable to try and change the entire web to work in 'strict mode'. Either that, or we should stick with the existing spec and simply require developers to understand and use it correctly. Nobody dumbs down compilers because of thick coders, why is this any different? It took me a couple of posts on this list and I ended up learning. I wouldn't call people 'thick' just because they don't understand the difference between @rev and @rel. I've seen numerous people (myself included) mistake the two. Hey Tantek, why don't you tell everyone the story about how you and Kevin confused the two and wrote the wrong one into vote-links? :D If the spec just ends up bending to the popular usage, then what's the point behind the standards movement? We may as well invest our time writing better error correction. The point is to build interoperable implementations, not make ideally pure languages. If you'll go read more about HTML5, you'd realize that large parts of its parsing section are about specifying a common error handling mechanism. Without that, there's little hope of having large numbers of user agents who can interpret an HTML document the same way. Also, 'bending to popular usage' is what microformats are all about. We try and figure out how people are already using the web, the vocabulary that they use and the common use cases, then document that into a microformat. Formats and applications should follow behavior, not try and create it. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
I understand that the attributes, as defined specify the direction of the relationship. However, it has been found in practice that people confuse these and misuse the two attributes. So, that ambiguity is already there in practice, but not reflected in the specification. HTML5 is a step towards having the spec better line up with the real world. Is the direction being maintained or dropped in the HTML5 spec? I'm not saying we should ignore the direction of links. I'm saying that we can only really annotate them in one direction. As someone who works for a search engine, I can safely say that third-party assertions (eg, that site over there voted for me) are unhelpful and usually ignored. Does that mean that search engines ignore XFN attributes? What defines a third party assertion and what makes a legitimate first-party assertion? WHATWG's mission is to make HTML5 backwards compatible with the way that HTML4 is deployed today. Revisiting the entire attribute set would be out of the question. But, of course, I can't speak for them. I can appreciate the need for backwards compatibility, though I had heard somewhere that HTML5 was redefining a lot of the existing markup (or was that XHTML 2?) To reiterate my main point, @rel and @rev are often confused by web authors today, which means that people writing consuming applications must treat them as such. When a web page says link rev=stylesheet .../ you can't take it at it's word. That's just the way things are, and it'd be unreasonable to try and change the entire web to work in 'strict mode'. You're right, the ambiguity already exists in the badly marked up data. But don't you think our effort should be spent educating those who are writing the code rather than compensating for their mistakes? Because the logical outcome to catering to their errors is a spec that evolves into something that doesn't make any sense. But if the apps that are crawling their sites don't pick up on their tags, they'll quickly wake up to the proper syntax. Kinda of like when Google doesn't crawl your site because you only have JavaScript generated navigation links. I think that there's room for compromise. I'm not saying let's force the web to run in strict mode per se, but if new apps being launched were a little less forgiving, people would adapt (and actually learn something in the process). I honestly believe the power to push people toward the adoption of standards (the spec) is in the hands of app developers and how lenient they choose to be with the data they consume. I wouldn't call people 'thick' just because they don't understand the difference between @rev and @rel. I've seen numerous people (myself included) mistake the two. Hey Tantek, why don't you tell everyone the story about how you and Kevin confused the two and wrote the wrong one into vote-links? :D I meant 'thick' in the nicest possible way (myself included). I'm more than willing to admit that there's a whole lot that I don't know and I don't appreciate for a moment that IE3/4 were forgiving of my bad markup when I was learning to build sites. I stagnated for a long time building crappy markup because of that. The point is to build interoperable implementations, not make ideally pure languages. If you'll go read more about HTML5, you'd realize that large parts of its parsing section are about specifying a common error handling mechanism. Without that, there's little hope of having large numbers of user agents who can interpret an HTML document the same way. I agree 100% with the idea of interoperability and a common interpretation of the spec in regards to error handling etc... But I think a line needs to be drawn in what's defined as an error. I think it's great that the browser doesn't break when I forget to close a p tag. But it shouldn't go ahead and plow through reams and reams of badly written code assuming I meant a when I wrote xyz. I should (as a developer worth his salt) learn to write a instead of xyz instead of writing garbage and expecting gold. What ever happened to GIGO? :-) Also, 'bending to popular usage' is what microformats are all about. We try and figure out how people are already using the web, the vocabulary that they use and the common use cases, then document that into a microformat. Formats and applications should follow behavior, not try and create it. I think that the spirit of microformats is right in adopting the standards that are in popular usage (ie adopting vcard for hcard). But at the same time, I think it's a mistake to adopt bad practices and use them because everybody does it. Best example of not doing this is the steady stream of developers now dropping table based design. The alternative would have been for the spec writers to say well, everyone's using it, let's just alter the spec in the next version to state that tables are also inteded for use in layout. I appreciate your taking the time to discuss this. A.
Re: [uf-discuss] Vote Links: rel=voted-for
On 1/23/07 12:15 PM, Ara Pehlivanian [EMAIL PROTECTED] wrote: I wouldn't call people 'thick' just because they don't understand the difference between @rev and @rel. I've seen numerous people (myself included) mistake the two. Hey Tantek, why don't you tell everyone the story about how you and Kevin confused the two and wrote the wrong one into vote-links? :D I meant 'thick' in the nicest possible way (myself included). I'm more than willing to admit that there's a whole lot that I don't know and I don't appreciate for a moment that IE3/4 were forgiving of my bad markup when I was learning to build sites. I stagnated for a long time building crappy markup because of that. Ara, the point is that with rel/rev in particular, it has confused *even the people that are supposed to be experts*. As Ryan points out, I myself got it wrong when I initially proposed to Kevin Marks that we use 'rel' for VoteLinks instead of their initial idea of using a new HTML attribute 'vote'. In fact I can say that *everyone* (without exception) I have spoken with who has tried to use rel/rev has made this mistake at some point, including a lot of the people on this list. The 'rel' / 'rev' distinction is perhaps one of *the most* confusing things in HTML4 (if not *the most confusing*). It is an outlier in the extent of confusion caused. Also, 'bending to popular usage' is what microformats are all about. We try and figure out how people are already using the web, the vocabulary that they use and the common use cases, then document that into a microformat. I know Ryan was summarizing, but to be clear (since this is a common misconception), how people are using the web is taken as an *input* to the process[1], NOT the conclusion. From those real world examples we produce analysis, implied schemas etc., and then take as additional input established vocabulary, formats etc. and synthesize them through the process into brainstorms which are eventually distilled into microformats. Formats and applications should follow behavior, not try and create it. Yes. Certainly for the 80/20 case. And certainly pre-existing behavior should drive the development of a format. Only in the rare case that there is no pre-existing behavior for a type of data does it make sense to try and invent, but that set of solutions is outside the scope of microformats since microformats are based on paving the cowpaths. I think that the spirit of microformats is right in adopting the standards that are in popular usage (ie adopting vcard for hcard). But at the same time, I think it's a mistake to adopt bad practices and use them because everybody does it. Agreed. Hence why I pointed out that existing practices are only an *input* to the process, not the conclusion. Best example of not doing this is the steady stream of developers now dropping table based design. The alternative would have been for the spec writers to say well, everyone's using it, let's just alter the spec in the next version to state that tables are also inteded for use in layout. Right, user/developer behavior is an indicator of the *need* for a solution, not necessarily the solution itself. Hence W3C took that behavior as input and produced CSS table layout as a solution, rather than simply saying go ahead and use table for layout. Thanks, Tantek [1] http://microformats.org/wiki/process ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
Ara, the point is that with rel/rev in particular, it has confused *even the people that are supposed to be experts*. As Ryan points out, I myself got it wrong when I initially proposed to Kevin Marks that we use 'rel' for VoteLinks instead of their initial idea of using a new HTML attribute 'vote'. In fact I can say that *everyone* (without exception) I have spoken with who has tried to use rel/rev has made this mistake at some point, including a lot of the people on this list. The 'rel' / 'rev' distinction is perhaps one of *the most* confusing things in HTML4 (if not *the most confusing*). It is an outlier in the extent of confusion caused. I think this issue is quickly becoming something that's probably better discussed in the HTML5 discussion forum and/or list. Because we're getting into a debate on whether or not we should keep/modify/alter the spec for @rev and @rel. And really, I don't even know if we're debating because believe me, I'm in complete agreement with you that trying to work out which to use is a royal pain in the neck. I'm not at all certain though that only one attribute is the best solution because in some applications, being able to communicate the direction of the relationship can be important. As a matter of fact I'm working on a WaSP proposal that would use the vote link spec to vote for articles on the web and it made sense to me that those documents could have rel links back to the WaSP voting page. My motivation for pushing the use of both rev and rel comes from roots in web standards and the idea that we should use the right tool for the right job, i.e. semantics. (bonus points to whoever knows the quote reference.) :-) A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On Jan 18, 2007, at 8:13 AM, Frances Berriman wrote: On 18/01/07, Ben Ward [EMAIL PROTECTED] wrote: On 18 Jan 2007, at 15:49, Frances Berriman wrote: Could Sites of the Month not just use rev=vote-for? As in - this site voted for me. Wrong way around Frances, I think. • rev=vote-for — 'this site is a vote for the href' • rel=vote-for — 'href is a vote for this site' Your concept is correct, though. It definitely seems like a valid case for a rel-vote. So: a href=http://back.to/site/a; title=Voted 'site of the month' by Site A' rel=vote-forSite of the Month!/a could be used to indicate your site had been 'voted for' by another. Doh! I think you're right. This is a very, very common mistake. So common, in fact, that the current HTML5 draft drops @rev. In the interest of keeping vote-links future compatible, we should rely on using both rel and rev. See the rel-faq [http://microformats.org/wiki/rel-faq#Should_.27rev. 27_even_be_used]. Anyway - the rev/rel relationsip basically means you (should) never have to extend your class names to do the other half of a partnership. In theory, yes, but in practice we can't make use of both rel and rev. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
This is a very, very common mistake. So common, in fact, that the current HTML5 draft drops @rev. In the interest of keeping vote-links future compatible, we should rely on using both rel and rev. See the rel-faq [http://microformats.org/wiki/rel-faq#Should_.27rev. 27_even_be_used]. See, now THAT doesn't make sense. I just understood the difference between rev and rel in relation to a Vote Link, and you need both. In fact, any HTML spec should keep it--and doing away with it because it's a common mistake is plain silly. It's too bad that the folks doing HTML5 are cutting it out. Maybe we can convince them otherwise. They'll be hobbling the spec if they do. A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
I don't agree that you can simply use rel=vote-for because it incorrectly gives the impression that you're voting for when really you were voted for, hence my suggestion to use the following: rev=vote-for rev=vote-against rev=vote-abstain rel=voted-for rel=voted-against rel=vote-abstained Because really, the relationship isn't the same in both directions. So do I just edit the wiki? (or will that get me a slap on the wrists?) A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On 18 Jan 2007, at 21:23, Ara Pehlivanian wrote: I don't agree that you can simply use rel=vote-for because it incorrectly gives the impression that you're voting for when really you were voted for, It doesn't give the impression that you're ‘voting for’ though — the use of rev or rel attribute determines that. URL A is a vote for URL B. That is the statement described by vote links. Which of those URLs is the current page is determined by choice of rel or rev, *not* a grammatical variant of the word ‘vote’. rel=voted-for rel=voted-against rel=vote-abstained The only difference here is the tense of the word ‘vote’. Moving ‘vote’ from the present tense to the past tense doesn't change the direction of the relationship. rel=vote-for would mean ‘The page I am linking to is a vote for this page’ rev=vote-for means ‘This page is a for for the page I am linking to’ Separate terms are really not needed to express what you're asking for. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
The only difference here is the tense of the word 'vote'. Moving 'vote' from the present tense to the past tense doesn't change the direction of the relationship. rel=vote-for would mean 'The page I am linking to is a vote for this page' rev=vote-for means 'This page is a for for the page I am linking to' Separate terms are really not needed to express what you're asking for. You're right, the semantics of the relationship are carried by the attribute name and not it's value. The value represents the type of vote whereas the attribute name denotes the direction. I feel kind of silly now that I understand it better. Thanks for the explanation. :-) A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On 18/01/07, Ara Pehlivanian [EMAIL PROTECTED] wrote: Pardon the new guy. This may have possibly been discussed before, I'd be interested in expanding the Vote Links spec to include a rel=voted-for (vote-abstained, voted-against) linking back to the originating document. What do you think? I have an implementation idea and this would come in really handy. Hi Ara! :) What's your implementation idea? May be the case that extending vote-links isn't necessary (and reuse is always the first port of call). F -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
The implementation would go something like this: # Site A lists a bunch of sites of the month (rev=vote-for) # Sites of the month display a site of the month icon that links back to the Site A listing for that month. A On 1/18/07, Frances Berriman [EMAIL PROTECTED] wrote: On 18/01/07, Ara Pehlivanian [EMAIL PROTECTED] wrote: Pardon the new guy. This may have possibly been discussed before, I'd be interested in expanding the Vote Links spec to include a rel=voted-for (vote-abstained, voted-against) linking back to the originating document. What do you think? I have an implementation idea and this would come in really handy. Hi Ara! :) What's your implementation idea? May be the case that extending vote-links isn't necessary (and reuse is always the first port of call). F -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On 18/01/07, Ara Pehlivanian [EMAIL PROTECTED] wrote: The implementation would go something like this: # Site A lists a bunch of sites of the month (rev=vote-for) # Sites of the month display a site of the month icon that links back to the Site A listing for that month. Could Sites of the Month not just use rev=vote-for? As in - this site voted for me. -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On 18 Jan 2007, at 15:49, Frances Berriman wrote: Could Sites of the Month not just use rev=vote-for? As in - this site voted for me. Wrong way around Frances, I think. • rev=vote-for — ‘this site is a vote for the href’ • rel=vote-for — ‘href is a vote for this site’ Your concept is correct, though. It definitely seems like a valid case for a rel-vote. So: a href=http://back.to/site/a; title=Voted ‘site of the month’ by Site A’ rel=vote-forSite of the Month!/a could be used to indicate your site had been ‘voted for’ by another. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On 18/01/07, Ben Ward [EMAIL PROTECTED] wrote: On 18 Jan 2007, at 15:49, Frances Berriman wrote: Could Sites of the Month not just use rev=vote-for? As in - this site voted for me. Wrong way around Frances, I think. • rev=vote-for — 'this site is a vote for the href' • rel=vote-for — 'href is a vote for this site' Your concept is correct, though. It definitely seems like a valid case for a rel-vote. So: a href=http://back.to/site/a; title=Voted 'site of the month' by Site A' rel=vote-forSite of the Month!/a could be used to indicate your site had been 'voted for' by another. Doh! I think you're right. Anyway - the rev/rel relationsip basically means you (should) never have to extend your class names to do the other half of a partnership. -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
So what would be the next step to adding to the spec? Keep in mind, I'm new to this process :-) A. On 1/18/07, Ben Ward [EMAIL PROTECTED] wrote: On 18 Jan 2007, at 15:49, Frances Berriman wrote: Could Sites of the Month not just use rev=vote-for? As in - this site voted for me. Wrong way around Frances, I think. • rev=vote-for — 'this site is a vote for the href' • rel=vote-for — 'href is a vote for this site' Your concept is correct, though. It definitely seems like a valid case for a rel-vote. So: a href=http://back.to/site/a; title=Voted 'site of the month' by Site A' rel=vote-forSite of the Month!/a could be used to indicate your site had been 'voted for' by another. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
Frances, In the case of rev=vote-for what would you put in the corresponding rel=? A. On 1/18/07, Frances Berriman [EMAIL PROTECTED] wrote: On 18/01/07, Ben Ward [EMAIL PROTECTED] wrote: On 18 Jan 2007, at 15:49, Frances Berriman wrote: Could Sites of the Month not just use rev=vote-for? As in - this site voted for me. Wrong way around Frances, I think. • rev=vote-for — 'this site is a vote for the href' • rel=vote-for — 'href is a vote for this site' Your concept is correct, though. It definitely seems like a valid case for a rel-vote. So: a href=http://back.to/site/a; title=Voted 'site of the month' by Site A' rel=vote-forSite of the Month!/a could be used to indicate your site had been 'voted for' by another. Doh! I think you're right. Anyway - the rev/rel relationsip basically means you (should) never have to extend your class names to do the other half of a partnership. -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On 18/01/07, Ara Pehlivanian [EMAIL PROTECTED] wrote: Frances, In the case of rev=vote-for what would you put in the corresponding rel=? The same. The distinction of meaning comes from the use of rel or rev (which clearly I keep mixing up, so I won't state it again). http://www.w3.org/TR/html401/struct/links.html#adef-rel -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
Yeah except that the spec states that rel describes the relationship from the current document to the anchor specified by the href attribute. So putting vote-for in the description would be an incorrect description. Rather, I think voted-for would be a more apt description to the related link. Your thoughts? A. On 1/18/07, Frances Berriman [EMAIL PROTECTED] wrote: On 18/01/07, Ara Pehlivanian [EMAIL PROTECTED] wrote: Frances, In the case of rev=vote-for what would you put in the corresponding rel=? The same. The distinction of meaning comes from the use of rel or rev (which clearly I keep mixing up, so I won't state it again). http://www.w3.org/TR/html401/struct/links.html#adef-rel -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
The rel and rev attributes play complementary roles -- the rel attribute specifies a forward link and the rev attribute specifies a reverse link. — http://www.w3.org/TR/html401/struct/links.html#rev-link Starting with rel: • rel=alternate means 'the linked document is an alternate representation of this page' Therefore using rev describes a reverse of that definition: • rev=alternate would mean 'this page is an alternate representation for the linked page' With vote links: • rev=vote-for means 'this page is a vote for the linked page' and reversed: • rel=vote-for means 'the linked page is a vote for this page' Hope that clarifies the attributes for you, Ara. Ben Okay, that makes sense. But that also means that the spec shouldn't constrain the Vote Links to rev only. Rather it should be expanded to include both uses and cite proper examples for each. N'est pas? A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
On Jan 18, 2007, at 11:55 AM, Ara Pehlivanian wrote: Okay, that makes sense. But that also means that the spec shouldn't constrain the Vote Links to rev only. Rather it should be expanded to include both uses and cite proper examples for each. N'est pas? To clarify, microformats specs don't seek to constrain HTML at all. They only describe expected behavior among those who have arrived at a rough consensus about specific bits of HTML. But you're free to, and furthermore encouraged to, use other bits of HTML as well. Not every bit of useful HTML semantics belongs in a microformat. Maybe this bit does, or maybe it doesn't, but the lack of a microformat should never prevent you from making your own HTML markup more descriptive. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote Links: rel=voted-for
To clarify, microformats specs don't seek to constrain HTML at all. They only describe expected behavior among those who have arrived at a rough consensus about specific bits of HTML. But you're free to, and furthermore encouraged to, use other bits of HTML as well. Not every bit of useful HTML semantics belongs in a microformat. Maybe this bit does, or maybe it doesn't, but the lack of a microformat should never prevent you from making your own HTML markup more descriptive. I agree with the idea that we should first use the semantics offered by HTML before creating a microformat. But microformats are an agreement among community members on certain standard usages of semantic class names and other attributes when the HTML spec either doesn't supply what's necessary, or more specific uses are required (as in standardized class names). What I meant by the word constraint was the fact that the spec for Vote Links originally stated that you should exclusively use the rel= attribute to mark up a Vote Link, and then was changed to more correctly reflect the nature of the relationship by using the rev= attribute--once again exclusively. This means that according to the microformats spec for Vote Links, a vote link goes one way. Sure, you can use a rel attribute to link back, but that doesn't mean that the usage will be standardized (aggregator friendly, etc...). Hence my proposal to specify the proper usage of both rev and rel. I don't agree that you can simply use rel=vote-for because it incorrectly gives the impression that you're voting for when really you were voted for, hence my suggestion to use the following: rev=vote-for rev=vote-against rev=vote-abstain rel=voted-for rel=voted-against rel=vote-abstained Because really, the relationship isn't the same in both directions. Your thoughts? A. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Am Montag, 6. November 2006 22:41 schrieb Ben Ward: It's because the microformat does not define the meaning of '@rel=vote-for', it just defines the meaning of 'vote-for'. The rel (or rev) relationship comes direct from HTML. The pool of values for @rel and @rev are shared as they are closely related attributes by design (these values are not always appropriate in both directions, of course). So, the value 'vote-for' is definable as 'a positive vote for a resource'. That's what vote-for (and vote-against and vote-abstain with their respective definitions) *always* means when used in HTML. The source and target of that relationship is what the @rel and @rev attributes describe, not 'vote-for' itself, and that comes from HTML. That is exactly what i think. But the specification explicitely relates the property vote-for to the rev attribute, thus indeed defining the complete attribute/property pair of rev=vote-for. If it would be like you wrote, then rel=vote-for as well as rev=vote-for would have sensible semantics. Although vote-against and vote-abstain is not that useful together with the rel attribute. In the case of rel=vote-against this would mean, translated to plain english: please vote against me. Syntactically correct, but semantically - erm- at least strange :) A simple meaning of positive/negative/neutral vote for a resource, if just looked at the property itself, would be what i largely prefere. Then this property might be combined with any attribute, inheriting the semantics of that attribute, and maybe inheriting the semantics of the element as well. So combined with the rev attribute, a rev=vote-for would mean a positive vote for that (target/remote) resource, whereas a rel=vote-for would then very logically mean a positive vote for this (local/current) resource. And more, it would be combineable with the class attribute as well: q cite=Galileo Galilei class=vote-forand still it's spinning around/q Well, forgive my english, i'm no native english speaker. And the cite attribute should contain a url. But that's not the point. The point is: Again you can apply your vote-for semantics to this construct. So this is a positive vote for the content of this container. Might in some cases be applicable to the id attribute as well. It would be wise to restrict the microformats specification to the semantics of the _property_ (as you wrote), adding the attribute/property pairs as examples and use cases, not more. This would make many microformats much more useful. regards Siegfried ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On 11/1/06, Siegfried Gipp [EMAIL PROTECTED] wrote: Well, at least i know many examples saying exactly that, but without using rel=vote-for. There are many pages out there trying to make the visitors vote for them. rev=vote-for means The current page is a vote for this URL. By definition that makes rel=vote-for mean This url is a vote for the current page. It could be used, for instance, to link to people who are adding their names to a petition? I don't think it can be taken to mean 'This is a place where you can vote for the current page', which seems to be your intent. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On 7 Nov 2006, at 17:03, Ciaran McNulty wrote: that makes rel=vote-for mean This url is a vote for the current page. Correct. However, this isn't mentioned in the spec or anywhere because it has an issue with authority. I could say 'That page over there is a vote for me'. That isn't authoritative, I could say that Google, Technorati, Tantek and Siegfrief Gipp all voted for my resource but an application shouldn't use that data, since I could be lying about it. Now you could still do this, but an application would have to inspect each of those resources to make sure the votes were really valid. Of course, that's still a valid use and does have assistive value to applications, but the authoritative relationship of vote-* is still @rev. That's why the spec talks in terms of @rev. Now, that's not to say the Wiki couldn't be expanded to describe what I've just said (but, y'know, better), but it certainly _is_ to say you cannot take @rel=vote-* to mean anything but the opposite of @rev=vote-*. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On Nov 2, 2006, at 8:14 AM, Siegfried Gipp wrote: Am Mittwoch, 1. November 2006 20:28 schrieb Ryan King: 1. The original spec of vote-links erroneously specified that the vote-links link relationships should be on the @rel attribute. There's content on the web (which will never go away) that uses this construct. So, using @rel='vote-for' is not compatible with past specifications. Well, that may be a point 2. Using @rel and @rev for different meanings is not future proof. It is highly likely that future versions of HTML will drop @rev. If the rev attribute will some day be dropped, then there would automatically be no legal way to use rev=vote-for. But this is out of scope for microformats. This is up to the w3c But then, if the rev attribute will be dropped, why not define a semantics for rel=vote-for? I think you missed how my two points interacted. It's not possible for us to define a semantic for rel=vote-for which is different than semantic of rev=vote-for. Because of my point #1 above, this will only cause ambiguity. Due to point #2, we may paint ourselves into a corner and lose the ability to express the semantic that rev=vote-for currently carries. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Am Montag, 6. November 2006 20:18 schrieb Ryan King: I think you missed how my two points interacted. It's not possible for us to define a semantic for rel=vote-for which is different than semantic of rev=vote-for. Because of my point #1 above, this will only cause ambiguity. Due to point #2, we may paint ourselves into a corner and lose the ability to express the semantic that rev=vote-for currently carries. Indeed, this i do not understand.Why should a definition of rel=vote-for have any negative effect (or any effect at all) on the definition of rev=vote-for? These are two different attributes. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On 6 Nov 2006, at 21:25, Siegfried Gipp wrote: Indeed, this i do not understand.Why should a definition of rel=vote-for have any negative effect (or any effect at all) on the definition of rev=vote-for? These are two different attributes. It's because the microformat does not define the meaning of '@rel=vote-for', it just defines the meaning of 'vote-for'. The rel (or rev) relationship comes direct from HTML. The pool of values for @rel and @rev are shared as they are closely related attributes by design (these values are not always appropriate in both directions, of course). So, the value 'vote-for' is definable as 'a positive vote for a resource'. That's what vote-for (and vote-against and vote-abstain with their respective definitions) *always* means when used in HTML. The source and target of that relationship is what the @rel and @rev attributes describe, not 'vote-for' itself, and that comes from HTML. Hope that clarifies. Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Am Mittwoch, 1. November 2006 20:28 schrieb Ryan King: 1. The original spec of vote-links erroneously specified that the vote-links link relationships should be on the @rel attribute. There's content on the web (which will never go away) that uses this construct. So, using @rel='vote-for' is not compatible with past specifications. Well, that may be a point 2. Using @rel and @rev for different meanings is not future proof. It is highly likely that future versions of HTML will drop @rev. If the rev attribute will some day be dropped, then there would automatically be no legal way to use rev=vote-for. But this is out of scope for microformats. This is up to the w3c But then, if the rev attribute will be dropped, why not define a semantics for rel=vote-for? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Am Mittwoch, 1. November 2006 17:16 schrieb David Osolkowski: You can't use vote-for for this, because vote-for already has defined semantics; it represents a vote that has been cast, not the ability to cast a vote. It's already possible to use vote-for in both rel and rev; one indicates that the current page is a vote for the link No, rel is explicitely excluded. And exactly that is what i don't think of beeing adequate. If there already exists a good semantic for rel=vote-for, that's just fine. On page A: a href=pageB rel=pollThe page being voted on/a On page B: a href=pageA rev=pollVote for this page here/a What about a href=javascript:somevotingfunction() rel=vote-for.../a ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On 11/1/06, Scott Reynen [EMAIL PROTECTED] wrote: There is already an established meaning for rev=vote-for, and the reverse of that doesn't really communicate anything useful. I don't know about that; I could certainly imagine, say, a proposal asking people to vote by making blog posts and linking, and then the proposal has a list showing who voted. It shouldn't be *authoritative*, because only the person casting the vote can say for sure that they voted a certain way. What about a href=javascript:somevotingfunction() rel=vote- for.../a ? I believe that means the page containing this link is voting for a JavaScript function. Probably not what you want to communicate. Hmm, isn't that backwards? somevotingfunction() is a vote-for the current page. See the FAQ entry that you yourself linked. I very much doubt that such a link makes sense, though. - David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On Oct 31, 2006, at 11:17 AM, Siegfried Gipp wrote: It's not about redefining the rel or rev attribute. It's about redefining the vote-for attribute value if used with the rel attibute. We have some significant problems with using @rel=~'vote-for', which IMO, keep us from ever using it: 1. The original spec of vote-links erroneously specified that the vote-links link relationships should be on the @rel attribute. There's content on the web (which will never go away) that uses this construct. So, using @rel='vote-for' is not compatible with past specifications. 2. Using @rel and @rev for different meanings is not future proof. It is highly likely that future versions of HTML will drop @rev. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Am Mittwoch, 1. November 2006 19:23 schrieb David Osolkowski: What about a href=javascript:somevotingfunction() rel=vote- for.../a ? I believe that means the page containing this link is voting for a JavaScript function. Probably not what you want to communicate. Hmm, isn't that backwards? somevotingfunction() is a vote-for the current page. See the FAQ entry that you yourself linked. I very much doubt that such a link makes sense, though. Well, at least i know many examples saying exactly that, but without using rel=vote-for. There are many pages out there trying to make the visitors vote for them. I dont' think that i myself will ever do something like that, i never will beg vor any votes! But who am i to disallow that for anybody else? So, if that makes sense or not is up to the author of that page, not up to me or the microformats team. The microformats team simply should define the semantics of that. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Am Montag, 30. Oktober 2006 22:33 schrieb Ryan King: 1. The link points to a resource which votes for THIS resource or contains some form or script or whatever to enable the user to vote for THIS resource, then the usage of the rev attribute is correct. This is out of scope for vote-links. I don't see, why. That's just a matter of definition. And this scenario is not uncommon (vote for me/this page/...). Although, only vote-for would make sense here. Vote against me would be at least very uncommon. I disagree. @rel determines the relationship between the referred resource and the current one. For example, this: You're right, i got confused. I'll change that on my page. And for the scenario 1 then the rel attribute should be correct. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On Oct 31, 2006, at 11:44 AM, Siegfried Gipp wrote: 1. The link points to a resource which votes for THIS resource or contains some form or script or whatever to enable the user to vote for THIS resource, then the usage of the rev attribute is correct. This is out of scope for vote-links. I don't see, why. That's just a matter of definition. Definition is important. I think there are two distinct ideas here: 1) Page A is a vote for Page B, i.e. a ballot 2) Page A is a place where you can create a vote for Page B, i.e. a polling place Using the same semantics for both is like saying a ballot and a polling place are functionally the same thing. Sure, both are part of voting, but that doesn't make them interchangeable. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Am Dienstag, 31. Oktober 2006 19:13 schrieb Scott Reynen: 1) Page A is a vote for Page B, i.e. a ballot 2) Page A is a place where you can create a vote for Page B, i.e. a polling place Right Using the same semantics for both is like saying a ballot and a polling place are functionally the same thing. Sure, both are part of voting, but that doesn't make them interchangeable. Right. Therefore use rel and rev attribute respectively :) Using rel means one type, using rev means the other type. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
On Oct 31, 2006, at 12:33 PM, Siegfried Gipp wrote: Using the same semantics for both is like saying a ballot and a polling place are functionally the same thing. Sure, both are part of voting, but that doesn't make them interchangeable. Right. Therefore use rel and rev attribute respectively :) Using rel means one type, using rev means the other type. But that's just not what rel and rev mean. And this part isn't even a meaning we've defined here, so we couldn't change it if we wanted to. It's defined in the HTML spec: The rel and rev attributes play complementary roles -- the rel attribute specifies a forward link and the rev attribute specifies a reverse link. Consider two documents A and B. Document A: LINK href=docB rel=foo Has exactly the same meaning as: Document B: LINK href=docA rev=foo Both attributes may be specified simultaneously. http://www.w3.org/TR/html4/struct/links.html#h-12.3.1 A polling place is not the reverse of a ballot. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Am Dienstag, 31. Oktober 2006 19:54 schrieb Scott Reynen: But that's just not what rel and rev mean. And this part isn't even a meaning we've defined here, so we couldn't change it if we wanted to. It's defined in the HTML spec: The rel and rev attributes play complementary roles -- the rel attribute specifies a forward link and the rev attribute specifies a reverse link. Hmmm, why not? Microformats do already define, that the XXX attribute with the value of YYY does have meaning ZZZ. So in this case microformats has already defined that the rev attribute with the value vote-for has some special meaning. Why not define that the rel attribut with the value vote-for has another meaning? It's not about redefining the rel or rev attribute. It's about redefining the vote-for attribute value if used with the rel attibute. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] vote-for
Limiting the vote-for relation to the rev attribute is not good. There are two different scenarios: 1. The link points to a resource which votes for THIS resource or contains some form or script or whatever to enable the user to vote for THIS resource, then the usage of the rev attribute is correct. 2. If a page contains a link to another resource, which contains some statement i would support, then the usage of the rel attribute is correct. For an example see my start page at http://www.rorkvell.de/ Down in the footer there are some badgets, two of them contain links to pages which i want to support, or so to say, which i vote for. The relation of my page (THIS resource) to the target is, that THIS votes for the target. So using the rel attribute should not be prohibited. Better would be a clarification when to use what. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote-Links use cases ?
On Dec 3, 2005, at 1:07 AM, Charles Iliya Krempeaux wrote: Hello, Just wondering if there's a list of use cases for vote-links somewhere? For example, are vote-links just a better version of rel-nofollow. (With rel=nofollow being equivalent to rev=vote-against.) Or are there other use cases. The first use I ever heard of was Technorati doing a distributed poll during the last US election. Tantek mentioned it here [http:// tantek.com/log/2004/11.html#d01t2339]. It is, of course, dead now. And on the topic of vote-links vs. relnofollow, notice that vote- links are actually older than relNoFollow. :D -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote-Links use cases ?
Hello, On 12/4/05, Ryan King [EMAIL PROTECTED] wrote: On Dec 3, 2005, at 1:07 AM, Charles Iliya Krempeaux wrote: Hello, Just wondering if there's a list of use cases for vote-links somewhere? For example, are vote-links just a better version of rel-nofollow. (With rel=nofollow being equivalent to rev=vote-against.) Or are there other use cases. The first use I ever heard of was Technorati doing a distributed poll during the last US election. Tantek mentioned it here [http:// tantek.com/log/2004/11.html#d01t2339]. It is, of course, dead now. I should probably read Tantek's blog more :-) I was actually thinking of using for something along these lines. So, for example, (in Canadian politics) a person could express the view on a bill like: I am against a rev=vote-against href=http://laws.justice.gc.ca/en/1995/39/;Bill C-68/a. And on the topic of vote-links vs. relnofollow, notice that vote- links are actually older than relNoFollow. :D Didn't know that. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
