SVG Working Group Teleconference -- 26 May 2011

<trackbot> Date: 26 May 2011

<vhardy> ScribeNick: vhardy

SVG2 features and approach

ed: how do we find which features people think are the most important ones?

heycam: we discussed it previously.
... I think we agreed to use a tool to do the poll.

shepazu: I am not comfortable using an external, non-w3c tool.
... have you heard about the community groups?
... W3C has community groups and there will be an infrastructure for forums and polling. This should help collect information.
... this is not urgent, right?

vhardy: some initial focus would help our efforts.

shepazu: I think we can wait a couple months. Does that make sense? Are we going to lose momentum?

heycam: there is enough things to work on in the next two months.
... but people are mentioning things on the list right now.

shepazu: we can still collect it?

vhardy: how?

shepazu: it has been a pretty short thread so far, except for contributions from Dr. Olaf and David Dailly.

heycam: should we take the topics from the mailing list and put it on the wiki?

shepazu/vhardy: yes, good idea.

vhardy: who does that?

heycam: we need to chose somebody.

shepazu: I think I should normally do that, but right now, I am too busy at the moment.

vhardy: when do we need this by?

shepazu: I do no think this will change in the next two months.

heycam: I think we still should collect the threads right now.

shepazu: there was some talk about having no new features.

heycam: there will likely be some new features.

shepazu: implementors can still implement or not implement certain features.
... if two implementors want to do a feature, there is a pretty good rational for doing it.
... this discussion is speculative at this point. But we will be driven by implementation, because of the CR criteria.

heycam: we do not want to specify a whole bunch of features with no implementation input.

<scribe> ACTION: heycam to collect initial email feedback on SVG 2.0 features the group should take on into a Wiki. [recorded in http://www.w3.org/2011/05/26-svg-minutes.html#action01]

<trackbot> Created ACTION-3045 - Collect initial email feedback on SVG 2.0 features the group should take on into a Wiki. [on Cameron McCormack - due 2011-06-02].

<scribe> ACTION: shepazu to send emails to the stakeholder mailing lists (www-svg & svg Yahoo developers) lists to solicit feedback on the high priority features the group should take on, preferably with use cases and requirements. [recorded in http://www.w3.org/2011/05/26-svg-minutes.html#action02]

<trackbot> Created ACTION-3046 - Send emails to the stakeholder mailing lists (www-svg & svg Yahoo developers) lists to solicit feedback on the high priority features the group should take on, preferably with use cases and requirements. [on Doug Schepers - due 2011-06-02].

ed: I wanted to talk about the SVG 2 process. jwatt wrote a wiki page on that.

vhardy: link?

<ed> hmm... was it this one? http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_authoring_guide

<heycam> http://www.w3.org/mid/4D8AC692.8030205@jwatt.org

heycam: we had two different ideas. One is to start from a blank slate and rewrite as we go.
... and not copy the original SVG text.
... the other method is to start off from the SVG 1.1 text, mark all of it as unreviewed. And then migrate as we go.

shepazu: that is a fair summary.

heycam: there were various points.
... but the starting point is the biggest thing to resolve.

shepazu: my approach is to start from scratch and make sure we get everything right?
... how do we make sure we get everything we need in the spec? There were discussions about this. There are two factors that weigh for my argument.
... one, we have established in previous telecons, we are not going to fold-in features that we now share with CSS. We will reference them, e.g., "a conforming SVG UA implements filters". This will knock out at least 3 chapters.
... another argument is that we have such legacy material in the spec, and it is so hard to fact check every bit, that not starting from a black slate will be complex very rapidly.
... with SVG 2, we should be freeer about how we can bring things in.
... this is the cruz of my argument, I think it is simpler to start from scratch. I did that approach for most of the DOM Level 3 spec.
... the editors of the DOM Core new spec. have been able to incorporate the new DOM Level 3 event spec. much more quickly compared to what I went through.
... it will also be easier to unify our language.

heycam: I have some comments, but may be jwatt can comment first?
... jwatt?

jwatt: I just want to see what is changing as we go along, so this is why I would like to start from the existing spec., to see a kind of linear progression.
... starting from scratch, we will see incompatibilities like between SVG Tiny and SVG Full.
... the idea of trying to keep track of what is kept from the old spec. seems very complex to me.

vhardy: could both of you elaborate on the problems you ran into before?

shepazu: one of the problems with DOM 3 Events was keeping track of what I had or had not changed. This was tedious.
... may be I was not methodical enough.
... If I had to do it again, I would mark all the spec. as unreviewed and then mark it as I go.
... for SVG 1.2, did it help to have existing text in place?
... SVG Tiny 1.2 was SVG 1.1 cleaned up with some features added. I don't think it was a success. It was hard to find what had or had not been edited.

heycam: I feel that starting with the existing text does not just mean we would review paragraphs one by one. We may rewrite parts of the text. But we would have to methodically mark the text so that we make sure that any removed text gets an equivalent new text. We should also make sure everything happens under version control.

vhardy: our specs. are under version control. Are you talking about a better use of version control?

heycam: with Mercurial, we would have better version control support.
... may be we should keep a version of the old spec. and pull things in from the new document.

jwatt: to be able to compare with the SVG 1.1 spec. is really critical.

shepazu: we can just diff two different documents.

heycam: that is difficult because the new document can be structured completely differently.

jwatt: diffing two documents shows you the differences between documents and they are compacted in a single item.
... source control tells you what happens in a given commit.

shepazu: it takes discipline to track all this.

jwatt: changes must be done in logical order.
... for example, a change where we update the way links are done in the spec.

shepazu: to me, it comes down to having to read both the old and new document and check that there are no contradictions.
... the SVG 1.1 spec. is confusingly organized, some pieces are scattered. e.g., pointer-events

jwatt: I have not problem with a commit that butchers pointer-events and replaces it with a new text.
... I think we really need to be able to track individual changes to the spec.
... my hope is that at the end of the process, we have fewer incompatibilities between the new spec. and the old one.

shepazu: I understand what you say, but I do not think it will bear out. It will be so much more effort to work around existing passages of text instead of writing new text.
... I think the argument will come down to a few people understanding fully any particular issue, understand what SVG 1.1 says and then rewrite for SVG 1.2
... I do not think that incremental changes are the way SVG 1.2 will come about.
... I think looking at the diff would not be the way to do it. The process will be to compare idea to idea, not line to line.

jwatt: it does not need to be line to line. It needs to be incremental.

shepazu: I think we are not going to agree. We do not necessarily need to pick one approach.
... we may start from different starting points and see what works best.
... having a lot of experience working with existing documents, including SVG 1.1 and SVG 1.2 tiny, I know it does not work.
... I am personally not willing to work that way.
... I do not want to mash bits and pieces.
... if the rest of the group wants to work that way, that is fine.
... if we start from the existing spec., it is going to be really hard to do anything.

jwatt: I am afraid that we will lose things if we start from a clean slate.
... like with new software just replacing old one.

shepazu: there are limits to that analogy. But it is true that with software you may lose functionality.
... specs are not software. If there is wording that is not well understood, then it should not be in the spec: how do we test it? how do we explain it?

jwatt: as an implementor, the spec. is a ton of things that are quite subtly connected and it is just by implementing that you realize the subtleties.

shepazu: I do not want to force my way down everybody's throat.
... if the group wants to start from 1.1, they it should.
... for the parts I edit, I would prefer to start from scratch.

heycam: starting from 1.1 means that you would have all the document styled away. When you start on a new section, you do not necessarily have to start from the previous version. You can edit or replace.
... the difference may not be as big as we think. But at least you see what is being added/changed.

ed: that makes sense. There will be other types of changes too.
... in the end, we will still have to look at both specs.

shepazu: yes, people will have to review two specs.

<ed> both, might mean all three, or more specs fwiw

shepazu: there may be more dramatic changes.

heycam: most of the time, when it comes to take an old paragraph from the spec., you would not be doing minor changes but writing things from scratch. But having the old text in the file, you still have the connection to the old text. But you are not burdened by the old text.

shepazu: I do not understand how it is important to delete the old text.

jwatt: it helps for sections where the changes are not too dramatic.
... and it does not stop the complete rewrites for the sections/chapters that need it.

shepazu: I am not sure which sections should remain. I think we should rewrite all sections of the spec.
... why don't you start as you suggest?

jwatt: I would like to hear other people's opinion.

heycam: the argument to track the changes we make is convincing to me so that we know how the spec. changes.
... on the other hand, I am not sure how much will be completely rewritten v.s., edited.
... even if all the text needs to be rewritten, it still has value to see how the spec. is progressing.

shepazu: from an external review perspective, I think it sends very different messages. If we keep the old text, reviews are going to be difficult.
... I think this is adding overhead.

heycam: I think there will be overhead but not much.
... I think we could try it and then see that, if the overhead is too much, then we will adapt our process.

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

VH: starting from scratch sounds compelling, btu the volume of work is kind of staggering
... it's a huge spec, if we're talking abotu rewriting every paragraph in the spec
... my gut feel is that I'm more comfortable with evolving and fixing
... having implementing large portions of the spec, I don't have that many problems with it
... like anything it can be improved, but I don't think everything should be rewritten
... I do find there are portions that are well written
... it's also a difficult exercise
... that it has problem therefore we have to throw everything away concerns me a bit
... I also share the concern about seeing things evolve
... starting from scratch it's hard to see how you've evolved
... I agree in the end you'll need to compare two specs
... but the evolution will help you

DS: I think there are sections we won't rewrite in the end
... neither approach says "oh we can't have any text from the old spec"
... each one says we're going to review everything we need as we go
... like I said, I don't think I will persuade you all, so I'm not going to pursue it

VH: a followup, who's committed to being an editor of the spec?
... I think the editors should have a lot of weight in the process
... since they're the ones doing the work
... the process should serve and help them, and not be imposed on them
... as much as we work with consensus, people who are doing the day to day work should have more weight

JW: SVG has had a much more open policy of everyone editing the spec
... some people do more work than others, obviously

DS: in reality not everybody edits
... it's a nice idea, but in reality most people don't edit, or edit very little

JW: once we're in mercurial I'll edit a lot more

ED: are we getting closer to deciding what to do here?

DS: since I'm in the dissenting voice, I'll retract my suggestion

ED: there's some overhead in removing the old text, but probably not that much
... but I'm fine with starting with the old spec and removing parts

DS: if we do it this way, I would really really ask that we not have the old text visible

<scribe> Scribe: Vincent

<scribe> ScribeNick: vhardy

shepazu: we should indicate to reviewers which parts people should be looked at.
... even having an editor draft with things marked as "do not review", I still get reviews on that part.

ed: then we will need invisible text (commented out or invisible).

shepazu: I am worried because the spec. is not organized in a good way and starting from the existing spec. may be difficult.

heycam: at some point, I suggested to put the whole spec. in a single document.
... this was in part to give more flexibility to the spec. organization.

ed: we reached some kind of consensus on how to proceed. We need an action on someone to do the initial commit.

<scribe> ACTION: jwatt to do initial SVG 2.0 commit into Mercurial. [recorded in http://www.w3.org/2011/05/26-svg-minutes.html#action03]

<trackbot> Created ACTION-3047 - Do initial SVG 2.0 commit into Mercurial. [on Jonathan Watt - due 2011-06-02].

RESOLUTION: The group decided to start the SVG 2.0 from the SVG 1.1 2nd edition with all the content commented or styled out and will proceed by reviewing and updating content incrementally.

Info on upcoming review periods:

* HTML5 specs (LC period ends August 3)

http://www.w3.org/News/2011#entry-9105

* DOM 3 Events (proposed LC period end June 28)

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

ed: do we need more time to review the specs?

heycam: are there specific things we need to pay attention to?
... we do not particularly depend on any features on the DOM Events Level 3. Is that right?

shepazu: I am too close to the problem. I do not think it is going to affect SVG particularly one way or the other.

heycam: there might be interesting things to give input on.

shepazu: it has a very good keyboard model, which is good for SVG. But things like the event model have not changed.
... now can omit the last parameter in add/removeEventListener. I cannot think about anything SVG specific.
... may be SVG 2.0 will add new events.

ed: the reason I asked is that the email asked if we needed more time for review. If we do not need more time, then we can move on.
... the other spec. is the HTML5 spec.
... there is a bit more time for this spec.

heycam: there are SVG related things such as parsing, but we have moved on from these issues.

SVG Compositing - the "plus" mode

http://www.w3.org/mid/645F9695BBAE0846A01542C63A9B8CB23D50E68CB8@HQMAIL03.nvidia.com

ed: do we have an editor for this spec.

heycam: I thought Alex or Rik would take over.

ed: we can talk about it on the mailing list.

SVG F2F

http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011

ed: shepazu, could you put up a questionaire for the F2F?

heycam: I think we can do it as chairs.

shepazu: I do not think I could get it in a timely manner.

<heycam> ed, http://www.w3.org/2002/09/wbs/showwb

<scribe> ACTION: ed to put up a questionaire for the Seatle F2F to clarify dates and attendance. [recorded in http://www.w3.org/2011/05/26-svg-minutes.html#action04]

<trackbot> Created ACTION-3048 - Put up a questionaire for the Seatle F2F to clarify dates and attendance. [on Erik Dahlström - due 2011-06-02].

vhardy: we have a request at Adobe to host. I am waiting for an answer.

SVG Open 2011

ed: can you be the chair of the SVG WG session.

heycam: yes.

SVG WG charter.

<shepazu> http://www.w3.org/2010/09/CSSWG/charter.html

<shepazu> http://www.w3.org/Graphics/SVG/WG/charter/2010/Overview.html

shepazu: there are some contradictions in the wording, e..,g CSS Animations v.s., Web Animations (we had agreement on the wording), CSS 2D/2D transformations.
... I would like to clarify that the SVG WG intends to work with the CSS WG on these things. Is that the expectation?

vhardy: yes.

heycam: as in having a single spec.
... ?
... we had a discussion about the transforms spec. during the FX call this week and decided to keep two separate specs. because we have lost an editor.

shepazu: for this discussion, I think I would like to coordinate with the CSS WG on the priorities, the spec. titles and the expectations on which specs. we work on together.

heycam: yes, I agree in particular about the Web Animations work.

shepazu: I'll edit our charter first. Then we should talk with the CSS WG to keep things in sync.

heycam: yes, we need to have the same idea about how we are going to work together.

shepazu: please send comments to me.
... on the CSS and SVG WG charters.
... we need to coordinate on what the charters communicate.
... discussion on public-svg-wg@w3.org

<shepazu> trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

26 May 2011

Attendees

Contents