See also: IRC log
<trackbot> Date: 26 May 2011
<vhardy> ScribeNick: vhardy
ed: how do we find which features people think are the most important ones?
heycam: we discussed it
... 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?
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.
<ed> hmm... was it this one? http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_authoring_guide
heycam: we had two different
ideas. One is to start from a blank slate and rewrite as we
... 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
... 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: 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
... 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
... 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
... 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
... 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
... 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
... 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
... 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.
* HTML5 specs (LC period ends August 3)
* DOM 3 Events (proposed LC period end June 28)
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.
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.
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.
ed: can you be the chair of the SVG WG session.
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
... I would like to clarify that the SVG WG intends to work with the CSS WG on these things. Is that the expectation?
heycam: as in having a single
... 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
... on the CSS and SVG WG charters.
... we need to coordinate on what the charters communicate.
... discussion on email@example.com
<shepazu> trackbot, end telcon
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/That could work I think. Can we talk over email?// Found ScribeNick: vhardy Found Scribe: Cameron Found ScribeNick: heycam Found Scribe: Vincent Found ScribeNick: vhardy Scribes: Cameron, Vincent ScribeNicks: vhardy, heycam Default Present: heycam, +1.408.536.aaaa, Doug_Schepers, jwatt, rik, tbah, ed Present: heycam +1.408.536.aaaa Doug_Schepers jwatt rik tbah ed Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0122.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 26 May 2011 Guessing minutes URL: http://www.w3.org/2011/05/26-svg-minutes.html People with action items: ed heycam jwatt shepazu[End of scribe.perl diagnostic output]