W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > October 2009

Re: Another take on versioning

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Tue, 13 Oct 2009 12:04:20 +0100
To: public-xml-processing-model-comments@w3.org
Message-ID: <f5b63ajv9l7.fsf@hildegard.inf.ed.ac.uk>
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';
      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".

- -- 
       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]
Version: GnuPG v1.2.6 (GNU/Linux)

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:27 UTC