Alan Garny wrote:
> Andrew Miller wrote:
>   
>> Alan Garny wrote:
>>     
>>
>> There are viewable web interfaces for git - see the gitweb at e.g.
>> http://repo.or.cz/w/cellml-draft-
>> miller.git?a=tree;h=normative;hb=normative
>>     
>
> How does it work?
>
> Using Opera, if I click on blob for abstract.xml, I get:
>
> ---------------------------------------
> This document is an unofficial working draft. The below describes the
> intended status of the specification, and not the current status right now.
> This document specifies CellML 1.2, an XML-based language for describing and
> exchanging mathematical models. This is the normative specification of
> CellML. It is intended to provide the minimum amount of information needed
> to accurately describe CellML. An alternative version is available which is
> annotated with much more explanatory material.
> ---------------------------------------
>
> While with Firefox, I get told that "[the] XML file does not appear to have
> any style information associated with it" and get show the document tree.
> Using Internet Explorer, I get told that the XML file "cannot have multiple
> DOCTYPE declarations".
>   

My demo setup uses DocBook together with XInclude to assmeble the 
document - if we use DocBook as our source format, we will also need to 
provide an easier way to view it - this could be as simple as 
referencing an XSL as the style information so people's browsers can 
view it - but I don't think this will help with the XInclude as I 
believe it is not generally supported in browsers (although we could 
create a trivial Javascript XInclude processor and include it in the 
repository which would allow people to visualise the latest version in 
their browsers, with the only requirement being a Firefox / recent IE / 
Opera browser with Javascript enabled).

> My point is that I would most likely need to learn about git before being
> able to use it. I might do that if that's what you guys end up using, but do
> you really expect others to do that? Can you really not opt for a 'simpler'
> solution?
>   

git, Mercurial, and Bazaar are really the only automated distributed 
version control systems that I know of - if we don't use one of those 
then we will end up manually co-ordinating everything that git would do. 
I think it is better to have an automated system while still being open 
to changes suggested by e-mail, rather than to not have an automated 
system at all.

>   
>> Of course, whatever format we use we will also want a rendered version.
>>
>> In terms of changes, users who don't do enough work on the specification
>> to justify setting up a git environment can always propose changes to
>> the mailing list. If they use git, it just makes it easier for us to
>> share and merge their changes. 
>>     
>
> Am I to understand that git has become the solution of choice?
>   
No, this is a proof of concept set-up to facilitate discussion of the 
options.

>   
>> I don't know how many major contributors
>> to specification development we would have who wouldn't want to install
>> Cygwin anyway - perhaps if there is anyone who this applies to on the
>> list now is the time to speak up :).
>>     
>
> I would certainly be interested to know indeed. I would be happy to
> contribute to the specifications, but I am not willing to install Cygwin for
> something that I am not going to use on a daily basis.
>   
> Again, there must be an easier solution?! 
>   

The MingW based system mentioned below might suit your requirements, or 
you perhaps you could use git from a Linux virtual machine that you have 
already got set up?

>  
>   
>> There is an MingW / MSYS based git port as well -
>> http://msysgit.googlecode.com/files/GitMe-0.4.2.exe - I haven't tried it
>> myself.
>>
>> We could use Mercurial - the only issue there is that the only free
>> hosting I could find ( http://www.assembla.com ) looks like it is part
>> of some company's business model and so I wouldn't want to rely on it
>> remaining free - we don't really want to require people who want to set
>> up their own repositories to rely on that.
>>     
>
> I would be interested to hear from people interested in contributing to
> CellML, and the kind of solution they would like to see implemented.
>
> Right now, I feel like git is not a suitable solution. What about DocBook
> and the other solutions that have been suggested so far?
>   
git, Mercurial, and Bazaar solve quite orthogonal problems to DocBook:
1) git and other similar technologies are used to track the 
specification - that is, they allow each person working on 
specifications to keep track of what they think should be the latest 
version of specification, and create changes relative to that, and share 
those changes with other people.
2) DocBook and similar technologies are for representing a particular 
version of a document in a computer-readable way that can be converted 
to various other formats.

We still need to decide on how we represent our specification regardless 
of how we track changes made to it (my example git repository currently 
uses DocBook - this is again just a proof of concept).

> Something that should be kept in mind: to go for a solution that suits the
> CellML team is one thing, but to have a solution that suits the community is
> probably even more important (that is if you want the community to be
> involved!).
>   
The good thing about distributed version control systems is that there 
doesn't need to be a core CellML team - there is no one central 
repository which only some people have access to, and instead anyone can 
set up their own remote repository. Obviously, at some point in the 
future we will need to all agree on a single version to become the final 
specification, and there will be revisions which are informally regarded 
as representing community consensus and therefore a useful place to 
suggest changes relative to.

Best regards,
Andrew
> Alan.
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>   

_______________________________________________
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Reply via email to