[BUG] Handle string values in enum facts

[aaroncameron-wk]

What happened?

It appears that xValue in this context can be a str or list containing a str. This means a str may be passed in self.nsmap.qname(qn) which causes the below exception.

ixbrl-viewer/iXBRLViewerPlugin/iXBRLViewer.py

Lines 267 to 275 in ebdc9d6

	elif f.concept is not None and f.concept.isEnumeration:
	qnEnums = f.xValue
	if qnEnums is None:
	factData["v"] = f.value
	factData["err"] = 'INVALID_IX_VALUE'
	else:
	if not isinstance(qnEnums, list):
	qnEnums = (qnEnums,)
	factData["v"] = " ".join(self.nsmap.qname(qn) for qn in qnEnums)

'str' object has no attribute 'namespaceURI'
  File "/usr/local/lib/python3.12/site-packages/iXBRLViewerPlugin/iXBRLViewer.py", in createViewer
    self.addFact(report, f)
  File "/usr/local/lib/python3.12/site-packages/iXBRLViewerPlugin/iXBRLViewer.py", in addFact
    factData["v"] = " ".join(self.nsmap.qname(qn) for qn in qnEnums)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/iXBRLViewerPlugin/iXBRLViewer.py", in <genexpr>
    factData["v"] = " ".join(self.nsmap.qname(qn) for qn in qnEnums)
                             ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/iXBRLViewerPlugin/iXBRLViewer.py", in qname
    return "%s:%s" % (self.getPrefix(qname.namespaceURI, qname.prefix), qname.localName)
                                     ^^^^^^^^^^^^^^^^^^

A similar issue was recently handled in a recent PR. It currently relies on the assumption that xValue is either None (if the value is missing or invalid) or it is a QName or list[QName]. We apparently also need to handle cases where xValue is str or list[str].

Version

1.4.17

With which browsers are you experiencing the bug?

Firefox, Chrome, Safari, Microsoft Edge

Documents

No response

Screenshots

No response

[brettkail-wk]

We apparently also need to handle cases where xValue is str or list[str].

Alternatively, should Arelle be ensuring that all isEnumeration concept values are list[QName]? I guess this is the current condition, so is there some non-xs:token non-xs:QName type in that list that is causing str (probably, then converted to a tuple) to be returned? Do you have more information on which type/concept it is?

[paulwarren-wk]

Alternatively, should Arelle be ensuring that all isEnumeration concept values are list[QName]? I guess this is the current condition, so is there some non-xs:token non-xs:QName type in that list that is causing str (probably, then converted to a tuple) to be returned? Do you have more information on which type/concept it is?

There was a 2016 PWD of Extensible Enumerations 1.1 that was based on string, not token (XbrlConst.qnEnumerationsItemType2016). That is supposed to hold a list of QNames so should be treated as baseXsdType = "enumerationQNames". I don't understand what the check for token is doing. If you were to remove it, I think it would handle the 2016 type correctly, although I'd be surprised if anyone is using that spec, and I don't think it's worth expending any effort on supporting it in Arelle.

[paulwarren-wk]

@aaroncameron-wk do you have a document that demonstrates this issue?