Parsing HDF5 with attributes ... cannot remove non-attribute item from template

[drowenhorst-nrl]

*** in the context of create template ***
When parsing an HDF5 with attributes, the data item/group that has an attribute cannot be removed from the template. For instance if the item/group has atributes "Bar 1" and "Bar 2", then the source tree appears like :
/Foo/Bar 1*
/Foo/Bar 2*
'/Foo'

You can remove "/Foo/Bar 1" and "/Foo/Bar 2" but not "/Foo"

Note here ... all "remove" actions are using the check boxes in the MetaData tree. See below for perhaps related issue.

[drowenhorst-nrl]

Not sure if related but ... with hdf5 files with attributes, attempting to remove rows using the "X" on the create template window, the first click will not remove the selected row, but the top item. Further clicks appear to do nothing.

[cryos]

This seems like a more general problem with attributes not quite fitting the data model. So our simple solution of just adding a * works for the most part, but the new XML parser is suffering from the same issue. I started looking into this last week, and I can see it with XML and HDF5 files.

Looking at the way the tree model works you cannot uncheck "directory" type things that contain other things. The issue as I see it is without attributes an entry is either a containing directory, so it doesn't get its own row in the table, or it is a data entry and it does get an entry. We now have another situation where an entry might be made for a data entry, and that data entry has several attributes it contains.

I think I understand the ez model stuff, but this probably warrants a discussion before we go changing things. Do we want to make attributes special in the data model, or do we want to generalize the nodes that contain things to be checkable/uncheckable in their own right?

[joeykleingers]

We had a meeting about this and decided to do the following:

• Rewrite any parsers that are returning nested file dictionaries to instead return flattened file dictionaries. EzMetadataModel also needs to be updated to remove the logic dealing with unpacking nested file dictionaries. The code in there should simplify quite a bit since it'll just be a matter of parsing each incoming flattened dictionary item into an EzMetaDataEntry object and then appending it to the "entries" list property.

• Any node (Foo) that has attributes will have a node in the tree called "Foo*" and a parallel node in the tree called "Foo.attributes" in italics. All the attributes for node Foo are listed as children of "Foo.attributes".