Why are there ODM elements in my define?

[SusanParker]

I'm wondering if the code will be updated to exclude ODM elements that aren't part of define.xml, from the macros that are provided with CST 1.4?  I created my first define and was curious why several of the 39 datasets are non-define-related and just ODM-related (formdefs, etc.).  I ran my define.xml through OpenCDISC validator and 6 warnings about ODM elements and one about an unknown attribute came out. 

Unknown attribute 'Id'

ODM attribute 'AsOfDateTime' should not be included in Define.xml

ODM attribute 'Description' should not be included in Define.xml

ODM attribute 'Domain' should not be included in Define.xml

ODM attribute 'KeySequence' should not be included in Define.xml

ODM attribute 'SASDatasetName' should not be included in Define.xml

ODM attribute 'SASFieldName' should not be included in Define.xml

I'm trying really hard to convince my company that we should attempt to use this tool, but not if we'll have to edit the heck out of it.

Probably shouldn't ask during SGF if I want anyone from SAS to answer. 

Thanks!

Sueoo

[Lex_SAS]

Hi Susan,

Thank you for your comments regarding the SAS Clinical Standards Toolkit in relation to the define.xml.

As you noticed, the 39 SAS datasets that define the SAS representation of the define.xml standard contain more ODM content then is typically found in a define.xml file that gets submitted.

The reason for this is that there are more use cases for the define.xml than just submitting to the FDA. For this reason SAS choose to include all elements and attributes from ODM that are related to metadata.

Whether or not content that is part of the ODM standard, but not specifically mentioned in the define.xml specification has been part of an extensive discussion within the CDISC XML Technologies team, and specifically the define.xml development team.
In the draft specification for define version 2 it has been formulated as follows:

"The XML Case Report Tabulations Data Definitions schema permits vendor extensions, as defined in the ODM 1.3.1 specification, to the elements defined in this specification. Any XML not explicitly specified as part of Define-XML v2.0 will be considered an extension. This includes ODM metadata not explicitly referenced in this specification. Extensions have no meaning implied by the Define-XML standard and the meaning must be agreed by the sender and receiver. That is, define.xml files that use extensions are not wrong, but instead the extensions may be ignored unless the sender and receiver have agreed otherwise."

A related problem is that there are currently no formal validation rules for the define.xml (apart from the XML schema). This means that every vendor (OpenCDISC, SAS, ...) must make their own interpretation of the rules, inclusing flagging as ERROR, WARNING, or INFORMATION. It is expected that  the CDISC XML Technologies team will define formal validation rules for the define.xml, so that there can be consistency between the different validation engines.

OpenCDISC takes the approach to flag attributes like the ones you saw as "WARNINGS". In my view valid ODM attributes that are not mentioned in the define.xml specification should be flagged as informational, not as "WARNINGS".
Receiving systems should be forgiving, and may ignore valid ODM attributes that are not part of the define.xml specification.
I recommend that you also bring this issue to OpenCDISC's forum.

We will take your comments in consideration when further developing the SAS Clinical Standards Toolkit.

At this moment you can already remove the attributes that you mention by using the following code (also attached):

libname srcdata "..\data";

data srcdata.definedocument;
set srcdata.definedocument;
call missing(Id, AsOfDateTime, Description);
run;

data srcdata.itemgroupdefs;
set srcdata.itemgroupdefs;
call missing(SASDatasetName, Domain);
run;

data srcdata.itemgroupdefitemrefs;
set srcdata.itemgroupdefitemrefs;
call missing(KeySequence);
run;

data srcdata.itemdefs;
set srcdata.itemdefs;
call missing(SASFieldName);
run;

This code should run just before running the %crtdds_write macro.

I hope this helps.

We will consider your suggestions.

Best,

Lex Jansen

Software Developer @ SAS

[SusanParker]

Lex, thank you so much!  Happy that you had time to reply during SGF.  I will be first in line, hopefully, for your workshop at PharmaSUG.

My main goal was to have tried creating a define with the toolkit prior to attending PharmaSUG so that I could ask intelligent questions.