An imported US-GAAP typed dimension is exposed as `Axis.is_typed_dimension=False`

[synfonia-llc]

Issue Type

• Data Quality Issue (incorrect financial values, missing data)
• XBRL Parsing Issue (statement rendering, concept mapping)
• Filing Access Issue (download failures, attachment problems)
• Performance Issue (slow operations, memory problems)
• Compatibility Issue (platform/dependency conflicts)
• Documentation Issue (unclear instructions, missing examples)

Environment

EdgarTools Version: 5.55.0
EdgarTools Source: upstream main at a0ff18089c844ddfe81bd21a1c7c56f4ed629e55
Runtime witness: audit worktree at 70c31469dc7e6d4b386a6f8fe4ce1276d48fca51; its edgar/** tree is identical to the upstream source revision above
Python Version: 3.14.4
Operating System: Microsoft Windows 11 (10.0.26200)

Bug Description

What you expected to happen:

When a dimension is declared with xbrldt:typedDomainRef and is used by filed xbrldi:typedMember contexts, the public Axis object should identify it as typed and retain its typed-domain reference.

Zymeworks' filing uses us-gaap:StatementOfIncomeLocationBalanceAxis in eight typed-member contexts. The referenced 2026 US-GAAP schema declares that axis as:

<xs:element
    id="us-gaap_StatementOfIncomeLocationBalanceAxis"
    name="StatementOfIncomeLocationBalanceAxis"
    substitutionGroup="xbrldt:dimensionItem"
    xbrldt:typedDomainRef="#us-gaap_QName.domain"
    ... />

What actually happened:

EdgarTools reaches the axis and all eight facts that use it, but the public metadata positively identifies the axis with the explicit-dimension defaults:

raw typed-member contexts: 8
facts selected by the typed axis: 8
axis.is_typed_dimension: False
axis.typed_domain_ref: ''

There is no exception or warning. A caller inspecting xbrl.axes cannot distinguish this filed typed dimension from an explicit dimension.

Error message (if any):

No exception or warning is raised.

Reproduction

Company/Ticker: Zymeworks Inc. (ZYME)
Accession: 0001937653-26-000047
Time Period: Quarter ended June 30, 2026
Relevant Forms: 10-Q

Minimal code to reproduce:

from lxml import html as lxml_html

from edgar import get_by_accession_number, set_identity

set_identity("Your Name your.email@example.com")
filing = get_by_accession_number("0001937653-26-000047")
assert filing is not None
source = filing.html()
assert source is not None
tree = lxml_html.fromstring(source.encode("utf-8"))
raw_typed = [
    element
    for element in tree.iter()
    if isinstance(element.tag, str)
    and element.tag.lower().split(":")[-1] == "typedmember"
    and element.get("dimension")
    == "us-gaap:StatementOfIncomeLocationBalanceAxis"
]

xbrl = filing.xbrl()
assert xbrl is not None

axis = xbrl.axes["us-gaap_StatementOfIncomeLocationBalanceAxis"]
facts = xbrl.query().by_dimension(
    "us-gaap:StatementOfIncomeLocationBalanceAxis"
).execute()

print("raw typed-member contexts:", len(raw_typed))
print("facts selected by the typed axis:", len(facts))
print("axis.is_typed_dimension:", axis.is_typed_dimension)
print("axis.typed_domain_ref:", repr(axis.typed_domain_ref))

Output on current main:

raw typed-member contexts: 8
facts selected by the typed axis: 8
axis.is_typed_dimension: False
axis.typed_domain_ref: ''

Additional Context

One filed context contains:

<xbrldi:typedMember dimension="us-gaap:StatementOfIncomeLocationBalanceAxis">
  <us-gaap:QName.domain>
    us-gaap:ResearchAndDevelopmentExpenseExcludingAcquiredInProcessCost
  </us-gaap:QName.domain>
</xbrldi:typedMember>

The definition linkbase also places this axis in the filing's share-based-compensation hypercube. Under XBRL Dimensions 1.0, a typedMember supplies the value of a typed dimension, so the public False value is not an ambiguous inference from a label. The SEC filing index provides the primary Inline document, extension schema, and definition linkbase used by the portable reproduction.

The first demonstrated loss is DTS import traversal. Zymeworks' extension schema does not redeclare this standard axis; it imports the official US-GAAP 2026 schema, where the quoted substitutionGroup="xbrldt:dimensionItem" and xbrldt:typedDomainRef="#us-gaap_QName.domain" attributes are declared. XBRL.from_filing() supplies only the filing's extension-schema attachment to SchemaParser.parse_schema_content(), and that parser enumerates declarations in the supplied content without resolving xs:import. The standard typed-axis declaration therefore never reaches the element catalog. Label processing later leaves a placeholder-like catalog entry, and the definition parser constructs Axis with only element_id and label, so the public Axis.is_typed_dimension and Axis.typed_domain_ref fields retain their defaults.

Even after imported declarations are made available, preserving substitutionGroup and xbrldt:typedDomainRef in schema metadata and propagating them to Axis would still be necessary. For this witness, however, the earliest observable loss is the untraversed imported standard schema, not attribute omission from a declaration that the parser had already loaded.

The practical impact is loss of dimension kind and typed-domain identity. Code that branches on Axis.is_typed_dimension, validates a typed value against its domain, or serializes the filing's dimensional model will treat this typed axis as explicit or will be unable to perform the operation from EdgarTools' public model.

A search of the local First-through-Fourth-Wave draft corpus found no duplicate. The closest upstream issue is #364, which concerned extracting the useful child value from an instance typedMember. That fix is working here—the query reaches the typed values. This report concerns the separate schema/definition-side Axis metadata fields, which still report the wrong dimension kind and omit the typed-domain reference.

A live search of the open and closed GitHub issue tracker should be repeated immediately before submission.

---

This issue will be handled using EdgarTools' systematic issue resolution workflow. A reproduction test will be created to verify the fix.

[dgunning]

Partially fixed on main in c17fe03 (PR #1263), and left open deliberately for the remaining half.

What shipped. Axis.is_typed_dimension and Axis.typed_domain_ref were declared on the model and written by nothing — grep across edgar/ returned only the two declaration lines — and ElementCatalog had no field to carry it either. So the triage here was half right: a complete DTS traversal would have left both False anyway, because nothing carried the answer and nothing read it. SchemaParser now reads xbrldt:typedDomainRef and substitutionGroup into the element catalog and DefinitionParser sets both Axis fields from it, which covers an axis the filer declares in its own schema — where typed dimensions almost always live in SEC filings.

What remains — the xs:import/DTS traversal you identified. SchemaParser.parse_schema_content() still enumerates only the xs:element declarations in the content it is handed, so an axis declared only in an imported taxonomy never reaches the catalog. That is a separate capability rather than a parser fix: every xs:import in our fixture corpus is an absolute URL to xbrl.org, xbrl.sec.gov or fasb.org (Microsoft's FY2024 schema alone has 12), so following them means fetching and caching multi-megabyte standard taxonomies, with network, cache-lifetime and offline-test consequences. It is scheduled for the 6.0 window.

One prerequisite worth flagging, since it is independent of the traversal and something a reporter can help with: no filing in our fixture corpus contains a typedDomainRef at all, so the typed-dimension case is currently covered synthetically. If you have a real filing that uses a typed dimension, pointing us at its accession number would be genuinely useful.

[synfonia-llc]

I did a search of typedDomainRef and could not find an example in my edgartools cache. Google searches for typedDomainRef point to European use-cases, which wouldn't be applicable for edgartools.

Thank you for looking into it.