- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 28 Jun 2011 22:00:29 -0400
- To: public-html@w3.org
On 06/28/2011 09:21 PM, Tantek Çelik wrote: > On Tue, Jun 28, 2011 at 02:54, Julian Reschke<julian.reschke@gmx.de> wrote: >> On 2011-06-23 23:15, Julian Reschke wrote: >>> >>> On 2011-06-23 23:03, Tantek Çelik wrote: >>>> >>>> On Thu, Jun 23, 2011 at 13:47, Leif Halvard Silli >>>> <xn--mlform-iua@xn--mlform-iua.no> wrote: >>>>> >>>>> Tantek Çelik, Thu, 23 Jun 2011 12:03:59 -0700: >>>>>> >>>>>> I personally am not opposed to 'index' in particular (I've used it in >>>>>> the past). >>>>>> >>>>>> However, I strongly prefer that we follow at least some sort of >>>>>> rational/scientific methodology in such iterations so as to provide >>>>>> objective (repeatable) reasoning of our actions, decisions, changes. >>>>>> >>>>>> So far I've been using the data available to reason how to treat >>>>>> existing or previous rel values. >>>>>> >>>>>> In short: >>>>>> * if a rel value was in a draft and is missing (without explanation) >>>>>> from the final spec, or >>>>>> * if a rel value was in a previous version of and is missing (without >>>>>> explanation) from an update to the specification (even a draft update) >>>>> >>>>> A repeatable, objective criteria: HTML5 doesn't per se decide what goes >>>>> into the Microformat registry. Rather, it is the opposite way. The >>>>> Microformats registry is supposed to be the one which forms the basis >>>>> for whether a link relation may pass the door to the HTML5 >>>>> specification. >>>> >>>> cite/link to HTML5 spec text or WG decision text that supports this >>>> "supposed to be" assertion? >>> >>> That's usually the point of a registry. >>> >>> As such, I disagree with what Leif said as well: "The Microformats >>> registry is supposed to be the one which forms the basis for whether a >>> link relation may pass the door to the HTML5 specification." >>> >>> No! Usually the point of a registry is to *decouple* the container >>> format from the definitions of extensions. Once you have a working >>> registry, you don't need to include values into the base spec, except >>> for those which *need* to be defined there. >>> >>> For instance, HTTP does have a registry for status codes. We don't >>> *need* to include them into the base spec, unless they are somehow >>> "special". >>> >>>> ... >>> >>> Best regards, Julian >> >> Tantek, what's the next step now? > > I was unable to follow Leif's reasoning - especially as it didn't > cite/quote anything from the spec or the decisions. > > >> Should I go ahead and edit the Wiki page? > > My concern is this, given that "index" was in the core HTML4 spec, and > now isn't in the core HTML5 spec, we must be diligent in explaining > *why* it is ok that we still register it (e.g. with specific quote > from the WG decision that explains that it's ok). > > If you can find such a quote (and not have to add sentences/paragraphs > of explanation/theory, i.e. this email thread), then yes, go ahead and > edit the wiki to register 'index' and add that specific cite/quote of > the WG decision. > > Otherwise I think the issue needs to raised back to the chairs for > clarification. Given that it was an issue raised to and resolved by > the chairs in the first place, it behooves us ask them if we're unable > to provide a clear direct quote that substantiates re-adding 'index'. Generally the chairs limit themselves to evaluating proposals that actually are brought forward. Here is the decision: http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Here is the proposal that was selected: http://lists.w3.org/Archives/Public/public-html/2010Nov/0042.html If it is helpful, here are the proposals that were not selected: http://lists.w3.org/Archives/Public/public-html/2010Oct/0268.html http://lists.w3.org/Archives/Public/public-html/2010Oct/0269.html http://lists.w3.org/Archives/Public/public-html/2010Nov/0041.html And here is the survey results: http://www.w3.org/2002/09/wbs/40318/issue-118-objection-poll/results > Thanks, > > Tantek - Sam Ruby
Received on Wednesday, 29 June 2011 02:01:02 UTC