CONSTRUCTORS

  XML::Pastor::Schema::Parser->new(%fields)

CONSTRUCTOR.

The new() constructor method instantiates a new object. It is inheritable.

Any -named- fields that are passed as parameters are initialized to those values within the newly created object.

The new() method will create a model and a contextStack if it is not passed values for those fields.

.

ACCESSORS

A stack (of type XML::Pastor::Stack) that keeps track of the current context. Every time a new schema is opened for parsing (as a result of include or redefine statements), a new context is pushed on the stack.

Each context is of type XML::Pastor::Schema::Context. Basically, the context keeps track of the DOM nodes that are being processed before they are inserted into the model.

counter()

A simple integer counter that keeps track of the count that is attributed to implicit nodes (typically simple types) that need to be named. Whenever such a node needs to be named, the counter is used to generate a unique name before being incremented.

model()

The schema model (of type XML::Pastor::Schema::Model) that is currently being constructed. The model is the result of the parsing operation and it is the internal reprsentation (information set) of a series of schemas that are related to each other (via includes or similar means).

OTHER METHODS

  $model = $parser->parse(%options);

OBJECT METHOD.

This method accomplishes the major role of this module. Namely, it parses a W3C XSD schema into an internal structure called a schema model.

Example:

  my $parser = XML::Pastor::Schema::Parser->new();
  my $model  = $parser->parse(schema=>'/tmp/schemas/country.xsd');

The W3C schema, which is in XML itself, is not parsed directly. Instead, it is parsed first into a DOM tree with the help of XML::LibXML. Then, a recursive algorithm is used for constructing a schema model which is an internal structure.

For more information on the schema model produced, please refer to XML::Pastor::Schema::Model.

OPTIONS

schema

This is the file name or the URL to the W3C XSD schema file to be processed. Experimentally, it can also be a string containing schema XSD.

Be careful about the paths that are mentioned for any included schemas though. If these are relative, they will be taken realtive to the current schema being processed. In the case of a schema string, the resolution of relative paths for the included schemas is undefined.

Currently, it is also possible to pass an array reference to this parameter, in which case the schemas will be processed in order and merged to the same model for code generation. Just make sure you don't have name collisions in the schemas though.

.