OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Validation - Is it worth it ?

[ Lists Home | Date Index | Thread Index ]

Fraser Goffin wrote:

>> Not many systems meet those criteria.
>
>
> Agreed (as stated).
>
> But the conundrum (if there is one) can also be viewed as :-
>
> a. I want to exercise [some] control over messages that arrive at the 
> service interface so that I have a reasonable degree of confidence 
> that the message is 'business processable' and that (as you say) there 
> is confidence that exploitation of the service will be caught by the 
> business rules that provide the actual implementation.
>
> b. I want consumers to call my service (I want to do business)
>
> c. I want to minimise message rejection where (a) is true.
>
> d. I want calling my service to be EASY for consumers (re: Tim Ewald's 
> notion of 'make it easy for people to pay you ' :-).
>
> e. That the service is not just a slave to a technical contract which 
> is actually expressed more strictly than the actual business process.
>
> Sometimes I think about this as the difference between 'compatible' 
> messages versus those which strictly adhere to a technical 
> specification. Perhaps its really to do with how closely that 
> specification mirrors the business requirements for the service that 
> 'we' want to implement (given, as I said in my original post, that the 
> contract is owned by an external body) ?

I think the issue of whether an accepting system should be liberal in 
what it accepts needs to be counterbalanced against the dangers of 
encouraging public exchange of documents that advertise that they belong 
to a standard document type, yet don't follow the minimum rules for that 
type.  Standards get their benefit from reach; incomplete subsets that 
are OK with you but which may omit information needed by others ruins 
this reach; too many local 'optimisations' cause global non-optimality.

It is just a question of expectations: the documentation for your 
interface just needs to say  "we accept any documents that accord to the 
standard schema, however we only use information according to this 
lesser schema" (where the lesser schema is the standard schema with 
everything you don't require made optional).

Another choice, when you have private exchange but want to use standard 
schemas as much as possible but you don't want extraneous fluff, is to 
have your own top-level elements, which then include whichever bits of 
the standard schema as needed. That is good markup practise: it makes it 
clear what is standard and what is non-standard. You might even have the 
same names but different namespace.

E.g. if the original schema requires

<standard:person>
 <standard:name>...
 <standard:address>...
 <standard:shoe-size>...
</standard:person>

and you don't want the required shoe-size, use

<my:person>
 <standard:name>...
 <standard:address>...
</my:person>

[PRODUCT PLACEMENT]  You might like to look at Topologi's Interceptor 
product at
www.topologi.com.  This is a proxy servlet that intercepts incoming POX 
data and tests, validates and dispatches the documents. In your case, 
for example, you could have Schematron validation of your busines 
requirements, but as a nice clean layer from the processing servelet.

Cheers
Rick Jelliffe




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS