[
Lists Home |
Date Index |
Thread Index
]
Karl Waclawek wrote:
> Yes and no. XML doesn't stream all that well, because it doesn't fragment very
> well (you always need to send entire documents).
>
> Can this be solved with the XML Fragment recommendation?
Except there is no such thing :) It never went to Rec.
>>For applications that can tune
>>into a stream that has already started (any broadcast app for instance), that
>>means they'd need to wait til the end of the current doc before they can start
>>displaying anything.
>
> Because they have to read the DTD? What if the DTD is already known a priori?
> There may still be problems (e.g. context, namespaces) - but would XML Fragment
> not address those?
No, because you can only parse an XML document from the start. Take the
following snippet:
<foo>
<bar/>
</foo>
If your app picks up the stream and sees the "a" of <bar/> as the first byte,
there's nothing useful it can do with that document.
You might need more than XML Fragment to address this (XUpdate would be another
candidate).
>>With binary infosets, that's not the case anymore. You can
>>also update parts of a document more often than others and other such niceties.
>>A lot of it is dependent on the transport layer, but binary infosets make that
>>possible. I'm eagerly awaiting my first SVG TV ;)
>
> For multi-media XML I certainly see a binary streaming format as having
> an advantage in bandwidth requirements. Not clear if the other points
> made above could not be solved with adding another specification.
Bandwidth speed but also decoding speed (you want to keep all you can for
audio-video decoding, especially on a small device). They /might/ be solvable
with other specs, but those specs don't exist whereas multimedia XML is already
deployed. I also don't know if streaming applies to areas other than multimedia
and printing, both of which are areas that typically need to gain as much in
bandwidth and/or processing power as they possibly can, ie areas that tend to
already use binary infosets.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
