Show concept taxonomy #305
Conversation
Security Insights(1) Vulnerable direct dependencies were detectednumpy < 1.21 via requirements.txtAction Items
Questions or Comments? Reach out on Slack: #support-infosec. |
| const nsURI = fact.concept().qname().namespace; | ||
| $('tr.taxonomy td', factHTML).text(this._report.taxonomyNameForURI(nsURI, nsURI)); | ||
| } | ||
| else if (fact instanceof Footnote) { |
There was a problem hiding this comment.
Pre-existing, but would it be better to use item naming (throughout) rather than fact? _itemSummaryHTML, ci (current item?), etc.
There was a problem hiding this comment.
Have split into separate methods so that we can have a descriptive variable name in both branches, and renamed to item in the common code.
| // taxonomies file. | ||
| // Returns def if none available. | ||
| iXBRLReport.prototype.taxonomyNameForURI = function(nsURI, def) { | ||
| const nsURIEscaped = nsURI.replaceAll(/[.:]/g,'_'); |
There was a problem hiding this comment.
Perhaps it's worth a small comment mentioning nsSeparator and keySeparator to make it clearer why we're doing these replacements? I'm not so familiar with i18next, so it took me a bit to dig up why they were special.
| @@ -0,0 +1,15 @@ | |||
| { | |||
| "http_//fasb_org/us-gaap/2022": "US GAAP 2022", | |||
There was a problem hiding this comment.
I somewhat worry this file will become difficult to maintain, either we don't remember to update it or we end up adding many things to it. I can already guess we're going to get support requests from customers (or our own professional services team) asking about inconsistencies. I wonder if it would be nicer to allow the names to be passed on the command-line when generating a viewer so that the ixbrl-viewer.js doesn't need to be rebuilt to add new names? Long-term, it would be nice if we could figure out how taxonomies could just provide these terse labels themselves, perhaps with a generic linkbase and a namespace-as-resource?
@derekgengenbacher-wf Thoughts on how we might manage this?
There was a problem hiding this comment.
Not Derek :) but I like the idea of a command-line option, it seems completely reasonable. The generic linkbase idea would be neat, but only if we could get regulators to start providing it somehow
There was a problem hiding this comment.
Another possible place to put it would be in the Taxonomy Package metadata. That already provides the option of multilingual name and description. It doesn't provide a short name option at the moment, but the schema is intentionally extensible, so it's something we could suggest.
It does already provide a separate version field.
The problem is how to then link it with specific namespaces, as a Taxonomy Package may define multiple concept-bearing namespaces.
This is probably something to raise with the Spec WG.
There was a problem hiding this comment.
To address the original point, I'm happy to move this to be a viewer-build-time input, rather than hard-coded into the JS, but I think it makes sense to provide some defaults.
I wonder if this is something we should actually address in Arelle? For US taxonomies, Arelle already has the edgartaxonomies.xml file which looks to provide exactly what we need, and is already being maintained in the Arelle codebase.
There was a problem hiding this comment.
Another possible place to put it would be in the Taxonomy Package metadata.
I think we want it discoverable from the XBRL docs, and I wouldn't expect that metadata to be referenced by the DTS (sounds backwards).
I'm happy to move this to be a viewer-build-time input, rather than hard-coded into the JS, but I think it makes sense to provide some defaults.
That seems reasonable to me.
For US taxonomies, Arelle already has the edgartaxonomies.xml file
If adding ESEF files and exposing that with some kind of Python API seems reasonable to Herm, et al, then that seems somewhat more palatable than trying to maintain a registry in this repo.
There was a problem hiding this comment.
I'll discuss with Herm. IFRS is already in that Edgar list, which the main thing that we care about for ESEF.
There was a problem hiding this comment.
Raised https://gitlab.xbrl.org/base-spec/base-spec/-/issues/292 to discuss a standard XBRL mechanism for this.
There was a problem hiding this comment.
@paulwarren-wk , it seems like all comments have been addressed and this seems like a good improvement. Do you have any hesitations with resolving merge conflicts and opening not as a draft?
|
@sagesmith-wf It's not clear to me that this thread was actually addressed (i.e., I'm not sure how our systems or other users would be able to plug in their own custom taxonomy mappings for whatever reason). |
This PR adds an additional field to the fact inspector that gives a human-readable label for the taxonomy that the concept is drawn from.
The primary motivation for this is so that the version of the taxonomy is visible. The inspector already shows the prefix used for the concept's namespace, but this is typically a non-version-specific string such as
us-gaaporifrs-full.The taxonomy names are stored in a translation file.
Taxonomy names are also in the highlight key: