From: David N. <dav...@gm...> - 2011-10-07 22:23:01
|
> The naive solution would be to stick in the type of repository into the URI, > however since the repositories can use different protocols this might be > tough. Unless we use a syntax like: > svn+<actual repository url> > hg+<actual repository url> > git+<actual repository url> > Thoughts? > > Well, for the 'model developer' user group, presumably they would have > access to a project repository. I think adding in authentication info is > outside the scope of SED-ML. At least on SF, you can just get the > appropriate revision as a regular URL, e.g., > http://sed-ml.svn.sourceforge.net/viewvc/sed-ml/sed-ml/schema/level1/version1/sed-ml-L1-V1.xsd?revision=410&pathrev=410 > I just thought this might reconcile the disparate needs of model developers > versus model end-users, but perhaps this mechanism is too simplistic. > > Correct, the URL you post above would work, however it would not really tell > the program that you are dealing with an SVN repository. So if we changed > the protocol from http to svn+http or git+http then tools could know, ok > this is actually in a repository and i should use those repository routines > (for example, clone the repository which also would allow for modifications > … ). I think this is well outside the scope of SED-ML. If you start having SED-ML tools needing to know about all the different version control and remote access protocols then you're back at the problem Nicolas raised regarding turning off tool developers due to the complexity of supporting the standard. The overhead of tools only needing to know about http/https and local files seems to be the right level to aim at. Someone simply using the SED-ML document is unlike to care how the models are accessed as long as the simulation experiment runs, and anyone interested in developing the underlying models is likely to want to manage the versioning themselves. Cheers, David. |