RE: [whatwg] <time> -- looking forward toward HTML6, needs assessment and spec-splintering

Aryeh Gregor wrote:
 
"A much saner solution seems to be to say that HTML supports exactly
one type of calendar: in this case, proleptic Gregorian."
 
In the past two years, I've seen folks conclude that some feature (like in this case, calendar systems like Chinese or Mayan) doesn't belong in HTML. I think realistically the WG means by that (assuming consensus, that may not actually emerge on this particular issue), that they don't belong in HTML5. 
 
It isn't that such stuff never belongs in HTML, rather that, for now, it may be too large a project. Not all theories of time are Cartesian; not all theories of space are dimensional. A semantics broad enough to support inference across differing concepts of time should probably, at some point in a possible future, be planned for. Maybe even sooner than that,  HTML should entertain alternative calendar systems -- but maybe not now, given a perceived need to actually arrive at a concrete spec at some time on some (consensually defined) calendar.
 
Do we keep track of those deferred issues that would be suitable for consideration in a future version of the spec? It might be nice to start a list of such things if such a list has not already been started. Are there issues that have been Resolved so tightly that they should never again be entertained? The items on the Issue Tracker don't seem to shed much light on the question. Among those which are marked "closed" very few seem to refer to functionality which should or should not be added to HTML. 
 
Two cases in point: 
 
Issue 49 (Pronunciation-semantics) was raised and then closed because "it otherwise does not meet the criteria we have set for Tracker issues in the group." What then is its status? (In this case I recall Hixie's analysis, which seemed sound to me. I can't find it, but as per recollection, he recommended waiting on it for now. )
 
Issue 47 (bookmark-and-clipping-support) -- closed, apparently since it has nothing to do with accessibility. I assume this means HTML5 will not do what was recommended here? Is it true that no HTML n for n>4 should ever do that?
 
The <canvas> tag (issue 15)  was approved by majority (aka consensus?) and so was closed.
 
Most of the others seem to be procedural things (how does tracker work; do we agree on the protocol for discussion and so forth). But hundreds of relatively small issues (too small to reach the criteria for Tracker issues?) have come and been decided on, and I would guess that at least dozens of those will reappear in HTML6. Maintaining pointers to the threads of those discussions might prove useful. *
 
Each time the WG decides (either through issue-tracker, consensus, or editorial logic) not to undertake some project there are a variety of possible reasons. Most often it is because the project lacks merit (in some socially perceived sense of merit). But often (or at least sometimes)  that sense of merit has a strong component of "practicality" intertwined with it. If projects are to be set aside not because they lack rationale, but because they are, at this point in time, impractical though desirable, then those are the sort of things that belong in the "deferred" or "postponed" pile. Issue Tracker does have a category called "postponed" but to date, nothing is in it.
 
Proponents of a feature might not be quite so disappointed if told their project was a good idea but that it has been postponed until HTML n  (for some n > 5). In some cases, individuals with wildly divergent (but valuable) opinions have drifted away in ways that may reduce the volume of the discussion, but that may also reduce the diversity of opinions.
 
By way of historical amusement, it might be fun, even, to predict what version of HTML a deferred project might belong in.
 
For example, I'd be willing to guess that cross-cultural calendar support won't really make it into HTML5, but that it will in HTML6. Support for non-Cartesian concepts of time may have emerged from the "Uncertainty Reasoning" Incubator Group but I'm not quite sure if their conclusions are in a form that will be usable until, say, HTML7.
 
Given the development cycle associated with specs, it seems like pipelining might be an appropriate methodology; it might circumvent future need for spec-splintering that some seem to advocate vis a vis the copyright / licensure issue. Given some of the problems that have been alluded to with dysfunctionality of the group, it may be possible to begin the engineering of a social climate in which HTML n can be built that will begin its work without some of that malaise. The first three months of public-html would form a fascinating case study. (I understand NSF has some funds this year???)
 
David
 
* I guess folks differ in terms of their concept of the importance of these debates. Some view opinions which do not match their own as noise that clogs the system;  others view them as data useful in predicting the amount of opposition that things may encounter once a spec is finally rolled out. I tend to think of them as messages bearing little snippets of wisdom in a cacophony of different dialects. One person's signal is another person's noise.

Received on Wednesday, 11 March 2009 00:30:50 UTC