Failure extracting XBRL from Inline + suggestion/request how to solve this problem

[Jacques Urlus]

I wanted to use the plugin ‘inlineXbrlDocumentSet’ to extract an XBRL file from an Inline XBRL document.

Trying to do this I encountered 2 problems.

1.      If the Report Package is extracted and I use the html-file as value for --file, it will look for the entrypoint scheme at the declared https location (as found in the html) but not in the Report Package itself. If an entrypoint scheme cannot be found, extraction will fail.

2.      If the value for -- file is the Report Packages (still zipped) it will try to create an extracted xbrl file at the same location of the html-file in the zip. Which of course fails.

To solve at least the second problem, I needed to change the location for the extracted file. It must be pointed to a location outside of the Report Package.

In the function ‘saveTargetDocument’ in the plugin the variable ‘targetUrl’ contains the location of the extracted file. Changing this for example in ‘targetUrl = r"E:\extract.xbrl"’ gives a positive result.

Wouldn’t it be a great idea to add an additional parameter (--outputfile) to the plugin which defines the location (and filename) of the extracted XBRL file.

Apologies for my request. As far as Python is concerned, I'm at a beginner level.

[Austin Matherne]

Hi,

Thanks for bringing this up.

Point one is expected behavior. When you extract a report package, the report files still point at the original URLs for any taxonomies. The package metadata that remaps those URLs to local files is not applied to the loose iXBRL docs, so Arelle will attempt to fetch from the declared web address. If you want to work with the extracted files in place, you can add your report package as a local taxonomy package (Help > Manage packages > Locally > select your package). That tells Arelle where to find the taxonomy files.

Point two arises because inlineXbrlDocumentSet was built for plugins like the EDGAR workflow. When you point it at a zip it tries to write back into that folder structure, which fails. To support arbitrary output locations we would need to handle relative paths and preserve any package remapping. Our conversion plugins for xBRL-CSV and xBRL-JSON follow this approach by producing a new report packages with the report files converted within.

I have opened a GitHub issue with a proposal that's consistent with how we handle other report format conversions.

Kind regards,
Austin Matherne