Re: XML Catalogs feature - should we deprecate it

[Steve Lawrence]

I missed this email so I'm a little late, but +1 to deprecating XML
catalogs.

On 6/4/21 6:48 PM, Beckerle, Mike wrote:
> 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
> 
> mbecke...@owlcyberdefense.com 
> 
> P +1-781-330-0412
> 

XML Catalogs feature - should we deprecate it

[Beckerle, Mike]

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

P +1-781-330-0412