> 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 Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion