issues-closed

From Microformats Wiki
Revision as of 01:04, 27 October 2011 by Tantek (talk | contribs) (drafted with existing closed issues and a few more.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

<entry-title>microformats issues closed</entry-title>

This page is for archiving closed issues about microformats in general. See:

closed issues

Closed issues that have no further actions to take.

closed 2005

Closed issues that were raised in 2005.

  • closed issue 2005-07-?? raised by Bud(?).
    1. Documents with user-generated content are hard to parse, and microformats present particular parsing challenges.
      • REJECTED. Strawman. Lack of specific examples of such documents. Insufficient detail - "particular parsing challenges" need to be described.
  • closed 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. See Wikipedia: Straw man argument. Saying "with user-generated content" out of context is a strawman. Leaving out a specific example makes it a hypothetical. Saying "particular parsing challenges", without stating them is meaningless. Hence strawman. Parsing questions should be phrased as such and discussed in IRC or the microformats-dev mailing list.

closed 2006

Closed issues raised in 2006.

    1. What is currently described as a "specification" on hCard and hCalendar 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)
      • ACCEPTED PARTIAL. How versioning should work is under consideration with various iterations of microformats (hCard 1.0.1, 1.1) and microformats itself with microformats-2. There is nothing remaining to do specific to this issue however.
      • RESOLVED process updated with better definitions for how/when a draft becomes a specification, and how a specification can become a standard. - Tantek
  • closed issue 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)
      • 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 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-2024 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)
      • ALL RESOLVED per:


closed 2007

Closed issues raised in 2007.

  • closed issue 2007-03-24 raised by Andy Mabbett.
    1. 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)
      • ACCEPTED RESOLVED per: hResume all editors/authors have put placed their work into the public domain per Creative Commons PD declaration and it's also been updated accordingly a while ago (~2007?). - Tantek
  • closed issue 2007-03-25 raised by Andy Mabbett.
    1. Also, there appears to be nothing on buttons to say that they're freely licensed, or public-domain. Andy Mabbett 03:01, 25 Mar 2007 (PDT)
      • ACCEPTED RESOLVED. buttons has a licensing section that now either makes it explicit or encourages contributors to do so on their own sites. That's all we can do. - Tantek
  • closed 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)
      • REJECTED. This was considered a while ago and rejected for a number of reasons:
        • Adds complexity for very little benefit. Using just one attribute (class) for a microformat makes them simpler and reduces chances of error. RDFa has been struggling with 'property' vs. 'rel' issues with just two attributes! - Tantek
        • Forcing an ID to be used for a microformat semantic is an unreasonable requirement to place on an attribute which can only have one value. The 'class' attribute works for microformats because authors can simply add microformats class names to their existing class values and have everything keep working. ID is single-valued and doesn't work that way. If there was a way to make ID multivalued that could help fix this, but then the first problem noted above, increased complexity, would still remain. - Tantek

see also

Retrieved from "http://microformats.org/wiki/index.php?title=issues-closed&oldid=44862"