[
Lists Home |
Date Index |
Thread Index
]
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@datadirect.com]
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.
|
