On May 8, 2013, at 9:19 PM, Rintze Zelle wrote: > On Wed, May 8, 2013 at 3:06 PM, Bruce D'Arcus <[email protected]> wrote: >> I'd like to ask an orthogonal question. See below ... >> >>> As this is backward-compatible, deployment in a CSL 1.0.2 version >>> should be possible (but I have no strong opinion). >> >> Do we have a common understanding of how we define >> "backward-compatible" for CSL? >> >> Do we maybe need to make that explicit if it's not now? > > Didn't we have this discussion already when I prepared the release of CSL > 1.0.1? > >> From http://en.wikipedia.org/wiki/Backward_compatibility: "If products > designed for the new standard can receive, read, view or play older > standards or formats, then the product is said to be > backward-compatible". So for us, I would define backward-compatibility > as the ability of CSL processors written for one specific version > (e.g. "1.0.1") to process CSL styles written in an earlier CSL version > (e.g. "1.0").
I think the following are two separate things: - the spec is backwards compatible - a CSL processor is backwards compatible Note that that no matter what you write in the spec a processor can *always* opt to be backwards compatible (unless you outright forbid it) by analyzing a given style and choosing between alternative algorithms. Note also that you can *always* make new features backwards compatible in the spec by doing exactly what you propose below: explicitly specifying alternatives by saying there is a 'new' way and an 'old' way. In my opinion this should not be part of a spec – by all means, you can add a note urging implementers to also support an 'old' way, but why force them? I find this extremely disrespectful – sure, it's easy for an established implementation to switch to a new feature and keep the old one around for compatibility's sake, but think for a moment what you're saying to developers working on a new implementation (I understand that this is something to be encouraged) – essentially, to implement a feature twice, or to wrap their head around how they can reconcile two approaches into a single algorithm – precisely what the spec fails to do in the first place. If a feature differs so much that the underlying syntax changes or that new elements need to be created, I don't think it's fair to call it backwards compatible. Such a feature should go into a major release and the legacy feature should be dropped completely. By doing this you're actually *helping* implementers to provide backwards compatibility, because they can simply look at a style's version and tell whether they need to follow the 'new' or 'old' way. A new feature that can be implemented in such a way that the *same* algorithm can still render old styles – this is something I would call backwards-compatible (as far as the spec is concerned). The original proposal for the feature in question was just that by the way – I would see no problem to include it in a minor release. This is not the case with the current proposal. Sylvester > If this proposal is accepted, there would be two ways to encode > conditions in CSL styles: the "old" way, where all conditions and the > "match" attribute are loaded on cs:if's and cs:else-if's, and the > "new" way, where we use the XML structure from the current proposal. > Styles would be able to mix & match at the level of individual cs:if's > and cs:else-if's (e.g., using the "old" structure for one cs:if, and > the "new" structure for the following cs:else-if). Since we keep the > "old" structure around, CSL 1.0.1 styles will keep working. Hence the > change would be backward-compatible, hence the change would qualify > for a 1.0.2 release. > > Rintze > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
