XML Information Set Requirements, W3C Note 18-February-1999

Jeffrey E. Sussna jes at kuantech.com
Fri Feb 19 23:36:04 GMT 1999


Sorry; I didn't mean to say it would definitely be necessary to support "endless" streams, just streams. Why is this relevant to Information Set Requirements? Perhaps it's not. But when you raise the level of abstraction, you open the door to asking questions such as "What is a document?" Given that the requirements in question tightly tie themselves to XML 1.0, it may all be moot, and this may all just be grist for the proverbial XML 2.0 mill. And by the way, I agree that XML shouldn't be seen as the solution to all problems. There are, however, a large set of problems to which it naturally wants to lend itself. 

In any case, let me give an example of how one might want to apply XML to streaming data. Imagine the following XML streaming data "packet":

<sensor-quantum timestamp="19990220T142003">
	<speed>25</speed>
	<direction>N</direction>
</sensor-quantum>

You can imagine an application that receives and processes these packets one at a time. At the same time, however, the application spools the packets to a file for offline analysis:

<sensor-run starttime="19990220T142000" endtime="19990220T162000">
	<sensor-quantum timestamp="...">...</sensor-quantum>
	<sensor-quantum timestamp="...">...</sensor-quantum>
	...
</sensor-run>

So, what's the document? Now, given the emphasis on "well-formed", by definition a sub-element in a well-formed XML document is itself well-formed, so maybe you can cheat. 

Jeff

-----Original Message-----
From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
Walter Underwood
Sent: Friday, February 19, 1999 2:59 PM
To: Jeffrey E. Sussna; 'John Cowan'; 'XML Dev'
Subject: RE: XML Information Set Requirements, W3C Note 18-February-1999


At 02:27 PM 2/19/99 -0800, Jeffrey E. Sussna wrote:
>I think this issue needs to be addressed. It may be the case that 
>the stream contains, not one, but many documents, where each 
>information "packet" is a document. Or perhaps the afore-mentioned 
>notion of "document fragment" is introduced, and each packet is a 
>fragment. But it will definitely be necessary to support this kind 
>of processing in some manner. 

"will definitely"? Any stream has to start, and ought to be able
to end gracefully. Why not start and stop once in a while for
resyncronization? A series of document-packets (packuments?)
should work fine.

On the other hand, I'm not sure that XML must be used to solve
every problem. It's beyond me what we gain by incompatibly 
re-implementing RPC, SQL, Java class files, or whatever in XML.
Let's solve some new problems.

If we don't let go of the XML hammer once in a while, everything 
starts to look like a thumb.

wunder

--
Walter R. Underwood
wunder at infoseek.com
wunder at best.com (home)
http://software.infoseek.com/cce/ (my product)
http://www.best.com/~wunder/
1-408-543-6946

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)




More information about the Xml-dev mailing list