[uf-discuss] Human and machine readable data format

[Ben Ward]

On 1 Jul 2008, at 13:28, Scott Reynen wrote:

> The difference with ISO dates is we've previously defined them as  
> content; I'm suggesting that's a mistaken definition, as these dates  
> don't function as content in our reference standard iCalendar.

In my view, it's not so much that an ISO dates isn't content per se,  
it's that it's not content for humans, and in this case, the date  
content for humans is being published in a different form. In HTML,  
visible content is for humans, content for machines is hidden.

This makes for a violation of the DRY principal, but it's the same  
violation we're already making, and it applies not just to datetimes,  
but also to durations (which has only just been mentioned in this  
discussion, and is important not to ignore), hCard telephone types,  
geo co-ordinates, and everything else documented on http://microformats.org/wiki/machine-data 
.

As an aside, this is why I favoured and have done some initial work  
into the empty-element-with-title extension to the value-excerption- 
pattern (which I'm also leading the effort to get properly specified,  
since it's previously not been). It keeps the machine content in the  
HTML, can be specified to keep it physical proximity to the human  
form, but due to the way empty elements are treated, does not expose  
that content to humans. It does not violate DRY any more than we  
already do and in relation to the ‘hidden data’ principal, I argue  
these are exceptional cases _because_ they are DRY violations. We are  
not hiding information, we're hiding an alternate representation of  
visible information. (issues page: http://microformats.org/wiki/value-excerption-pattern-issues) 
.

Much of this same line of discussion applies to the class-name data  
embedding that Jake and Frances have discussed.

If there's a semantically acceptable solution to this, which doesn't  
violate any principals, or DRY, or the semantics of HTML, doesn't  
compromise accessibility or internationalisation, and meets publishers  
demands for flexibility and doesn't compromise user experience, then  
that would be fantastic. None of the discussions so far seem to match  
that.

B