Content-detected formats (XML Schema, OpenAPI) are attributed to the root unit, not the unit that holds the files, so schema-declared says "no file to judge"

Offen
  • Stimmt etwas nicht?
#283 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
tooling

Rechercherichtung

Start with the content-detection origin at project_validator/facts/structure.py:224, which attributes ContentLanguages to the root path, and with _schemas() in project_validator/questions/declaration.py:52-58, which filters schemas by owner unit. Reproduce with a sub/ unit containing a.xsd lacking targetNamespace and check that schema-declared reports it instead of 'no XML Schema file to judge'. Done when probe-found formats map to the owning unit and that repro fails as expected.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

docbook/docbook: schema-declared PASS "no XML Schema file to judge" although 14 XSDs (6 without targetNamespace) and 364 documents were read: the facts are assigned to the root unit, whose formats do not include XML Schema, while the files live in the MovedToCodeberg unit; the root (holding only a README) is also reported as a Shell/XML Schema/XSLT product. hledger-web's config/openapi.yaml is read as a product SchemaDeclaration but OpenAPI is attributed to the root unit, so schema-declared reports "no OpenAPI file to judge" and static-analysis/schema-validation judge unit .. Formats found by content probes should belong to the unit that owns the files (the #51 design put probe-found formats on the root unit).

Evidence from the corpus audit

docbook/docbook / schema-declared
  • kind: FALSE_POSITIVE
  • actual: PASS: no XML Schema file to judge
  • expected: FAIL: 6 XSDs declare no targetNamespace (and 364 documents are asked for a schema location); the facts
    were all produced but assigned to a unit whose formats do not include "XML Schema".
  • evidence: MovedToCodeberg/src/docbook/schemas/4.5/xsd/docbook.xsd:64:
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> (no targetNamespace; same
    for calstblx, dbhierx, dbnotnx, dbpoolx, htmltblx.xsd). --facts --only schema-declared emits 378
    SchemaDeclaration facts (14 targetNamespace, 6 with "missing": ["targetNamespace"]; 364 schema location).
    .map.json units: "directory": "." has formats: ["XML Schema","XSLT"], languages: ["Shell"] but owns no
    file; "directory": "MovedToCodeberg" has formats: ["XML"] only. Validator:
    project_validator/facts/structure.py:224 ContentLanguages(origin=Origin(path="."), ...) (content detection is
    always attributed to the root); questions/declaration.py:_schemas filters by owner(schema.path, units) == unit,
    so the root unit gets zero schemas and judge_schema_declared says "no XML Schema file to judge"; per_unit only
    asks units whose formats contain the language.
  • repro: sub/build.gradle (any build file making sub/ a unit) + sub/a.xsd with <xs:schema xmlns:xs="..."> and
    no targetNamespace; nothing at the root. Expected FAIL, actual PASS.
  • confidence: high
docbook/docbook / detection
  • kind: DETECTION
  • actual: units: . product (Shell; XML Schema, XSLT) and MovedToCodeberg product (Gradle; Java, JavaScript; XML)
  • expected: one unit MovedToCodeberg carrying Shell (gradlew), XML Schema and XSLT; the root holds only README.md.
    Consequence: "XML schemas: no tests found (XSpec suites)", "Shell: CI never runs shfmt", "Shell: no static analyzer"
    are all reported against the empty root unit.
  • evidence: find . -maxdepth 1 -type f -> ./README.md only; README.md:1: # Moved to Codeberg;
    MovedToCodeberg/gradlew, MovedToCodeberg/src/docbook/schemas/5.0/rng/docbook.rng. Validator: same
    structure.py:224 as above (origin ".").
  • repro: as the previous finding; look at --map units.
  • confidence: high
simonmichael/hledger / schema-declared
  • kind: FALSE_NEGATIVE
  • actual: PASS: no OpenAPI file to judge (and static-analysis: OpenAPI/AsyncAPI: no static analyzer runs, schema-validation FAIL, both judged for unit .)
  • expected: PASS: 1 OpenAPI file declares its version and info.version (hledger-web/config/openapi.yaml), judged in unit hledger-web. The --facts output shows the file was read as a product SchemaDeclaration with nothing missing, but the OpenAPI format is attributed to the root unit while the file is owned by the hledger-web unit, so _schemas() filters it out.
  • evidence: hledger-web/config/openapi.yaml:13: openapi: 3.1.0; :21: version: 1.0.0; --facts --only schema-declared: "kind": "SchemaDeclaration", "origin": "hledger-web/config/openapi.yaml", "format": "OpenAPI", "role": "product", "declared": {"openapi": "3.1.0", "info.version": "1.0.0"}, "missing": []; .map.json units: root formats: ["Dockerfile", "OpenAPI", "TOML", "YAML"], hledger-web formats: ["YAML"]; project_validator/questions/declaration.py:52-58: if schema.format == format_ and owner(schema.path, units) == unit
  • repro: cabal.project with packages: web, web/web.cabal, web/config/openapi.yaml (openapi: 3.1.0, info: {title: x, version: 1.0.0}); expect the file judged
  • confidence: high

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.