Please don't do this. It's already hard enough to find the latest version.

We are doing this because of the following reasons:

(1) We need a light-weight process for updating the 'key' and 'code' tables that is separate from the main D3E spec so that we can easily add new values to these tables without revising the entire D3E spec. We hope that we don't have to update these tables often, but we recognize that mobile (e.g.) is an interesting area that is changing relatively fast.

See the previous discussion relating to this:
http://lists.w3.org/Archives/Public/www-dom/2014JanMar/0135.html

(2) It is *easier* to find 'key' and 'code' values when they are in separate documents because you can search the entire doc without worrying about encountering values from the other table. This is an issue that has already come up as people are using the ED because the tables are rather large -- searching is practically a requirement when looking for appropriate values and it is easy to find yourself in the "wrong" section.

By having a separate spec that defines all the 'key' values, developers can refer to this single doc without having to worry about being confused by the 'code' values. And vice versa for people looking up 'code' values.


And finally, your comment that it is "already hard enough to find the latest version" is not a valid argument. Once the spec is finalized and released, the latest version will be clear and obvious - just as it is for other W3C specs.

As far as (1) goes, specs are never finalised unless they're obsolete and irrelevant. You're going to be finding bugs and needing to add new features for years or decades and probably more often than adding new values; if your process means that the spec is hard to edit, then your process is broken.

Also, note that one of the W3C's most serious problems right now is that it's not "clear and obvious" what the latest version is. It's usually the editor's draft, but that's not always linked to from the out-of-date TR/ page drafts; sometimes the latest version is not even a W3C spec; sometimes, however, the TR/ page _is_ the most up to date version but it points to an out-of-date editor's draft; sometimes specs change short name leaving trails of older versions behind that don't point to the newer versions, etc. It's a big mess. (The real solution is to just have one URL per spec, but obviously that's out of scope for this bug!)

We debated using another form of single-point registry like a Wiki, but that didn't feel official enough. Ultimately another Note or Rec-track document is what we decided upon with the WG chair's input.

I'm not sure that the "what's the most current version of the spec" issue gets any more confusing with these two extra documents than it already is with the single DOM3 Events spec.

(I usually rely on the date of the draft to help me, but with ReSpec, the date is always today's date (it's computed) regardless of the actual last change date... I wonder if Robin Berjon has heard this feedback?)

This split has been completed. The current ED URLs are:

D3E: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html
D3E-key: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-key.html
D3E-code: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html

At the moment, we only have an official URL for D3E since the others have not yet been promoted to the stage where they get an official URL:

D3E: http://www.w3.org/TR/DOM-Level-3-Events/
D3E-key: TBD
D3E-code: TBD

Thanks Gary! (FYI, I just added the two new EDs to WebApps' spec status page <https://www.w3.org/2008/webapps/wiki/PubStatus>.)

Re the "short names" of the new specs, we will need to agree on them before we request publication of First Public Working Drafts, which I presume will be the same date as the publication of the next LC of D3E. I don't feel strongly about the names and we should probably discuss the options on www-dom (some options: D3E-{code,key}-values, DOM-{code,key}-values, ...)