[jira] [Updated] (DAFFODIL-2535) Deprecate XML Catalog Feature

["Mike Beckerle (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Beckerle updated DAFFODIL-2535:
------------------------------------
    Description: 
Quiet consensus discussion on dev list is that we should deprecate support for XML Catalogs for the reasons below (taken from email thread)
 
XML Catalogs seem 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 or 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, XML Catalogs can be deprecated. 
 

  was:
Quiet consensus discussion on dev list is that we should deprecate support for XML Catalogs for the reasons below (taken from email thread)
 
XML Catalogs seem 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, XML Catalogs can be demonstrated. 
 


> Deprecate XML Catalog Feature
> -----------------------------
>
>                 Key: DAFFODIL-2535
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2535
>             Project: Daffodil
>          Issue Type: Improvement
>          Components: Front End
>    Affects Versions: 3.1.0
>            Reporter: Mike Beckerle
>            Priority: Major
>
> Quiet consensus discussion on dev list is that we should deprecate support for XML Catalogs for the reasons below (taken from email thread)
>  
> XML Catalogs seem 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 or 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, XML Catalogs can be deprecated. 
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)