Dev team,
This has come up so many times now. In Daffodil, in Internal owl tools like XSAT2, now in the DFDL coverage tool. Frankly anything that processes XML Schemas hits this or other limitations of this library. I think we really should fix this the right way. So it all boils down to two things: 1. Add a feature - Modify Xerces so that w3c DOM tree nodes, if downcast to an Impl class or interface, have the location information populated and available. 2. Adding enabling of this feature to ws-schema to access to the underlying DOM object – which would provide access to the location info, as well as solve all the other limitations mentioned in our Daffodil coding style wiki article which mentions a number of shortcomings in ws-schema, not just file/line info. This should be dead-simple. It just needs to invoke Xerces DOM parser with the new feature option turned on. This all needs to be optional (default off) since it adds to memory use and could slow things down marginally. This would make it possible to eventually strip all the XSD traversal logic hacking out of Daffodil and have it use ws-schema as the way to access the XSD-flavor of DFDL, paving the way for alternate non-XSD syntax variants to fit into the design also, which is a priority feature for DFDL v2.0 and all the XML-haters in the world. I forked xerces-j to start investigating this. I already have a fork of ws-schema. Collaborators are welcome. ChatGPT is quite helpful at explaining things about how Xerces J works – e.g, how to add a new feature flag that works the way the other feature flags work.
