- From: Robert Burns <rob@robburns.com>
- Date: Sun, 24 Jun 2007 17:14:28 -0500
- To: Dan Connolly <connolly@w3.org>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
On Jun 24, 2007, at 4:31 PM, Dan Connolly wrote: > On Sun, 2007-06-24 at 14:02 -0500, Robert Burns wrote: >> On Jun 23, 2007, at 1:31 PM, Dan Connolly wrote: >> >>> >>> The differences document is nice and short; it has gotten >>> a generally positive reaction. >> >> I think the positive reaction to the document is due to the fact that >> we needed such a document to move the discussion along within the WG. >> I don't think we're even close to a public release of that or any >> document (maybe we'll be ready next month or August). > > We're already behind schedule for publishing something, strictly > speaking. We were chartered 7 March; 3 months later is 7 June. > Due to the fact that we weren't exactly firing on all cylinders > on 7 March, a slip 'till the end of June or early July is > somewhat straightforward; beyond that... I can ask for an exception > to the heartbeat rule, but I would need to make a very good case. > > The heartbeat rule is > http://www.w3.org/2005/10/Process-20051014/groups.html#three-month- > rule > > It was cited from the "What should the HTML WG publish first?" survey, > right at the top... > > "If you're not familiar with the process of Working Draft publication, > see the list of W3C working drafts, section 7.4.1 First Public Working > Draft of the Process document, and the heartbeat requirement." > -- http://www.w3.org/2002/09/wbs/40318/wd7/results > > >>> I suggest this WG should publish it in its present form. >>> http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/ >>> Overview.html >>> $Revision: 1.22 $ of $Date: 2007/06/23 15:22:05 $ >> >> I think to release that document now would be a big debacle. It would >> create similar misunderstandings to those faced by XHTML2 when >> everyone thought they couldn't have <img> elements in their documents >> anymore (like HTML was going to become text only). Such >> misconceptions will dominate the discourse about HTML5 and the public >> will not recognize all of the positive contributions HTML5 makes. > > I see the risk; being quiet is not likely to help. Better to > let the discussion start, I suggest. > >> Before we can publish this or the spec, we should wait for the >> detailed review to come in over the next few weeks. > > I agree that publishing the spec should wait until the scheduled > review completes, but only presuming this WG publishes something > else to satisfy the heartbeat requirement first. Would not publishing the design principles as a working draft satisfy the heartbeat requirement? I've seen little objections to that document and think it could be made ready for publication (at least as a working draft if not final) rather quickly. >> On the HTML4 / >> HTML5 differences document, we need to: >> >> 1) settle the issues already raised on the assistive technologies >> features that are missing in HTML5. > > I think it's perhaps worthwhile to note issues that have gotten > a lot of discussion. I intended to suggest text along those lines > as soon as I saw Anne's draft. But that was 2 weeks ago, and > I haven't managed to do it. And I'm not sure it will be easy > to come to consensus on a description of the status of discussion. > So I am content to just report, factually, which features are > in the current editor's draft. > > The "status of this document" section will of course note that > there are various open issues and that the WG hasn't made > decisions on any of them. > > I hope you can accept publishing a document while these issues > are still open. I don't see how we can meet the heartbeat > requirement otherwise. In general, I would certainly support publishing working drafts while issues are still open. However, on some of these issues I think it would be irresponsible to publish with such serious issues left outstanding. Again, I'm saying that these issues will dominate the discussion long after they're resolved by the WG. It will be hard to live down the misconception that "HTML5 is that new version that is less expressive than the old version" mentality. Better to make sure these mistakes are fixed before the first public working draft is published. >> From the discussions that have >> occurred so far, I would say the overwhelming consensus is that these >> features should NOT be dropped in HTML5. > > "overwhelming consensus" is a contradiction in terms, in W3C process. > In W3C process, if one person objects, there is not consensus. There > is no level of support sufficient to be called "consensus" as long > as objections remain. I have not really seen serious objections to including the assistive technology semantics. Perhaps they occurred before I arrived, but I've tried to diligently read everything that's passed since I joined the working group. > It might be correct to say "the overwhelming majority of opinion" > or some such, but that would be based on a lack of information; > most WG members have not given their opinion. Perhaps > "the overwhelming argument that has been presented" is accurate. Is not "given an opinion" the same as "not given their opinion". My understanding of WG rules was that an active objection needs to be registered and a passive silence would not be counted as an objection. > Evidently, the editors are not convinced. Or perhaps they haven't > gotten around to reading all the relevant arguments. I hope > the editors respond to this issue in due course in a way that > results in consensus. Otherwise, we'll escalate to the whole > WG and make a formal decision. I'm not sure what priority > to give to that task, but I hope I can put it at a lower > priority than a decision to make our first publication. > Otherwise, we run into the heartbeat requirement and the > risk that this WG gets closed altogether. > > >> If we decide to publish the >> differences document without settling these AT issues, we need to (at >> the very least) explain what alternative mechanisms authors will use >> in HTML5 for the features from HTML4 that HTML5 no longer supports >> >> 2) provide detailed explanations for the semantic changes in elements >> such as <ht>, <i>, <b>, <strong>, and <small>. > > Feel free to suggest any specific changes you want. > > <rant> > Saying "we need X" as though we're a bunch > of customers who can demand service annoys me. We are the working > group. If we want work done, the most constructive thing is > to do it. > </rant> I'm not clear on how to do it. Perhaps I haven't read the materials sufficiently, but isn't it appropriate to air the necessary changes here on the email list. Others have also added this to the wiki. What else should we members of the working group do? I'm not trying to be facetious here, I honestly thought that airing things here on the email list was the way we move the process forward to meet our deadlines. If there's more I should be doing I'd be happy to. >> In my view, the change >> in semantics means we do not maintain the html namespace. After all, >> a namespace is a promise that the names used in the space will always >> mean the same thing. New names may be added. Other names may be >> deprecated. But the names, once introduced, will always have the same >> meaning. > > I'm not so sure. The TAG looked into that and found otherwise: > > "As a general rule, resources on the web can and do change. In the > absence of an explicit statement, one cannot infer that a namespace is > immutable." > -- http://www.w3.org/2001/tag/doc/namespaceState.html Certainly a namespace is not immutable. I never meant to suggest otherwise. However, that's not the same thing as saying that the names within a namespace can simply change their meaning from one document to the next. To me that would be saying there is no namespace at all. Yes there are names used to designate certain ideas. However, its not a namespace because those names can designate one idea in one place and an entirely different idea in another place. In our situation, a named element may designate one idea in one html document and an entirely different idea in another html document. That would mean the absence of a namespace. Namespaces are mutable in the sense that names may be added and they may be deprecated or taken away. However, even when taking names away one would expect the namespace to keep track of what was taken away and not add the same name back years later that means something else. There's nothing in <http://www.w3.org/2001/tag/doc/ namespaceState.html> that would lead me to think otherwise. That document's purpose is to determine "whether or not adding new names to a (published) namespace is a sound practice.". That's not an endorsement for dropping any consistency in name / semantics over time. Again, I think the design principles document should suffice for the heartbeat rule and there was significant support for publishing that (and little discussion objecting to its current state). Take care, Rob
Received on Sunday, 24 June 2007 22:14:35 UTC