- From: Chris Lilley <chris@w3.org>
- Date: Wed, 10 Nov 2004 10:35:21 +0100
- To: Scooter Morris <scooter@cgl.ucsf.edu>
- Cc: www-svg@w3c.org
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