xml-dev - RE: What is wrong with SVG?

[Jon Ferraiolo <jferraio@adobe.com>]

At 05:51 PM 3/6/00 -0800, Don Park wrote:
>Jon ferraiolo wrote:
>>In the spirit of fostering communication, I'll attempt to
>>address some of questions.
>
>Thanks Jon.  I appreciate your participation in this discussion.
>I have some remaining questions and a response to your negative
>assessment that the path syntax change is highly unlikely.
>
>1) SIZE ISSUE
>
>  While I can sympathize with the WG's concerns over size, I am
>  puzzled as to the size difference between:
>
>    [1] M100 200L200 100              - 16 chars
>
>  and
>
>    [2] <M/>100 200<L/>200 100        - 22 chars
>
>  or
>
>    [3] <M>100 200</M><L>200 100</L>  - 28 chars
>
>  While [1] saves about 42% over [3], [1] saves only 27% over [2].
>  While this might still seem to be a significant saving, the saving
>  drops even further as data to command ratio and data value size
>  increases.  For example:
>
>    [4] C133.67,217.00,137.00,218.33,137.00,218.33
>
>  over
>
>    [5] <C/>133.67,217.00,137.00,218.33,137.00,218.33
>
>  which results in only about 7% saving in size.
>
>  Perhaps I missed something.  Does the WG's assessment of the real
>  size saving resulting from the current approach differ from these
>  numbers?  

We didn't consider the above alternative. Instead, the two main approaches
we looked at were the VML approach (like what SVG has now) and PGML, which
used a "full" XML approach, such as:

    <path>
      <moveto x="100" y="200"/>
      <curveto x1="133.67" y1="217.00" etc. />

The PGML example mapped directly to convenient DOM access and mapped well
with XSLT, but we felt the size of PGML files and the size of the PGML DOM
were unacceptable.

As I remember, we decided against a syntax with coordinates as character
data because we wanted character data only for things that were textual in
nature (such as <text> elements). Thus, we ruled out:

    C133.67,217.00,137.00,218.33,137.00,218.33
or
    <C/>133.67,217.00,137.00,218.33,137.00,218.33

>
>2. ATTRIBUTE ISSUE
>
>  You did not go into reasons for using attribute instead of content
>  text for path data.  Because SVG uses attribute for path data, it
>  had to create custom interfaces for accessing the content.  What
>  were the compelling reasons that justified these costs?

I thought I already explained the reasoning in previous email.

>
>>However, the particular subject of the <path> element has been debated
>>many times in the past and, at this stage, for better or worse, given
>>the degree of debate that has already occurred in this area and the
>>very late point that we are at with SVG, it is highly unlikely that
>>the path syntax will change.
>
>I am disappointed by this.  Am I to understand that the nature of the
>W3C's 'Last Call' is addressed to the W3C member companies only and
>not to the public?  If so, then I must conclude that the SVG spec
>is not a standard for general public.  I would appreciate some
>clarification on the real nature of W3C's Last Call.

No, SVG is open for public review and comment. We welcome comments from the
public, such as those recently having to do with the 'path'element. I have
not stated that there would be no changes with the 'path' element, but just
indicated that the likelihood of change was small. 

These comments have been made in the desire to be candid and truthful about
what is likely to happen. Would you prefer instead that I set up
expectations incorrectly, or perhaps that the comments were left unanswered?

A main reason for the likelihood of change being small is that this is a
second last call, not a first last call. The first last call started August
12, 1999. At that point, the SVG working group was more willing to consider
any and all feedback. 

I do not recall any feedback comments to the first last call about the
'path' element.

With the second last call, the goal is to get feedback on those changes
(mostly done in response to first last call feedback comments) that have
happened since first last call. However, the 'path' element has stayed the
same and thus isn't one of the topics on which we were expecting feedback.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************