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] Schemas As Anti-bodies and Dynamical Systems

[ 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).


From: Nathan Young [mailto:natyoung@cisco.com]


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"  

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  

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?


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>


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

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