I should perhaps add that my solution must also violate either restriction 3, or 4- that is, you can hide the year element with CSS. If you leave it visible, then it may follow common usage in a lot of situations. Or you might end up using a year in situations where you may not usually specify a year, violating the common usage in that situation. If you hide it, then you violate 3. But, the choice of which principle to violate is left in the hands of the author.

On 04/05/2007, at 9:49 AM, Breton Slivka wrote:

This is a very difficult problem. Difficult problems need as many potential solutions as possible to be presented- The more solutions, the more chance of arriving at a good one. The tricky part here is creating a solution which is in line with common usage.

It seems to me that by basing hcalendar on a single existing format, then expecting it to conform to some wider sense of principles concieved well after that format was created- It's a bit counter productive. the ISO date format itself does not fall in line with common usage, unless you consider the iCalendar format- posted in the raw on an html page to be common, or any ISO date.

So basically we are presented with a number of restrictions, which define the range of possible solutions. It seems to me that in order to more effectively solve this problem, this set of restrictions should be clarified- Here's what I've got so far, correct me if I'm wrong.


Date markup must:

1> be capable of marking up dates from multiple cultures and languages
2> Follow the DRY principle
3> Be completely visible
4> Follow common usage
5> Be machine readable
6> Be unambiguous

and the unstated (and perhaps unconcious) restriction

7> Be as similar to iCalendar as possible in form and function.

At least two of these restrictions conflict. Most obvious is number 4 and 6.

Common usage is frequently ambiguous, so we should perhaps acknowledge that a microformat that marks up a date is going to either force common usage to be unambiguous (By requiring the inclusion of a year in all dates)

Or instead, allow ambiguity through sophisticated (or unsophisticated) guessing on the part of the parser. If this course is taken, this process of guessing should be documented and standardized

Or, violate restrictions 2 and 3, which is the current solution.


So, are those all the restrictions? In order to arrive at a solution, at least one of them must be violated- are we violating the right one?

Here's my contribution to the solutions pool. Violate number 7. Example:

  July 26th, 2005

<span class="vmonth">July</span> <span class="vday">26</span>th, <span class="vyear">2005</span>

This solution is certainly more verbose, but note that it follows all restrictions except for 7.

Which restrictions do you want to violate?

_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Reply via email to