> It wouldn't make sense to use a different namespace for the draft, and > then change the namespace, because that would mean that experimental > implementations would all have to be changed (we shouldn't be making > substantive changes between agreeing on a draft and releasing an > endorsed specification, and changing the namespace is a very major > change in terms of compatibility).
That is the point I am trying to make - at the moment people are free to propose a draft specification, assign themselves and cellml.org namespace and thats it. To me this shows that the specification is supported and endorsed by the CellML Project. > Having specifications in the URL is appropriate for a draft > specification. The only time this would be a problem would be if a draft > purported to be endorsed by the CellML team when it was not (all drafts > at the moment have language which makes it explicitly clear that they > are drafts, and are not yet endorsed). I'm not talking about draft specifications - I'm trying to say that before draft specifications are endorsed by the CellML Project by adding them to the specifications page and assigning an appropriate cellml.org namespace there needs to be a process whereby the CellML community, and ultimately the management committee, can decide whether the specification is appropriate for the CellML project. For such a decision to be made, some effort must have already been made in terms of developing an outline of the specification and a description of the purpose for the specification. > This is the usual way of developing standards: > 1) Someone writes a draft. > 2) The community identifies problems with the draft. > 3) Any problems are fixed, and step 2 is repeated until the draft is of > good quality. > 4) The specification gets endorsed by the group standardising the > specification. Exactly, I have no trouble with this process. I just think there needs to be a step 0 whereby someone proposes a potential specification and we need to decide if the CellML Project/community is the best place for steps 1-4 to occur. > I don't foresee how having many specifications up there can cause > problems, but if any problems do arise, there is no reason why we can't > adopt a different policy later. Well, I think between us we have covered most of the relevant issues, so unless someone else speaks up I guess I'm the only one who sees this approach as a problem and we'll just leave things as they are... David. -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
