Chronological Thread 

< Chronological >      < Thread >

---

> 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: david.nickerson at nus.edu.sg

---

• [cellml-discussion] New Draft: Custom Subset Metadata specification, Andrew Miller, 11/06/2006
  • [cellml-discussion] New Draft: Custom Subset Metadata specification, David Nickerson, 11/07/2006
    • [cellml-discussion] New Draft: Custom Subset Metadata specification, Andrew Miller, 11/08/2006
      • [cellml-discussion] New Draft: Custom Subset Metadataspecification, David Nickerson, 11/08/2006
        • [cellml-discussion] New Draft: Custom Subset Metadataspecification, Andrew Miller, 11/08/2006
          • [cellml-discussion] New Draft: CustomSubset Metadataspecification, David Nickerson, 11/08/2006

---

Archive powered by MHonArc 2.6.18.