> As a proof of concept, I have set up an unofficial CellML specification > git at http://repo.or.cz/w/cellml-draft-miller.git . This repository is > intended to show the concept of using a distributed revision control > tool to work on specification development, and not to suggest that this > is necessarily the type of technology which will be used for the actual > specification development. > > I have used DocBook as the source format in this repository based on the > preliminary consensus on the CellML discussion mailing list - again, > this is not intended to suggest that DocBook will be the final format > used for specification development, but to show the concept, as one > format or another needs to be chosen even at he proof-of-concept stage. > > git clone git://repo.or.cz/cellml-draft-miller.git andrews-spec-version > cd andrews-spec-version > git checkout -b normative remotes/origin/normative > > You now have a local repository of my unofficial draft version of the > specification. You can make and commit your own changes locally, and > potentially push them to your own publicly visible repository (which > would allow me, or someone else to pull the changes into my version). > This makes it easy for everyone to keep their own draft versions, and > merge in changes that they agree with from others. We could eventually > set up an official git where changes which become widely accepted are > pushed, and to provide a starting point for people wanting to propose > additional changes. > > BTW on my system, I can generate the HTML output using: > xsltproc --xinclude --param section.autolabel 1 > /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl toplevel.xml > >toplevel.xhtml > > The exact command you should use will depend on where things are > installed on your system.
Though I do have a Linux virtual machine, my main working environment is Windows. So, how do I go about using git? My point is that if you want to involve the community (which I understand you do), then you have to provide a solution that not only suits your needs, but all those of the community. In other words: opt for a solution that is as easy as possible to use and this from any platform. It seems to me that, until now, we have only given a list of possible solutions (together with their pros and cons) and that's fine, but what do we exactly want from that solution? Personally, I would favour a solution that: - is web-based (so anyone can have access to it from anywhere), - could be used by non-computer specialists (indeed, let's not forget that someone interested in CellML doesn't necessarily mean someone who is capable to understand or willing to learn some, if not all, of the technologies that have been discussed so far), - provides a useful history of changes (i.e. the diff feature discussed before), - uses an XML-based internal format (I believe this would be useful if we think long-term strategy, which we obviously should!), but that certainly doesn't mean that we should have to manipulate that format directly (see my 2nd point above), - can convert the internal format to a nicely formatted PDF file (and maybe other formats?). Just a few thoughts... PS: "you" is used to mean "the Auckland CellML team". PPS: http://www.cellml.org/ seems to be 'dead', even though I can tracert/ping it... _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
