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"

Đang mở
  • Có gì không ổn?
#283 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Python
Star
4
Fork
1
Merge trung bình
10 giờ 41 phút
Pull request đã merge (30 ngày)
79

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của cpp-best-practices/project_validator

Tất cả issue của cpp-best-practices/project_validator

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.