[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Fallacies of Validation, version #2

• To: "Roger L. Costello" <costello@m...>
• Subject: RE: Fallacies of Validation, version #2
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Thu, 26 Aug 2004 12:39:55 -0500
• Cc: xml-dev@l...

Right.  And if the expectation of the contract is 
violated, a flag goes up and is sent to whoever has 
subscribed to that event type.  That is where the 
OLAP part of the thread leads.  You don't have 
to have OLAP to do this; we do it routinely with 
relational systems but as the complexity of the 
relationships goes up, the utility multidimensional 
indexing does as well.  

Aka, event-driven intelligence: a flag is raised 
given recognition of a pattern/error/trend and 
the system sends a subscriber(s) a message.

Schemas are good at the boundaries.  The part you 
left out was the bit about messaging.  (In a genetic 
model, versions or alleles.)  As a control or filter, 
it can raise events, aka, validation errors.  If 
you like, the model of selection based on fitness 
or other criteria can be used to direct the evolution 
of the system based on feedback in the form of 
messages.  That is what business intelligence 
systems do.  That is the essence of self-aware 
systems.  They modify the environment or themselves 
to achieve a goal, but moreover, they know how 
to pick the events to which they subscribe to 
enable them to know how, when and what to modify. 
The critical skill is imagination.

Jonathan's point is correct.  These are design 
assumptions not fallacies.  They are fallacies 
when their counterpoints are assumed to hold 
universally.  Again, knowing when to tighten 
or relax a constraint is what engineers are paid 
to know and refigure.

Don't get hung up in the models.  A schema knows 
how to do one thing: tell you if the message 
conforms or doesn't to its expectations.  Where 
and when you use this in a system or system of 
systems is entirely up to you.  XML Doesn't Care.
It isn't and can't be imaginative.  That's a process, 
and by the way, it isn't a rule.  It's jhana.

len

-----Original Message-----
From: Jonathan Robie [mailto:jonathan.robie@d...]

I think these are assumptions, rather than fallacies, and there are 
environments in which they hold.

Schemas are often used to create a contract between the producer and 
consumer of data. You promise me that the information you send me will 
fulfill the criteria expressed in the schema, and I have the right to 
reject data that does not meet these criteria. That's a common and 
legitimate use of schemas.

But the schema expressed in the XML schema language is often not the 
entire contract; there may be several contracts, expressed in different 
languages, and some of these may be constraints of the application 
domain. That's why schema extensibility is so important.

Of course, as a consumer of data, I may also impose conditions that I 
don't tell the producer about, or the producer may impose conditions 
that I am not aware of. I may also choose to look at data even if it 
does not fulfil our contract. But that's not what's in the contract.

• Prev by Date: Re: Fallacies of Validation, version #2
• Next by Date: Re: are native XML databases needed?
• Previous by thread: generating xml from xsl
• Next by thread: RE: Fallacies of Validation, version #2
• Index(es):
  • Date
  • Thread