Re: [Miase-discuss] annotation/notes element

[Dagmar K. <da...@eb...>]

I put a note to discuss the changeAttribute type issue and the re-naming 
of modification types issue during the workshop.

Dagmar


Frank Bergmann wrote:
>> ? The two variable glyphs carry the same attribute. But we nevertheless
>> need to fork them. For parameter, we should rewrite the UML with only
>> one glyph.
>>
>>     
>
> (I counted taskReference / modelReference as attributes)
>
>   
>>>>> - changeAttribute: newValue should be of type xs:double
>>>>>           
>>>> Not sure, could I - for example - change
>>>>
>>>> <listOfProducts>
>>>>      <speciesReference species="PZ"/>
>>>>
>>>> the species (XML) attribute "PZ" to some other species, e.g. to
>>>>         
>> change
>>     
>>>> the product in a reaction? Could that make sense? Or would we
>>>>         
>> consider
>>     
>>>> that as a completely different model then?
>>>>         
>>> right ... you actually could do that ... this does worry me a bit ...
>>> i'd much rather that people would swap out whole reactions than
>>>       
>> fiddle
>>     
>>> with products like that ... this seems like a sure way to create
>>>       
>> invalid
>>     
>>> models ... no xs:double here then :)
>>>       
>> I am with Frank here. This worries me a little as well. And actually, I
>> remember that at one time changeAttribute was not called
>> changeAttribute but changeValue. It could only change a numerical
>> value. Then it became changeAttribute, which is actually a bit
>> confusing with changeXML as well. 
>>
>>     
>
> I've double checked my implementation, and indeed I did use string for
> precisely the reason, that you might want to change some other attributes.
> Here Xpath gives us all the freedom we want, or enough rope to hang
> ourselves with. We could use it to set any attribute, like sbml Id, boundary
> conditions, constant flags, relocate species and more. The problem with this
> is that it might work fine for one model and cause lots of problems for
> another model, partly because of for example default values in SBML (and I
> know this is remedied by level 3).  
>
> Lets create some examples first before changing the proposal, if we can come
> up with a valid (and useful) case for keeping non-numerical values, then
> perhaps it is worth keeping them. 
>
>   
>> To remove the problem and tackle the other confusions, what about
>> renaming the three "modification types":
>>
>> changeValue
>>
>> replaceXML
>>
>> computeValue
>>
>>     
>
> Let us postpone renaming the types until we find more examples. 
>
> Best
> Frank
>
>
>