Re: Handling Circular and Re-entrant Library Imports

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vojtech writes:

> [a question about Appendix G, Handling Circular and Re-entrant
> Library Imports]

Hmm.

That algorithm [1] is at best misleading, if not downright broken.

In step (4), it says:

       . . .

       R := union of (R,r[0])

       . . .

     If N(U,P) contains duplicates, then the same step name is
     declared in different resources (which is an error).

     . . .

     If S(U) contains any duplicates, then the same step name is
     declared in different resources (which is an error).

The first 'If...' is incoherent, since N(U,P) is a pair, so
'containing duplicates' doesn't make any sense.  I think it should
just be removed.

The second 'If...' will, however, never fire, embarassingly, because
the assignment above, being a union (and R being _set_), will by
definition merge duplicates!

Corrected version of (3) -- (5) follows:

   3. Associated with every resource URI a list of step types declared
      within and a list of the "top level" imported resource URI
      values (i.e. the base URI of the resolved resource for each
      p:import element in the library or pipeline).

      This is effectively two maps:

      D: {uri} -> {bag of step declarations}
      I: {uri} -> {set of uris}

   4. For any resource, we define a recursive map:

      N: ({uri}, {set of uris}} -> ({bag of step declarations},{set of uris})

        N(U,P) :=
           let R := D(U)
           for each k in I(U)
              if k not in P
                 P:= P + k
                 let r:= N(k,P)
                     R:= R + r[0]
                     P:= r[1]
           return (R,P)

   5. For any resource, the bag of types recursively defined therein is:

      S: {uri} -> {bag of step declarations}

        S(U) := N(U,{})[0]

      If S(U) contains any duplicates, then the same step name is
      declared in different resources (which is an error).

> The algorithm in the section "Handling Circular and Re-entrant Library
> Imports" does not seem to take into account the fact that p:declare-step
> and p:pipeline can contain import statements as well.

> Since the algorithm is primarily URI-based, the spec should probably say
> something about how to represent the nested p:declare-step/p:pipeline as
> URIs, at least conceptually.

I _think_ we said that import processing could be lazy, didn't we?
That is, only top-level imports get followed automatically -- nested
ones only get called if their embedding pipeline gets used.

Furthermore, and arguably more important, nested imports are scoped to
the pipeline which embeds them:

  "An import statement loads the specified IRI and makes any pipelines
   declared within it available to the current pipeline."

OTOH we have (in 3.2 Scoping of Names [2])

  "The scope of the names of the step types is the pipeline in which
   they are declared, including any declarations imported from
   libraries via p:import. Nested pipelines inherit the step types in
   scope for their parent."

So, I think we need to add the following to Appendix G:

  [proving harder than I thought.  I think the whole appendix needs to
   be rethought.  I'm working on it. . .]

ht

[1] http://www.w3.org/XML/XProc/docs/langspec.html#handling-imports
[2] http://www.w3.org/XML/XProc/docs/langspec.html#scoping
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFKcwMGkjnJixAXWBoRApQTAJ0flJtvQC0epqCZ5tIgnMOYeuHMKwCfSeA0
HcWJ7lXdQ8rPuzzkuX9wx3U=
=5uyK
-----END PGP SIGNATURE-----

Received on Friday, 31 July 2009 14:43:56 UTC