I spent quite a bit of time this week trying to get 2 DFDL schemas using XML Catalogs to work.
I succeeded, but I find XML Catalogs very fragile, with important aspects that don't work (I was unable to get relative-catalogs to work at all) and I am wondering if we really need to support XML Catalogs not. Our classpath based resolution of schema locations works quite well and can be used to make quite modular DFDL schemas. Currently, XML schemas built into Daffodil (e.g., tdml.xsd, the schema for DFDL schemas, etc.) are resolved from a built-in XML catalog, but really the fact that this is using a catalog is not particularly important. You can think of it as they're just built into our resolver. XML Schemas referenced using the schemaLocation attribute on an xs:import/xs:include or the xsi:schemaLocation on XML instance documents are resolved by either: 1) relative to the file containing the reference, i.e., the file containing the include/import statement 2) relative to the root of any directory or jar on the classpath, searching them in classpath order. First one found wins. This enables one to create multi-part DFDL schemas, such as for an envelope format, and a payload format carried inside the envelope format. Each can be testable separately, and a combining schema can be created that puts the payload on the classpath first, followed by the envelope format, and combines the two. Given that this works, and works well, I am wondering if we should just deprecate the XML catalog feature. Thoughts? Mike Beckerle | Principal Engineer [cid:000f208e-56f7-4520-ae10-2256125e4e50] mbecke...@owlcyberdefense.com<mailto:bhum...@owlcyberdefense.com> P +1-781-330-0412
