Saxon

Hi Martin,

I believe the idea is that you create a new SchemaManager for each set
of schemas that you want to use for validation. Individual XSD files
describe a set of schema components which, taken together, are the model
against which validation is done.

How would an XML editor like oXygen that does on the fly validation while the user might
be editing/changing schemas work? Does it have to create a new Processor to work with a
clear/new SchemaManager?

You don’t have to create a new Processor, just a new SchemaManager.

SchemaManagers are tied to a particular processor, I expect, because of
interactions with the name pool and the available types, etc.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

I missed that the Java API has a public constructor for SchemaManager https://www.saxonica.com/html/documentation11/javadoc/net/sf/saxon/s9api/SchemaManager.html#SchemaManager-- but for .NET https://www.saxonica.com/html/documentation11/dotnetdoc/Saxon/Api/SchemaManager.html at least the API documentation doesn't show a public constructor so I wonder how your suggestion would work with .NET.

Need to dig more in the API documentation and write some sample code.

Sorry, Norm, that was the idea when the API was designed but it was never fully implemented. The original idea was that each SchemaManager would be able to manage a separate pool of schema components, but currently there's only one such pool held at Processor/Configuration level, and you can add to it but you can't remove anything,

It wouldn't actually be too difficult to allow multiple schemas in a configuration for document validation purposes, but the problem comes when the nodes in the validated documents have type annotations that refer to a particular schema type, we would need to move to two-part identifiers where the type annotation identifies both a schema and a type within that schema, and that starts to get complex.

Sorry, Norm, that was the idea when the API was designed but it was never fully
implemented. The original idea was that each SchemaManager would be able to manage a
separate pool of schema components, but currently there's only one such pool held at
Processor/Configuration level, and you can add to it but you can't
remove anything,

Interesting. That’s going to be problematic in a context like XProc
where there’s a single processor for the entire pipeline. I’m sure
there’s an example pipeline somewhere that forks on the basis of a
version attribute and validates with either the V1 schema or the V2
schema. Sounds like that’s just going to fail.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica