>> I have just starting looking at using git and checking your current >> draft of the specification. I have made a few changes and attach the >> patch (generated with git diff -p > andre.patch). Not really sure the >> best way to do things in order to share changes - I guess if there are > That way is probably okay for small changes. I believe git has ways to > e-mail patches while keeping the change identifier - that might make it > easier to merge back and forwards in the future, because if I commit > your change and you update, it would be good if there was no need to > re-merge that patch. I have never actually tried git's e-mail features, > although I believe that they are used extensively for Linux kernel > development.
that sounds like something that could be quite useful. Guess it'll be a matter of how many more patches we will be creating and how many people run their own repository. >> And then a couple of other things I changed that we can maybe discuss >> more on cellml-discussion. You are using 'CellML File' as the base unit >> whereas I generally think of them as documents - especially in the >> context of generated data which may never exist in an actual file. >> Again, just my preference :) > I guess the only issue is that file implies it is always a single XML > file, while document could potentially be more than one file. maybe....just trying to think of an example where someone might create a single "CellML Document" using something like XInclude or XML entities or something...can't think of anything off the top of my head though so maybe CellML File is a better term than a CellML Document. >> And the second point, which I'm sure has been discussed in the past but >> I can't quite recall is the statement that CellML processing software >> should not attempt to process documents containing elements in the >> CellML 1.0 namespace. Perhaps you could just refresh my memory as to >> where that came up before? > The idea is that CellML 1.0 and CellML 1.1 namespaces shouldn't be > mixed. CellML 1.x (x > 1) processing software can also process CellmL > 1.0 files, but it must do so in accordance with the CellML 1.0 > specification, and not in accordance with any of the future > specifications, because CellML 1.0 documents are not valid under those > later specifications. The annotated specification will probably need to > explain this, but that explanation is not necessary to define CellML 1.2 > and so not really appropriate in a normative-only version of the document. ok - thanks for the reminder, its slowly coming back to me and makes sense. Andre. _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
