Open aaroncameron-wk opened 6 months ago
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?
Alternatively, should Arelle be ensuring that all
isEnumeration
concept values arelist[QName]
? I guess this is the current condition, so is there some non-xs:token non-xs:QName type in that list that is causingstr
(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.
@aaroncameron-wk do you have a document that demonstrates this issue?
What happened?
It appears that
xValue
in this context can be astr
or list containing astr
. This means astr
may be passed inself.nsmap.qname(qn)
which causes the below exception. https://github.com/Arelle/ixbrl-viewer/blob/ebdc9d6023ac52e9e505efe5caa05257b5bc3079/iXBRLViewerPlugin/iXBRLViewer.py#L267-L275A similar issue was recently handled in a recent PR. It currently relies on the assumption that
xValue
is eitherNone
(if the value is missing or invalid) or it is aQName
orlist[QName]
. We apparently also need to handle cases wherexValue
isstr
orlist[str]
.Version
1.4.17
With which browsers are you experiencing the bug?
Firefox, Chrome, Safari, Microsoft Edge
Documents
No response
Screenshots
No response