|
|
| (93 intermediate revisions by 25 users not shown) |
| Line 1: |
Line 1: |
| = hCalendar Issues =
| | {{DISPLAYTITLE:hCalendar issues}} |
| | __TOC__ |
| | These are externally raised issues about [[hcalendar|hCalendar]] 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. |
|
| |
|
| These are externally raised issues about [[hcalendar|hCalendar]] 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. — [http://tantek.com/log/ Tantek]
| | '''IMPORTANT''': Please read the [[hcalendar-faq|hCalendar FAQ]] and the [[hcalendar-issues-resolved|hCalendar resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered. |
|
| |
|
| See related [[hcard-issues]].
| | 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. — [[User:Tantek|Tantek]] |
|
| |
|
| == Issues ==
| | For matters relating to the iCalendar specification itself, see [[icalendar-errata]] and [[icalendar-suggestions]]. |
|
| |
|
| Please use this format:
| | See related [[hcard-issues]]. |
| * YYYY-MM-DD raised by AUTHORNAME
| |
| *# ''Issue 1: Here is the first issue I have.''
| |
| *# ''Issue 2: Here is the second issue I have.''
| |
|
| |
|
| And add new issues to the top of the list:
| | == closed issues == |
| | See: [[hcalendar-issues-closed]]. |
|
| |
|
| * 2006-02-01 raised by [[RyanKing]]
| | == resolved issues == |
| *# ''Issue 1: Given that now, or soon will have hAtom, should we disallow vJournal, so that we don't have 2 blog-post formats?''
| | Issues that are <span id="Resolved_Issues">resolved</span> but may have outstanding [[to-do]] items. See: [[hcalendar-issues-resolved]]. |
| * 2006-01-04 raised by [[User:CGranade|CGranade]]
| |
| *# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
| |
| *#* REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.
| |
| *# ''All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.''
| |
| *#* ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
| |
| * 2005-10-14 raised by [[User:MarkoMrdjenovic|MarkoMrdjenovic]]
| |
| *# ''UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. [http://www.ietf.org/rfc/rfc2445.txt RFC] recommends use of addr format for uids which is problematic in html id (does not validate). [[User:HenriBergius|HenriBergius]] pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org''
| |
| *#* ACCEPTED-PARTIAL. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
| |
| *# ''DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.''
| |
| *#* ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
| |
| *# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''
| |
| *#* For more discussion of this, please see [http://microformats.org/wiki/hcalendar-brainstorming#UID_handling hCalendar brainstorming: UID handling]
| |
| <pre><nowiki>
| |
| <li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
| |
| <abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
| |
| <abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
| |
| <a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
| |
| <span class="summary">From the other cal</span>
| |
| </a>
| |
| <abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
| |
| </li></nowiki></pre>
| |
| * 2005-09-29 raised by RyanKing
| |
| *# ''How does one use ATTENDEE?''
| |
| * 2005-07-27 raised by Paolo Massa
| |
| *# ''I tried to add a hcalendar event in my blog but it rendered orribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:
| |
|
| |
|
| .vevent .summary {
| | == Issues == |
| | | Please add new issues to the '''bottom''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted. |
| //remove all the previously set properties, for example:
| |
| | |
| text-decoration: none;
| |
| | |
| font-size: 100%;
| |
| | |
| ...
| |
| | |
| }
| |
| | |
| Since the hCalendar microformat is the following,
| |
| | |
| <span class="vevent">
| |
| | |
| <a class="url" href="http://www.web2con.com/">
| |
| | |
| <span class="summary">Web 2.0 Conference</span>:
| |
| | |
| ...
| |
| | |
| I hope to have been clear but I'm not so sure ;-)''
| |
| | |
| | |
| * 2005-07-21 raised by Neil Jensen
| |
| *# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming]. Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''
| |
|
| |
|
| * 2005-07-11 raised by Kragen
| | === issues 20010 === |
| *# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk|xFolk]].''
| | <div class="hentry"> |
| | {{OpenIssue}} |
| | <span class="entry-summary author vcard"> |
| | <span class="published">2010-MM-DD</span> |
| | raised by <span class="fn">[[User:Toby|Toby]]</span> |
| | </span> |
| | <div class="entry-content discussion issues"> |
| | * <strong class="entry-title">non-ending events</strong>. How to deal with events that do not end, or even as such occur, just "applied" to a person. Such as in hResume, an award, under experience, would use hCalendar. it does not have an end nor does it continue, I am awarded a certain status and now have that status or recognition of ability. It is awarded on a certain date but it does not end, I do not lose ability, but nor does the awarding continue, I am not re-awarded every single day, so the solution of "to present" for an ongoing event etc, is not really suitable. |
|
| |
|
| * 2005-06-21 raised by Hixie
| | Some new way to do this could be added to hCal that is not linked to vCal so that online extractors of hCal (and not vCal) would not automatically represent events with no end date as ending "present" (as with madgex hres to word) unless otherwise specified that this is intended. |
| *# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
| | </div> |
| | </div> |
|
| |
|
| * 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
| | == Template == |
| *# ''There is no copyright statement and no patent statement.''
| | {{issues-format}} |
| *#* ACCEPTED. I have updated [[hcalendar]] (and [[hcard]], and all other MicroFormats) with a standard copyright statement and patent statement.
| |
|
| |
|
| * 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
| | == Related Pages == |
| *# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
| | {{hcalendar-related-pages}} |
| *#* REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
| |
| *# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
| |
| *#* REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
| |
| *# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
| |
| *#* REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
| |
| *# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
| |
| *#* REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
| |
| *# ''There are styling and tooltip issues that are unresolved.''
| |
| *#* REJECTED (empty statements). See the [[hcalendar-faq|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
| |
| *# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
| |
| *#* REJECTED (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.
| |
| *# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
| |
| *#* ACCEPT-PARTIAL. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
| |
| *#* ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats]] specifications in general? (If not, why not?)''
| |
| *#** ACCEPTED. Yes, all [[microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
| |
| *#*** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
| |
| *#**** ACCEPTED. This is on Tantek's [[to-do]] list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.
| |
These are externally raised issues about hCalendar 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.
IMPORTANT: Please read the hCalendar FAQ and the hCalendar resolved issues before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.
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
For matters relating to the iCalendar specification itself, see icalendar-errata and icalendar-suggestions.
See related hcard-issues.
closed issues
See: hcalendar-issues-closed.
resolved issues
Issues that are resolved but may have outstanding to-do items. See: hcalendar-issues-resolved.
Issues
Please add new issues to the bottom of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.
issues 20010
open issue!
2010-MM-DD
raised by Toby
- non-ending events. How to deal with events that do not end, or even as such occur, just "applied" to a person. Such as in hResume, an award, under experience, would use hCalendar. it does not have an end nor does it continue, I am awarded a certain status and now have that status or recognition of ability. It is awarded on a certain date but it does not end, I do not lose ability, but nor does the awarding continue, I am not re-awarded every single day, so the solution of "to present" for an ongoing event etc, is not really suitable.
Some new way to do this could be added to hCal that is not linked to vCal so that online extractors of hCal (and not vCal) would not automatically represent events with no end date as ending "present" (as with madgex hres to word) unless otherwise specified that this is intended.
Template
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">
{{OpenIssue}}
<span class="entry-summary author vcard">
<span class="published">2011-MM-DD</span>
raised by <span class="fn">~~~</span>
</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
</div>
</div>
Related Pages
This 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.