xml-dev - Behavior and Semantics

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

[from David Durand]
>	
>	------ This is a copy of the message, including all the headers. ------
>	
>	Return-path: <david@dynamicdiagrams.com>
>	Received: from punch.ic.ac.uk [155.198.5.17] 
>		by bowmore.cc.ic.ac.uk with smtp (Exim 1.58 #2)
>		id 0yhlBp-0004JO-00; Fri, 5 Jun 1998 02:21:05 +0100
>	Received: from dynamicdiagrams.com [205.181.196.2] 
>		by punch.ic.ac.uk with smtp (Exim 1.62 #1)
>		id 0yhlBn-0000UP-00; Fri, 5 Jun 1998 02:21:04 +0100
>	Received: by dynamicdiagrams.com (940816.SGI.8.6.9/940406.SGI.AUTO)
>		for xml-dev@ic.ac.uk id VAA08243; Thu, 4 Jun 1998 21:10:05 -0700
>	Date: Thu, 4 Jun 1998 21:10:05 -0700
>	From: david@dynamicdiagrams.com (David G. Durand)
>	Message-Id: <199806050410.VAA08243@dynamicdiagrams.com>
>	To: xml-dev@ic.ac.uk
>	Subject: Re:  Behavior and Semantics (was Re: OK, I've read some books, tons
>	    of articles, and...)
>	
>	>From: Peter Murray-Rust <peter@ursus.demon.co.uk>
>	
>	>You have rightly realised that a DTD defines the structure of a document,
>	>but not how it behaves or what should be done with it.
>	
>	This is exactly correct. This is because the set of possible behaviors
>	a document might exhibit and processes to which it might be subjected
>	is an open (infinite) set. By providing names in some well-known
>	ontology, we hope to make it easier to re-use information with
>	different processes.
>	
>	I'm responding to this, because I hope that I can help unconfuse soem
>	issues that you have persistently confused as to the applicability of
>	the "stylesheet notion".
>	
>	>There are two sorts of objects that will be interested in XML documents,
>	>humans and machines (and possibly some combination).
>	 
>	>For humans the most common activity will be using a stylesheet to render
>	>the document in a way that is more meaningful to a human. Thus <TITLE>
>	>could be rendered in large font in the middle of the page. Most humans can
>	>recognise a title because they have seen thousands in their life. Similarly
>	>something like
>	><DATE format="ISO8601">19980604</DATE> might be rendered as
>	>June 4 1998
>	
>	>- the information is no different but it may be better understood
>	 
>	>At 17:01 04/06/98 -0400, moliphan@footprint.com wrote:
>	
>	>>A question I have is, how does my behaviour travel with the data (as
>	>>structure does not define behaviour)? I have seen how Java parsers can
>	>>traverse document elements, and given elements I can now associate actions
>	>>with them using Java, but how does that help you, my interested party
>	>>unless you can use my code with the data?
>	>
>	>Machines need other ways of interpreting XML data and so - for example - if
>	>I send someone a molecule in XML a stylesheet isn't much help. You have to
>	>have a program. So long as we all agree on the DTD and the semantics and
>	>the ontology (tough) it doesn't matter what program we use.  Unfortunately
>	>much chemical ontology is hardcoded into programs.
>	
>	This is the point on which you are incorrect. The term stylesheet is
>	perhaps confusing, since it implies a formatting specification, but
>	then the notion, like most of the notions in XML, comes from the print
>	(and online) publishing world.
>	
>	XML stylesheets will have a hook to a fully general scripting
>	language. That means that it will be possible to have stylesheets that
>	access special browser caspabilities, Java code, or whatever. It's
>	important that this be done via style sheets, since that's the
>	standard mechanism, and since users will be able to change stylesheets
>	if they need to interpret the data differently. For instance, you
>	might supply a molecule with a "display 3D model" style, while I want
>	to "view" it by using my molecular synthesis generation software.
>	
>	Both of us are accomodated by XML, and both are served by the use of
>	a single method of attaching processing semantics to a document.
>	
>	>>The paradox as I see it is that XML provides an open definition of
>	>>structuring data, but there is difficulty then in providing a generic (low
>	>>cost) method of using the data. My data will be (and, hopefully act)
>	>>different from yours and everybody else's, therefore no generic agent is
>	>>going to know what to do with it.
>	
>	>Your *data* may be different, but hopefully your ontology can be mapped
>	>onto other peoples. Thus maths will use MathML - the equations will vary ,
>	>but they will all use the same DTD. Similarly chemists and biologists can
>	>use CML, and assuming they all mean the same thing by a an ATOM (fairly
>	>easy) and BOND (*not trivial*) they can interchange information seamlessly.
>	> Moreover mathematical chemists can use both MathML and CML in the same
>	>document using the namespace approach.
>	
>	And, using the stylesheet mechanism, you can inform users of the
>	method of processing _you_ intend to use with the data.
>	
>	In most browsing contexts, a default display stylesheet will be
>	appropriate, but the fact XML inherently supports indirection for
>	processing methods allows a lot of power for repurposing and upgrading
>	data that is already created.
>	
>	  -- David
>	------------------------------------------+----------------------------
>	David Durand                 dgd@cs.bu.edu| david@dynamicDiagrams.com
>	Boston University Computer Science        | Dynamic Diagrams
>	http://www.cs.bu.edu/students/grads/dgd/  | http://dynamicDiagrams.com/
>	                                          | MAPA: mapping for the WWW
>	                                          |
http://dynamicDiagrams.com/minimapa
>	
>
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)