Re: ACTION-78: Suggestion text for 1.5.4

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).

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
>
>
>
>
>

Received on Sunday, 18 January 2009 22:51:46 UTC