[
Lists Home |
Date Index |
Thread Index
]
Bullard, Claude L (Len) wrote:
> This is likely the nut of the problem to be resolved. It is possible
> that binarization gets the best results for each application
> by becoming non-interoperable across applications.
Yes, that is definitely something to be given thought to. However the same can
be said of virtually anything meant to interoperate. A number of features could
be dropped from XML for instance, but the hard thing there would be to find
which parts to drop.
It is likely that an interoperable bInfoset format would be less efficient than
a highly specialised one. I'm pretty sure I could cook up something that would
compress better than most bInfoset formats (like XbMill) and lose speed, dynamic
update, etc. But if I'm only gaining 10% on the interoperable format, it's not
worth it. It's all in figuring out the right trade-off, and I certain it's very
well possible to find something generic.
Besides, considering losing interoperability may be an option in some systems
today, but I see it as an increasingly costly decision as "webization" proceeds
from outside documents (making things HTTP-accessible) to within them (usage of
mixed-namespace documents). As the workings of multiple-namespace documents are
increasingly well understood, I wouldn't be surprised to see some interesting
mixes of SVG, XForms, X3D, various voice MLs, some music and sound control ML,
XHTML, all of those shooting off or carried inside Web Service message, with
lots of RDF sprinkled over. In fact, with the exception of X3D and the music
stuff, all of that is already visible in the SVG world.
You aren't going to go far in there without an interoperable format :)
> Considering all text nodes to be of the same content and
> equal in value is false. The binarization approach taken
> to indexed face set content (see X3D) and <p> may be
> completely different.
Very true. I'm tempted to place that as issue number one, the rest (encoding of
the structure) can multiple solutions but it ought to be simple enough to pick
the best. Adressing the encoding of text nodes leads one to think of pluggable
codecs, and all the associated interoperability issues. Some groups however have
been working on the issue (I believe notably around X3D) and I'm pretty sure we
can find something inside (abtract codecs) or outside (content negotiation) of
the format.
In fact, if HTTP 1.1 content codings took parametres, we'd have the answer
already. Damn :)
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
