[
Lists Home |
Date Index |
Thread Index
]
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>
>
--
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
Nathan Young
A: ncy1717
E: natyoung@cisco.com
|
