[
Lists Home |
Date Index |
Thread Index
]
An important aspect is that the immune system "learns"
and does so by mirroring binding sites, such that over
time, the binding sites of antibodies that can be
created by the lymphocytes increases given activated
bindings, but unused sites tend to die off (are
'forgotten'). One might find this analogous to
the proliferation of XML schemas/DTDs for the web
and their concentrations in neighborhoods of use.
It is the copy machine of memory at work in an
environment of near or far neighbors (distinctions
or variety vs strength of connections or relationships).
Now what is the structural levels at which one
wants to group this 'learning' aspect into controls:
o Portal
o Enterprise
o Machine
o Document
and so on. However, given XML reliance on
syntax and "doesn't care" about meaning, a
system based on XML messaging can begin as
unbounded but becomes bound over time (the
effect of attractors).
Yes, 'recognition' over 'validation'. Quite so.
Note that lymphocytes act by cloning. If an immune
system is a network, then a network might act by
cloning 'recognition' receptors (which one could
insist is what anti-virus software does through
distribution lists, thus limiting the rate of
an 'infected' network).
A document management system could be a 'learning'
system. This seems straightforward to me and
congruent with what I observe in bootstrap
systems that start with simple messages that
offer up services, then become more complex as
the services undertaken multiply. Over time,
the system is subject to the limits of the
energy budget (becomes specialized) and the
effects of the initial conditions of the messages
accepted/rejected. Now one would look for
the distinctions among structural and functional
complexity (space and time).
len
-
From: Nathan Young [mailto:natyoung@cisco.com]
Hi.
In cases where I've found validation useful, the subset of documents I'm
interested in is a much smaller and more specific set of documents than
the set that I would like to exclude. This makes "accept if" conditions
easier to define than "reject if" conditions. I think in general this is
the case and has led to the current state of document validation, but I
agree that it need not always be so.
I think there are actually two closely related questions:
- do you build a set of documents based on acceptance criteria or
rejection criteria?
- what do you do with the set of documents you end up with?
Schemas and DTDs tend towards defining a pattern that must match the
document, though I think you could find exclusion cases as well.
Schematron allows you to define an even richer set of "reject if"
conditions.
Once you have the set of documents that validated, you can decide what to
do with those. Do you accept them? Do you reject them? Sometimes it
might make more sense to talk about "recognition" rather than "validation".
Virus detection software maintains a set of virus definitions for the
reasons mentioned in the first paragraph; namely that the set of virus
signatures is smaller than the set of valid applications. So it's doing
traditional document validation in that it is looking for positive
matches, but it uses "validation" as criteria for rejection.
Immunity in biological systems has an extra requirement not generally
present in document management. On the surface it would seem that if the
immune system could recognize parts of the local system as such, it could
react to anything else as an intruder. Invading bacteria would be
equivalent to "non-validating documents".
The wrench in the works the immune system faces in "validation" is that
the cases are not bound. Immune cells need to apply the criteria to a
case it cannot evaluate in entirety. So rejection is the only criteria
the immune system can apply for security reasons. It's too easy for an
intruder to carry adequate validation conditions along with an evil hidden
payload.
In reality, the immune system looks for a very large set of recognized
intruders, applying a large set of positive matching criteria.
Immunizations provide an addition to this set of criteria.
This is in an environment where extensive filtering has already gone on.
The skin is a very restrictive filter, and the digestive system less
restrictive but still very effective. How to extend this metaphor to
document management?
--->N
On Thu, 10 Feb 2005 12:23:23 -0600, Bullard, Claude L (Len)
<len.bullard@intergraph.com> wrote:
> OR satisfies(S1)-weakly/strongly.
>
> If this were easy, I'm not sure it would be fun to ponder.
> But for anyone who wants to dig into the background, read
> Niels Jerne's papers on vertebrate immune systems as networks and
> generative grammars. I suspect this means dynamically
> generating anti-schemas from schemas given an initial
> instance.
>
> If schemas are mini-networks (they are graphs, yes?), and there
> are relationships among these (have to be if one has a
> compound document) there is a possible analogy.
>
> Where does this model lead?
>
> I don't know. That's why, for me, it's fun.
>
> But I think there is a symmetry with the problems of
> dynamically evolving namespaces, versions, and
> unchanging URIs although that has no connection to
> why I am reading in this topical domain.
>
> len
>
>
> From: Michael Kay [mailto:mike@saxonica.com]
>
> Most of this goes into my "incomprehensible to a mere computer scientist"
> bucket, but the idea of an anti-schema is one I like. I wonder how many
> of
> the restrictions in the capability of XML Schema disappear if we define
> the
> constraints on a document using expressions such as satisfies(S1) and not
> satisfies(S2)?
>
> I expect someone will tell me there is a vast body of theory on forming
> the
> union and intersection of regular grammars...?
>
> Shame that in XSLT and XQuery, failing to validate against a schema is
> always a fatal error.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
|
