The conclusion on the original proposal was that it was hard to read (from a human perspective) and had the problem of moving some of the logic to the attribute values (which from an implementation point of view, and for validation purposes, is a problem).
This proposal is more verbose, but also more readable. > ['all', ['type', 'all', ['book']], ['variable', 'nand', ['edition']]] Only programmers can parse that ;-) > This is the information I need to process the conditions – I personally think > that using 4 XML nodes to describe this list makes testing a nightmare. It's again a trade-off between being friendly/readable to style implementors, and being friendly to the processors. Though I am not sure where the nightmare comes from in this case. Did you mean it's harder to build test cases? In which way? Charles On May 13, 2013, at 10:40 AM, Sylvester Keil <[email protected]> wrote: > > On May 13, 2013, at 9:50 AM, Charles Parnot wrote: > >> 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, you're right, if we still want to encourage its use that's a > compelling reason to keep the old way around, of course. (I wanted to make > the case firmly against keeping old features around just for the sake of > compatibility.) > > But if this is the case, it gives me even more reason to believe that the > original proposal was actually the better one – if only a handful of styles > need the advanced syntax anyway it seems much more reasonable to me for it to > be an extension of the normal syntax rather than a completely different one. > Especially since you decided to lose the 'not:' in favour of 'nand' matchers > anyway. > > Do we really want to add two new elements for an alternate syntax when most > styles use attributes on cs:if anyway? > > Thinking about how to implement this, my best approach was to simply convert > the new conditions to the lists which can be used with the original/extended > rendering algorithm. But this just tells me that all we're accomplishing here > is introducing a bloated XML syntax to describe simple lists. > > Looking at the example: > > <choose> > <if> > <conditions match="all"> > <condition type="book"/> > <condition variable="edition" match="nand"/> > </conditions> > <text macro="some-text-macro"/> > </if> > </choose> > > > What I would do here, in order to evaluate the statement is translate the > conditions to something that can be reduced efficiently. Something like this: > > ['all', ['type', 'all', ['book']], ['variable', 'nand', ['edition']]] > > This is the information I need to process the conditions – I personally think > that using 4 XML nodes to describe this list makes testing a nightmare. > > Also, think of the headaches you're creating for tools that create styles > like the style editor: if you have a condition in the 'old' way and you > change a little detail – does it stay in the old way or is it converted? If > you try to keep it in the old way then once you add a feature that can't be > expressed in the old way you need to convert everything etc. – or if tools > cannot handle this sort of thing, as a style author you're forced to convert > all conditions to the new syntax if you want to add something that was not > supported previously. With the original approach you can always add new > conditions without having to change the old ones. > > Sylvester > > > >> 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 > > > ------------------------------------------------------------------------------ > 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
