|
|
| (12 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| <entry-title>hCalendar issues</entry-title>
| | {{DISPLAYTITLE:hCalendar issues}} |
| __TOC__ | | __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. |
| Line 20: |
Line 20: |
| 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. | | 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 === |
| | |
| | |
| | |
| === issues 2007 === | |
| <div class="hentry">
| |
| * {{OpenIssue}} <span class="entry-title"><span class="published">2007-01-20</span> raised by <span class="author vcard"><span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span></span>
| |
| <div class="entry-content">
| |
| *# <span id="dtend-date-plus1">Where <code>DTEND</code> is a date</span>, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki><abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.
| |
| *#*The ISO date 2007-04-30 is directly equivalent to 2007-04-30 00:00:00, which is why it's used as the end time of an event occuring on 2007-04-29. In this fuller context then you can view it as an abbreviation of 'the end of 29 April 2007'. Authors uncomfortable with this could use <nowiki><abbr class="dtend" title="2007-04-29 23:59:59">29 April 2007</abbr></nowiki>, or be more specific with their times. - [[User:CiaranMc|Ciaran McNulty]] 09:21, 12 May 2007 [GMT]
| |
| *#**The ISO standard has 2007-04-29 24:00:00 expressly to mark the end of the day 2007-04-29 rather than the start of the day 2007-04-30. This seems far preferable to 23:59:59. [[User:Matthew|Matthew]] 15:22, 17 Jul 2007 (PDT)
| |
| *#* This certainly risks confusion. The abbr title includes different information than the content; different when read by a 'normal' user who does not know about the exclusive-end-date.
| |
| *#** The trouble is going to be with dates (rather than date-times). User expectation is different if you are talking about "3 o'clock", which really is a point-in-time, and "29th April", something lasting 24 hours. No problem saying an end time is 'exclusive', but an end-date can be either and is typically inclusive.
| |
| *#** Using a more precise <code>dtend</code> is just a workround, you might not really want to say to the second when an event ends (as in 2007-04-29 23:59:59). You might easily want to say it runs from the Wednesday to Friday without committing to precise times - or that the event is sometime on that Friday but you don't know when.
| |
| *#* Possible options could be:
| |
| *#** Include a note in the standard that contradictory markup such as <code><nowiki><abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code> is bad practice and should be avoided
| |
| *#** Make a break with the ical usage that end dates are exclusive.
| |
| *#** Make the meaning clear: <div><code><nowiki><abbr class="dtend" title="value=date:value=inclusive:2007-04-29">29 April 2007</abbr></nowiki></code></div> <div><code><nowiki><abbr class="dtend" title="value=exclusive:2007-04-30">29 April 2007</abbr></nowiki></code></div> <div>or maybe</div> <div><code><nowiki><abbr class="dtend;value=date:value=inclusive" title="2007-04-29">29 April 2007</abbr></nowiki></code> [[User:Webf2|Webf2]] 00:25, 13 May 2007 (PDT)</div>
| |
| *#* ACCEPTED BRAINSTORM SPECUPDATE. In practice (e.g. http://barcamp.org ) it appears all too often (thus easy) to make the mistake of assuming a dtend value is inclusive, and thus the last day of many events is truncated by a day. I am proposing a solution on [[hcalendar-brainstorming]] in an attempt to help this move forward. In short, introduce the syntactic sugar "[[hcalendar-brainstorming#dtlast|dtlast]]", which treats date values as *inclusive* for the last day of an event. Semantically "dtlast" is merely an override for any "dtend" property setting on that hCalendar event, with the aforementioned slight difference in handling. More details on [[hcalendar-brainstorming#dtlast|hCalendar brainstorming: dtlast]]. [[User:Tantek|Tantek]] 07:48, 1 Sep 2008 (PDT)
| |
| *#* REOPENING based on new data. It seems the number of instances that dtend is being used to indicate an inclusive end date has only increased in the past year, and by knowledgable authors as well. Adding a new property just for inclusive end dates may very well only confuse the matter. We need to seriously consider changing "dtend" to *be* inclusive for "date" values only, keeping its current functionality for datetime values (suggested by [[User:Webf2|Webf2]] above). This is probably worthy of documenting on its own page, something like [[dtend-issue]]. - [[User:Tantek|Tantek]] 05:40, 26 August 2009 (UTC)
| |
| </div>
| |
| </div>
| |
| | |
| | |
| | |
| === 2009 ===
| |
| <div class="hentry">
| |
| * {{OpenIssue}} <span class="entry-title"><span class="published">2009-02</span> raised by <span class="author vcard"><span class="fn"> JMesserly </span></span></span>
| |
| <div class="entry-content">
| |
| *# Unclear whether YYYY or YYYY-MM is valid for dtstart or dtend
| |
| *#*Rationale for partial dates:
| |
| *#*#'''Identity theft'''- Wikipedia for example has guidelines on Living Persons to protect against identity theft. Over 3000 Marriage, Birth and death dates and emitted by wikipedia, and a high percentage for living persons include year only for birth date.
| |
| *#*#'''Unavailable precision''' Example: the birth date of Augustus Caesar is precisely known for the Roman calendar used at the time, however because of the frequency and chaos with which adjustments to that calendar were made prior to the adoption of the Julian calendar, the exact gregorian equivalent required for ISO8601 is impossible to know with precision. The best historians agree on is plus or minus 2 days, and it is said that it is unlikely there will ever be better precision. This is an example where we are using YYYY-MM, and it is quite common on in the 3500 genealogy pages emitting dstart/ dtends at [http://genealogy.wikia.com/index.php?title=Special:WhatLinksHere/Template:Info_table_person&from=70556&back=0&limit=500 genealogy.wikia.com], where it is frequently the case that family histories have only partial dates. -[[User:JMesserly|JMesserly]] 19:15, 6 April 2009 (UTC)
| |
| </div>
| |
| </div>
| |
| | |
| | |
| <div class="hentry"> | | <div class="hentry"> |
| {{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-07-14</span> raised by <span class="fn">[[User:BenWard|BenWard]]</span></span> | | {{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"> | | <div class="entry-content discussion issues"> |
| * <strong class="entry-title">Specification references to <code>abbr</code> pattern need to be removed/updated</strong>. See: [http://microformats.org/wiki/hcalendar#Human_vs._Machine_readable /hcalendar#Human_vs._Machine_readable] — the spec currently reads “This specification recommends that such <code><abbr></code> elements be used for the following iCalendar properties: DTSTART, DTEND, DURATION, RDATE, RRULE</code>. That is no-longer appropriate. In fact, I think it should be made clearer that those properties ''may'' be marked up using the abbr, or value-class patterns, but that it isn't required. The current language basically masks the fact that you might publish <samp>2009-07-14</samp> literally, and may be some reason why people believe that they ''have'' to use the abbr pattern. Further, this language is incompatible with publishing HTML5 with the <code>time</code> element. | | * <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. |
| ** Proposed resolution: Remove all ‘endorsement’ language regarding specific optimization patterns from the spec. The properties concerned should link to appropriate patterns and suggest uses ‘may’ use them to control the presentation of dates. --[[User:BenWard|BenWard]] 17:39, 14 July 2009 (UTC)
| |
| </div>
| |
| </div>
| |
|
| |
|
| <div class="hentry">
| | 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. |
| {{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-07-14</span> raised by <span class="fn">[[User:BenWard|BenWard]]</span></span>
| |
| <div class="entry-content discussion issues">
| |
| * <strong class="entry-title">All properties that are appropriate for use with the [[value-class-pattern]] must opt in to using it.</strong>. See: [[machine-data]] for the current reference for which properties have value-class-patterns support. Revisions of specifications should be updated to opt-in to value-class where appropriate.
| |
| </div> | | </div> |
| </div> | | </div> |
|
| |
|
| == Template == | | == Template == |
|
| |
| {{issues-format}} | | {{issues-format}} |
|
| |
|
| == Related Pages == | | == Related Pages == |
| {{hcalendar-related-pages}} | | {{hcalendar-related-pages}} |
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.