Hi, Cameron-
Thanks for bringing this discussion down to brass tacks.
I would personally think a useful final step would be a way to merge in
sections of drafts from multiple sources, not just fork Ian's draft.
That way, when people vote on draft features, they would be comparing
apples to apples... the results could be folded into the HTML WG draft
(which of course Ian is welcome to fold back into the WHATWG draft,
since he is committed to keeping the W3C and WHATWG drafts the same).
I like the idea of multiple editors, since it gives people the
opportunity to engage in productive activities rather than distracting
arguments. I would, of course, expect the same high quality of
specification from any proposals as I have come to expect from Ian's
draft; this quality should be in both the technical material, and also
in the spec precision, and as close to the editorial voice of the spec
as possible.
When this group was just starting, there was agreement that there would
be at least 2 editors. Since David Hyatt has not had time to
participate in the specification process (though he is an active
implementer), I think it's appropriate for us to open the door to
multiple editors, as Sam has done. Making concrete ways to facilitate
that, as Cameron suggests, is the next logical step.
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Cameron McCormack wrote (on 7/21/09 11:17 PM):
Shelley Powers:
> It gets fuzzy after that point. Sorry if I'm asking for what's
> obvious to everyone else, but could you give me the precise steps
> to take, from prep of voting text, to vote, to incorporation into
> existing working draft based on your preferred approach (camera
> ready spec text)?
Sam Ruby:
Anybody who wishes to edit can arrange to do so:
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0018.html
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0017.html
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0019.html
Once a tangible work product (be it a completely independent spec or
a "mashup") is produced and a minimum level of diverse public support
is demonstrated, a vote can be called for[1], and the work product
(and by implication, the editor that produced it) can be viewed as
"official".
It seems to me that producing these “branched” versions of the spec is
more difficult than it should be. If this duelling specs approach is
indeed the process the WG is following, then it should be easy for
someone to check out a copy of the HTML 5 spec source, make their
updates and pull changes from the “main” branch (i.e., Ian’s version of
the spec). CVS doesn’t make this terribly easy to do, but I guess
that’s what we’re stuck with.
The following is how the HTML 5 spec is built, AIUI. The HTML 5 spec
source lives in the WHATWG Subversion server:
http://svn.whatwg.org/webapps/source
Using some build scripts that I believe aren’t published anywhere, the
WHATWG version of the spec
http://svn.whatwg.org/webapps/index
and the W3C single-page version of the spec
http://dev.w3.org/cvsweb/html5/spec/Overview.html
are generated. Only the final HTML form of the spec is checked in to
W3C CVS. Mike’s scripts then split the W3C version of the spec into the
multipage version:
http://dev.w3.org/cvsweb/html5/spec/index.html
If, hypothetically, I were interested in producing one of these branched
specs, I would want to be able to do something like:
# Check out the repository
$ cvs -d :ext:[email protected]/sources/public co html5
# Copy a “template” directory into a new directory for my draft
$ cd html5
$ mkdir spec-mccormack
$ cp template/* spec-mccormack
# Do an initial first build, which would fetch
# http://svn.whatwg.org/webapps/index and record which revision it got
$ cd spec-mccormack
$ make
# Check in this draft (currently identical to Ian’s), which would
# result in it being visible as
# http://dev.w3.org/html5/spec-mccormack/
$ cvs add *
$ cvs commit -m 'Initial commit of spec-mccormack.'
# Now I make some changes to the spec, then build and commit them
$ vi source
$ make
$ cvs commit -m 'Undeprecate @summary!'
# Merge recent changes from Ian’s draft, then commit them (this would
# perhaps leave merge conflict markers in ‘source’)
$ make merge
$ make
$ cvs commit -m 'Merge in changes from Ian’s draft.'
Now, most of that Makefile/template stuff shouldn’t be hard to set up.
The only things missing are the parts of Ian’s build scripts that aren’t
handled by a regular Anolis invocation, which I think is the document
prologue (all the stuff before the ToC) and handling the<!--START-->
and<!--END--> markers which delineate the separate specs that are
generated from the source (HTML 5, Web Database, Web Storage, Web
Workers, Web Socket specs). Maybe other things too, I’m not sure.
