Re: Customer requirement, a critque

Am 25.02.2013 um 07:52 schrieb Arved Sandstrom <asandstrom2@eastlink.ca>:


>>>>> 6. Is this a corner case Tony? I don't know. I can see the use where
>>>>> 'which page this block goes on'
>>>>> does not matter. IMHO your example is too specific?
>> It is unusual, yes, and not at all easy either declaratively or through an
>> API, or so it seems to me.  However, customers don't always come with
>> problems that have nice, easy solutions, nor do they couch things in
>> XSL-FO terms.


> Viewed through another lens it's not unusual at all, it's a filter. It's a formatting-time conditional with an 'else' or 'otherwise' that describes multiple processing strategies on the items of a list. I've seen this described as relevance filtering in reporting and BI, but hey, it's ultimately just filtering.
> 
> Maybe I'm missing something, but I can see how this would actually be easy to describe declaratively (where XML-based FO or under programmatic control in an API).

I agree that this would be easy do describe declaratively. My point is though that while you can implement declarative solutions to problems a, b, c, d, ..., other customers come up with problems α, β, γ and so on that are not yet built into the formatter. Thus it is of no great value to try to make an exhaustive list of problems (+spec +implementations), because we will never be able to do that.

While I certainly agree that solving 100% of all customer requirements is not feasible, we should strive for at least 90%. (And not "90% of the problems we thought about".) Hence my approach with formatter feedback + programming language = building blocks to solve 99% of the requirements.


Regards

   Patrick


Patrick Gundlach
speedata
Berlin, Germany
+49 30 57705055
http://speedata.github.com/publisher/

Received on Monday, 25 February 2013 08:20:15 UTC