[
Lists Home |
Date Index |
Thread Index
]
>-----Message d'origine-----
>De : Simon St.Laurent [mailto:simonstl@simonstl.com]
>Envoyé : mardi 22 janvier 2002 19:59
>À : Clark C . Evans
>Cc : xml-dev@lists.xml.org
>Objet : Re: [xml-dev] Being "precise" vs being "human"
>
>
>My answer to the whole mess is simple: there ain't any meaning, just
>labels and structures. Anything else is a bonus or a nightmare,
>depending.
I'd like to do some a bit of philosophy on the subject, but be warned that
it may be totally offtopic and built on intuitive thinking, not science :).
I think that data has no meaning if there is nothing to process the data. A
book has no meaning if there is no one to read it.
However, when reading a book, the meaning is recreated from the text in the
reader's mind, but the meaning is nowhere in the book, just in the writer's
and the reader's brains (there is often a difference between the writer's
ideas and their reproduction in the reader's mind).
Likewise, XML data has no intrinsinc meaning. XML is a way to convey meaning
between two systems. In the emitting and receiving system, meaning exists
because there is code running there.
If we read an XML bill produced by a billing system, we understand the bill
(thanks to the nice property of XML that it allows the use of human-readable
labels). It creates a meaning in our mind. Likewise, an accounting system
that receive the XML bill 'understands' the bill because it has code that
can process it and change the environment accordingly to its understanding
of the document.
Of course, the means of understanding are not the same : a human being uses
its little knowledge of XML and its enormous knowledge of names and concept
to recreate the meaning of an XML document, whereas a computer just runs
code that behave differently according to the patterns of labels that it
finds in the document. The knowledge of the computer is just the
pre-programmed behaviours that are associated to pre-defined patterns.
But the job is nonetheless done. If I send an invoice as an XML document to
an automated accounting system (if such a thing existed), and got a cheque
in return, I'd declare that the system understood the document and that the
XML format was fit to convey the meaning of the invoice, and the system to
get this meanings. The proof is my cheque.
It is the fact that a system can read a document, and react appropriately,
that makes me think that yes, there is some meaning somewhere, even if it's
not in the XML documents.
The meaning is what you get when a program's run depends on its input data.
Which means that you can observe meaning everywhere in a computer.
I think I'll read something about the Shannon-Weaver model, in order to
refine my ideas... But anyway, that's why I'm thinking that even if the
practical notion of 'meaning' in computer science is not as noble as in
human sciences (because it's basically code whose execution depend on some
input data), we should try to look for better ways of exchanging 'meaning'.
Today, the 'meanings' that can appear in a computer are rader crude compared
with those that can appear in our minds. But why not try to improve that,
little by little ?
If 'meaning' is the result of a synergy between structured data and code
processing the data, then improving the exchange of meaning needs :
1) to improve the exchange of structured data, which XML is all about
2) to improve the exchange of code. It begins by allowing stylesheets and
plugins to be downloaded and ran automatically, who knows where it can go ?
A corollary of those two objectives, and maybe a pre-requisite, is to find
ways to describe structured data itself, in the form of structured data
about structured data, AKA meta-data.
If meta-data allows a program to automatically find an appropriate piece of
code to process an unknown piece of data, then it's a great leap forward.
Plugins are the easiest example of that, because the way a plugin can be
integrated into the browser framework is relatively obvious. For other
contexts (billing system, for example), the task can be way more difficult.
This is something that we need to think about. We can't work on XML without
thinking about the programs and frameworks that will process XML documents,
because XML is a way to convey meaning, and meaning needs code AND data, not
just data.
So, yes, let's think about this 'meaning' stuff, let's recognize that it's
already there, already in your browser, everywhere in your OS or
applications, but not as nice and elaborate as it can be in our minds. Let's
keep on finding ways to better exchange meaning, which means better
exchanging data, meta-data and code.
Best regards,
Nicolas Lehuen
>--
>Simon St.Laurent
>Ring around the content, a pocket full of brackets
>Errors, errors, all fall down!
>http://simonstl.com
>
>
>-----------------------------------------------------------------
>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://lists.xml.org/ob/adm.pl>
>
|
