RE: EXI WG's inquiry about ISSUE-2050

Hi Chris and the members of SVG WG,

Thank you for your quick response, and the EXI WG appreciates very much 
the prospect of the two WGs to collaborate for mutual benefits on the issue..

Once such a shim API is in place for verbose XML path syntax, EXI will fit
squarely to serve as an content-coding for SVG file exchanges.

>From EXI WG's point of view, we would like to make EXI work to its fullest 
to best serve SVG documents. One significant ingredient to achieve that is the
use of XML Schemas. EXI uses XML Schemas not for validation, but for 
informing the processors of the most likely structure/datatypes of the
documents. We are aware that SVG is using Relax NG for defining its syntax.
We would like to explore the idea of having a parallel normative XML Schema 
that is not for defining SVG syntax but for informing EXI processors of what 
it can expect more likely than others gramatically. We would like to have this
discussed together with SVG WG. Is this something that we can work together
on among other aspects?

Since the EXI WG is going to meet during TPAC this year, we thought it a 
great chance for the two WGs to get acquiainted and discuss the issue
face-to-face, depending on the schedule of the two WGs. 

Sincerely,
Takuki Kamiya
for the EXI Working Group


-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org] 
Sent: Thursday, April 26, 2012 3:21 PM
To: Takuki Kamiya
Cc: www-svg@w3.org; member-exi-wg@w3.org
Subject: Re: EXI WG's inquiry about ISSUE-2050

On Tuesday, April 24, 2012, 11:52:49 PM, Takuki wrote:

TK> After looking around for any existing such efforts, we were informed of
TK> ISSUE-2050 [1] that seems to suggest there has been similar interest within
TK> SVG WG itself as well.

Yes, the trade-offs regarding expressivity, manipulability, verbosity and filesize for SVG paths have been a constantly recurring feature in the design of SVG.

TK> It looks as though, however, that the issue has not been given much attention
TK> since its creation. We would like to know if the issue is still considered
TK> valid within SVG WG, and if so, there is any plan to revisit the issue in the
TK> near future. 

Having fixed the path syntax for SVG 1.0, the problem then became how to introduce a new, more verbose syntax in parallel while minimizing the impact on existing implementations, and not requiring content authors to redundantly author both forms, for old and new user agents.

Besides better compression with schema-aware processors, the other motivation for considering the more verbose syntax was the ability to manipulate (and perhaps style) subpaths without content authors having to implement a path parser themselves. It would also allow smaller incremental changes to be made to individual subpaths without having to pull out an entire, possibly large, path attribute value and replace it with another, probably similar, value.

SVG 1.1 is now completed, and the WG is concentrating on requirements and features for SVG2. So it is a good time to re-consider this longstanding issue; we looked at it on todays SVG conference call, and I was given ACTION-3270 to relay to you the results of that discussion.

One way forward which we have considered in the past is to add a DOM API which would allow interconversion of the two path forms. This would allow content authors who want to manipulate sub-paths to call the API, get a handle to the verbose form, manipulate it and then call the corresponding API to convert it back to the old path syntax. this approach would also allow deployment to a mix of old and new user agents, by supplying  a 'shim' or script which implements the API if it is not supported natively.

The API could also be used by an EXI pre-processor, taking existing SVG content and converting paths to the new form. This could be transmitted as EXI and then on the receiving end, converted back to the old syntax (to minimize the DOM footprint and to allow rendering in existing implementations).

TK> The EXI WG would like to move the issue that is well described in [1] forward,
TK> however, we do not want to make an overlapped effort inadvertently. It would
TK> be ideal if the two WG can make a concerted efforts toward the same goal.

The SVG WG would value the opportunity to work on this together with the EXI WG.


-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Wednesday, 9 May 2012 19:51:12 UTC