Re: ACTION-78: Suggestion text for 1.5.4

Robert J Burns wrote on 01/18/2009 05:51:06 PM:
>
> Hi Larry,
>
> Now that's a section draft I could support. it's NPOV, Fox News Style
> (fair and balanced). It presents both sides: the one about the openly-
> produced vendor-neutral language; and then the truth (though I guess
> they usually don't get to that part at Fox due to time constraints).

Neither represent the truth.

While a number of hyperbolic assertions have been made about the decision
making process around here (including the one below which was labeled as
being presented explicitly for *amusement* purposes), in my short tenure
here my biggest observation is that deadlines are created primarily for the
enjoyment of the "whooshing" sounds that they produce [1], and the effect
of that dwarfs all other explanations for the current status quo of the
working group.

In a larger context, the W3C frankly dropped the ball with respect to
continue the evolution of HTML.  A number of companies and individuals
reacted to that differently: Adobe, Microsoft, and Ian to take three
examples.  Note I said Ian, not WHATWG or Google.  From my point of view,
Ian is the nucleus around which the WHATWG formed, and Google later
provided him a home.

I joined this group because the future of the web is important to me, and
surveying the various options, this is the one that I chose to support with
my time and effort.  And by "this" I mean the one that is a direct result
of efforts that Ian started five or so years ago.

Reducing the scope of the context a bit, the WHATWG clearly has a PR
problem of their own making, and the HTML working group clearly has an
effectiveness problem.  On the latter, my observation is that the
expectation simply isn't in place that deadlines mean anything.  And there
are two parts to that: (1) those that volunteer for a deadline all too
often don't take the date they they themselves put in place seriously, and
(2) from what I can tell, nobody else does either.  Much to my surprise
when I had made a concrete proposal myself on a minor action item and
having heard no objections went to close the action item, I found that
things don't work that way around here.  In fact, I was chastised for
having that expectation.[2]

And regarding the former ("PR") problem, let's just say that for now, I
would much rather have the former problem than the latter.  *MUCH*

Reducing the scope of the context down to this specific action item: Larry
apparently *does* take deadlines seriously.  He has made a serious proposal
a specific replacement for this entire section, namely a null string.  To
date, he has obtained no objections.  In fact, I read Maciej's email as
being in support of this proposal[3].

So let me ask this: Is there *anybody* who *can't* *live* *with* this
proposal (namely removing section 1.5.4)?  If so, why not, and what do you
propose instead?

Returning back around to the "hyperbolic assertions" that I started this
email talking about: I honestly don't know what the truth is there.  I do
know that I was able to work with Ian in the past (e.g., convincing him of
the wisdom on accepting as conformant a trailing slash in always empty
HTML5 elements[4]).  On the topic of the recent action item[5] I had
accepted, I had an private IM conversation with Ian on this and he was
ready to adopt Henri's suggestion[6] right then and there, and *I* asked
Ian to hold back until Thursday in order to give everybody an opportunity
to weigh in on the subject.

And I won't ever know the truth until we have a specific instance where
somebody has taken the effort to drive something to closure and gain the
closest thing we can ever possibly have to consensus around here: namely a
concrete proposal with a number of independent endorsements and with nobody
indicating that the can't positively live with that proposal; and yet for
whatever reason the editor chooses not to update the draft based on
consensus.

And just to close this email with something concrete, I'll simply ask
again:

Is there *anybody* who *can't* *live* *with* this proposal (namely removing
section 1.5.4)?  If so, why not, and what do you propose instead?

- Sam Ruby

P.S.  If people know of past history that I should be aware of, feel free
to bring it to my or ChrisW's attention off list.  For the moment, I would
prefer if this list concentrated primarily on making forward progress on
the spec, and less so on meta process issues.

P.P.S.  Please do *not* write me and tell me that you take deadlines
seriously and provide proof.  That was a bit of hyperbole on my part.  :-)
Instead do me a favor and respond constructively if you take issue to a
proposal, and work to meet future dates that you either set or have already
set for yourself.

[1] http://www.quotationspage.com/quote/723.html
[2] http://lists.w3.org/Archives/Public/public-html/2009Jan/0159.html
[3] http://lists.w3.org/Archives/Public/public-html/2009Jan/0117.html
[4]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-November/008035.html
[5] http://www.w3.org/html/wg/tracker/issues/54
[6] http://lists.w3.org/Archives/Public/public-html/2009Jan/0164.html

> Take care,
> Rob
>
> On Jan 18, 2009, at 2:36 PM, Larry Masinter wrote:
>
> > I suggested removing section 1.5.4 from the specification.  The text
> > of 1.5.4 mentions vendors 7 times, application developers 4 times,
> > and users only once.  It makes numerous specious claims, including
> > claims about the similarity or equivalence of the problems
> > addressed, about the openness of the process by which the
> > specification was created, about the neutrality of the advantage the
> > specification plays in the ongoing "browser wars", about the range
> > of platforms and devices that are supported in comparison with the
> > languages it is contrasting with, about the benefits to application
> > developers and the costs of the alternatives, about the cost to
> > switch between platforms or the relevance of that cost compared to
> > other costs and benefits.
> >
> > I think it's more effective to focus on the technical issues rather
> > than the political ones, and removing the text seems better than
> > engaging in further debate.
> >
> >
> > However, I did say I had alternative text which I would offer, if
> > removing 1.5.4 isn't acceptable. In that spirit, I offer the
> > following flame for your amusement (do not quote out of context):
> >
> > <flame>
> > Some people claim that this specification is independent of the
> > various proprietary application languages that various vendors
> > provide, but is intended to address many of the same problems.
> >
> > They also claim that, in contrast with proprietary languages, this
> > specification is intended to define an openly-produced, vendor-
> > neutral language, to be implemented in a broad range of competing
> > products, across a wide range of platforms and devices. This enables
> > developers to write applications that are not limited to one
> > vendor's implementation or language. Furthermore, while writing
> > applications that target vendor-specific platforms necessarily
> > introduces a cost that application developers and their customers or
> > users will face if they are forced to switch (or desire to switch)
> > to another vendor's platform, using an openly-produced and vendor
> > neutral language means that application authors can switch vendors
> > with little to no cost.
> >
> > Others believe that this specification was the product of a self-
> > selected cabal of browser implementers, with a closely held decision
> > process in which technical decisions are made by a single individual
> > and dissent shouted down by his accolades. They believe that it is
> > equally likely that this specification is intended to preserve the
> > hegemony of proprietary search engine providers and walled-garden
> > handset operating system makers by stifling any innovation in the
> > web that is outside of their control.  This specification reifies
> > and promotes current poor practices of web authors who have taken
> > advantage of previous proprietary extensions and implementation
> > accidents in previous browsers, and permanently mandates backward
> > compatibility of web browsers with current desktop PC applications
> > in a way that forces a processing model that is inappropriate for
> > many otherwise legitimate contexts for delivery of web content.
> >
> > The web has seen a growth of rich extensions in web functionality
> > for interactive graphics, video, 3D, image browsing and so on, well
> > beyond the scope of "HyperText" which is the natural province of the
> > HyperText Markup Language (HTML).  This specification increases the
> > scope of HTML to include poorly designed equivalents of a small
> > number of features previously only found in innovative extension
> > languages -- languages from a wide range of sources, which were
> > designed specifically for meeting user needs for greater
> > expressivity. Even though there are widely available implementations
> > of most of those languages, some browser makers prefer to have the
> > entire experience in an integrated software package completely
> > within their control.  Of course, any specification of HTML itself
> > cannot completely satisfy all future needs for expressivity and
> > interactivity, and so extensions -- whether originally from a single
> > vendor or an alliance within the broader community -- will continue
> > to be an important source of innovation for the web and its users.
> > </flame>
> >
> > (tell us how you really feel)
> >
> > Larry
> > --
> > http://larry.masinter.net
> >
> >
> >
> >
> >
>
>