From Microformats Wiki
issues /
Revision as of 10:39, 5 January 2009 by Brian (talk | contribs) (Reverted edits by VarbaSleto (Talk) to last version by Brian)
Jump to navigation Jump to search

Microformat Issues

These are externally raised issues about microformats in general (these issues MUST apply to more than one microformat, which MUST be explicitly listed, otherwise the issue should be raised on the format specific issues page) 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

As this is a general microformats issues page, please only note concrete real world issues. Theoretical issues will be deleted, as will any issues raised that do not contain documentation of specific real-world examples that use real-world microformats (not just brainstorms).

Closed Issues

Resolved issues that have no further actions to take. These will likely be moved to a separate page like microformats-issues-closed.

  • 2005-07-?? raised by Bud(?).
    1. Documents with user-generated content are hard to parse, and microformats present particular parsing challenges.
      • REJECTED. This is a straw man issue.
  • 2005-07-13T19:44-07:00 raised by Bud
    1. Follow-up to previous issue: Tantek needs to supply some justification for why this is a strawman as every developer I have talked to has raised it. It may be that the solutions described below are sufficient to solve the issue. More neutral statements to that effect might be more constructive.
      • REJECTED. Bud, saying "particular parsing challenges", without stating them is meaningless. Hence strawman. I think you may be mistaking questions for issues.

Resolved Issues

Issues that are resolved but may have outstanding To Do items. As issues are resolved, they will be moved from the top of the Issues list to the bottom of this section.

  • ...


Format Specific Issues

Please raise format specific issues on the respective page:

Pattern Specific Issues

Please raise pattern specific issues on the respective page:

IP Issues

  • 2006-12-08 raised by Andy Mabbett.
    1. As evidenced in discussion of an emailed response from eBay, the current position on the IP rights relating to microformats is unclear, or at least not clearly expressed. It seems to me that there should be an unambiguous statement of the current position, either for each individual format, or collectively, on a page to which people with concerns may be directed.
      • ACCEPTED. A clearer statement of both copyright and patents both in specific specs and in general would be a good thing. In general, the end result that our current copyright/patent statements seek is Creative Commons, W3C, and IETF compatibility in terms of both copyrights, and royalty free patent policies. I will work on this Tantek 11:58, 9 Dec 2006 (PST)
        • open issue! This appears to be unresolved; and in the light of, for example, hCard#Copyright the hCard 'spec', the statement in the FAQ that "Microformats are open standards licensed under Creative Commons Attribution" to be, at best, erroneous and misleading. Andy Mabbett 11:04, 10 Mar 2007 (PST)
        • Also causing concern here. Prompt resolution would be advisable Andy Mabbett 09:04, 24 Mar 2007 (PDT)
          • First, Citation microformat efforts is not ready for use in Wikipedia anyway. Second, what is unclear about the Creative Commons/W3C/IETF license and patent statements? This appears to be a theoretical issue / nitpick. Yes, things can be made clearer, but "erroneous" and "misleading" are inaccurate labels.
          • This is not a citation issue. For example, hCard's current copyright statement is not compatible with the Creative Commons license:

            This specification is (C) 2004-2021 by the authors. However, the authors intend to submit (or already have submitted, see details in the spec) this specification to a standards body with a liberal copyright/licensing policy such as the GMPG, IETF, and/or W3C. Anyone wishing to contribute should read their copyright principles, policies and licenses (e.g. the GMPG Principles) and agree to them, including licensing of all contributions under all required licenses (e.g. CC-by 1.0 and later), before contributing.

            If you look at the wikicode, this is actually the "MicroFormatCopyrightStatement2004" default microformat copyright.--JoeAndrieu 15:09, 24 Mar 2007 (PDT)
  • Further to the above (but out-dented for clarity), hResume cedes copyright to "the authors": "This specification is (C) 2006 by the authors"; and names just one author; Ryan King. What legal standing does the "the authors (sic) intend to submit..." clause have? What exists, to reassure someone (or some mega corporation's lawyers) contemplating or already using hResume that they won't be invoiced by Mr King? Why aren't the other people who contributed to that spec jointly credited with its copyright? Andy Mabbett 17:34, 24 Mar 2007 (PDT)

Legal Entity Issues

2007-03-24 raised by Joe Andrieu, clarified by Rohit Khare on 2007-03-27.

  1. What is the legal entity responsible for operating
    • Rohit Khare originally registered the and .org domain names on 2005-01-25 and CommerceNet, LLC, a non-profit 'think tank' with a long history as a neutral sponsor for developing standards for Internet commerce (often, in conjunction with other formal standards bodies). CommerceNet currently underwrites the server hosting costs and, in the past, has co-ordinated donations with other sponsors for events such as the anniversary party, the workshop where the site was launched, and promotional items.
  2. What is the legal entity responsible for the intellectual property on
    • The current microformats copyright statement recognizes that IP is originally vested in the author(s), who are then expected to share those rights with the community by permitting their redistribution on's wiki, blog, and mailing list archives. The additional distinction of becoming a specification may come with additional obligations to redistribute IP, such as a formal Creative Commons copyright license and a royalty-free patent license. The community is currently encouraging contibutors to voluntarily adopt a public domain release.
    • Note that CommerceNet, LLC does not exercise any editorial control over the content of the site, mailing list, specifications, or the process, nor does it accept funds on behalf of (see the disclaimer). Conversely, the Admins do not have any independent legal identity at present, such as a partnership, foundation, or corporation. Please refer any legal questions or concerns directly to Rohit Khare before raising them as a matter of public record, as discussed on the mailing list [1].

Governance Issues

See: governance-issues

Miscellaneous issues

    1. What is currently described as a "specification" on hCard 1.0 and hCalendar 1.0 is no such thing.
    2. Andy, what would it take to turn it into a "specification"?--JoeAndrieu 15:13, 24 Mar 2007 (PDT)
    3. [Belated response; only just seen the question!] - for a start, removal of user commentary; versioning. Andy Mabbett 02:37, 14 Jan 2008 (PST)

See also:

New Issues

  • open issue! 2007-04-01 raised by Andy Mabbett.
    1. Shouldn't microformats be recognised on ID as well as class? In other words, if I know I'm gong to have only one review or only one location, or whatever, on a page, then "id=hReview", id="geo" etc. are semantically valid and appropriate. Andy Mabbett 11:32, 1 Apr 2007 (PDT)
  • ...


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

See also