[
Lists Home |
Date Index |
Thread Index
]
The schema is the expression of the context as understood
by the schema author. The awareness is in the schema
author. It is the instance that is variant. The schema
author either does or does not have a contract with the
schema user, and even if they do, that contract might
change and either they renegotiate or they don't. If
they don't, the instance will fail because it expressed
a different context. The schema works and can be quite
detailed, it caught the errors from its context viewpoint.
Now it comes down to the authority to determine which is
wrong. Some say the instance is always right. If that
were true, I wouldn't need a schema. If the schema
is always right, then contexts don't ever change. That
usually isn't true either. Is the context view of
the schema too large (the boundary)? That is a major
mistake found in lots of schema design (Dare to do less).
Now, why is the dynamic assembly approach better as
a means to handling just-in-time context instantiation
over writing smaller schemas? Because once again,
we may not capture all the exceptions. So what? At
some level of detail, exceptions really are errors.
What if the business rules are improperly understood?
I see examples of this every day.
Again, not means, but the objective (that is, CAM is a
means, application blocks are a means, ASP pages are a
means)? We all sell systems so we tend to get very
happy to explain the means. To choose among means,
we have to define a fundamental objective and that
is why I keep bringing up value-focused thinking.
<forRoger>
This problem overlaps the challenges of specification
and standards writing. We don't know what we know
until we know it and can't prove we know it until
we test it and prove the test confirms what we know.
Circular indeed but a spiral is what we want. The
pattern we often see is two overlapping spirals
going in opposite directions, a classic Koch fractal
with a limited space but an infinite curve.
</forRoger>
len
From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
Bullard, Claude L (Len) <len.bullard@intergraph.com> writes:
> Aha. I think the schema is precisely context aware but
> it cannot change the context it can be aware of.
Hmm, yes, no, maybe? Perhaps the writer of the schema is aware of the
context for which they intend the schema to be applicable. Certainly,
the schema defines validity for some context. But is that awareness of
(any) context? It seems to me that awareness of context implies a means
to acknowledge when the schema at hand does not apply?
> As I
> said to David, it can tell that something is a thing
> but not the thing. It can express the intention in
> some detail but it cannot change the intention.
>
> In short, it is not a dynamic assembly mechanism
> because it is not dynamic.
>
> It is a means to determine the fit of the instance
> to the expectation of the receiver. It cannot
> know that expectation which is why it is referred
> to as a contract. If used transactionally, it
> requires a priori negotiation.
Yes, the context is fixed before hand; therefore, the schema itself is
not context aware; no dynamics means no awareness (circular reasoning
rules).
>
> From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
>
> Wasn't aware that was the objective (local context predominates)...
>
> However, I think we have a partial answer: schema have no
> built in mechanism for context awareness or context resolution.
>
>
|
