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"

未關閉
#283 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
1-2 天
新手友好度
35/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
python
領域
tooling

研究方向

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.

由索引模型根據 Issue 內容生成。

描述

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

主要語言
Python
星號
4
分支
1
平均合併
10 小時 41 分鐘
30 天內合併 PR
79

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南,環境需要你自己搭建:先看它的 README,通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

cpp-best-practices/project_validator 的其他 Issue

查看 cpp-best-practices/project_validator 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。