W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > November 2007

Circular Imports

From: Alex Milowski <alex@milowski.org>
Date: Sun, 4 Nov 2007 16:16:37 -0800
Message-ID: <28d56ece0711041616u32ab34fcld8450d155246a91a@mail.gmail.com>
To: "XProc WG" <public-xml-processing-model-wg@w3.org>

Since an importing pipeline is only allowed to use one level of imports (a
pipeline may not use an imported pipeline's imports), we have only the
issue of circularities when imports reference each other.

For example, the simplest case is:

   * pipeline A imports pipeline B
   * pipeline B imports pipeline A

A more complex case would be;

   * pipeline A imports pipeline library X
   * some pipeline within library X imports A (eventually)

and you can add any number of levels in there.  In any event, since
you've already seen A, you know its step declartion and can effectively
complete the import.

A similar situation exists for pipeline libraries except that you have a set
of pipeline names and step declarations.

I propose we add the following to handle this:

   * In section 5.10 p:import, we need to define the resolved location based
      on the 'href' attribute.  The 'href' attribute must be resolved
against the
      base URI of the p:import element.  The resulting URI is the "resolved
      location" of the import.

   * We need to clarify that imported pipelines are treated as step

   * When loading a pipeline, a processor must keep track of the resolved
      location of imports (e.g. a simple stack of URI values) and
detect circular
      imports by literal comparison of URI values as strings.  If two URI values
      differ by encoding, the processor must treat them as different imports.

   * When a circular import is detected, the processor must provide the
     same step declarations from the original, earlier import.

I think those last two bullets belong in prose in 5.10.

What this means is that in the case of a circular import, a processor
must determine the
step declarations provided by a pipeline or library before completely loading
the importing construct.  The good news is a it suffices to provide
references to
the correct step declaration (e.g. one from the earlier import) and
then, once all
parts are loaded successfully, the complete step can be determined.

That is, the step's signature is known at the start of the import  but
the step's interior isn't
until all the imports are completed.

Here's my suggested changed text for 5.10:

"The 'href' attribute is resolved against the base URI of the p:import
element to produce the resolved location of the import.  An
implementation must keep a stack of these resolved
locations along with the declarations provided by the imports.  When
the import's resolved
location is already in this stack (e.g. a circular import), the same
imported declarations must
be made available and the resolved location must not be processed
again.   A resolved location
is considered the same when the string values of the URI values are the same.

An import statement provides either the pipeline imported or all the
pipelines in a library
available to current pipeline as a step.  Any imported pipeline has an
implicit signature that
constructs an implicit step declaration consists of the inputs,
outputs, and options declared on
it.  These step declarations are associated with the resolved location
and re-used in the case
of circular imports.

It is a dynamic error...."

I believe the errors are the same.

--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language

Bertrand Russell in a footnote of Principles of Mathematics
Received on Monday, 5 November 2007 00:16:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:54 GMT