Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

-strict accepts a namespace with indistinguishable memberships (warning, exit 0)

Closed
  • Is something wrong?
#973 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #1050 by @devin-ai-integration — merged

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
backend

Research direction

Start by tracing how -strict and the service’s strict_conformance setting affect validation and how duplicate owned member names are reported. The issue gives a reproducer and expected behavior: under strict mode the warnings should become errors, while default-mode output stays unchanged. Check existing validation tests and add coverage for both modes; the issue does not name specific files or tests.

Written by the indexing model from the issue text.

Description

The ruling

spec-pilot gap register #13: indistinguishable memberships are reported as a warning, as the pilot reports them, so that duplicated names in the training corpus do not fail its clean gate. The register's own assessment is that "the rule is a validate… constraint — a violating model is not well-formed — so a warning under-reports it".

Model and observed behaviour
package P {
    part def A;
    part def A;
}

$ sysml -validate -strict dup.sysml
dup.sysml:2:14: warning: Duplicate of other owned member name
dup.sysml:3:14: warning: Duplicate of other owned member name
✓ dup.sysml: no errors
$ echo $?
0

develop 1e68ecf2d. Without -strict the output is the same.

Why it is wrong under -strict

KerML §8.3.2.4.5 Namespace, validateNamespaceDistinguishibility (spelt so in the PDF): "All memberships of a Namespace must be distinguishable from each other." The two As have the same name and the same metaclass, so by §8.3.2.4.3 Membership::isDistinguishableFrom they are not distinguishable, and the model is not well-formed. -strict is described as judging "the model as conforming SysML v2", yet it accepts this model with exit 0. So a check run with -strict cannot rely on it to reject a model the specification says is not well-formed.

Proposed behaviour

Only under -strict (and strict_conformance on the service), report indistinguishable memberships as an error. The default stays a warning, so the training corpus, its clean gate and the differential against the pilot are unchanged.

This widens -strict from notation alone to this one well-formedness constraint, which is a change to what the flag means. If that is not wanted, a separate opt-in (a flag, or a lint code that can be raised to an error) would serve the same need.

The case against

The question to the specification's authors in #13 is still open. If they rule that a tool may keep resolving a namespace with indistinguishable memberships, an error would be stricter than the specification intends. Even then, the constraint as published is a validate… constraint, and a strict mode that claims conformance seems the place to apply it as written until that ruling changes it.

🤖 Generated with Claude Code

Dominant language
Go
Stars
36
Forks
10
Avg merge
13h 49m
Merged PRs (30d)
774

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Open-MBEE/OpenSysML

All issues in Open-MBEE/OpenSysML

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.