[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Streaming XML (Was RE: XML Information Set Requirements, W3C Note 18
Couldn't find a coin - so I suppose I should respond: Marcelo Cantos wrote: > On Sat, Feb 20, 1999 at 04:08:24PM -0000, Mark Birbeck wrote: > >then we can't put anything on that > > wire other than news headlines (and really you shouldn't process > > anything until you receive that closing element, but I know > > that's what > > people are requesting they can do). > > I disagree with that last parenthesised remark. Stream-based parsers > do and indeed should process data as it arrives. XML browsers _most > certainly_ should do so. > > Not that I disagree with your overall point (I haven't really given it > that much thought), but the above is definitely wrong IMO. You seem to have missed the point of the discussion. The question is whether it is legitimate to open a stream of XML with some sort of element like: <stockPrices> and then spend the rest of the day sending out things like: <stockPrice> <ticker>MSFT</ticker> <price>1000</price> </stockPrice> and then at the end of the day, sending: </stockPrices> No-one so far in the discussion has argued that this is good XML - except you Marcelo, but you can be excused because you haven't given it much thought - because if you were validating this you should not (CAN NOT!) say the document 'stockPrices' is valid until you receive the closing element. And that would mean you couldn't process the intervening prices until you had validated the entire document, and that would mean your data feed would be useless. So, what people are discussing is whether there is any way of keeping within the principles of XML and still having an 'infinite document' or an 'open-ended document' or whatever. In other words, how can we correctly process those intervening 'stockPrice' elements when we haven't yet had the complete document to which they belong. Now, you just say 'stream-based parsers' *should* do this. But if you think that, back it up. Everyone else in this discussion has said why they are for or against such an approach. If it's obvious to you, then please share. My contribution to the discussion - which I *did* give much thought - was to try and argue that it is not very good programming practice anyway, to open a stream for 8 hours. Instead we should remove the containing 'stockPrices' document, and then send lots of 'stockPrice' documents throughout the day. This has many advantages, such as the ability to maintain consistency with current XML approaches, the ability to send multiple 'types' of data along one wire, and the ability to send a DTD with each document, or even an abbreviated DTD if required. In short, my disagreement was with trying to map 'the stream' to 'the document', rather than to 'a carrier of many documents', and I argued that we already have everything we need in XML 1.0 to implement very powerful stream processing. Regards, Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|