Re: Customer requirement, a critque

On 02/25/2013 04:19 AM, Patrick Gundlach wrote:
> 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/
>
>
>
>
Errr, I was actually arguing for making your approach a possibility, 
Patrick, hence my continued mention of a formatter API. This would not 
be restricted to specific problems at all.

I may have confused the issue by suggesting that if FO itself was 
enhanced to include some feedback constructs, that if such a formatter 
API were in place (and implemented by a formatter) that those FOs could  
be internally handled the same way as if they had been scripted 
externally. I agree that if we specifically solve problems a, b, c d, 
..., then all we've done is solve problems a, b, c, d, ...

AHS

Received on Friday, 8 March 2013 01:23:42 UTC