SYNOPSIS

 # for internal use only
 my $code = XML::Compile::Translate->compile(...);

DESCRIPTION

This module converts a schema type definition into a code reference which can be used to interpret a schema. The sole public function in this package is compile(), and is called by XML::Compile::Schema::compile(), which does a lot of set-ups. Please do not try to use this package directly!

The code in this package interprets schemas; it understands, for instance, how complexType definitions work. Then, when the schema syntax is decoded, it will knot the pieces together into one CODE reference which can be used in the main user program.

Unsupported features

This implementation is work in progress, but by far most structures in W3C schemas are implemented (and tested!).

Missing are

 schema noNamespaceSchemaLocation
 any ##local
 anyAttribute ##local

Some things do not work in schemas anyway: import, include. They only work if everyone always has a working connection to internet. You have to require them manually. Include also does work, because it does not use namespaces. (see XML::Compile::Schema::importDefinitions())

Ignored, because not for our purpose is the search optimization information: key, unique, keyref, selector, field, and de schema documentation: notation, annotation. Compile the schema schema itself to interpret the message if you need them.

A few nuts are still to crack:

 openContent
 facets on dates and base64Binary
 final is not protected

Of course, the latter list is all fixed in next release ;-) See chapter DETAILS for more on how the tune the translator.

DETAILS

Translator options

performance optimization

The XML::Compile::Schema::compile() method (and wrappers) defines a set options to improve performance or usability. These options are translated into the executed code: compile time, not run-time!

The following options with their implications:

qualified XML

The produced XML may not use the name-spaces as defined by the schemas, just to simplify the input and output. The structural definition of the schemas is still in-tact, but name-space collission may appear.

Per schema, it can be specified whether the elements and attributes defined in-there need to be used qualified (with prefix) or not. This can cause horrible output when within an unqualified schema elements are used from another schema which is qualified.

The suggested solution in articles about the subject is to provide people with both a schema which is qualified as one which is not. Perl is known to be blunt in its approach: we simply define a flag which can force one of both on all schemas together, using elements_qualified and attributes_qualified. May people and applications do not understand name-spaces sufficiently, and these options may make your day!

Name-spaces

The translator does respect name-spaces, but not all senders and receivers of XML are name-space capable. Therefore, you have some options to interfere.

Wildcards handlers

Wildcards are a serious complication: the any and anyAttribute entities do not describe exactly what can be found, which seriously hinders the quality of validation and the preparation of XML::Compile. Therefore, if you use them then you need to process that parts of XML yourself. See the various backends on how to create or process these elements.

Automatic decoding is problematic: you do not know what to expect, so cannot prepare for these data-structures compile-time. However, XML::Compile::Cache offers a way out: you can declare the handlers for these "any" components and therewith be prepared for them. With XML::Compile::Cache::new(allow_undeclared), you can permit run-time compilation of the found components.