Re: SVG 1.2 Comments

On Wednesday, November 10, 2004, 7:28:01 AM, Scooter wrote:


SM> Here are some comments that I have been working on in response to
SM> the SVG 1.2 last call. I've been really trying to read all of the
SM> comments and discussion in www-svg, and I frankly have been less and
SM> less comfortable about adding my comments to the mix.

Its unfortunate that you, and perhaps others, are discouraged from
making last call comments by the rather combative attitude of a few
people who chose to use last call as a way to either get the SVG WG shut
down,or at least mired in process and unable to progress.

I thank you for getting past that and sending in your comments anyway.

SM> Why? Well, for two reasons, mainly. I seem to represent a very minor
SM> focus of the SVG specification, someone who is attempting to add
SM> some SVG functionality to an existing web browser,

On the contrary, that is one of the target audiences of the
specification. You should also check out the recently launched Compound
Document Formats (CDF) working group, which is even more relevant to the
mixture of SVG with (X)HTML by reference and by inclusion.

SM> and I'm probably the least knowledgeable of the folks working on SVG
SM> in Mozilla. Second, and perhaps more salient, is my confusion of the
SM> tone and WG response to comments made in the list. I will freely
SM> admit that Ian Hixie's unfortunate initial response (throw the whole
SM> thing out and start over) did not set a really positive tone, the
SM> increasing animosity in the list makes me wonder whether the working
SM> group really wants comments, or at least comments from folks such as
SM> me,

There are two different things there. yes, the working group wants
comments - technical comments, especially from implementors of svg
renderers or authoring tools, and also from other working groups, and
from the content creation community.

I appreciate that the rather hostile atmosphere caused by Hixie's attack
has made genuine progress more difficult, but I for one am trying to
separate out the genuine technical comments (such as yours) from
flamebaiting and trolling.

SM> who have a very strong need for SVG+MathML+XHTML+Javascript in a
SM> browser that scientists are willing to use every day. Note, this is
SM> not an accusation, this is a perception.

Its an accurate one. The market is clearly there. We live in a
technological society - the number of people in the scientific,
engineering, technical, financial etc sectors who could use
multinamespace documents with graphics, mathematics, and text is
substantial.


SM> I am also confused by the nature of the "Last Call", and the
SM> process. I am not very familiar with the W3C, so I could use some
SM> education. When I began putting my comments together, it was my
SM> understanding that comments would be submitted to the working group,
SM> which would consider them in total, and develop some form of formal,
SM> thoughtful reponse.

That's right. Typically there is some discussion, if the point the
commentor makes is not clear, or further information is required, etc.
The focus of such discussion is on clarifying the comment, pointing out
areas of the spec that might satisfy the request, etc.


SM> The "Last Call" is, as I understand it, the formal opportunity for
SM> "outsiders" who have not been part of the working group's process to
SM> read the output of the working group and give their input, which
SM> necessarily means that many of the comments will be new to the
SM> working group, and will come from views not well represented on the
SM> working group.

This is also correct.

SM> I have concluded that I must be in error concerning the process.

No, just that this particular last call was hijacked by a small number
of people. It seems to be settling down, now.

SM>  It
SM> seems like the model is that each of the features of the specification
SM> be argued out in the forum until someone is convinced that the "other
SM> side" is right, without much opportunity for formal response from the
SM> working group as a whole,

The lengthy and somewhat heated discussions here are atypical, both for
W3C ad a whole and for SVG in general. Naturally, if someone uses Last
call to lodge a comment that SVG should be abandoned, W3C shut down,
things like that, there will be reaction and angry discussion, which is
not helpful. I am reminded of an old nettiqutte maxim, "don't feed the
trolls".

The formal responses come in a disposition of comments document, showing
each last call issue raised, how it was handled, etc. None of the
responses from various working group members here count as that formal
response.

SM>  or even a recognition of the general 
SM> sentiments being articulated by the posters.   I can certainly see the
SM> advantages to this more public form of discourse, but it seems like it
SM> might lead to more hard feelings than otherwise necessary.

I agree. Its sad when a normally productive forum is interrupted like
that, but after a while

SM> In particular, the sense that I have is that those providing
SM> comments (in particular the implementors of Opera and Mozilla) are
SM> raising some very solid concerns about implementing specific
SM> features within the SVG 1.2 specification.

Some of them are valid concerns, I agree. Some are not. Some of the heat
has come from trying to tell the difference.

SM>    Given that we haven't seen any comments so far from
SM> Apple or Microsoft, the comments by members of the Opera and Mozilla
SM> development team represent a significant population of potential users
SM> (users of web browsers), and they seem to be speaking with a certain
SM> amount of unity.  One response that I've often seen by members of the
SM> working group is "we talked about that and discarded it".  Is that a
SM> valid response?  Of course, it may have been discussed, and may have
SM> been discarded for completely valid reasons, but without sharing the
SM> nature of that discussion, and the reasons for discarding the 
SM> proposal/approach, its hard for those of us "outside" to understand what
SM> the rationale is, so (as a reader), I'm left really struggling to 
SM> comprehend the positions of the working group.

I can empathize with that.

SM> I guess I'm also very confused by the positioning of the working
SM> group. It seemed to me that working with Opera, Mozilla, and Apple
SM> to implement SVG would be very important to the working group, as it
SM> would certainly have a significant impact on the use of SVG as part
SM> of general web content.

It would be, if they were interested in implementing. I have been asking
senior Opera employees, for example, to implement SVG for many years
now. The response has always been along the lines of 'not now' or 'too
hard'; perhaps because the focus has moved away from W3C standards and
more towards replicating a Win/IE clone experience on other platforms.

The success of mobile implementors like Zoomon, Bitflash, KDDI,
Macromedia and Nokia has shown that it is entirely possible to implement
SVG on a mobile platform with highly constrained processor, memory,
etc;its more a case of seeing a business opportunity and wanting to do
it, frankly. I have said in the past thatthere are two ways to approach
writing a web user agent; one is to implement a bunch of W3C specs, and
one is to reverse engineer every strange quirk and foible and outright
bizarre mangling that current legacy user agents implement and that
legacy content depends on. Its very difficult to do both. So to some
extent what you see here is a clash of cultures, legacy broken HTL world
vs modern, standards-based, XML-focussed world.

Moilla shows that it is possible to implement to both worlds, at the
expense of multiple codepaths; having a MathML implementation and an SVG
implementation, for example. As you say, that presents a very compelling
user agent for the substantial scientific, engineering, and
economics/finance markets. But it still takes effort and it depends on
how many people are working on which codepath; and also how easy it is
for people to submit code, get it checked, and have it added to the
codebase. People are very interested in seeing SVG in Mozilla, although
if their code is rejected or blocked they may loose interest after a
while. its a case of nurturing those developers that want to help.

Last time I went to Netscape to talk to them about SVG in Mozilla it was
a very productive meeting. But the effort needs to be encouraged.

Apple used to be members of the SVG WG, and contributed much to the
group. The MacOS X rendering layer is very well suited to
implementing SVG on top of, in consequence. I would certainly encourage
Apple to implement SVG. I am happy to go talk to them about it once
more.

SM> It is my perception, however (don't shoot me, I recognize the
SM> difference between perception and fact) that the SVG working group
SM> isn't really that interested in whether Mozilla, or Opera, or Apple,
SM> or even Microsoft implements SVG or not.

Not at all. Although, after asking and trying to get the desktop HTML
browsers to do this for so many years, its certainly fresh and
encouraging to see SVG get implemented from scratch in a fairly brief
interval in the mobile phone space, and start showing up on dealers
shelves. There is faster turnover in that space - people get a new phone
every 18 months, so the 'how to get joe public to download a newer
browser or change to a better one' is somewhat solved there. In
addition, there is not the mass of legacy content there that binds them
to an older browser.

SM> My perception is that the working group is working very hard to
SM> court the manufacturers of cell phones and other mobile devices,
SM> which is why they have defined SVG 1.2 Mobile.

Yes. There is a focus on that market and it is helping get adoption
there.

SM> Why is there not an SVG 1.2 Web?

On the desktop, because the legacy HTML browsers were not interested in
adding the newer XML based specifications - SMIL, MathML, SVG  - into
their fragile rendering layers. New XML based stuff could go  in that
did not affect rendering, such as P3P as an obvious example.

SM> Is this audience not of at least equal importance?

Yes. And eventually, as the amount of modern standards based content
increases because of mobile use, the desktop folks are going to want to
see it too. At the moment there is a bit of a chicken and egg situation
- not so much content, so no pressure to upgrade, so not much content,
as the amount of deployed user agents  that can view it is below
critical mass.

SM>  Given the lack of a profile for mixed-namespace web
SM> browsers,

http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/

SM>  I can certainly understand the perception of many of my 
SM> colleagues that SVG is "not meant for use on the web", but for use 
SM> "within embedded devices".  Is this true?

No, its not true. Its meant for use on the Web, clearly. There has just
been resistance from some legacy user agents to adding it. Mozilla is a
classic case where that is not true, although there have been setbacks
in terms of getting code on the trunk, getting it enabled, having to
switch backend renderer because of licensing issues, etc. Meanwhile the
regular progress in SVG-enabled builds has been gratifying to see.

Amaya was another attempt, at W3C, to show how XHTML and MathML and SVG
could usefully be integrated together.

The decision to not do any SVG 1.2 in Mozilla is also disappointing,
since Mozilla will not be able to help SVG 1.2 get through CR. Although,
its not clear if that is a decision of the Mozilla foundation or just
the policy of a couple of people' I hope that latter and that wiser
voices will prevail. A bit of conditional compilation could easily make
"1.2' and '1.1' builds available and many in the SVG developer community
would I suspect be interested in helping to implement there.

SM> If, on the other hand, the developers of mixed-namespace web
SM> browsers (note that I'm specifically /not/ using the more generic
SM> term "user agent").

For more on that, please see
http://www.w3.org/2004/CDF/

SM>   Then I would think that the working group would be working
SM> more closely with the folks from Mozilla and Opera to see what things
SM> they see as hard to implement, and what things they see as easy.

SM> Having comments from a plug-in vendor that implementing something in
SM> their plug-in

Note that technically, the entire HTML renderer in WinIE is 'a plug-in'.
Win/IE is just an ActiveX container.

If implementors start with an SVG-only codebase and start extending out
to XHTML, that seems at least as valid as starting with (X)HTML and
expanding out to SVG. In some ways easier, because instead of 'DOM 0'
etc there is a DOM 2 codebase to build on.

SM> was relatively straightforward only serves to minimize the
SM> complexities of implementing a specification like SVG into an
SM> existing large, cross-platform code base.

I agree that integrating any rendering component into an existing and
large codebase is hard, depending on how well modularised and extensible
that base is, whether it is already using XMLparsing and an XML DOM and
is namespace aware, etc.

SM> Again, I may be missing something, here, and if I'm really way off
SM> base, let me know. I am honestly confused.

No, you are not far off base. Its unfortunate that some of the fighting
here has soured things somewhat. Hopefully we can put that down to a few
misguided individuals, and move on.

SM> End of meta comments...

I'm going to close my comments there and respond to the technical
comments in a separate email.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Wednesday, 10 November 2004 09:35:21 UTC