RE: [public-exi] <none>

Hi,

I think your research is in a sense making an epoch because it is an effort
that seeks synergy between EXI and SVG, both of which are W3C technologies,
and should set a nice example of using EXI by the organization defining it.
Thanks for taking up the effort!

I'd like to make one suggestion that might help taming the issue of the
choice between integer and float.

Instead of choosing between integer and float, you can model the structure
such as follows, with x and y defined as elements with optional attribute
"decimals" that represents the number of decimals after the decimal point.

<M>
  <x decimals="1">101</x>
  <y decimals="1">201</x>
</M>

Since the attribute "decimals" is optional, it occurs only as necessary,
and the extra markup cost is 1 bit that is needed for indicating its
presence. When "decimals" does not occur, each data can be represented
as 1 + 9 = 10 bits (at minimum), instead of the full blown float which
constantly uses at least 18 bits.

You also indicated that SVG schema is huge.
(Maybe you can call it even small compared with Docbook schema, I suppose. ;-)

You may want to separate the schema used for exchange from the more stringent,
constraining schema used for validation. One simple schema may just declare
element and attribute names so that their names get into the initial string
table. You should be able to calibrate the schema by defining some element
content as repeatable choice of child elements so that the generated grammar
is of minimal size, as necessary.

Paraphrasing Robin's last note, please don't hesitate to explore and
relish EXI more. ;-)

-taki


-----Original Message-----
From: public-exi-request@w3.org [mailto:public-exi-request@w3.org] On Behalf Of Robin Berjon
Sent: Thursday, May 28, 2009 8:06 AM
To: FABLET Youenn
Cc: public-exi@w3.org; fujisawa.jun@canon.co.jp
Subject: Re: [public-exi] <none>

Hi,

On May 28, 2009, at 14:42 , FABLET Youenn wrote:
> As some of you may remember, we had some discussions during TPAC
> 2008 about how to use EXI for better SVG path compression.
> During that discussion, I said that we made some experiments on
> applying EXI compression on path data structured as XML trees.
> The results were showing that, although the current compact syntax
> does a really nice job, using EXI on XMLized path data would
> certainly improve the situation, at least in the scenarios we are
> aware of.

Thanks, this is interesting and matches the research we'd done back
when I was with Expway. Without even going into complex SVG-specific
codecs you can also gain quite a fair bit by losing the absolute/
relative semantics which only very few authors care about. That brings
the number of commands from 19 down to 10 (you list 20, but z and Z
are identical).

Where it concerns precision, large tracts of content out there has too
much of it -- a lot of it could use integers, or perhaps two decimals
tops. It's hard to do anything smart in there without becoming SVG
specific, but some tricks include looking to see if zoomAndPan=disable
(which does *not* mean that zooming is impossible, but can be used as
a hint) and looking at the viewBox definition and its relationship to
the size of the canvas -- that can help derive the necessary precision
one actually needs unless massive zooming occurs (you rarely need to
place things more precisely than 1/10th of a pixel).

Anyway, interesting stuff! Don't hesitate to share more :)

--
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Friday, 29 May 2009 01:00:28 UTC