[
Lists Home |
Date Index |
Thread Index
]
- From: "Jeffrey E. Sussna" <jes@kuantech.com>
- To: "'Walter Underwood'" <wunder@infoseek.com>,"'John Cowan'" <cowan@locke.ccil.org>,"'XML Dev'" <xml-dev@ic.ac.uk>
- Date: Fri, 19 Feb 1999 15:33:39 -0800
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@ic.ac.uk [mailto:owner-xml-dev@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@infoseek.com
wunder@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@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@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)
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/ and on CD-ROM/ISBN 981-02-3594-1
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)
|