Folks,
I have a vanity domain for Go imports maintained with some rather hacky
shell (so not worth listing as an implementation), and I think I have it
working.
side-question: is there a validator for the tags found?
I also have a top-level page, with links to the various projects as
direct children; each of those projects now has the vcs-autodiscovery
meta elements, but nothing in the top-level page helps a semantic parser
distinguish which links are for VCS projects vs just being links to
somewhere else.
I'm thinking something like a link type to go in the space-separated
list of a "rel" attribute on the "a" tag, except those are normally
about the relationship to _this_ document. Could be a span with
metadata attached to it, and the "a" tag within that span.
Any thoughts/plans along these lines? Out of scope?
So this:
<li><a rel="vcs-repo" href="frob/">frob</a> — frobnozzle your widgets</li>
<li><a rel="vcs-repo" href="waft/">waft</a> — display your widgets</li>
but in a style which is structurally sound and people can live with.
Thanks,
-Phil
On Tue Feb 15, 2022 at 7:00 PM GMT, Phil Pennock wrote:
> I have a vanity domain for Go imports maintained with some rather hacky> shell (so not worth listing as an implementation), and I think I have it> working.
Hey, I'm glad to see more people have implemented this!
> side-question: is there a validator for the tags found?
There isn't a reference implementation (yet) if you are asking
for a tool to verify if your meta tags are correct. I have been
meaning to write one.
I'd be happy to take a look if you want to send me a link.
> I also have a top-level page, with links to the various projects as> direct children; each of those projects now has the vcs-autodiscovery> meta elements, but nothing in the top-level page helps a semantic parser> distinguish which links are for VCS projects vs just being links to> somewhere else.>> I'm thinking something like a link type to go in the space-separated> list of a "rel" attribute on the "a" tag, except those are normally> about the relationship to _this_ document. Could be a span with> metadata attached to it, and the "a" tag within that span.>> Any thoughts/plans along these lines? Out of scope?>> So this:>> <li><a rel="vcs-repo" href="frob/">frob</a> — frobnozzle your widgets</li>> <li><a rel="vcs-repo" href="waft/">waft</a> — display your widgets</li>>> but in a style which is structurally sound and people can live with.
That sounds interesting. I like `rel="vcs-repo"' for this
purpose. It could go nicely on <https://git.sr.ht/~user/>.
I don't have any objections. Let me look a bit closer at the rel
attribute, this can probably be added to the RFC.
On 2022-02-16 at 19:15 +0000, Mark Dain wrote:
> I'd be happy to take a look if you want to send me a link.
Sure, thanks. Go vanity domain: <https://go.pennock.tech/>
> That sounds interesting. I like `rel="vcs-repo"' for this> purpose. It could go nicely on <https://git.sr.ht/~user/>.> > I don't have any objections. Let me look a bit closer at the rel> attribute, this can probably be added to the RFC.
I've added this to the links on the above index page. I'm happy to
change to something else. I just want to make life easier for others
with a little semantic structure, while not requiring large amounts of
complexity to maintain.
The index page for the domain is manually maintained as HTML. The
per-project pages are built with shell, sed, etc, just creating enough
pages to allow `go get` to work even when given a sub-path within a
module, all trusting the repo .git/description and README.md and not
protecting against HTML injection, since they're all my own repos.
-Phil
On Tue Feb 15, 2022 at 7:00 PM GMT, Phil Pennock wrote:
> <li><a rel="vcs-repo" href="frob/">frob</a> — frobnozzle your widgets</li>> <li><a rel="vcs-repo" href="waft/">waft</a> — display your widgets</li>
I've been thinking about this for a little bit. Have you heard
of IndieWeb? They markup pages with Microformats, like so:
https://microformats.org/wiki/h-entry#Example
I can imagine something like h-repo with p-url. Like so:
<article class="h-repo">
<a href="..." class="u-url p-name">Snazzy Tool</a>
<p class="p-summary">A very fine tool</p>
</article>
That may be more in-scope to have as part of IndieWeb. They have
a few pages on the wiki about repositories, but no way of
marking them up yet: https://indieweb.org/repository
Do you want to reach out to them? This might be the right place:
ircs://irc.libera.chat:6697/microformats
On 2022-02-20 at 20:06 +0000, Mark Dain wrote:
> I've been thinking about this for a little bit. Have you heard> of IndieWeb?
Vaguely.
> They markup pages with Microformats, like so:> https://microformats.org/wiki/h-entry#Example
There's not really enough there to see how this contrasts with
schema.org itemscope/itemprop stuff, besides being simpler because it's
less rigorously defined.
If you check the individual projects linked from the index, where I
added the forge:* and vcs:* meta tags, those pages already had
`http://schema.org/SoftwareSourceCode` (now updated to `https:`, since
the schema definitions now allow it).
There's a degree of orthogonality in approach between the
vcs-autodiscovery attributes, following in the spirit of the Go tooling
tag-handling, vs the schema.org microformats. I'm happy enough to have
both. But as the approach moves towards more generic schema overlays, I
don't want to mix-and-match on different parts of the site. I ... can't
provide a "fair" analysis here, only what feels right vs what feels at
cross-purposes, if that makes sense.
So if I were to extend the generic schema stuff, it would probably be
with the well-defined and established ontologies, such as Dublin Core,
and it would be applied in parallel to be consistent.
-Phil