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

Reply via email to