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

Re: [Public WebGL] WebGL URI Extension Proposal



On Thu, May 17, 2012 at 12:18 PM, Florian Bösch <pyalot@gmail.com> wrote:
> On Thu, May 17, 2012 at 8:07 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>>
>> You are correct that this is a misrepresentation of my position. My
>> position is actually:
>>
>> "When tools processing formal languages wish to describe and consume
>> source using language extensions, a standard method should be used."
>>
>> The OpenGL ES WG clearly agrees with this statement by inclusion of
>> the #extension preprocessor directive.
>>
>> I am simply advocating the expansion of #extension's namespace to the
>> namespace of the Web, URI.
>
> I admit defeat. I still don't have the faintest idea what this is supposed
> to solve. I'm trying to find the use-case in there, and you sure sound like
> it's perfectly obvious, but darned if I can find it.

The use case is declarative language extension in a Web environment.

The URI extension represents the understanding that the official WebGL
extensions have aliases/synonyms in the URI namespace. The official
Web names (URI) of the official extensions are the real names of those
extensions in a global context.

Acceptance/rejection of the extension is not zero-sum. If something
like URI is standardized, the most important result will be the
ability to standardly represent URIs and URLs in WebGLSL preprocessor
source. This is important because WebGL shaders are Web resources and
should conform to the shading language standard. If an extension to
the language has been used, the shader source is still a resource that
is still nearly WebGLSL and should be served with the WebGLSL media
type (with the extension noted).

Being able to declare extension use by URI in a standard way costs
very little to implementers (as I attempted to demonstrate) and makes
the shading language an actual Web language (HTML, CSS, JS, XML can
all represent URIs). The fundamental components of the Web are
resources and links. WebGLSL provides neither so far. This extension
is an evolutionary adaptation of *Web*GL to the Web environment and
will be a competitive advantage of WebGL over competing graphics
stacks.

To use a previous city planning analogy, this extension is like a
municipal zoning ordinance for WebGLSL meta-programmers. Without this
ordinance, meta-programmers will be constructing de facto lock-in for
every tool or tool-chain. We will all suffer when some WebGLSL tool
becomes popular and leaves its extensions implicit without a commonly
agreed way to annotate them if we desire (the tool is not required to
emit or consume URI extension declarations but we should be able to
annotate extended source in a standard manner). Neither humans nor
machines will be able to understand exactly what semantics are
intended in a given implicitly extended shader resource.

The URI extension proposal makes language extensions into Web names
and resources through the use of links. It provides the language a
means to grow in an orderly fashion and enables tools which understand
many different standard libraries, syntactic and semantic extensions,
and source verifications. It reduces the cost and complexity of
customizing WebGLSL to the job at hand by representing extensions via
an already ubiquitous globally federated namespace.

The #extension directive is the natural place in WebGLSL to declare
extensions being used in a shader source listing. I have a number of
implementations under development that use it for this purpose. This
is the purpose for which it was designed.

The conversation I would like to have regards not whether something
like the URI extension is necessary (it is, doesn't hinder anyone if
it exists and is independently implementable anyway) but rather what
manner of integration between WebGL and RFC 3986 is most agreeable and
could be standardized to prevent a Babel-esque tragedy (I'm looking at
you, IE).

Do you disagree with the syntax I have chosen?

Do you have concerns regarding source comment conflicts? Allowable alphabets?

Do you think relative URI references should be allowed or are absolute
references safer?

They may twist the words "Open" and "Free" and "Standard" but I will
not stand for the perversion of "Web". Web is a philosophy and cannot
be achieved by nominal fiat alone no matter how titanic.

David Sheets

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------