A Saxon Configuration can only hold one Schema (that is, a set of schema components, with no inconsistencies or naming conflicts between them).

If you want to handle multiple schemas (that cannot be merged into one under these rules) then you will need to use multiple Saxon Configurations. This may or may not be a problem depending on what you are trying to do.

Michael Kay
+44 (0118) 946 5893

On 17 Jun 2014, at 18:11, Scott Bailey (IT) <Scott.Bailey2@albertahealthservices.ca> wrote:

We recently acquired some enterprise licenses for Saxon and I am attempting to incorporate the saxon enterprise jar into my project code.  I am currently using the jaxp api for both validation and transformation and I have encountered an issue with the schema factory and generating a Schema object which is specific to using saxon EE. I've also tested with just the saxon HE as well as Xerces, and the problem does not exist.  The problem I have is that some of the schema file will not generate a new Schema object and the exception message is "Duplicated components found in schema".
The code I have to instantiate my factories is:

try {

  Source saxonSource = new StreamSource(new File(gtvsConfig.getSaxonConfig()));

  saxonConfig = (EnterpriseConfiguration) Configuration.readConfiguration(saxonSource);

  if (logger.isDebugEnabled()) {

    logger.debug("Using Saxon configuration file: "+gtvsConfig.getSaxonConfig());


} catch (XPathException e) {

  logger.warn("GTVS: Failed to load the specified Saxon configuration, using a default configuration.");

  saxonConfig = (EnterpriseConfiguration) Configuration.newConfiguration();


transformFactory = new com.saxonica.config.EnterpriseTransformerFactory(saxonConfig);

schemaFactory = new com.saxonica.jaxp.SchemaFactoryImpl(saxonConfig);


later on I iterate over a list of sources (StreamSource) and to create a Schema object for those sources I use:

Schema aSchema = schemaFactory.newSchema(source);


and cache the Schema object for later use.  Essentially I am creating a cache in a Singleton during the start up of my web app.  When required, other components will access the singleton and obtain the Schema object which is then applied to a message.  The error occurs when generating the Schema object, so it happens up front.


A bit of background on the schema files.  We are performing system integration in the healthcare space.  We have multiple groups who are providing versioned packages of resource files all of whom use the HL7 v3 schema files.  Since these packages are owned by the external groups we do not modify them and since these groups are independent when they provide a package the provide all of it, thus there is a lot of overlap between versions a group provides as well as between groups.  To keep everything straight we put a package into its own directory structure.  The HL7 schema files perform copious xs:include actions all of which are issued with relative path names.


package1/schema/hl7/hl7file1 --> includes hl7file2


package1/schema/custfile3 --> includes hl7file1


package2/schema/hl7/hl7file1 --> includes hl7file2


package2/schema/custfile4 --> includes hl7file1


The files from package1 compile just fine on their own, just like the files from package2 compile just fine on their own, but when compiled together the second file to compile doesn't compile and generates the duplicate exception noted previously.


If I understand the saxon EE it generates a Processor with a Configuration and a SchemaManager whether I am using the s9api or jaxp.  I also understand that the SchemaManager is creating its own cache (which is not done in saxon HE).  I suspect that this at the root of what is generating the exception, would that be correct?  How does one deal with this collision using saxon?

Scott Bailey
pHIE Development Team
Alberta Health Services
mobile: 403.710.1677

This message and any attached documents are only for the use of the intended recipient(s), are confidential and may contain privileged information. Any unauthorized review, use, retransmission, or other disclosure is strictly prohibited. If you have received this message in error, please notify the sender immediately, and then delete the original message. Thank you.
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
saxon-help mailing list archived at http://saxon.markmail.org/