One QNAM is declared more than once with disagreeing variable metadata

Rule

NS-006

Category

Define-XML

Basis

Confirmed Traceable to the published specification text cited below.

Detectability

Define-XML conclusive The Define-XML settles this one way or the other. No further evidence is needed to know whether it applies.

Finding type

Metadata gap

Applies to

SDTMIG 3.2, 3.3, 3.4

What changes in v4.0

Under SUPP-- every value is a character QVAL, so variable-level metadata — label, data type, length, codelist, origin — is carried per QNAM in Define-XML value-level metadata rather than by the column itself. The v4.0 NS-- structure gives each non-standard variable its own column with real variable-level metadata, and Section 8.2 provides no NS-- column for QLABEL, QORIG or QEVAL at all: QLABEL becomes the variable's label, QORIG becomes its Origin. This Define-XML declares the same QNAM more than once with those attributes disagreeing, so it does not say what the resulting NS-- column should look like. The conversion cannot resolve that from the metadata, and picking one declaration silently is how a length or a codelist quietly changes during a migration.

What to do about it

Reconcile the declarations before converting. Decide which label, type, length, codelist and origin the QNAM actually has; where two genuinely different uses share one name, that is a naming collision to resolve rather than a metadata error to average out, and the NS-- structure will force the decision anyway because two columns cannot share a name. Fix the Define-XML first — it is the input the conversion reads.

What the scan can and cannot see

Two value-level declarations of one QNAM disagree about label, type, length, codelist or origin. That disagreement is entirely within the Define-XML this scan read. Which declaration is right, and whether the rows are affected, is not established and is not claimed.