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"

Ouverte
  • Quelque chose ne va pas ?
#283 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
1-2 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
python
Domaine
tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.