|
From: Burkhard S. <b_...@us...> - 2004-12-16 03:39:14
|
Mark, thanks for your quick reply. Yes, I actually did miss the point. :-) Thanks for helping me get my head around this. I agree that we have a lot of options for encoding something with AnIML. And I think that's exactly where the Technique Definitions come in. Using those we can pretty closely control how to encode something. This relieves end-users from the tedious modelling task. Had we had a Technique Definition for Mark Mullins' experiment, things would have been a lot easier. So this puts a lot of responsibility into the handy of the authors of Technique Definitions. But that's what we as a committee are here for. It also means that we should soon look into creating a document with "best practices for Technique Definition authors". I've looked over your proposal and am looking forward to hearing more about it tomorrow. It looks to me that it's adding even more degrees of freedom -- which is both good and bad. As I've posted to the list (not through yet), I've recently written a full parser for AnIML and (if there's enough time tomorrow) could share some experiences. Especially the recursion is rather straightforward to handle if you follow a certain pattern. Talk to you tommorow. I'm looking forward to my long distance bill... ;-) Best wishes, Burkhard Mark F. Bean wrote: > I agree with Burkhard. And by the way, the more I wrestle with AnIML in > close detail for the documentation, the more impressed I am with Burkhard's > brain! He solved a number of problems that I would not have known how to > do. The recent changes are small items in comparison with the tremendous > job done by Burkhard, Dominik, and Maren. But let's not stop there - I want > to consider the restructuring proposal seriously tomorrow. > > Perhaps Burkhard missed the point here (probably because my emails have been > confusing). The problem originated when Mark Mullins wanted to put > segmented chromatogram vectors in AutoIncrementedValueSets - which just > isn't going to work unless we allow more than one AutoIncrementedValueSet - > which AnIML does. Having done that, the problem became knowing how long > each Vector segment was - and so the changes started to snowball. I > recommended that he simply encode the data as an EncodedDataSet and not > worry about the space saving, and that we restrict AutoIncrementedValueSet > and EncodedDataSet to 0 to 1 per Vector. If we do NOT do that, the > VectorSet length becomes problematic as there is no guarantee that all > ValueSets in a Vector are the same length. > > This illustrates my point that AnIML flexibility may need to be constrained > more - there are too many solutions to problems right now. > > I hope you can join us tomorrow Burkhard, > > best wishes, Mark > > |