[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Caught napping!
John Cowan wrote:
> W. E. Perry wrote:
> > The example I use to illustrate the consequence of this premise is
> > that a natively XML database must be able to commit any well-formed
> > XML instance--and commit it as an instance of the document type
> > described by its root element. It must then be prepared to commit
> > *as a further instance of the same document type* any other
> > well-formed XML document which exhibits the same root element [...].
> Why privilege the root element type? Why not require XML databases
> to categorize documents based on the presence of U+2022 in the
> value of an attribute named "schritschifchisted" in an element
> whose grandparent is "yolki-palki"?
Because this is XML, and root and document are defined constructs which are
required, and which we may therefore confidently expect to find in
> If you don't know any English, it's no use my writing to you in English,
> no matter how carefully I explain myself; and you can't learn English
> except from people who already know it. Complete node autonomy is as
> useless as completely private languages.
But this is not about complete node autonomy! Far from it, in fact. This is
about autonomous processes which are dependent upon shared data (in Jon
Bosak's felicitous formulation, that data gives them 'something to do').
However, *what* a process does is defined in the first instance by that
process, not by the form of the data upon which it operates, or the model
or schema to which such data might conform.. The very point of my argument
is the question: what is the nature of the 'sharing' of data between
otherwise autonomous processes? Where the data conforms to a model or
schema or other a priori form, known to all of the processes which might
operate upon that data, then we could say that in a very real sense the
schema, or model or form (in the Platonic sense) of the data drives the
process. That is the model-centric view. I am positing something very
different, but which is in my experience much closer to the nature of
arbitrary instances of data in the real world. This is that the data
instance as originally created has some content and that content is
understood by its creator to exhibit certain properties. Some portion of
that same content may (and I argue, will) be understood, by processes
independent of that original creator, to exhibit certain other properties
which makes that data, or content, of interest to those processes precisely
because those properties indicate that such data might be put to some use
through the operation of those processes.
> > it may need to selected for processing based on a process' very
> > different understanding of the nature of that content.
> Granted. Where does this understanding come from?
The understanding, which is to say the elaboration of particular semantics
from the data, comes directly from the operation of the process. That is
why only a process can determine the semantics of particular data *in the
outcome of the operation of that process, on that occasion and in those
particular circumstances*. In practice, this means that if a process can
instantiate, from a particular XML instance, data upon which it appears
that that process might perform useful work, the only real test of whether
it can, in fact, do so is to permit that process to operate and then to put
the outcome of that process to use, to see whether it is in fact of the use
that had been expected.