Skip to content

Stop warning about an empty System Composer interface dictionary - #46

Merged
ww-mw merged 1 commit into
mainfrom
no-sc-catalog-warning
Sep 30, 2026
Merged

ww-mw merged 1 commit into
mainfrom
no-sc-catalog-warning

Conversation

@ww-mw

@ww-mw ww-mw commented Sep 30, 2026

Copy link
Copy Markdown
Member

Opening an ordinary .sldd could put a banner over the tab:

One part of this file could not be read, so what you see below is incomplete.
The dictionary part "simulink/systemcomposer/interfaceDictionary.xml" holds
nothing readable, so architectural entries are reported by their Simulink class
rather than their System Composer type.

It was a false positive on a complete file, and it was raised inconsistently —
the compressed-binary reader warned where the uncompressed-text reader stayed
quiet, so the same dictionary said two different things depending on how it had
been saved. That is the "one rule, two paths" shape ScCatalog exists to close.

An empty catalog part is what MATLAB writes into any dictionary System Composer
has merely touched: built-in value types, no definitions. Nothing is lost, and
two measurements settle that the catalog-less fallback is not a degrade:

  • Only Simulink.Bus is ambiguous. Over 14,668 derived entries in four real
    dictionaries, every other class is 1:1 with its classification, so IsDerived
    plus the class already yields the identical Kind. IsDerived also drives the
    Architectural-vs-Design section split on its own.
  • For Simulink.Bus, the fallback IS MATLAB's answer. Strip the part from a
    dictionary holding a StructType and a DataInterface, reopen it in MATLAB
    R2027a, and both come back as Simulink.dictionary.archdata.DataInterface —
    exactly DERIVED_KIND_BY_CLASS['Simulink.Bus']. MATLAB does not regenerate the
    part on save, and it ignores simulink/ArchitecturePart.xml, which still
    records the struct type under DataTypes.

So both readers now stay silent on the same terms, whether the part is absent
(nearly every .sldd) or present and empty. With the part there, the file is
still the authority and classification is unchanged.

Tests

  • scCatalog.test.ts — the binary reader over a MATLAB-shaped empty member, and
    the equality of the two formats' silence and kinds.
  • parseWarnings.test.ts — the kinds either reader falls back to (all eight
    classifications), and the kinds with the catalog present.
  • dataModelSources.test.ts — no .sldd reaches two layers once this warning is
    gone, so the shared-sink test now proves the contract directly: the array the
    parser filled is the array the source carries, and the node layer appends to it
    rather than replacing it.

npm run verify: 4941 passed, 26 skipped, 0 failed.

Opening an ordinary .sldd could put a banner over the tab saying the part
"simulink/systemcomposer/interfaceDictionary.xml" holds nothing readable and
that architectural entries are therefore reported by their Simulink class. It
was a false positive on a file with nothing wrong with it, and it was raised
inconsistently: the compressed-binary reader warned where the uncompressed-text
reader stayed quiet, so one dictionary said two different things depending on
how it had been saved.

An empty catalog part is what MATLAB writes into any dictionary System Composer
has merely touched -- built-in value types and no definitions -- so the file is
complete and there is nothing to act on. Two measurements settle that the
fallback is not a degrade either:

  - Only Simulink.Bus is ambiguous. Over 14,668 derived entries in four real
    dictionaries every other class is 1:1 with its classification, so IsDerived
    plus the class already yields the identical Kind. IsDerived also drives the
    Architectural-vs-Design section split on its own.
  - For Simulink.Bus the fallback IS MATLAB's answer. Remove the part from a
    dictionary holding a StructType and a DataInterface, reopen it in MATLAB
    R2027a, and both come back as Simulink.dictionary.archdata.DataInterface --
    exactly DERIVED_KIND_BY_CLASS['Simulink.Bus'].

So both readers now stay silent on the same terms, whether the part is absent
(nearly every .sldd) or present and empty. Four tests pin it: the kinds either
reader falls back to, the kinds it produces when the catalog IS there, and the
equality of the two formats' silence.

test/dataModelSources.test.ts no longer had a .sldd reaching two layers once
this warning was gone, so the shared-sink test now proves the same contract
directly: the array the parser filled is the array the source carries, and the
node layer appends to it rather than replacing it.
@ww-mw
ww-mw merged commit 524613b into main Sep 30, 2026
1 check passed
@ww-mw
ww-mw deleted the no-sc-catalog-warning branch September 30, 2026 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant