From: Frank B. <fbergman@u.washington.edu> - 2009-01-29 08:13:45
|
> > As far as I know UML, two entities with identical names in a UML > schema > represent the same (identical) class. So, in the UML you find two > "drawings" of parameter/variable classes, but in fact they > correspond to > one "physical" class as they carry identical class names. it just looked confusing as Variable at least seemed to have different attributes ... but I'm certainly no expert using UML ... > > >> >> - Of course to make variables work in the ChangeMath case, a variable >> now can refer directly to a model, where before we would only refer >> to >> variables based on a taskreference. I'm not exactly sure why we did >> it >> that way. However having these two (possibly different) ways to >> describe where a variable comes from seems troublesome to me. If >> possible we want to avoid tables in the specification telling people >> what to use when. (Anyone not feeling pain, just look at the SBML >> specification and Table 5 or how to interpret constant / boundary >> condition). We still have time to sort things out ... or is this a >> non-issue, and it is an error to use modelReferences in variables for >> datagenerator, while using a taskreference is an error for variables >> in ChangeMath. If so they need to be renamed :) ... the schema >> currently lists both as optional, which does not do this situation >> justice :) >> - parameter value type should be xs:double rather than xs:string > > Yes, I think that's what you mentioned before. > I think everybody agreed on changing it to the XML Schema type > xs:double!? > If I don't get any complaints, I'll change it :-) > No skipping over the bigger question please :) > >> - for notes and annotations, which are currently strings, it might be >> nice to use more than simple strings. If I were to use annotations, >> I'd rather use a block of xml ... good news, mike has gone through >> the >> trouble before and the sbml schema has the needed specification: > > Yes, I remember I've had that discussion with Mike. > My idea was to keep the notes/annotations as unrestricted as possible. > But I am sure you're right ;-) the thing is ... the current version with just xs:string is much more restrictive than xsd:any ... > > >> >> <xsd:sequence> >> <xsd:element name="notes" minOccurs="0"> >> <xsd:complexType> >> <xsd:sequence> >> <xsd:any namespace="http://www.w3.org/1999/xhtml >> " >> processContents="skip" >> minOccurs="0" maxOccurs="unbounded"/> >> </xsd:sequence> >> </xsd:complexType> >> </xsd:element> >> <xsd:element name="annotation" minOccurs="0"> >> <xsd:complexType> >> <xsd:sequence> >> <xsd:any processContents="skip" >> minOccurs="0" maxOccurs="unbounded"/> >> </xsd:sequence> >> </xsd:complexType> >> </xsd:element> >> </xsd:sequence> >> >> - for ChangeXML a structure like "annotation" above should be >> used for newValue, rather than xs:string > > I agree. Any comments, otherwise I'd change the data type. thank you > > >> - 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 :) best Frank |