> It is arguable as to whether this is a bug or a problem in the invocation:

I suspect a bug in that it is not being picked up as an error, so (4) 
below would probably be a good thing. And it is also a problem with 
invocation on my part. Now that I know however, I can avoid the 
invocation problem.

While (3) would probably also be useful, as long as (4) is done with a 
nice explanatory error message then it would be a nice-to-have feature 
rather than an essential.

> 1) The CellML API is supposed to be able to work transparently as either 
> a server or locally. Allowing process state such as the current working 
> directory to affect the behaviour seems wrong under this paradigm (e.g. 
> you could write code which called chdir between calls, but this would 
> stop working if you switched to using CORBA). Since this may be the 
> first model loaded through the API, we have no other way to know what 
> the caller intends if they give a relative path.
> 2) The current API interface doesn't address the possibility that the 
> loaded URL might be relative, although it doesn't rule it out either. 
> When I documentation for the url parameter, I intended 'The absolute URL 
> from which to load', and so I think it should probably be updated to say 
> that.
> 3) It would make sense for the command line tools like CellML2C and 
> RunCellML to take relative URLs, but it would probably be better for 
> them to translate to an absolute URL before passing to the CellML API, 
> since they know what absolute URL they would like to resolve against.
> 4) Perhaps the CellML API should throw an exception if it receives a 
> relative URL, so that these problems get caught sooner?
> Best regards,
> Andrew
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
cellml-discussion mailing list

Reply via email to