When you put it this way, I agree "backward-compatibility" is more of a trick than a real thing.
However, it got me thinking: do we want to get rid of the "old" syntax, where the predicates are in the `<if>` element? I would think no, we want to keep them. This is still the shortest and most readble way to write conditionals in most cases. So maybe in this case, we are in fact truly backward-compatible :-) Charles On May 13, 2013, at 9:11 AM, Sylvester Keil <[email protected]> wrote: > > 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 -- Charles Parnot [email protected] twitter: @cparnot http://mekentosj.com ------------------------------------------------------------------------------ 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
