On 8/15/07, David Nickerson <[EMAIL PROTECTED]> wrote: > Hi Matt, > > This makes quite a bit of sense to me. > > > So, more concretely, I am proposing that: > > - we start the notion of a versioned workspace or package. > > yep. It would also be good to decide on either workspace or package :-)
I like 'package' over 'workspace' since I can imagine someone's workspace having more than one package present. I am thinking of a package as being a collection of one or more models that are considered a unit. I don't know whethere this would require all models to be related in some way via imports, or whether there could be arbitrary collections that form a package where entry points(models) are defined in a manifest/metadata file. > > > - the package is named and has an abstract version > > and the name is part of the package URI or the URI is the name? I don't know if a package name would need to be a URI, but it might be convenient. It's not clear to me yet what the scenarios for a package would look like. But if there is some consensus of at least a package root that contains the package manifest/details, then a URI for this could be possible. But if not a URI, I would at least recommend some use of namespaces, e.g. the package a.b.c.tar.gz would unbundle into a/b/c/*, where c would be the root of the package and * is the tree from there onwards. But that's just a possible pattern amongst many. > Do you see things like the simulation and graphing metadata to start > interacting with packages/workspaces in addition to straight CellML > models or that the concept of a package supersedes the use of models in > this context? (I'm thinking the latter would make more sense than > starting to tie variable references to particular document versions) I would think metadata that needs to refer to a particular version of a package would refer to the package itself via a URI and also a version label. Note, version labels, if used in a similar way to software, can include wildcards or wildcard like behaviour to refer to groups of versions, or all versions, or a very specific version. > > > - for the minimal case of a CellML 1.0 model and metadata in a single > > document, the package name can be the model name, but the abstract > > version is still separate from the document version > > Why the restriction on only CellML 1.0 models? Currently a model name is > not used for anything so I'm not sure why a 1.1 model name can't also be > used as a package name? Sorry, I wasn't very clear. I was trying to think of the simplest case of a model, which is actually a 1.0 or 1.0 model that consists of only a single model document that has both model and metadata contained in it. And I was thinking what a package would mean for that. But I suppose that even a single model document scenario should be thought of as residing in a single container that would form the package root and hence offer a way of naming it through a URI or dotted namespace.packageroot combination. > > > - that we add a package name and version number metadata construct to > > all the models. > > while this makes sense in a 1.0 world, in a more general case any given > model could be in more than one package/workspace. I'm guessing that the > metadata construct you are thinking about could then easily be outside a > particular model document (or within one) and refer to all it's > constituent models via their URI? Where the URI or some other identifier > would consist of the document version information. Yep. You are right. This information would need to be a package metadata file. so an example minimal layout: bread/sourdough/matts/.metadata bread/sourdough/matts/recipe.xml .metadata would point to the local recipe.xml and also contains a version, e.g. 0.1-dev The package might be called bread.sourdough.matts or http://backing.org/bread/sourdough/matts/ more complicated would be: bread/sourdough/matts/.metadata bread/sourdough/matts/recipe.xml bread/sourdough/matts/ingredients.xml where .metadata points to the local recipe.xml and ingredients.cml and also to the following external resources (which are likely to be used in imports by the models) bread/measurement/metric/units.xml bread/techniques/kneeding/method1.xml and .metadata also contains a version, e.g. 0.1-dev The package name would still be the same as in the minimal example. If we round trip to subversion and document versions again, then I would expect that useful releases of a package would be tagged. > > > - that for most purposes in our discussions we will be talking about > > this abstract version and what it would mean to increase its major or > > minor numbers, alpha, beta, or release status etc. > > agreed. > > > Andre. > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion > _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
