Re: Another take on versioning

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

Still in the exploring alternatives mode -- the fact is that almost
all new steps will be 'vanilla': with primary in and primary out.
Further to my previous speculations, do any of the following
alternatives seem potentially viable:

 1) Assume any unknown step is vanilla, i.e. has primary
    sequence='true' input and output ports;

 2) Add a backwardsCompatible attribute which is allowed on any
    container or step, which if 'true' means the step is vanilla, and
      a) Default it to 'true';
     or
      b) Default it to 'false'.

Whether we still require a version attribute, and only do (1) or (2)
in 'forward-compatible' mode, is a separate question.

What does backwardCompatible='false' mean?  I think the simplest (but
least flexible) interpretation is draconian, i.e. it makes the version
indicator whose scope it's in a requirement, not just advice.

I sort of like version indicator, (2a) and the draconian
interpretation -- it means that if people ship pipelines with Vnext
steps in them and a Vnext declaration and nothing more are making a
"no harm will come from running this on a Vlast implementation"
commitment.  But we give authors the wherewithall to _easily_ say
"you _can't_ run this without a Vnext processor".

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)

iD8DBQFK1F60kjnJixAXWBoRAoCyAJ4z82TBBgOoQo2k75aszKHNvCCrawCdFX3g
o1x2Lw0adqBcNxLjmOwWsmA=
=x6g8
-----END PGP SIGNATURE-----

Received on Tuesday, 13 October 2009 11:04:50 UTC