stevedlawrence commented on pull request #560: URL: https://github.com/apache/daffodil/pull/560#issuecomment-847015817
There was a comment I found in an email but can't currently find it in github, whree @mbeckerle said: > Gone. However, I would say, that this pluggable XML readers stuff feels like stuff of a bygone era when everyone thought there would be competition around XML libraries, and pluggable XML technologies from vendors, etc. This seems silly in retrospect. But maybe it is needed for backward bug-for-bug compatibility in some cases. > >For us, I don't think pluggable XMLReader makes any sense. We're far too sensitive to exactly their characteristics. > > think we should explicitly check for the exact XMLReader classes we support, and error if it isn't that. > >Thoughts on this check? I'm wondering if we should just be explicitly creating the XML Reader that we are expecting? As you said, we depend on very specific behavior from a specif XMLReader, so using something like ``SAXParserFactory.newInstance().newSAXParser().getXMLReader`` to get some XMLReader seems like a mistake. I'm wondering if there's a way to directly create a Xerces XMLReader. Maybe we should use the overloaded newInstance function that takes a class name? Or maybe we can directly create the right class ourselves, and avoid this pluggable logic? Then we really can assume that we have a certain XMLReader. Would it then even be possible to have a daffodil-lib function that gets the things XMLReader stuff we need and set the secure defaults, so there's only one place we need to call setSecureDefaults, with the assumptino that everything gets the XMLReader from our new daffodil-lib function? -- 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. For queries about this service, please contact Infrastructure at: [email protected]
