From Microformats Wiki
Jump to navigation Jump to search

relTag Issues

These are externally raised issues about rel-tag with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek


Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
  • open issue! 2014-09-23 raised by tommorris
    1. Formal deprecation of object-level rel-tag usage
      Given that HTML5 seems to have decided that rel-marked links are document-scoped, and left it to metadata-in-HTML implementations (RDFa, Microdata, Microformats etc.) to work out how scoping works (itemscope in microdata, the about/typeof in old-style RDFa, resource in RDFa Lite 1.1), the use of rel-tag to specifically mark object-level tags will not work. In microformats2 h-entry, the solution that seems to be taking its place is to use the 'category' property which µf2 parsers can parse according to the same parsing rules as any other properties. It would seem reasonable—although rather sad—to deprecate rel-tag.
      As the primary use case of rel-tag is to tag blog posts (or microblog "notes" in the IndieWeb milieu), given the HTML parsing rules as they currently stand, that use case can't be fulfilled using rel-tag anymore. rel-tag can still be used for tagging a page. If a rel-tag link is on a web page, it'll obviously be parsed by a µf2 parser and included in the 'rels' dictionary outputted, but it may be worth deprecating the rel-tag specification as it no longer serves a purpose—the primary use case is better filled using h-entry's category property.
  • open issue! 2012-04-18 raised by Ross McDonald
    1. At the time of writing rel-tag is catagorised as stable, but has a sub-heading 'Draft Specification 2005-01-10'.
  • open issue! 2009-12-27 raised by Sebastian Joseph
    1. I have a problem with this specification. It requires the tags to be links, but isn't it possible to select tags without linking them? In my opinion tags are not anything different than visible keywords. So it should be allowed to use any html elements as tags, too. I would prefer the usage of a wrapper, for example with class page-tags. Then the text content of the wrapped elements with class tag should be used as tags for this page. If a Image if used as tag, then the implementations should use the alt-text of this element. The element with class page-tags should only appear once at a page.
  • open issue! 2007-03-28 raised by James Craig
    1. Internationalization (i18n) issue with restful tag spaces. Restful tag spaces cannot be used with non-western characters unless escaped in unicode, which renders a restful tag space quite pointless. For example:
      • A Japanese Katakana tag ピフ would have to be
      • A Hindi Devanagri tag चट would have to be
There should be another way to specify the human-readable tagname.
      • One possible solution is to provide a "romaji" or transliteration of the characters to the Latin alphabet. It would be a bit troublesome for pictographic alphabets such as kanji, but it would work well for Russian, Katakana, Hiragana, and similar phonetic alphabets. This i18n issue is a problem for URLs in general, a more fundamental issue that has to be fixed. The URL spec was created before UTF existed. (NOTE: index names for tags can be different from the raw tag, as demonstrated by Flickr). Bloritsch 19:19, 23 July 2009 (UTC)
  • open issue! 2007-01-10 raised by Andy Mabbett
    1. I recently received an e-mail circular, asking that images and blog posts about a particular event be tagged in the style:
20070110 AB123YZ postcode:uk=AB123YZ upcoming:id=123456 upcoming:event=19876 upcoming:venue=14567 geocoded geotagged geo:lat=52.3456 geo:lon=-1.2345
Is any work being done, to document such tag "schema"? Andy Mabbett 12:43, 10 Jan 2007 (PST)
Isn't that several different tags? I.e. "20070110", "AB123YZ", "postcode:uk=AB123YZ" .... At least this is how a site like Flickr would decipher it. The rel-tag standard handles each one separately, although the "machine tags" (as Flickr calls them) have the same issues as the i18n issue above. Bloritsch 18:00, 17 July 2009 (UTC)
  • open issue! 2005-06-21 raised by Hixie
    1. Issue H-1: This specification is lacking a user agent conformance section. Does the UA simply crawl the DOM looking for all <html:a> elements with a "rel" attribute that contains a "tag" keyword (after space-separated splitting) and then grab the href="" value? How about relative links? Must they implement xml:base? <html:base>? Other things?
    2. Issue H-2: What's the point? Isn't free-text search more effective than relying on people to remember to put a particular tag?
      • Tags are used for various reasons, including the ability to re-find information later. Free text search has its own issues, including raising the signal to noise ratio of search results.
  • 2006-01-10 raised by Adam Willard
    1. Issue 1: Somewhat confused. Please either fix or elaborate the difference in the URLs in the Tag Spaces area -> is it /tag/ or /tags/ or /wiki/. Is this URI changeable or is this just showing other implementations. If this is the case I am confused on the implementation. Should /wiki/ only show tagged content of wiki? Should URIs be constructed as /definition/ /blog/ etc... to return those items? Or is it just returning pages and the webmaster just decided on /wiki/ or /tag/ or /applicationdir/?
      • ACCEPTED FAQ - We need to make this an FAQ entry. --RyanKing 14:46, 25 Jan 2006 (PST) (@TODO)
    2. Issue 2: More information on actually implementing a tag space would be helpful. I wrote a tagging system on our intranet and we run IIS. So I had to install URLrewrite (ISAPI) to create the URI /tag/tagname. We horrible Microsoft people aren't as lucky to have Mod Rewrite.
      • REJECTED IRRELEVANT - Implementing a tagspace is well outside the bounds of the rel-tag specification. --RyanKing 14:46, 25 Jan 2006 (PST)
  • 2006-02-09 raised by JonathanFeinberg
    1. Issue 1: It's bizarre to have the tag be denoted by the URL. The content of the a tag is a perfectly suitable place to contain the tag.
      • REJECTED, IGNORES ESTABLISHED PRACTICE. Flickr and and other tagging sites established the defacto standard of having the tag term be denoted by the last segment in the URL. rel-tag was designed to leverage that existing behavior. Theoretical arguments about suitability are irrelevant in the fact of overwhelming existing practice.
    2. Issue 2: There's no way to distinguish between an individual user's notion of a tag and a global tag (i.e., Fred's java tag versus all things tagged with java.
      • REJECTED UNTRUE. ACCEPTED FAQ. Tag spaces (see rel-tag specification) are used for distinguishing, e.g. Flickr does this with photos from one user with a tag, vs. photos from all users with a tag. to-do - add this to the the rel-tag-faq.
    3. Issue 3: It's not reasonable to restrict the host's REST implementation according to this spec's rather limited idea of a "good" tag URL. The idea of tags as query parameters is rejected without justification, for example. Query parameters are a perfectly legitimate means of denoting state.
      • REJECTED, IGNORES ESTABLISHED PRACTICE. Flickr and and other tagging sites established the defacto standard of having the tag term be denoted by the last segment in the URL and thus defined what makes a "good" tag URL. rel-tag has codified this good practice.
  • 2006-02-09 raised by Robert Yates
    1. Issue 1: So I work alongside Jonathan at Lotus / IBM and we have several systems in development each with their own tag implementations. All of them have their own pages that are dedicated to listing the things within them that have been tagged by a given tag. Some of these systems use a url notation that ends in /tag but many (the majority) do not. We are looking to have a standard way that these systems can sematically tag their tags and relTag looked very promising. However, given that some of the systems produce tag urls that do not end in /tag we are a little stuck. It would be extremely hard and somewhat impracticle to get all these groups to ensure that their tag urls end in /tag. Are you at all considering another approach. We'd love to use relTag within our products, but at the moment we can't. Looking for some help / guidance.
      • Clarification: By '/tag' do you mean '/<tag-name>'? --RyanKing 15:21, 9 Feb 2006 (PST)
        • yes -- rob yates 18:56, 9 Feb 2006 (EST)
      • I wanted to do a quick survey to see how many other sites would struggle to easily adopt this format, due to the fact that they don't currently end their tag urls '/<tag-name>'. While I definately agree that ending with '/<tag-name>' is a best practice, I do feel that their needs to be an option for sites that don't do this, but still want to semantically tag their tags. Here's some sites that I found that cannot easily adopt reltag without reworking server side logic. There's some pretty big names on this list.
  • open issue! 2006-04-06 raised by Evan
    1. The scope says 'rel="tag" is specifically designed for "tagging" content, typically web pages (or portions thereof, like blog posts).', but it's not clear how to associate a tag with one portion of a web page and not another. Some common use cases: image galleries, blog posts, yellow-pages directories, hcard directories, lists of bookmarks. Does the tag apply to the <a> element's immediate containing element? All containing elements? One possibility I suggest: the tag applies to the most immediately enclosing element with an "id" attribute (addressable, at least in XHTML, as #idval), or to the entire page if there is no such element. Another possibility is having a tagtarget class, so that the parent with that class is the object being tagged.
    2. In most sites that support tagging, the association is done visually. There isn't any semantic markup that would tie the tag to the "id" attribute of the content being tagged. XML has "ref-id" attribute, which can be used. Not sure if it should be made part of the rel-tag standard though. Bloritsch 18:26, 17 July 2009 (UTC)
  • open issue! 2006-11-24 raised by Andy Mabbett
    1. Why not also allow tagging on within-page links (i.e. after "#" as well as after "/")? Then, if I have a page with sub-sections, each of those could be a tag, according to their ID:
<ul class="navbar">
<li><a href="#whisky" rel="tag">Whisky</a></li>
<li><a href="#wine" rel="tag">Wine</a></li>
<h2 id="whisky">"Whisky</h2>
<h2 id="wine">"Wine</h2>
    1. Isn't this a major departure from how tags are used across different sites? When I click on a tag link, I expect to see other content that applies that tag. Bloritsch 18:26, 17 July 2009 (UTC)
  • open issue! 2006-11-26 raised by Andy Mabbett
    1. There is a danger of encouraging users to breach WCAG 1.0 priority 2 guideline 13.6 "Clearly identify the target of each link". If a page has a link thus <a href="">BBC</a>, tagging it with a link thus <a href="" rel="tag">BBC</a> will result in two links on the page, both labelled "BBC", with different targets.
    2. Typically tags are kept in one location on a screen so that visually they have a context--this provides disambiguation for seeing users. However, this practice does not address usability for people dependent on screen readers.Bloritsch 18:26, 17 July 2009 (UTC)
  • open issue! 2007-01-01 raised Jan 2006 by Ben Buchanan as limitations of rel="tag" microformat
    1. Summary: Under the current draft, tags and relevant tagspaces are potentially hard to create; and it's still easy to abuse the system. Humans can still be tricked and so can the machines. It's a great spec if you happen to have a compliant directory structure, but if your site doesn't match then you either recreate your entire system... or, more likely, you sadly advise the client that tags aren't happening.
  • open issue! 2007-02-03 raised by Evan
    1. There may be value in adopting, supporting or commenting on the machine tags format in use at Flickr. Machine tags (also called triple tags) are a structured tag format with the syntax "namespace:property=value". Examples: "geo:city=Portland". It's not clear how machine tags interact with other microformats ("geo:long=..." and "geo:lat=..." are two commonly-used examples, which clearly overlaps with geo), whether other sites and services will support machine tags, and how to include them here.

Need reformatting

These issues were mistakenly added to the rel-tag-faq and should have been put here in the first place. They need to be reformatted as issues.

Are tags case sensitive?

  • Are tags case sensitive? Is "Dog" the same tag as "dog" and "DOG"?

Multi-word tags

  • How should a multi-word tag be made? For instance, if using Wikipedia as a name space, a page about a Black Redstart (a bird) would be tagged Black_Redstart, with an underscore [1]. Is there any way of aliasing alternatives ("BlackRedstart", "Black-Redstart", etc.)? Is any particular format preferable?

Related pages

The rel-tag specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.