- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Fri, 13 Apr 2012 13:53:37 +0100
- To: Ian Devlin <ian@iandevlin.com>
- Cc: public-html@w3.org
- Message-Id: <461FF522-2A44-4DF5-97BA-B150D3F5575A@gmail.com>
Hi Ian, There are a couple of items around this which i'd like to highlight. The first is that ISO 8061 actually does cater for the encoding of BCE date\times, if you check section '3.5 Expansion': "…By mutual agreement of the partners in information interchange, it is permitted to expand the component identifying the calendar year, which is otherwise limited to four digits. This enables reference to dates and times in calendar years outside the range supported by complete representations, i.e. before the start of the year [0000] or after the end of the year [9999]." It seems that authors and consumers interested in BCE date\times would implicitly agree with expanded year representation including a sign [±YYYYY] and that HTML microsyntax should explicitly allow for this as an extension over the ISO standard in similar manner to the optional exclusion of timezone [Z] character and the other enhancements which were addressed in Tantek's proposal. Further to this, if this ability were not the case and ISO 8061 and the HTML date\time microsyntax were incapable of being extended, the means to satisfy this use case would be, as you suggest, through the addition of an attribute to <time> in order to derive the definition of the @datetime value. This represents the same solution as applied through <data> with a @type discriminator yet for a single datatype and use case. This is the point which i raised within my proposal under Rational heading "Discrimination of Denominations" which examines the alternative approaches between encoding within <time> and <data>. One of the concerns over <time> is that deferring type resolution to the microsyntax is an inflexible and non-extensible solution and if in order to satisfy further use cases <time> requires the addition of a discrimination attribute, then this indicates that the approach taken by <data> is the terminal solution. To explore this some more, if we look at data representation within computational machines we find separation between type and data, for example: Media Types and Content. The media type defines the processing model and the the content is the data to be processed. This has proved to be a valuable separation within document\content encoding and, by extension, that this also represents the same value within data representation. Thanks, Cameron Jones On 12/04/2012, at 7:19 PM, Ian Devlin wrote: > Hi, > > I noticed from the summary email that went out earlier today that Issue 183: Enhance and simplify the time element is due to close tomorrow. > > I'd like to submit an additional change proposal which isn't a counter proposal, but merely a suggested enhancement to Tantek's proposal which forms the basis of Issue 183. > > My proposal: add an 'era' attribute to the HTML5 <time> element, can be found at - http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element > > Regards, > > Ian > > -- > ian devlin > e: ian@iandevlin.com > w: www.iandevlin.com > t: @iandevlin > skype: idevlin > > buy my book: html5 multimedia: develop and design > > >
Received on Friday, 13 April 2012 12:54:23 UTC