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

Re: [Public WebGL] Issues with Extension Registry

On Wed, Dec 7, 2011 at 10:38 PM, David Sheets <kosmo.zb@gmail.com> wrote:
> On Wed, Dec 7, 2011 at 10:19 PM, Kenneth Russell <kbr@google.com> wrote:
>> On Wed, Dec 7, 2011 at 1:37 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>>> On Tue, Dec 6, 2011 at 5:36 PM, Kenneth Russell <kbr@google.com> wrote:
>>>> On Tue, Dec 6, 2011 at 4:58 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>>>>> On Thu, Dec 1, 2011 at 3:51 PM, Kenneth Russell <kbr@google.com> wrote:
>>>>>> On Mon, Nov 28, 2011 at 8:09 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>>>>>>> On Mon, Nov 28, 2011 at 6:16 PM, Kenneth Russell <kbr@google.com> wrote:
>>>>>>>> On Mon, Nov 28, 2011 at 6:01 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>>>>>>>>> On Mon, Nov 28, 2011 at 5:19 PM, Kenneth Russell <kbr@google.com> wrote:
>>>>>>>>>> On Wed, Nov 16, 2011 at 5:30 PM, Chris Marrin <cmarrin@apple.com> wrote:
>>>>>>>>>>> On Nov 15, 2011, at 2:51 PM, Kenneth Russell wrote:
>>>>>>>>>>>> On Sat, Nov 12, 2011 at 11:26 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>>>>>>>>>>>> I have some issues with the registry:
>>>>>>>>>>>>> 1) Why are extensions "numbered"? It doesn't seem to add any value to list
>>>>>>>>>>>>> the "number" of the extension in the specs. I think we should remove it
>>>>>>>>>>>> This was discussed in the working group some months ago. The model was
>>>>>>>>>>>> inherited from the OpenGL extension registry, and I recall that the
>>>>>>>>>>>> reason for numbering there is that extensions are written as deltas
>>>>>>>>>>>> relative to the spec. The numbering disambiguates which extension
>>>>>>>>>>>> applies its edits to a given section first.
>>>>>>>>>>>>> 2) A better approach would be to list the submission date of the
>>>>>>>>>>>>> extension. Then the there can be a list of extensions by submission date.
>>>>>>>>>>>> How does this really differ from the numbering scheme? Extensions
>>>>>>>>>>>> submitted later have a higher number.
>>>>>>>>>>>> Also, how would ambiguity be resolved between two extensions submitted
>>>>>>>>>>>> on the same day? Admittedly this is a rare case.
>>>>>>>>>>>>> 3) Extensions should be listed by submission date and alphabetically
>>>>>>>>>>>> Sorry, do you mean having two lists (one sorted by submission date and
>>>>>>>>>>>> one sorted alphabetically), or one list sorted primarily by date and
>>>>>>>>>>>> secondarily alphabetically?
>>>>>>>>>>> I was thinking about two lists, sorted in the two ways. That way you can browse historically if you want. But if you're looking for a specific spec alphabetically would be easier.
>>>>>>>>>>>>> 4) Every spec should have a status section.
>>>>>>>>>>>> This should be implicit in the first line of each spec (whether it's
>>>>>>>>>>>> draft or not), and draft specs should use the Khronos working draft
>>>>>>>>>>>> banner. However, it looks like there are inconsistencies; I'll clean
>>>>>>>>>>>> this up.
>>>>>>>>>>>>> 5) Specs  that are final should be in a separate list from those still under
>>>>>>>>>>>>> evaluation
>>>>>>>>>>>> This sounds good. What would you think about making this split but
>>>>>>>>>>>> leaving the numbering scheme?
>>>>>>>>>>> Yeah, I'm fine leaving the numbering scheme. Seems odd (I don't ever see myself referring to "extension 17" for anything). But if it's been discussed, that's fine. But the unratified specs should be split out.
>>>>>>>>>> Sorry for the delay, but these changes have been implemented:
>>>>>>>>>> http://www.khronos.org/registry/webgl/extensions/
>>>>>>>>>> Thoughts?
>>>>>>>>> Javascript is required for the page to render correctly? The
>>>>>>>>> Javascript's function is not dynamic so why is it necessary to be
>>>>>>>>> executed at view-time instead of, say, edit-time?
>>>>>>>>> Why not keep the registry data in an XML file and use XSLT to
>>>>>>>>> transform that to a static page that doesn't require Javascript? Then
>>>>>>>>> the actual data of the registry would be trivially machine-readable
>>>>>>>>> with potential for arbitrary metadata (number, date, depends...).
>>>>>>>> I'm no expert in this area -- this was the only way I knew how to get
>>>>>>>> the desired result.
>>>>>>>> If you would contribute a patch that implements your suggestion that
>>>>>>>> would be excellent.
>>>>>>> Attached is a gzipped tar file that contains
>>>>>>> extreg/
>>>>>>> extreg/Makefile
>>>>>>> extreg/registry.html
>>>>>>> extreg/registry.xml
>>>>>>> extreg/registry.xsl
>>>>>>> The Makefile knows how to use 'xsltproc' to produce 'index.html'.
>>>>>>> I fixed two unmatched </p> tags on the page and added an alternate
>>>>>>> link of type text/xml to the head.
>>>>>>> Please mint a URL for the XML to live (or use conneg if you have
>>>>>>> it/it's not painful to use).
>>>>>>> Let me know if you find any issues and I will resolve them.
>>>>>> Hi David,
>>>>>> Thanks very much for doing this. The extension registry's been updated
>>>>>> with your contributions. Please post if there are any issues with it.
>>>>>> The XML file will permanently live at
>>>>>> http://www.khronos.org/registry/webgl/extensions/registry.xml .
>>>>>> -Ken
>>>>> I would like to contribute a templatization of the WebGL extension
>>>>> registry (attached).
>>>>> This templatization allows extension specifications to be provided in
>>>>> an easily consumable XML format and eases the maintenance of the
>>>>> extension registry by abstracting irrelevant DOM structure from the
>>>>> specification documents. There are fewer repetitions of the same
>>>>> information and all uses are now kept in sync automatically. For
>>>>> instance, the extension version is extracted from the revision history
>>>>> (WEBGL_EXT_lose_context exhibits this desync right now and
>>>>> OES_vertex_array_object has duped revision dates -- these have been
>>>>> corrected).
>>>> Hi David,
>>>> Thanks for this substantial contribution. This is a really nice
>>>> cleanup and adds some nifty features.
>>>> Coincidentally, I just committed a fairly large checkin to the
>>>> extension registry, cleaning up some of the issues between the draft
>>>> vs. official extensions.
>>>> The registry should be stable for the time being. Do you think you
>>>> could update your patch? The significant changes are the use of
>>>> different CSS files for drafts vs. official extensions, and the
>>>> addition of vendor-prefixed name strings to the draft specs.
>>> Sent out-of-band.
>> Thanks very much for this significant contribution. After a little
>> tweaking t's been committed and has already begun to pay off in being
>> able to fix formatting bugs in all of the extensions' HTML just by
>> modifying one XSL file.
> You're welcome. I'm glad you are finding the centralized document
> structure useful.
>> I added you to the list of contributors in the WebGL spec.
> My affiliation is with Ashima Arts. I post to this list as a
> representative of the Web-at-large.

Updated your affiliation in the spec.

>> Should there be a link to the Atom feed from the extension registry?
> There is an Atom alternate <link> in <head> for autodiscovery but some
> sort of visual icon/link/indication on the page would be great.

Added. This should show up in a few minutes.

> I look forward to a plethora of useful and widespread extensions.

There's an argument to be made against having too many extensions,
since optional functionality makes life harder for developers. :)

I do however also look forward to the addition of more useful functionality.


> David
>> -Ken
>>>>> This templatization also provides a reverse chronology of extension
>>>>> revisions on the index page and generates a corresponding Atom feed.
>>>>> A primary driver of this work is the exact module typing of
>>>>> extension-provided ESSL built-ins (e.g. OES_standard_derivatives).
>>>>> I have corrected email address mismatches on a couple extensions with
>>>>> mailto's to enne@chromium but text referencing zmo@chromium.
>>>> Thanks.
>>>>> r16254 appears to break the <ol> numbering on the index of the registry.
>>>> Yes. This was fixed earlier today.
>>>>> Have WEBGL_debug_renderer_info and WEBGL_debug_shaders been ratified?
>>>>> Their body header titles say "Draft" but their head titles do not. The
>>>>> index currently lists them as official. I have synchronized the status
>>>>> of the extensions via the root element in their specifications. Upon
>>>>> ratification, simply change the root from <draft> to <extension>. I
>>>>> would also request inserting a revision entry in the history element
>>>>> upon ratification so the status change propagates and interested
>>>>> parties are notified.
>>>> Yes, they're considered official based on consensus on the
>>>> public_webgl mailing list. Going forward, we can and should add a
>>>> revision history entry when an extension is promoted from draft to
>>>> official status.
>>>>> Finally, I would like to request that OES_standard_derivatives specify
>>>>> directly the return type of getParameter with the new enum.
>>>> How you would like to see this specified?
>>>>> I hope that this helps ease the maintenance burden and consistency
>>>>> management of the extension registry and makes managing large numbers
>>>>> of extensions tolerable.
>>>> This will certainly make things more maintainable, though the
>>>> maintainers of the extension registry will have to learn XSL.
>>>> Appreciate your contribution and help getting to the point where we
>>>> can switch over to using these templates.
>>>> -Ken
>>>>> As always, if you find bugs, errors, typos, or whatnot please let me
>>>>> know and I will resolve the issue.
>>>>> Best,
>>>>> David

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