RE: ACTION-78: Suggestion text for 1.5.4

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

Received on Sunday, 18 January 2009 20:37:26 UTC