[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Issues with Extension Registry
On Mon, Nov 28, 2011 at 5:19 PM, Kenneth Russell <firstname.lastname@example.org> wrote:
> On Wed, Nov 16, 2011 at 5:30 PM, Chris Marrin <email@example.com> wrote:
>> On Nov 15, 2011, at 2:51 PM, Kenneth Russell wrote:
>>> On Sat, Nov 12, 2011 at 11:26 AM, Chris Marrin <firstname.lastname@example.org> 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
>>> 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:
executed at view-time instead of, say, edit-time?
Why not keep the registry data in an XML file and use XSLT to
the actual data of the registry would be trivially machine-readable
with potential for arbitrary metadata (number, date, depends...).
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: