[Insight-developers] MetaIO Unknown meta-data bug

[Bradley Lowekamp]

Hello,

I have pushed a topic with three commits to my github account:

https://github.com/blowekamp/ITK/commit/64b230bfa6f0d8c4b477704d3dd6033c27536e28
https://github.com/blowekamp/ITK/commit/f44e632683f787d3f566323a8dd5db6d4b76e619
https://github.com/blowekamp/ITK/commit/5c7281cfdc1888e907b85a86cbf779cc4f21cf27 *

*I am not entirely comfortable with the changes to the parsing of header the header information and making the non-blank whitespace terminate the string fields. There is a potential for some serious side effects there. While all the ITK tests still pass as I was looking over the metaIO object tests they appear to be the type which just write the data out and then prints it to stdout, it does not verify that's it's correct. So that does not help to instill confidence in the correctness in the above change.


> 
> From: Stephen Aylward <stephen.aylward at kitware.com>
> Date: Wednesday, August 15, 2012 9:57 AM
> To: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Cc: ITK <insight-developers at itk.org>
> Subject: Re: [Insight-developers] MetaIO Unknown meta-data bug
> 

...

> 
> Third - it is a bug we should fix.   My preference is to simply not
> write out a tag if there is no associated value.   Agreed?  

My initial commit did this in ITK. The second one does this in the metaIO library and additionally prints a warning.


>   Then, if
> a tag without a value is found, should it report an error, or just
> continue on?   I guess continue on, but not report that tag as set.
> Agreed?

I think it's more complicated and ambiguous. 

Well with the current parsing/grammar? it is ambiguous as to if the tag/field has an empty value, or if it's value is on the next line, which may be the next tag/field. I am using the term empty value to indicate a string of zero length as opposed to no value, which sounds more like a NULL pointer or something.

My third patch does not let the parse "eat" newline or other non-blank white spaces after the tag/field name. This may have other consequences, in the parsing, so I am not entirely comfortable with it. If the value is empty, we might as well just set the value to the empty string, if we are able to parse it.

The more I think about the more I think it may be best to not change the parsing, and just stop allowing the metaIO library to write ambiguous empty value for fields, which is accomplished in the first two patchs. Agree?

> 
> Thanks,
> Stephen
> 



========================================================
Bradley Lowekamp  
Medical Science and Computing for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120815/983e59c6/attachment.htm>