We should use existing microformats, not make new asf- ones (unless it is for asf concepts like PMC).
Schema.org is a popular one that is also discovereable by search engines. See for instance: http://schema.org/SoftwareApplication http://schema.org/SoftwareSourceCode http://schema.org/releaseNotes On 22 Jun 2017 1:02 am, "sebb" <seb...@gmail.com> wrote: On 22 June 2017 at 00:56, Shane Curcuru <a...@shanecurcuru.org> wrote: > I like Owen's common urls idea elsethread, which would be great for > projects that are willing to use those URLs, but that's not something > we're likely to require. > > Rich Bowen wrote on 6/21/17 4:40 PM: >> On Jun 21, 2017 20:12, "Shane Curcuru" <a...@shanecurcuru.org> wrote: >> >> >> If we're doing something new, why not use rel="" values? >> >> https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types >> >> We could even abuse the rel= attribute to add some of our own keys if we >> really wanted to. This would make link checking super-easy for sites >> that use it. >> >> >> Not a clue what you're suggesting. Can you be more specific? Or give an >> example? > > HTML standard(s) allows a rel="" attribute on <a...> tags. One value is > rel="license", which "indicates that the hyperlink leads to a document > describing the licensing information". > > Various unofficial microformats also use things like rel="friend" for my > homepage link that points to Rich's blog, because he's a friend. > > We could (ab)use this to add our own set of rel="trademark" values that > the Whimsy site checker (either for policy links, or for recommended > links like these) could scan for. This is more valuable when some > projects want the link *text* to say "source repository" and other > projects want it to say "github repo" or the like. > > But if we're going to propose patches to a bunch of websites, having a > set of rel= values that we consistently use might be a really simple way > to add structure to the links, even if we're making up our own values. In which case, maybe an "asf-" prefix would be sensible to avoid possible clashes with official rel names. > - Shane > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org