[Neiland85]

Refs #156388

Clarify the documented relationship between DocumentType.publicId and systemId for parsed XML documents, including PUBLIC and SYSTEM declarations, and note that createDocumentType() does not validate identifier combinations for programmatically created objects.

This covers only the publicId/systemId mapping. Other remaining items in #156388 are out of scope.

• Issue: xml.dom docs are missing important information necessary for usage #156388

[Neiland85]

Thanks for confirming this point in the issue discussion. I’ve submitted #157646 to document that mapping explicitly.

For parsed XML documents, the combinations correspond as follows:

• publicId and systemId non-None → PUBLIC
• publicId is None, systemId non-None → SYSTEM
• both are None → no external identifier
• publicId non-None, systemId None → not produced by parsing a valid XML DOCTYPE

I also noted in the PR that createDocumentType() does not validate the identifiers, so programmatically created DocumentType objects may have other combinations.

I’ll leave the PR open for maintainer review and follow any requested changes.

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #34771797 | 📁 Comparing 7e5a837 against main (6dad8b8)

  🔍 Preview build  

33 files changed · + 1 added · ± 32 modified

+ Added

• library/dialog.html

± Modified

• builtins/functions.html
• c-api/hash.html
• c-api/init_config.html
• c-api/interp-lifecycle.html
• c-api/module.html
• c-api/slice.html
• c-api/stable.html
• c-api/threads.html
• c-api/unicode.html
• deprecations/c-api-pending-removal-in-future.html
• and 22 more...

[Neiland85]

Hi, just following up on this documentation PR. It clarifies the DocumentType.publicId / systemId combinations for parsed XML documents and notes the behavior of createDocumentType() for programmatically created objects.

The documentation preview is available, and I’m happy to revise the wording if anything needs clarification. Thanks for your time.