Project

Profile

Help

For schema based validation, if I want a clear/new SchemaManager, do I need to create a new Processor?

Added by Martin Honnen over 1 year ago

Most of my uses of Saxon from the s9api (be it with Java or CS) targeted XPath or XQuery or XSLT (and usually not schema-aware) so I think it was always adequate and sufficient to have a singleton Processor created once and create any XsltCompiler or XPathCompiler or XQueryCompiler or DocumentBuilder of that singleton Processor.

Now I am experimenting with schema based validation and Saxon EE/SaxonCS and I wonder whether that concept/approach holds up: as the SchemaManager seems to be tied to the Processor and there doesn't seem to a way to clear the schema cache or reset it, what happens if a user of my code with a singleton processor e.g. first tries to validate some instance document against version 1 of a schema for a certain target namespace and then wants to try whether an instance document is also valid against version 2 of a schema for the same target namespace? Will trying to compile a second schema with the same target namespace as an existing one in the SchemaManager give an error?

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?


Replies (4)

Please register to reply

For schema based validation, if I want a clear/new SchemaManager, do I need to create a new Processor? - Added by Norm Tovey-Walsh over 1 year ago

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

RE: For schema based validation, if I want a clear/new SchemaManager, do I need to create a new Processor? - Added by Martin Honnen over 1 year ago

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.

RE: For schema based validation, if I want a clear/new SchemaManager, do I need to create a new Processor? - Added by Michael Kay over 1 year ago

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.

RE: For schema based validation, if I want a clear/new SchemaManager, do I need to create a new Processor? - Added by Norm Tovey-Walsh over 1 year ago

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

    (1-4/4)

    Please register to reply