Re: [xml-dev] reasons why an XML instance must be validated witha XML sc

[Steve Newcomb <srn@coolheads.com>]

Philippe is precisely correct.  But I would put it more pungently: When 
information interchange fails, the finger of blame must be pointable.  
If information interchange has already failed, then if the XML is 
consistent with its schema, maybe the problem is on the recipient's 
side.  If the XML is not OK, then probably there's at least one problem 
on the sender's side.

It's usually best to *avoid* information interchange failures, and 
that's another good reason to validate outgoing XML instances.  Before 
sending the XML instance, the producer process can check whether, if 
information interchange later fails, the parser will point the finger of 
blame at the producer.  It's a quality-control measure for people who 
prefer to avoid situations in which their work is subject to objective 
criticism.  (And that's just about everybody, I guess.)

As far as I know, there's no other reason for validation than pointing 
the finger of blame.  If all information interchange failures can be 
detected and diagnosed in other ways, then there's no need for XML 
validation.  

If you work in the real world, where failures of information interchange 
sometimes occur, XML validation is normally one of the least expensive 
and most powerful ways to detect, diagnose and prevent information 
interchange failures.   (It can't detect every cause of information 
interchange failure, of course.)

Philippe Poulard wrote:
> ilango a écrit :
>> If so, why should we use XML schema to validate XML?
>
> An XML Schema is the expression of some constraints expected on an XML 
> document class. Expressing constraints on XML documents ensure that 
> applications will process them without causing faults. Expressing 
> constraints with schemata ensure that applications developers will 
> spend most of their time in designing data process and few of their 
> time in controlling them.
>