Furthermore, regarding the othertag I have in this document, pointing to the RSS feed list (for which I’d specified a rel value of “feeds“), I’ve had a quick shufty at the allowed values for the rel attribute of thetag. While “feeds” isn’t explicitly there, and “help” is the closest fit from the choices given, I’ve nevertheless decided to keep the link type “feeds“, and qualify that definition with a meta data profile. Just to see where this leads.
This is what I interpreted from the W3C HTML specs:
- There is a provision, following the definition of the explicitly allowed values, to define new link types for the rel attribute:
“Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types.”
- You can do this by providing the location a meta data profile in a profile attribute of the HTML document’stag.
- According to the explanation of the meta data profiles, these locations are URIs, which can be globally unique names, or actual links to be followed.
- Unfortunately, the specification doesn’t go so far as to actually define what the format of such a meta data profile is:
(If anyone can show me a pointer to where profile formats are described, that would be great!) 5. So I’ve decided to go for a simple URI, “qmacro:weblog”, for now, on the basis of this statement:
“User agents may be able to recognize the name (without actually retrieving the profile) and perform some activity based on known conventions for that profile.”
This is what it now looks like:......
I might be barking totally up the wrong tree, but that’s the price of fun experimentation. I think the only thing that needs to be different is the actual URI – if we can agree on a standard global name, so much the better.