Re: Another viewpoint on validation

This is good. That's exactly the kind of reasoning I was looking for. I
have a rather twisted mindset as a professional coder, and long ago lost
touch with what "regular" users of anything want or don't want, or what
they find easy or what they find difficult. Which is why i always ask. :-)

Thanks,
Arved

On 12-04-08 06:38 PM, Tony Graham wrote:
> On Tue, April 3, 2012 12:54 am, Arved Sandstrom wrote:
>> My first attempt seems not to have gone through...
>> On 12-03-31 03:23 AM, Dave Pawson wrote:
> ...
>>>>  As Tony noted, many users are interested in 'is featire X supported
>>>> by Y processor'
>> As am I. And "support" means that feature X is "validly" supported, that
>> is, according to spec. Maybe incompletely, e.g. processor Y doesn't
>> support all the properties (by spec) for a given FO, but you know that
>> the properties you can use on that FO with processor Y are correctly
>> implemented.
>>
>> This again gets back to what I'm saying. The available processors are in
>> fact all we've got and all we'll ever have, to do the real work. In the
>> case of FO or CSS the XML+XSLT combo is just phase one, producing the
>> input for the browser or the FO processor. But as users what we really
>> care about is the output of the browser or FO processor: people have
>> always cared more about what real web browsers do with
>> HTML/XHTML+JavaScript+CSS than they do in the theoretical validity of
>> the input.
>>
>> How many people actually validate their XHTML web pages before feeding
>> them to a web browser? I don't know anyone who does that. I never have,
> They do when it's an EPUB and the web browser is the one built into the
> EPUB reader.  People get a lot of mileage out of using 'epubcheck'.
>
>> and I've written thousands of web pages in dozens of web apps. So why
>> worry so much about validating XSL-FO before it feeds to an FO
>> processor? Let's just maybe concentrate on the processors as the source
>> of validity information.
> If we go back to my memory of what was said at the Prague meet-up. people
> there did want to know that their XSL-FO would work with their XSL-FO
> processor *before* they went to the time and trouble of trying to make
> pages.  It seemed to be the knowing what was and wasn't implemented by an
> implementation that vexed them, rather than the differences between what
> the spec says and what an implementation produces.
>
> And if you've already paid money for an implementation, or gone to the
> trouble of integrating a free one, then it probably doesn't matter so much
> that another implementation has a different interpretation of some
> properties or even has a different cross-section of supported properties:
> your first preference will be to work with what you have now rather than
> throw it away and buy a new processor.  And if you can find out when
> you're writing your stylesheet that the property you just used isn't
> supported by your processor, you'll feel a lot less stressed than when you
> don't know and the use of that property causes an error message from every
> page of a 100-page document.
>
> Regards,
>
>
> Tony.
>
>
>

Received on Sunday, 8 April 2012 23:39:29 UTC