[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] another proposal to temporarily expose some device/driver information only when really needed



On Tue, May 1, 2012 at 7:18 PM, David Sheets <kosmo.zb@gmail.com> wrote:
That's a nice personal opinion. It's my understanding that the W3C
strongly disagrees with your view in a large number of web standards.

The "W3C" isn't a hive mind with a single opinion.  If members of the W3C want to bring their opinions and their reasoning to the discussion, they're free to, but "the W3C thinks this" is meaningless.

FWIW, Hixie doesn't seem to find much value in URLs as identifiers: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1584.html

'slow' is a valid relative URI reference. I am simply proposing a
default base URI inside of Khronos' URI namespace with properties
interpreted as URI references. This automatically gives us a way to
extend the result set of the host profile call without collision and
provides means to unambiguously refer to these properties (instead of
"the property called 'slow' in the object returned from
getDeviceAttributes() in WebGL 1.0").

The meaning of a string has nothing to do with the "version" of WebGL; it can't change in incompatible ways over time.  You can't change the API in backwards-incompatible ways between two "versions" of WebGL.  (I put "version" in quotes because versions are meaningless with web APIs, and other web APIs are moving away from versioned specs. I hope that WebGL will follow suit in time.)

You yourself said

> This is a really hard thing to do in a way that's both forwards- and
> backwards-compatible...

and I have proposed the use of a ubiquitous web standard which solves
this ambiguity problem.

Please reread what I said.  The problem has nothing to do with naming, and everything to do with the fact that the meaning of the word "slow" changes over time, as the typical speed of hardware improves.  Whether you call it "slow" or "http://pointless.url/slow" changes nothing.

(I'm not inclined to debate the URL question further unless a WebGL spec editor thinks it's worth consideration, to not derail the thread further.)

--
Glenn Maynard