Specific AOM constraints for DV_ENCAPSULATED (DV_MULTIMEDIA and DV_PARSABLE)

Description

Does anyone thinks that we should have specific constraints for encapsulated data?

IMO it would be nice to have specific constraints to specify stuff like max data size, allowed media types, allowed formalisms, allowed charsets, etc.

Attachments

1

Activity

Show:

Sebastian Iancu December 28, 2018 at 12:29 PM
Edited

Just discovered these comments now; the DV_MULTIMEDIA.size is an attribute, not a function. DV_PARSABLE.size is a function.

Pablo Pazos March 9, 2018 at 3:43 PM

How can a constraint be specified for data: Array on DV_MULTIMEDIA, it is not clear for me, for instance to have a min/max length constraint for data.

Since size is a function, no constraints can be defined over size directly.

Pablo Pazos August 30, 2017 at 1:32 PM

I think the data types spec description for DV_PARSABLE.formalism should be updated. Now is too open "Name of the formalism, e.g. GLIF 1.0 , Proforma etc.".

Can we use mime types for that? Formalizing the value space makes it easier to use.

Pablo Pazos June 19, 2015 at 6:51 PM

Which AOM/AOP classes are in use for such DV_MULTIMEDIA constraint? It that a C_COMPLEX_OBJECT with C_PRIMITIVEs applied to each attribute?

My intention was to see if there is any value to have something like C_DV_MULTIMEDIA, like we have for DV_ORDINAL or CODE_PHRASE (used to constraint DV_CODED_TEXT.defining_code).

Thomas Beale June 19, 2015 at 11:31 AM

This is already possible - the screenshot above shows a test ELEMENT with value set to DV_MULTIMEDIA. All the RM properties of DV_MULTIMEDIA are shown in grey, so far unconstrained.

Details

Reporter

Components

Priority

Created June 18, 2015 at 10:37 PM
Updated December 28, 2018 at 12:30 PM