[cellml-discussion] CellML Versioning Strategy
Hi all, At the break-away session on the versioning strategy for CellML (which followed the Auckland CellML meeting today) we discussed the future of how we would version CellML, including whether we would put all elements for the next version of CellML in a completely different namespace, or only the elements that had changed. A summary of the discussion is up at http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ under "Breakaway session on versioning strategy for CellML". Note that the participants at the session have not had a chance to correct errors in it yet, and it may not yet accurately reflect everyone's view. However, it does lay out the options, and so may provide a starting point for any suggestions or comments from the community. Please send and such suggestions or comments to the CellML discussion mailing list prior to the 3rd October 2007. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] CellML Versioning Strategy
"Andrew was opposed to the idea of changing all the namespaces, and suggested changing the namespace of a particular element in only some circumstances:" I agree very strongly with this. It would make writing out xpath expressions simpler since you know absolutely what namespace for what elements you want to target. The namespace argument also applies to new attributes - they need to be placed into a new namespace too and references explicitly as such in a document since the rule for CellML is that unnamespaced attributes will acquire the namespace of the element owning them. "Poul thinks that mixing namespaces means you have to scan the entire document before you can determine that you don't support a particular version of the model. " I don't understand that. You might want to scan a document to see what "versions" the model conforms up to, but one of the nice things about pushing these new elements/attributes into new namespaces is that you can still treat a model as say 1.1 even if it contains 1.2 elements and attributes. So the "scanning" is already done implicitly by a library that is simply trying to use a CellML model and is reading it at the version level it is capable of. Of course CellML 1.1 is broken in this sense. "There was some discussion about what namespace the model element should be in CellML 1.2. Randall suggested it should be in CellML 1.1 and not CellML 1.0 " Can we apply this to all existing elements and attributes then? So that when 1.2 comes along and its interpretation we only really have 1.2 and 1.1 to deal with. cheers Matt On 9/19/07, Andrew Miller <[EMAIL PROTECTED]> wrote: > Hi all, > > At the break-away session on the versioning strategy for CellML (which > followed the Auckland CellML meeting today) we discussed the future of > how we would version CellML, including whether we would put all elements > for the next version of CellML in a completely different namespace, or > only the elements that had changed. > > A summary of the discussion is up at > http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ > under "Breakaway session on versioning strategy for CellML". Note that > the participants at the session have not had a chance to correct errors > in it yet, and it may not yet accurately reflect everyone's view. > However, it does lay out the options, and so may provide a starting > point for any suggestions or comments from the community. > > Please send and such suggestions or comments to the CellML discussion > mailing list prior to the 3rd October 2007. > > Best regards, > Andrew > > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
Matt Halstead wrote: > "Andrew was opposed to the idea of changing all the namespaces, and > suggested changing the namespace of a particular element in only some > circumstances:" > > I agree very strongly with this. It would make writing out xpath > expressions simpler since you know absolutely what namespace for what > elements you want to target. > > The namespace argument also applies to new attributes - they need to > be placed into a new namespace too and references explicitly as such > in a document since the rule for CellML is that unnamespaced > attributes will acquire the namespace of the element owning them. > This is something which I think we should change ASAP - it is a deviation from the XML specification which we should not be declaring at the CellML level. I think that once this is sorted out, versioning the elements is sufficient, and there is no need to mix namespaces of attributes within the same element (if the attribute definitions change, then the semantics of the element have changed, so we change its namespace). > > "Poul thinks that mixing namespaces means you have to scan the entire > document before you can determine that you don't support a particular > version of the model. " > > I don't understand that. You might want to scan a document to see what > "versions" the model conforms up to, but one of the nice things about > pushing these new elements/attributes into new namespaces is that you > can still treat a model as say 1.1 even if it contains 1.2 elements > and attributes. So the "scanning" is already done implicitly by a > library that is simply trying to use a CellML model and is reading it > at the version level it is capable of. > > Of course CellML 1.1 is broken in this sense. > > "There was some discussion about what namespace the model element > should be in CellML 1.2. Randall suggested it should be in CellML 1.1 > and not CellML 1.0 " > > Can we apply this to all existing elements and attributes then? So > that when 1.2 comes along and its interpretation we only really have > 1.2 and 1.1 to deal with. > I think that was the intention - model was only an example of an element with semantics that we don't plan to change, and any other element which is neither new nor changed in CellML 1.2 would be treated along the same lines. Then we can just implement 1.2 (and perhaps 1.0) without worrying about explicitly implementing 1.1 as a separate task. Best regards, Andrew > cheers > Matt > > > > On 9/19/07, Andrew Miller <[EMAIL PROTECTED]> wrote: > >> Hi all, >> >> At the break-away session on the versioning strategy for CellML (which >> followed the Auckland CellML meeting today) we discussed the future of >> how we would version CellML, including whether we would put all elements >> for the next version of CellML in a completely different namespace, or >> only the elements that had changed. >> >> A summary of the discussion is up at >> http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ >> under "Breakaway session on versioning strategy for CellML". Note that >> the participants at the session have not had a chance to correct errors >> in it yet, and it may not yet accurately reflect everyone's view. >> However, it does lay out the options, and so may provide a starting >> point for any suggestions or comments from the community. >> >> Please send and such suggestions or comments to the CellML discussion >> mailing list prior to the 3rd October 2007. >> >> Best regards, >> Andrew >> >> ___ >> cellml-discussion mailing list >> cellml-discussion@cellml.org >> http://www.cellml.org/mailman/listinfo/cellml-discussion >> >> > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
On 9/19/07, Andrew Miller <[EMAIL PROTECTED]> wrote: > Matt Halstead wrote: > > "Andrew was opposed to the idea of changing all the namespaces, and > > suggested changing the namespace of a particular element in only some > > circumstances:" > > > > I agree very strongly with this. It would make writing out xpath > > expressions simpler since you know absolutely what namespace for what > > elements you want to target. > > > > The namespace argument also applies to new attributes - they need to > > be placed into a new namespace too and references explicitly as such > > in a document since the rule for CellML is that unnamespaced > > attributes will acquire the namespace of the element owning them. > > > > This is something which I think we should change ASAP - it is a > deviation from the XML specification which we should not be declaring at > the CellML level. I think that once this is sorted out, versioning the > elements is sufficient, and there is no need to mix namespaces of > attributes within the same element (if the attribute definitions change, > then the semantics of the element have changed, so we change its namespace). > Yup > > > > "Poul thinks that mixing namespaces means you have to scan the entire > > document before you can determine that you don't support a particular > > version of the model. " > > > > I don't understand that. You might want to scan a document to see what > > "versions" the model conforms up to, but one of the nice things about > > pushing these new elements/attributes into new namespaces is that you > > can still treat a model as say 1.1 even if it contains 1.2 elements > > and attributes. So the "scanning" is already done implicitly by a > > library that is simply trying to use a CellML model and is reading it > > at the version level it is capable of. > > > > Of course CellML 1.1 is broken in this sense. > > > > "There was some discussion about what namespace the model element > > should be in CellML 1.2. Randall suggested it should be in CellML 1.1 > > and not CellML 1.0 " > > > > Can we apply this to all existing elements and attributes then? So > > that when 1.2 comes along and its interpretation we only really have > > 1.2 and 1.1 to deal with. > > > I think that was the intention - model was only an example of an element > with semantics that we don't plan to change, and any other element which > is neither new nor changed in CellML 1.2 would be treated along the same > lines. Then we can just implement 1.2 (and perhaps 1.0) without worrying > about explicitly implementing 1.1 as a separate task. > > Best regards, > Andrew > > > cheers > > Matt > > > > > > > > On 9/19/07, Andrew Miller <[EMAIL PROTECTED]> wrote: > > > >> Hi all, > >> > >> At the break-away session on the versioning strategy for CellML (which > >> followed the Auckland CellML meeting today) we discussed the future of > >> how we would version CellML, including whether we would put all elements > >> for the next version of CellML in a completely different namespace, or > >> only the elements that had changed. > >> > >> A summary of the discussion is up at > >> http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ > >> under "Breakaway session on versioning strategy for CellML". Note that > >> the participants at the session have not had a chance to correct errors > >> in it yet, and it may not yet accurately reflect everyone's view. > >> However, it does lay out the options, and so may provide a starting > >> point for any suggestions or comments from the community. > >> > >> Please send and such suggestions or comments to the CellML discussion > >> mailing list prior to the 3rd October 2007. > >> > >> Best regards, > >> Andrew > >> > >> ___ > >> cellml-discussion mailing list > >> cellml-discussion@cellml.org > >> http://www.cellml.org/mailman/listinfo/cellml-discussion > >> > >> > > ___ > > cellml-discussion mailing list > > cellml-discussion@cellml.org > > http://www.cellml.org/mailman/listinfo/cellml-discussion > > > > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
> At the break-away session on the versioning strategy for CellML (which > followed the Auckland CellML meeting today) we discussed the future of > how we would version CellML, including whether we would put all elements > for the next version of CellML in a completely different namespace, or > only the elements that had changed. > > A summary of the discussion is up at > http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ > under "Breakaway session on versioning strategy for CellML". Note that > the participants at the session have not had a chance to correct errors > in it yet, and it may not yet accurately reflect everyone's view. > However, it does lay out the options, and so may provide a starting > point for any suggestions or comments from the community. > > Please send and such suggestions or comments to the CellML discussion > mailing list prior to the 3rd October 2007. That all seems reasonable to me, just one comment: - At the moment, CellML doesn't explicitly support the rem element (remainder function in MathML), even though CellML does allow its use (at the risk of ending in a situation where a model may work fine in a given CellML tool -- that supports the rem element --, but not in a nother -- that doesn't support the rem element --). Now, say that we officially want CellML to 'support' the rem element, how do we go about doing that? Otherwise, Matt wrote: > ... You might want to scan a document to see what > "versions" the model conforms up to, but one of the nice things about > pushing these new elements/attributes into new namespaces is that you > can still treat a model as say 1.1 even if it contains 1.2 elements > and attributes... Treat that model in what way? Surely, if a model uses some 1.2 elements, then there must be a reason to it. Therefore, a 1.2 model cannot be treated as a 1.1 model, or did I miss something? Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
> Otherwise, Matt wrote: > > > ... You might want to scan a document to see what > > "versions" the model conforms up to, but one of the nice things about > > pushing these new elements/attributes into new namespaces is that you > > can still treat a model as say 1.1 even if it contains 1.2 elements > > and attributes... > > Treat that model in what way? Surely, if a model uses some 1.2 elements, > then there must be a reason to it. Therefore, a 1.2 model cannot be treated > as a 1.1 model, or did I miss something? It really depends on the intention of adding to the spec. If you are adding elements that change the interpretation of the CellML 1.1 namespace elements, then yes, there is no point in trying to see only the cellml 1.1 model within a model that has 1.2 elements. Sometimes people use "levels" to denote changes to a spec (which often also a new namespace) that are additive and still render the previous level a valid model. > > Alan. > > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
Matt Halstead wrote: >> Otherwise, Matt wrote: >> >> >>> ... You might want to scan a document to see what >>> "versions" the model conforms up to, but one of the nice things about >>> pushing these new elements/attributes into new namespaces is that you >>> can still treat a model as say 1.1 even if it contains 1.2 elements >>> and attributes... >>> >> Treat that model in what way? Surely, if a model uses some 1.2 elements, >> then there must be a reason to it. Therefore, a 1.2 model cannot be treated >> as a 1.1 model, or did I miss something? >> > > It really depends on the intention of adding to the spec. If you are > adding elements that change the interpretation of the CellML 1.1 > namespace elements, then yes, there is no point in trying to see only > the cellml 1.1 model within a model that has 1.2 elements. > > Sometimes people use "levels" to denote changes to a spec (which often > also a new namespace) that are additive and still render the previous > level a valid model. > I think that the CellML specification should only describe 'core' aspects which affect the interpretation of the model. Anything which is additive should not be in the core CellML but should use extension elements or be in RDF. A simple rule to identify whether an unrecognised element is a fatal error is to see if it is in a namespace starting with http://www.cellml.org/cellml/ . If it is, then tools should assume that they are unable to interpret the model correctly and so should fail. If it isn't, it is an extension element, and so is not essential to the interpretation of the model, but rather is additive as Matt has described, and so may safely be ignored. Best regards, Andrew > > >> Alan. >> >> ___ >> cellml-discussion mailing list >> cellml-discussion@cellml.org >> http://www.cellml.org/mailman/listinfo/cellml-discussion >> >> > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
Alan Garny wrote: >> At the break-away session on the versioning strategy for CellML (which >> followed the Auckland CellML meeting today) we discussed the future of >> how we would version CellML, including whether we would put all elements >> for the next version of CellML in a completely different namespace, or >> only the elements that had changed. >> >> A summary of the discussion is up at >> http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ >> under "Breakaway session on versioning strategy for CellML". Note that >> the participants at the session have not had a chance to correct errors >> in it yet, and it may not yet accurately reflect everyone's view. >> However, it does lay out the options, and so may provide a starting >> point for any suggestions or comments from the community. >> >> Please send and such suggestions or comments to the CellML discussion >> mailing list prior to the 3rd October 2007. >> > > That all seems reasonable to me, just one comment: > > - At the moment, CellML doesn't explicitly support the rem element > (remainder function in MathML), even though CellML does allow its use (at > the risk of ending in a situation where a model may work fine in a given > CellML tool -- that supports the rem element --, but not in a nother -- that > doesn't support the rem element --). Now, say that we officially want CellML > to 'support' the rem element, how do we go about doing that? > A lot of things are valid CellML but are not supported by everyone (really, the only thing widely supported are systems of ODEs). CellML provides the overarching structure for describing these things, and we need to start to narrow down exactly what tools should be supporting as well, using compatibility documents or something like that which describe a feasible subset of CellML to implement. The could be more than one of these, but we don't want there to be too many similar documents. However, I think we should keep them away from the core of CellML, because CellML's generality is quite useful when it comes to expanding into new types of problems (for example, constitutive laws, PDE systems, and so on). Best regards, Andrew > Otherwise, Matt wrote: > > >> ... You might want to scan a document to see what >> "versions" the model conforms up to, but one of the nice things about >> pushing these new elements/attributes into new namespaces is that you >> can still treat a model as say 1.1 even if it contains 1.2 elements >> and attributes... >> > > Treat that model in what way? Surely, if a model uses some 1.2 elements, > then there must be a reason to it. Therefore, a 1.2 model cannot be treated > as a 1.1 model, or did I miss something? > > Alan. > > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
>> - At the moment, CellML doesn't explicitly support the rem element >> (remainder function in MathML), even though CellML does allow its use (at >> the risk of ending in a situation where a model may work fine in a given >> CellML tool -- that supports the rem element --, but not in a nother -- that >> doesn't support the rem element --). Now, say that we officially want CellML >> to 'support' the rem element, how do we go about doing that? >> > A lot of things are valid CellML but are not supported by everyone > (really, the only thing widely supported are systems of ODEs). CellML > provides the overarching structure for describing these things, and we > need to start to narrow down exactly what tools should be supporting as > well, using compatibility documents or something like that which > describe a feasible subset of CellML to implement. The could be more > than one of these, but we don't want there to be too many similar > documents. However, I think we should keep them away from the core of > CellML, because CellML's generality is quite useful when it comes to > expanding into new types of problems (for example, constitutive laws, > PDE systems, and so on). this seems a good approach to be taking. I'm personally in favour of removing the "CellML subset" of MathML and resorting to such compatibility or best practice documents to apply specific restrictions to what can be used in certain types of mathematical models represented in CellML. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
