- From: W. E. Perry <wperry@fiduciary.com>
- Date: Thu, 18 May 2000 16:21:14 -0400
- To: Tim Berners-Lee <timbl@w3.org>, xml-uri@w3.org
Tim Berners-Lee wrote: > I would disagree. I would say that there are a set of understandings which > are > broken when that happens. Also, the system has broken here. The author of a > document uses <b>poison</b> for emphasis and the browser puts up a picture > of Beethoven. The reader of > the document does not notice the phrase and drinks the poison. Whether you > regard that as > desirable or not, it was not the semantics of the message. It was not "that > signified". But it was the legitimate outcome of the process. Want a different outcome? Use a different processor (browser). By installing and configuring that software on your local node, you have authorized its behavior and delegated your safety to it. That is your absolute right, grounded in your autonomy as a node. > That is not the way the Web is designed IMHO. The Internet is designed on > the > assumption that using common languages such as English we come to define > protocol > specifications which are generally considered to be well defined. This > specifications > define new languages (such as xml namespaces) where a syntactically valid > sentence has a > semantics which is then indirectly defined though the language spec. You > find the semantics by applying the > definitions from the specification to the particular combination of terms > chosen by the document > author. The semantics is a form of product of the syntax of the document > and the semantics of > the specification of the namespace used. As processed in some potentially uniquely local combination by software running on the local node. The instance document is one input; local parameterization of local-running software decides what portion of it to use, and how. Other inputs treated in the same way may include schemas or other explanatory structures which the transmitter of the document might have pointed to, other schemas or reference data which the receiver of the document might point to, in general or in the instance, and the inherent biases of the processing software itself. What we are really talking about here is re-use--of both instance documents and of the code which processes them. I use documents (filled with 'expected' financial semantics!) every day in ways which their authors never intended. Traders who write tickets rarely think about the process of settling their executions or of filing required regulatory reportings. The order and execution tickets themselves, though, can (and should!--nothing could make more clear to the auditors the connection through a single ticket between two mutually-anonymous operations in separate backoffice departments) be used as the primary input to trade comparison, cashiering, delivery, custody, and regulatory reporting processes. Those process will need to fetch other input and reference data unknown to the authors of those trade tickets, and must begin their processing by specifically ignoring the intended semantics of those tickets, which no longer are applicable. Respectfully, Walter Perry
Received on Thursday, 18 May 2000 16:21:17 UTC