ppkarwasz commented on PR #104: URL: https://github.com/apache/commons-secure-xml/pull/104#issuecomment-5846777466
**Why only namespace-aware helpers** A sweep of the checkouts in my workspace (excluding the JDK, NIST Juliet, vendored dependency sources and build copies, with duplicates removed) found 962 `DocumentBuilderFactory` and 354 `SAXParserFactory` creation sites: | | DOM | SAX | |---|---|---| | Explicit `setNamespaceAware(false)` | 30 (3%) | 24 (7%) | | Namespace-aware (`setNamespaceAware(true)` or `newNSInstance()`) | 407 (42%) | 135 (38%) | | Never call `setNamespaceAware` | 470 (49%) | 163 (46%) | Explicitly non-namespace-aware parsing is niche. Most of the explicit `false` calls just restate defaults next to `setValidating(false)`. Only a handful depend on it (qName-based handlers, DTD-validated documents), and those usually configure other settings too, so they need the factory anyway. A non-namespace-aware helper would also not be portable as a plain `newSAXParser()`. On Android, a `SAXParserFactory` whose namespace awareness was never set produces namespace-aware parsers (`ExpatReader` processes namespaces by default). So the helper would have to call `setNamespaceAware(false)` explicitly, and its name would have to say so (`newNonNS*`). Given how rare the deliberate use is, this PR leaves the non-namespace-aware variants out. Adding them later is backward compatible, so we can introduce them if there is demand. **`newNSXMLReader()` and `newNSXMLReader(ContentHandler)`** Of the 148 `SAXParser.getXMLReader()` sites where the parser is created just for the reader, from a factory these helpers could replace, 57 (39%) immediately register a `ContentHandler` on the reader. The rest wrap the reader in a `SAXSource` or an `XMLFilter`, return it, hand it to a library (dom4j, Digester, ...), or parse without a handler. Hence both overloads. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
