[uf-discuss] human readable date parsing

[Breton Slivka]

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 at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss