Metadata Types

[calvin.harman@…]

With the addition of psLib SDRS Section 5.2.4 (Configuration files), the
psMetadataType has become less useful. Given that metadata configuration files
need to take psVectors for most of the psTypes (not just the PS_META types), I
propose that we add a psType member to the psMetadataItem struct. We'd also
need to change the psMetadataType enum to remove the types already covered in
psType and add a PS_META_PS_TYPE to let users know that the metadata type was a
standard psType. With this addition, psMetadata functions would also become
standardized with the types that the rest of psLib uses.

[eugene]

In looking into this bug, I started to look a bit more at the psType and
psMetadataType entries as currently defined. I agree that there is some
overlap, but I'm not sure I agree with your solution. This also relates to the
point in bug 206. In particular, the psType is supposed to be used to define
the math structures, and probably should not even include the PS_TYPE_OTHER
entry, much less the PS_TYPE_BOOL and PS_TYPE_STR entries. No vectors, scalars,
or images are of these types. The other data containers (psList, psHash,
psArray) are completely untyped at the moment, and while they may contain mixed
types, they should probably be used to groups of data that are of a single type.

Our design is such that any mixed conglomeration of data that needs to be

carried around with more detailed information should be carried by a psMetadata
container rather than the more basic containers.

So, here is my proposal, which I've put into the current SDRS draft:

1) psElemType only contain entries which are valid for psImage, psVector,
psScalar (drop the OTHER and the newly added STR and BOOL).

2) psMetadataType drops the PS_META_IMG entry and replaces it with PS_META_MATH.

In this case, the entry is one of our self-defining data types, whose type and

element type are defined by their own type entry.

note that a given psMetadataItem may be of type PS_META_F32 or of type
PS_META_MATH for which the entry is of type PS_TYPE_F32. In the first case, the
data value is just stored in md.data.F32 while in the other case, it is stored
in ((psScalar *)md.data.void)->data.F32, an additional level of indirection.

*) the psMetadataItem.data.void entry has a confusing name (and is slightly
inconsistent). I propose this be changed to psMetadataItem.data.data to be
consistent with the other data container void pointer names (though I welcome
any alternative suggestion for psMetadataItem.data!)

) I'm not very happy with the names PS_META_ITEM_SET and psMetadataItem.items.

They don't really give the concept that those entries represent. suggestions?

I've updated the SDRS version 8 draft to reflect these changes.

[calvin.harman@…]

In response #1 above...

I think we should still add the PS_TYPE_BOOL and PS_TYPE_STR to psElemType. I
don't think we should restrict the usage of psTypes to only image, vector, and
scalar. The image, scalar, and vector functions are already set up to produce
errors it the user tries to use an invalid type, which boolean and strings
would be for these cases. I see psType as a generic structure that could be
used by any function within psLib or psModule.

Regarding _OTHER (also in Eugene's #1 above), I do agree that the _OTHER types
in psLib should be dropped, since it leaves things vague. I think that _UNKNOWN
types in psLib should also be dropped for the same reason.

In response to #2 above...

If we were to add psType as a member of psMetadataItem, not only could we
remove PS_META_IMG, but also _META_S32, _META_F32, and _META_F64. These would
be unnecessary since they're already covered in psType. If we have a metadata
item whose psMetadataType is PS_META_MATH, we'd know to go to psMetadataItem's
psType to get the primitive type. Also, for cases when we have vectors in the
configuration file, we need to know both type and dimensionality, which is not
covered in the current psMetadataType, but is in psType. This would also pave
the way to adding image data to configuration files, since it too is in psType.

Regarding psMetadataItem.data.void (also in Eugene's #2 above), I replaced this
with "psPTR V" to make it consistent with the rest of psLib. You should see it
in the upcoming release.

Regarding the names PS_META_ITEM_SET and psMetadataItem.items (also in Eugene's
#2 above), I also agree. They aren't very descriptive. As things have evolved
with psMetadata, metadata items that are PS_META_ITEM_SET, seem more
like "parent" or "folder" nodes, since they usually contain children of
repeated metadata items, like comments. For the "items" member, I usually refer
to this as "metadataItems" in the code, since that's what it holds. Other
suggestions for these names would be welcome.

[eugene]

we converged on the following:

we use psMetadataType to define the general data type the in psMetadataItem and
added an entry psElemType ptype to specify the primitive data types (psS32,
psF64, etc). This is the same enum as is used by the psVector and other psType
entries to define the primitive data types.

Bool is now part of the valid psElemType entries

STRing remains part of the psMetadataType entries.

PS_META_LIST replaces PS_META_ITEM_SET

psMetadataItem.items is renamed psMetadataItem.list and merged into the union .data.

[Paul Price]

Closing subsequent to release of SDRS-08, ADD-07.