[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Catalog Resolver for XSD and XSLT
- From: Michael Kay <mike@saxonica.com>
- To: Thangalin <thangalin@gmail.com>
- Date: Fri, 12 Sep 2014 00:17:05 +0100
I think you are asking about how to do this in the Java world - the answer for .NET might be quite different.
Frankly, JAXP is very disjointed for this kind of thing: it's a collection of separate APIs for different tasks, with little thought about how they might be combined.
With the Saxon API you can do the schema validation as you parse the document on its way into the transformation. Using s9api it's essentially:
Processor p = new Processor();
XsltExecutable exec = p.newXsltCompiler().compile(stylesheet);
XsltTransformer t = exec.load();
t.setSchemaValidationMode(ValidationMode.STRICT);
t.transform(source, destination);
No mention here of a catalog resolver, but you can use one if you want.
Michael Kay
Saxonica
mike@saxonica.com
+44 (0) 118 946 5893
On 11 Sep 2014, at 23:50, Thangalin <thangalin@gmail.com> wrote:
> Hi,
>
> What is the canonical way to validate XML files (loaded using
> JAXP/DOM) against an XSD then subsequently transform them using an XSL
> template having file paths determined from a catalog resolver? See
> this SO question for details:
> http://stackoverflow.com/q/25698764/59087
>
> The posted answer works (http://stackoverflow.com/a/25698765/59087),
> but has undesirable traits, such as:
>
> * Using an XMLCatalogResolver and a CatalogResolver.
> * Creating an XML catalog resolver instance using the catalog resolver instance.
> * Traversing a DOM to determine the XSD URI.
> * Creating a SchemaFactory to perform the validation.
> * Calling the XML catalog resolver instance to find the local XSD file path.
> * Passing the catalog resolver instance to the XSL transformer instance.
>
> It seems like those aspects of the code should be handled by existing
> APIs, especially the contortions required to extract the XSD URI from
> the DOM. Contortions such as parsing processing instruction attributes
> or extracting the schemaLocation, depending.
>
> The project: https://bitbucket.org/djarvis/validating-catalog-resolver/
>
> The offending code:
> https://bitbucket.org/djarvis/validating-catalog-resolver/raw/master/src/TestXSD.java
>
> The most problematic parts of the code are the:
>
> * getSchemaURI method; and
> * if( schemaURI != null ) { ... } code block.
>
> I think that they are redundant, but do not know what mechanisms are
> available to avoid having to manually parse and validate against an
> XSD whose file path is looked up using an XML catalog. Ideally, the
> XML file would only have to be parsed once. I'd like to avoid using
> the SAX2DOM class, if possible.
>
> The code works, but there must be a better way.
>
> How can parsing the processing instruction and manually calling a
> SchemaFactory for validation of the DOM be eliminated?
>
> How can using both XMLCatalogResolver and CatalogResolver be avoided
> (e.g., is an LSResourceResolver required)?
>
> Any other comments, critiques, and corrections are most welcome.
>
> Thank you.
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]