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
