Re: Another take on versioning

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

Norman Walsh writes:

> The way that XSLT *isn't* parallel is in the requirement to build a
> dependency graph.

[Still hoping for a low-overhead solution]  So let me go back and look
at your message about _that_. . .

> The most troubling part of this approach is the way in which "invalid"
> has to percolate through the pipeline and be taken into consideration
> in different places:

So, how can we avoid percolating at all. . .

>   1. When evaluting if all of the branches of a p:choose have the same
>      signature, ignore any branch that directly contains an invalid
>      step. If all the branches are invalid, then the p:choose is
>      invalid.

Counterproposal -- assume any branch with an invalid produces a
sequence.

>   2. When evaluating if the p:try/p:group and p:catch branches of
>      a p:try have the same signature, ignore either clause if it
>      contains an invalid step. If the p:catch includes an invalid
>      step, then the p:try is invalid.

Ditto.

>   3. If a subpipeline contains an unrecognized step (not in a p:choose
>      or p:try/p:group), then that subpipeline has to be marked
>      invalid.

What happens if you don't?

> If you don't do this, then I don't think it's possible to build the
> dependency graph.

How about this, by analogy with another of Jeni's proposals, namely
that we rule out adding primary ports to XProc steps (actually, I
guess that was my proposal: we promise to make only benign changes,
and benign changes are adding optional options and non-primary ports):

We could mandate that any unrecognised xp:step be treated as if it had
no primary ports.  Or, perhaps better, we mandate that it be treated
as if it had a an un-named sequence=true primary input port' and an
unnamed primary sequence=true output port called 'result'.

Either way, the dependency graph computation doesn't have to change at
all.

I'm left feeling that getting rid of requiring the declarations is
what's causing all this trouble.  Let's weigh up two alternative bad
scenarios:

 Scenario 1, with today's design: Jeni points out that having one
 pipeline import the V1 declarations and a library, which in turn
 imports the v2 declarations, will cause a static error (conflicting
 definitions).  Actually of course _that_ won't ever happen, because
 no-one will ever explicitly import the v1 library -- they don't need
 to.

 So Scenario 1 will only arise when we publish v3 . . .

 Scenario 2, with the proposed version-identifier-based design: Any
 pipeline using _new_ steps from v2, and hence marked with the v2
 version identifier, causes problems for dependency calculations, or
 requires some kind of funny defaulting (i.e. what I explored above).

So, seems to me the cost of Scenario 2 is much higher than the cost of
scenario 1.

And here's a way to reduce the cost of Scenario 1:  

  1) Lexically scope the effect of importing XS version libraries.
     
  2) Optionally get rid of xs0050 (multiple imports of xproc version
     libraries not allowed).  We either commit to a single line of new
     version libraries, and specify that in case of multiple imports
     in a single scope the most up-to-date is used, or just specify
     some arbitrary tie-break.

  3) Extend the definition of allowed changes (section 2.13) to
     include adding non-primary ports.

ht
- -- 
       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)

iD8DBQFK06DEkjnJixAXWBoRAmMxAJ4uTB0Xk/fc+t9KP4gr0WyffODeeACggp8v
i90gpTixNzO7NN8xIcYLA3k=
=RvoF
-----END PGP SIGNATURE-----

Received on Monday, 12 October 2009 21:34:27 UTC