DD0084: Referenced File is missing - although files are present in same directory

DD0084: Referenced File is missing

Hi Heidi,

Do you also have def:ArchiveLocationID as an attribute on ItemGroupDef referencing the def:leaf?

Hi Heidi, …

Hi Heidi, 

Your XML text looks correct.

Are you sure that you are validating your define.xml from the same directory which contains study datasets?

Regards, 

Sergiy

Hi Sergiy,…

Hi Sergiy,

Yes, I am sure. After creating the define.xml I copy the resulting define.xml file into the folder which also contains all corresponding xpt files and documents (e.g. the Reviewers Guide). This is the define.xml I select in Pinnacle 21 for validation.

Regards, Heidi

Was this every resolved?

Was this issue ever resolved?

I am having the same problem, community v2.2.0.  I get the error on every one of my referenced files - the datasets, the methods and supplemental docs - AND on the reference style sheet (DD0085). 

The define.xml opens in a browser with the style sheet no problems. All the referenced files open with the hyperlink. 

I've examined the XML, the def:leaf elements look fine.

I have another define.xml that does not have this problem (but has all the same files).  I've compared the ODM, Study, Global Variables and MetaData elements between the two and they look the same (except of course some attribute entries).  I've compared the def:leaf elements and they look the same.  I've compare the def:ArchiveLocationID attributes on the ItemGroupDef elements and they look the same. 

Define-XML standard as well as Unix/Linux OS are case-sensitive

Hi, 

Define-XML standard as well as Unix/Linux OS are case-sensitive. For example, "AE.xpt" is not the same as "ae.xpt".

Please ensure that it's not your case and that all referenced files are available in the same folder as a location of your define.xml file.

It can also be due to a limited user access to the referenced folder. 

I cannot reproduce your issue in Windows OS. However, we received few reports from users who ran validation on Unix/Linux and had a case-sensitivity error as above. 

Thanks, 

Sergiy

I have identified the problem...

After much testing I have identified the problem (it is not a problem with case-sensitivity, or folder privileges, and its not a problem with the define.xml file itself)

If the text "define-xml" is in the file path, the problem occurs.

For example

\test file\new define-xml\define.xml - error occurs

\test file\new file\define.xml - error does not occur

still cannot reproduce your case using your example

Hi Jennifer,

I still cannot reproduce your case using your example or anything else. I do not receive any false-positive DD0084 messages if a path to files in define.xml is correct.

Kind Regards, 

Sergiy

How to reproduce

I am running Windows 10.

Here is a full path where the problem can be seen:

"C:\Users\jenfe\Desktop\define.xml testing\sample study\define.xml"

simply removing ".xml" from the path and the problem no longer occurs:

"C:\Users\jenfe\Desktop\define testing\sample study\define.xml"

DD0084 - how to reproduce

I could also reproduce these issues.

The error seems to appear when both the file path (folders) contains "define.xml" AND when the file itself is named "define.xml".
Examples: ...\define.xml\define.xml     => error occurs
                ...\definexml\define.xml      => no error
                ...\define.xml\define2-0-0-example-sdtm.xml     => no error

How was this programmed? Was DOM (Document Object Model) and XPath used to locate the sas files?

Thank you, Jozef!…

Thank you, Jozef!

I've finally got it.

Sergiy 

DD0084 - how to reproduce

I did some extra testing. For example, when I rename the define.xml file into "a.xml" and have:
C:\......\a.xml\a.xml

I do not only get the same false positive DD0084 errors, but I do also get a false positive DD0085 "Missing Define XSL".

So it looks as in these cases the software is unable to correctly resolve the file paths, not to the XPT files nor to the stylesheet (in my test case, it is in ../stylesheets).
I haven't looked into the source code yet (might do that in the weekend), but I suspect that the software takes the file path of where the tested file resides and then looks, from left to right, to the first occurrence of the file name in the path. In the above mentioned cases, this of course leads to an incorrect path.

Once again, software developers who are used to work with XML do this using XLink/XPath to find out where the referenced files reside (that is exactly the meaning of the "href") and not do this by string comparisons, which is bad practice.

DD0084

Well, since href is relative to the Define-XML file, the software first needs to identify the path to the Define-XML file. My guess is that the software in this case assumes <define folder>/<define file name>, but does not take into account that <define file name> might already be part of <define folder>. I’m not sure this has anything to do with XLink or XPath, but just with the algorithm to extract a path from a complete file name.

Anyway, an interesting bug, with some great detective work to uncover it! Now it’s up to the P21 folks to fix it :-)

Lex

opinions are my own, not my employer’s.