SVG Working Group Teleconference -- 15 Feb 2009

<trackbot> Date: 15 February 2009

<ChrisL> come on, you slackers, get into work already :)

<ChrisL> hi erik

<ed__> hello

<ed__> do you want to call in every day or just some of the days?

<ed__> we have a polycom here, but we need to set it up

<ChrisL> i'm willing to call in every day

<ed__> ok, we're just missing a phoneline now :)

<shepazu> ChrisL: I sent the phone number to the SVG WG list

<shepazu> ChrisL: +61 299768755

<ChrisL> thanks doug

trackbot, start telcon

<trackbot> Meeting: SVG Working Group Teleconference

<trackbot> Date: 15 February 2009

Invited experts

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

DS: Robin Berjon has asked if we'd be interested in having him as an IE
... any objections?

[none heard]

RESOLUTION: We will invite Robin Berjon as an invited expert

<scribe> ACTION: Doug to do the paperwork for berjon's IE application [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action01]

<trackbot> Created ACTION-2458 - Do the paperwork for berjon's IE application [on Doug Schepers - due 2009-02-22].

DS: Zack Rusin from KDE expressed interest when discussing it with him at SVG Open

<scribe> ACTION: Doug to follow Zack Rusin's interest in being an invited expert [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action02]

<trackbot> Created ACTION-2459 - Follow Zack Rusin's interest in being an invited expert [on Doug Schepers - due 2009-02-22].

DS: Rob Buis, also
... he's from WebKit
... I contacted Zack a while back and I said that we're in the middle of 1.2T, so we don't have time to work on diffusion curves right now (the gradient stuff)
... but that when we're finished with it we'd follow it up again
... I have permission from plh to invited him, and it should be approved

<ChrisL> Joshua Andler

DS: I chatted with Josh Andler (from Inkscape) a few months ago

<ChrisL> http://www.w3.org/2000/09/dbwg/details?group=19480

DS: and his impression that we'd get back to him when we were done with 1.2T
... if we can make it clear to him to get him involved with stuff going forward, we could find features that Inkscape would be interested in

<scribe> ACTION: Chris to come up with topics of interest to Inkscape so we can approach Josh Andler [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action03]

<trackbot> Created ACTION-2460 - Come up with topics of interest to Inkscape so we can approach Josh Andler [on Chris Lilley - due 2009-02-22].

ISSUE-2213

ISSUE-2213?

<trackbot> ISSUE-2213 -- Some issues in the definition of suspendRedraw/unsuspendRedraw/forceRedraw -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2213

ED: do we need to address every weak spot in the 1.1 spec or whether we can live with how it is and focus on 1.2

MON AM1 - Issues

MON PM1 - SVG IG Japan report

MON PM2 - Core 2.0 and plans

<ed__> http://dev.w3.org/SVG/profiles/1.2T/errata/errata.xml

CM: nothing in the errata yet related to this (just ed's issue removing the exception for unsuspend*)

<ed__> sorry, wrong errata

<ed__> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml

<ed__> #remove_exception_on_unsuspendredraw

http://www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement

CM: summary of boris' comment is that these methods should just be hints

ED: i think that would be fine, it's just for the author to tell the UA to lay off updates for a while
... just to help optimisation
... it doesn't hurt if it redraws too much, performance would be worse, you might see things you shouldn't (half an updated tree for example)
... but that's what you'd see anyway if the feature wasn't supported at all
... so it's sort of a hint already

CM: does mozilla implement these?

JW: not really
... if you were doing drag and drop, user implements script that moves the x/y position across, and it would flicker with intermediate steps
... but now script changes are grouped together, so you don't get this flickering
... so there's not much use for it now

ED: there are other ways of avoiding redraws, e.g. building trees outside the document, then inserting that into the document

JW: a lot more performant to do it that way

ED: agreed
... in my experience it's more predictable to do it that way

JW: but if there is a lot of stuff in the document that you're manipulating, you wouldn't want to remove it to just do the modificaitons

ED: so there is still some use
... it's pretty common on svg-developers to ask "i have to update all these coordinates on all these <path> objects, and i don't want to have updates between"

JW: so what's the errata?

ED: this is suggesting that suspendRedraw is a hint

<ed__> http://www.w3.org/Graphics/SVG/WG/track/issues/2213

http://lists.w3.org/Archives/Member/w3c-svg-wg/2005JanMar/0439.html

ED: i would agree with jonf about suspendRedraw only working on the outermost svg
... although i guess in some cases it might be useful to do that as well

CM: would that scope the limiting of rendering to that subtree?

ED: yeah

JW: i don't see how we can reasonably do that
... limit it to subtrees
... if people make a tonne of changes under a subtree...
... all the drawing logic is global for the window
... you'd need to store it, it'd be a nightmare
... i think suspendRedraw should be document wide
... what's the use case for having it work on a subtree?

ED: that's the question
... i suppose you could have a mapping application with a view that modifications are prevented only in that part

CL: if you have a subtree that you know will have sporadic updates
... but in other cases, you might want every single change visible
... so they're constructing something, then when they're done, redraw
... you could give them something else to look at it, hide the subtree being modified

JW: switch off, you mean the user could? or the implementations?

CL: the author could. they'd clone that subtree, set display none, twiddle it, then add it back to the document

ED: you want to keep the old image in place while you do the updates

CL: right, it's a workaround

ED: there'd be other ways of getting the same effect

DS: i'm not convinced there's a pressing need for it on a subtree

ED: haven't checked the code, but i don't think we support suspendRedraw on subtrees

DS: you could be constructing something in a DOM, outside of the document, then just insert it into the document when you want it to render

ED: we should have some examples like that somewhere
... or the IG could make such examples to show that that's how you do that

DS: a best practice
... it might not be intuitive to some people

CM: what if there is HTML around the SVG? and you call suspendRedraw on the <svg>

<shepazu> (http://www.w3.org/Graphics/SVG/WG/wiki/SydneyF2F2009#Agenda)

CM: would that be difficult to prevent working on the HTML?

JW: i think so, yes

ED: for us it is not difficult to limit it to an SVG view
... you can suspendRedraw on multiple SVG fragments in an HTML document separately
... in our implementations, each SVG fragment is sort of a separate document
... so it's possible to do that

JW: when suspendRedraw happens, you could take a snapshot image?
... what happens if you have an SVG fragment in some HTML, and then the HTML changes causing the SVG fragment to translate or change size, what happens then?

ED: you have to buffer content

DS: it has to be interactive though

ED: so it's a static rendering, but the tree/events are different underneath

DS: so it shouldn't stop timelines, interactivity etc.
... for me suspendRedraw is just like that best practice... so the implementation effectively works on a cloned DOM (the unsuspended one) and then renders it all at once at the end
... would events still fire?

ED: you might get unintuitive results because the tree could be different from how it looks

JW: say i suspendRedaw, and i move a circle from the left to the right of the screen, and it takes a really long time for some reason
... if the user clicks on the circle on the left, as it appears, is that targetted to the circle?
... suspendRedraw shouldn't be used across really long times

DS: it should be used for complex DOM operation but you don't want it to all go the screen at once

ED: practically in every case i've seen, it's much better to build the changed tree outside the document since it's more predictable what behaviour you get
... so suspendRedraw is more of a hint to optimise content, not as predictable

JW: does it matter what the implementations does, if it's only meant to be used over a short time period?

DS: it should matter, we need to say what occurs

<ed__> http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGSVGElement

JW: the spec doesn't explicitly say that animation timelines, interaction, events, hit testing, etc. continue

DS: when there's something moving, when you click it, what is most intuitive/predictable/useful to the user/author for hit testing?

ED: you could still do workarounds like have some rectangle on the top that always catches events, for example

DS: i can see good arguments for using the apparent location or the real location

CM: i think using the real location would be easier

ED: we have no chance of knowing where the element was before

JW: i think the implementation should be doing optimisations, not having the author specify it

ED: when is a good time to redraw? it's a hint to say when the author would want a redraw.
... the spec doesn't say when to do redraws
... i agree that implementations should do optimisations

JW: it could be used as a hint to say you don't need to render between these points
... but that's different from it being a requirement that the user doesn't want to show these particular states

DS: i wouldn't want the implementation to render when i don't want it to

ED: there is a timeout, so you still might get a rendering
... the spec caps the timeout at 60 seconds

DS: should it throw an event when it unsuspends?

ED: or something that says when you render, in general

DS: suspendRedraw should only affect the rendering, nothing else
... should we have an event for when the suspend timeout occurred?
... i think it would be useful to have it whenever unsuspend happened

JW: before or after the paint?

DS: most usefully before the paint

CM: i'd think after the paint

ED: we could split it into two events...

DS: after paint would be ok
... so are we agreed that it isn't a hint but it's a demand?
... for me it's a question of allowing the author to control, definitely that painting doesn't happen

ED: i would say that it's possible for authors to prevent it working well, e.g. a long timeout
... anyone that implements it will look "worse" than those that don't

DS: permance yes, it's possible to misuse it
... at the same time, it's more predictable if it always works
... as an author, it's really good to have predictabilty

JW: i think 60 seconds is a bad maximum, it's very long
... so you've messed things up for the user

AG: the default values are normally something sensible

JW: lots of things could have changed in 60 seconds
... the user's interactions with it could be completely confused
... if 60 seconds, why have a limit at all?

CM: i agree
... what would be a reasonable limit?

CL: 60 seconds sound arbitrary to me

DS: not sure what it gives us if we change it

JW: 60 seconds gives the author something to shoot themselves in the foot with

ED: having no limit at all...

JW: 60 seconds is effectively no limit

DS: more sensible would be to have no cap

CM: 500ms or 1sec?

CL: if there's a huge amount of churn in the DOM, and you have redraw on, there might be lots of needless redraw

DS: you could set a longer timeout then

CL: sometimes the intent is to improve response times

DS: i'm concerned about changing something

ED: i think we shouldn't change it for 1.1
... better to try to find better solutions for core 2.0

JW: certain clarifications could happen
... could we put in the spec that suspendRedraw may be implemented by creating a snapshot of the element, and therefore ancestor elements that cause scaling might show pixellation?
... if there's a reasonable default, like 1s, the user probably wouldn't notice

ED: i'm not sure that in such a case, opera wouldn't show an image at all, maybe white or whatever the background was
... because there was no rendering at that size (if you change size)

DS: so should we allow this on svg fragment in html?

JW: in terms of whether it's an erratum, or a 1.2 thing, certain things can go in an erratum
... e.g. suggesting that you could implement it by buffering the rendering, then if it scales it might pixellate, or it might not render at all
... that and what happens with event handling
... it might be good to know that if you click you're going to be clicking on somewhere that might not be where the element is any more

ED: it can be used sometimes for optimising
... but i do prefer doing changes outside the document
... we could recommend using it only in certain situations
... in the most common case it's faster to update outside the document
... we could say that it's useful for when you have stuff in the document that you don't want to take out just to update
... we'd recommend the alternatives

JW: just an informative section?

ED: yes
... could you run in to the same problem with canvas?

DS: i guess you could have something that takes a long time to render

<scribe> ACTION: Cameron to suggest some rewritten text for these suspend methods [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action04]

<trackbot> Created ACTION-2461 - Suggest some rewritten text for these suspend methods [on Cameron McCormack - due 2009-02-23].

open ISSUE-2213

reopen ISSUE-2213

<trackbot> ISSUE-2213 Some issues in the definition of suspendRedraw/unsuspendRedraw/forceRedraw re-opened

Image view box cropping

DS: here's an argument to using viewBox in addition to crop

<ed__> ISSUE-2002

<ed__> ISSUE-2002?

<trackbot> ISSUE-2002 -- Controlling the implicit viewBox of raster images used in the <image> element -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2002

DS: in general, css does the simplest thing
... a lot of their approaches is satisfying 80% of use cases
... svg is good for handling 20% cases
... e.g. smil animation in svg versus css animations
... crop would handle a large number of use cases
... but it's slightly different from the way we do viewBox
... do people really want to do aspect ratio preservation on cropped parts of an image?

ED: i think it would be useful in some cases
... it does give more control
... if we reuse viewBox for cropping, then we would be able to address fewer use cases
... if we say that viewBox could override the intrinsic one, we wouldn't be able to control with preserveAspectRatio

AG: you might want to use crop in conjunction with viewBox

ED: the crop would be cutting out the image before doing a viewBox on it

DS: i'm thinking of width/height in combination of viewBox

CM: is this just for raster?

ED: crop is new, so it could apply to SVG content too
... it'd need more thought in that case
... an svg could have no width/height attributes and no viewBox, what happens?

JW: do you allow 100% to be intrinsic?
... if you have width/height set to 100% being displayed in an <img>, you fit it to the size of the <img>

ED: for an svg, do you want to control the viewBox or would you like to control the width/height/x/y on the root <svg>?

JW: viewBox can essentially let you give an x/y

DS: would it be worth saying in addition to width/height in SVG.next, be able to say defaultWidth/defaultHeight?
... so width/height=100%, and defaultWidth/defaultHeight would be suggested dimensions

JW: replaced element SVG stuff, the whole way we managed to solve svg embedded in html was with css replaced element rules
... the rule is width/height on the svg element are the intrinsic dimensions
... if the implementation can't resolve the percentages, then you fall back to the css 300x150 default
... the defaultWidth/defaultHeight fell by the wayside in lieu of the css replaced element handling

ED: i was suggesting that i take another look at the crop property and come up with a proposal for using that with svg
... clip is user space coordinates, only affects what gets drawn
... crop changes what the image is that is being rendered
... crop effectively changes what the input image is

[doug draws on a flip chart]

JW: we don't support viewBox on <image>, only preserveAspectRatio
... i think in the DTD it doesn't allow viewBox

CM: same for the viewBox IDL attribute, it's not on SVGImageElement

<anthony> http://www.w3.org/TR/SVG11/images/coords/PreserveAspectRatio.svg

struct-image-06-t.svg has pAR on <image>

http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-image-06-t.svg

those reference PNGs, though

<scribe> ACTION: Erik to play with preserveAspectRatio="something slice" to achieve something like crop but without using crop [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action05]

<trackbot> Created ACTION-2462 - Play with preserveAspectRatio=\"something slice\" to achieve something like crop but without using crop [on Erik Dahlström - due 2009-02-23].

CM: crop can also do inset

trackbot, action-2462?

<trackbot> Sorry, heycam, I don't understand 'trackbot, action-2462?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

trackbot, ACTION-2462?

<trackbot> Sorry, heycam, I don't understand 'trackbot, ACTION-2462?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

ACTION-2462?

<trackbot> ACTION-2462 -- Erik Dahlström to play with preserveAspectRatio=\"something slice\" to achieve something like crop but without using crop -- due 2009-02-23 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2462

JF: have you thought about rotating when cropping the image?

issue-2002?

<trackbot> ISSUE-2002 -- Controlling the implicit viewBox of raster images used in the <image> element -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2002

[discussions on flip chart]

ED: for these more complex transformed cropping, the author could just use clip-path in conjunction with transforming to get the same effect

ISSUE-2223

ISSUE-2223?

<trackbot> ISSUE-2223 -- Consider Changing BBox Behavior of Filters -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2223

JW: there are very few svg bugs that are repeated
... one is that we're clipping incorrectly on filtered elements
... it all comes down to x/y/width/height of the <filter> element
... defaulting to -10%,-10%,120%,120%
... this probably came from wanting to limit the size of the filter so that it doesn't work over the whole canvas
... it's not very hard to make a quick filter graph to work out what area you need

ED: i misunderstood your concerns then
... i agree it would be if the defaults would be what you want
... does it just apply to blur, or other filters too?
... blur is the most commonly wanted filter, and that extends beyond the bbox

JW: ignoring primitives for the moment
... so this area is causing clipping when you have filter primitives that extend outside of that box
... authors are blurring a lot, and it's going outside that default bbox
... the implementation can figure out the optimal area to apply the filter to
... to us it seems that it's causing more problems
... it's cuaisng confusion for authors, by resulting in clipping
... i don't see it as a use case for clipping, just use a clip path

ED: as a default, it might be easier if the implementation worked it out
... that would apply only when you have objectBoundingBox on the filter?

JW: No

ED: which cases then? what would be the default?
... you might have content that relies on this default area that the filter applies to

JW: when would you need that?

ED: for anything that inside a filter fills that area
... e.g. feFlood

CM: flood defaults to filling an infinite area

JW: you could still say that it floods the filter primitive subregion, but that subregion does not clip
... you could still have a region, the region is whatever (-10%,-10%,etc.)
... but if the filter still paints outside that area it doesn't get clipped

CM: so instead of having feFlood being clipped, change it so that it floods a particular area

JW: we're getting bugs where inkscape is calculating an optimal size, but it's getting it wrong, so now there is lots of SVG out there with incorrect width/height on <filter>
... omnigraffle gives the whole canvas as the filter region

ED: so that never clips

DS: in inkscape you have the opposite, they're trying to optimise
... but if it's a bit wrong, then you get weird clipping

AG: you could offset the feFlood

CM: but that would be a separate primitive?

DS: gaussian blur is the most commonly used primitive

ED: it's one that draws outside the bbox

JW: does it matter that blur is the only one that is important?

ED: well we could make a targetted fix just for blur

JW: and then if we add another one later that is commonly used?
... feOffset too

DS: it will be hard to get the tools to changed
... there's content out there that looks funky because of this filter clipping

[discussion about having x/y/width/height defining the filter region, so that primitives align to it, but allow painting outside it]

ED: if you have a subregion outside the filter region it would clip, but that's not common for authors to use

AG: would it be difficult in the filters module to have keywords for x/y/width/height?

ED: given that the content already exists, auto would have to be the default

DS: the only reason you want clipping is for optimisation, really

ED: sometimes you want to filter some parts of what you're filtering

CM: you could use the primitive subregions for that?

ED: probably
... i think feFlood, feOffset and feTurbulence generate images
... and they rely on a defined filter region
... all three of those extend outside
... maybe not feTurbulence

JW: if we decided that it wouldn't clip, then mozilla would put that in 3.1
... but as long as not too much content breaks, and that's what the WG wants

DS: so some people might be using the filter region for specific effects, rather than just for optimisation

ED: you can also clip out regions with a clip path that you want to filter

<scribe> ACTION: jwatt to propose some text for filter region clipping [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action06]

<trackbot> Created ACTION-2463 - Propose some text for filter region clipping [on Jonathan Watt - due 2009-02-23].

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2009Feb/0017.html

action-2463?

<trackbot> ACTION-2463 -- Jonathan Watt to propose some text for filter region clipping -- due 2009-02-23 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2463

SVG Interest Group

<jwatt> scribe: jwatt

DS: SVG IG is doing:

<ed_sydney> http://www.planetsvg.com/

DS: community site (work going slowly, but progressing)
... SVG Open - trying to pull resources
... probably 1st weekend in October, hosted by Google, hopefully also sponsored by Mozilla too
... going to launch planetsvg soon
... basically a community site: tutorials, news, developer/designer forums (basically the thing that's not set up yet)
... we'd like to start making torture tests
... find points where browsers don't align. edge cases
... whereas acid tests are more theoretical, we'd focus on problems that users are actually running into frequently
... Jeff Schiller is running the IG
... Brad Neuburg considering joining the IG

JF: SVG IG JP
... started activity last oct
... no conference, but had f2f meetings in oct, nov, jan

<jun> [ML] http://lists.w3.org/Archives/Public/public-svg-ig-jp/

JF: have Japanese mailing list

<jun> [Wiki] http://www.w3.org/Graphics/SVG/IG/wiki/Japan

JF: and wiki page
... page has pointers to meeting minutes
... group consists of the members:
... Takagi-san (KDDI)
... Yakuna-san (HTML WG)
... Goho-san (MS Japan)
... several other people related to JIPDEC (Japanese industrial standards)
... SVG IG JP has currently two areas of focus
... standardization and mapping
... translating SVG 1.2 Tiny to Japanese

<jun> [SVG Map] http://blog.svg-map.com/2008/07/the-index-of-sv.html

JF: working on SVG map specification, based on proposal by Takagi-san
... originally an independent specification, using different namespace, but IG JP agreed to work on new module
... currently contains layering, tilling and support for geo-coordinates, and special metadata useful for mapping
... IG JP originally saw this as a profile, but now think it should be a module because mapping may want to use other modules
... so the module would contain features useful to mapping, and not be a different svg

DS: tiling is a prefetching strategy as well as a region of interest issue

JF: Level of Detail is also useful for mapping, but thinking to exclude it from the layering and tiling module
... all client side - not specifying anything server side
... question to the WG: does the WG want so split out Level of Detail and z-index from Layering and Tiling?
... or keep them together in a single module?

CM: I'd like to see more details to see if it's general enough to go in SVG instead of mapping

DS: it's not just mapping - anything where you have very different level of detail
... circuit diagrams for example

JF: plan to come up with first draft in April
... will submit to W3C and JIS
... the original map profile [link above] has z-index and LoD too

RESOLUTION: SVG WG recommends that SVG IG JP work on separate tiling and layering module, and the SVG WG will consider the case of z-index and LoD

ISSUE: Investigate the use cases and requirements for z-index

<trackbot> Created ISSUE-2226 - Investigate the use cases and requirements for z-index ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2226/edit .

ISSUE: Investigate the use cases and requirements for Level of Detail

<trackbot> Created ISSUE-2227 - Investigate the use cases and requirements for Level of Detail ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2227/edit .

<shepazu> ACTON: shepazu to look into how SVG IG JP can submit Layering and Tiling Module to W3C/SVG WG

<shepazu> ACTION: shepazu to look into how SVG IG JP can submit Layering and Tiling Module to W3C/SVG WG [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action07]

<trackbot> Created ACTION-2464 - Look into how SVG IG JP can submit Layering and Tiling Module to W3C/SVG WG [on Doug Schepers - due 2009-02-23].

<animation> element with regards to mapping

JF: a member of SVG WG IG would like to know if the <animation> element will definitely be supported in future SVG specifications or not

<ed_sydney> concern raised from SVG IG is that <image> in SVG 1.1 supports referencing svg, but it's forbidden in 1.2T

<ed_sydney> and not supported in 1.1 tiny

ED: I would expect the next major version of Tiny to allow <image> to reference SVG, but whether or not it runs animations or scripts, should be defined properly

DS: In the bucket module I'm writing about the different usage scenarios for SVG
... there are a bunch of issues

<shepazu> http://www.schepers.cc/svg/blendups/embedding.html

DS: if you look at this document in Opera, CSS backgrounds should display, but they should not have animation
... when they are used for <image> in HTML they should display and have animation, but no script
... well, look at the page

ED: we should have the table for SVG referencing elements

<ed_sydney> DS: I would expect <svg:image> to behave just like <html:img> wrt to scripting/animation etc (look at the above url)

ED: I would recommend either <image> or <animation> for tiles

<ed_sydney> ...image for static tiles where you don't need to know exactly what element inside the tile document was clicked

<ed_sydney> ...animation for the ones where you need to know

<ed_sydney> scribe: ed_sydney

svg bucket module

CM: there are various things we need to have somewhere

DS: bigger issues in svg need some coordination
... for reuse and so on
... there's a bit of talk about it in 1.1 and 1.2T, but there's not something you can actually reference
... spec doesn't talk about some common rpoblems and how to solve them
... WHOOOOAAA!

(the room next door also wooooes)

scribe: i don't think we've decided if it's going to be a module or a profile

CM: would you also want to have an integrattion stpec?

DS: not appropriate to have every spec split into tiny pieces
... a spec has to have a certain length or content to make it useful
... we're breaking down the spec into modules, but i think there should be one larger spec that covers all of svg

CM: so for common infrastructure, and for solving things that we haven't resolved on yet

DS: for addressing common usage scenarios

CM: so not for random things only

DS: i'm thinking core of the language
... so common infrastructure etc

CM: still feels a bit abstract
... and for modules we've already started on
... we might need to have some hooks in tiny that we could put in, but we can't change everything in tiny (though we can errata some things)

AG: we should first finish the errata for 1.1, before starting on 1.2T errata

DS: part of me wants to make this a short spec, for usage scenario stuff, but part want to make it a core type spec, but it's a bit early to decide

AG: right
... there's no place for it now, but the wording we put it in we can reuse later
... sometimes we can lose track of the problem in issues, if left alone for a long time
... fleshing the wording out makes more sense, and sticking it into the bucket spec

CM: i'm happy for this to be a place we put things for now
... but i'd like to know what's our plan with it
... at the moment mozilla says they're targetting 1.1, and not really targetting 1.2T...how do you (JW) think things should progress? we can't keep doing 1.1 errata forever

JW: I assume 1.2 full or core 2.0 or whatever the next iteration happens to be
... a few years away

DS: what if we put things into a spec, and plan to go with that in a couple of years?

JW: i'm guessing there might still be some incompatibilties 1.2T <-> 1.1 that we need to look at

AG: full 1.2 started sort of like a bucket, and then was split into modules

DS: wrt to inconsistencies, 1.1 had alot of problems, so if the next version addressed those, and tried to keep compatibility, but i don't mind if we clean up the 1.1 spec
... especially if it helps with html integration

JW: what's the reason for having modules?

DS: smaller easy to write, easy to review

JW: why would a module be shorter than a chapter?

DS: it's not, but it's 400page spec vs 40 page chapter/module
... we do get complaints about the length of the spec

JW: but that would be the same for a profile consisting of modules

DS: but the moduels would have got some review before then
... a module can go on top of another module
... it's standalone, and some other specs can reference that part only
... like CSS

CM: the infrastructure isn't there yet
... liek override this sentence, and then do this other thing
... in tiny

DS: integration is one part of the bucket spec

CM: modularizing is a tradeoff
... ease of review vs how things fit together

DS: there are benefits of both ways
... we're almost done with some of the modules already
... but there are integration issues

JW: the problem with module is that you might need to change the modules after they've gone through review, unless you sync with a profile or integration spec
... in which case the mdoules aren't very different from chapters anyway

DS: modules are easier to work on in a way

JW: maybe for very independent modules

DS: tiling and layering would be quite different

CM: some things might be easy to separate, but some other things like compositing and filters change some base things, like how stuff renders
... and you might need to reference other modules

JW: for some things it's useful to have one spec, so you can search in it, and to define interaction etc
... calling it a module doesn't do away with that

CM: does our charter define our roadmap wrt to modules vs monolithic spec?

JW/DS: don't think so

JW: many things interact, so I'm leaning on favoring the monolithic way of doing things
... I know TOR was concerned about modules, and which ones to support

CM: so advancing at different rates, and the reason that you may need to change integration points as it goes aliong is a concern

DS: it's also a concern not to obsolete 1.2T too early
... JIS needs it to be stable

AG: that's the reason for having the modules, so that we could build them on top of 1.2T
... we could fold the modules into a monolithic spec at a later point

CM: might waste efforts dealing with integration points

DS: progressing documents to LC or CR, finding out if there are any problems....
... we could advance all the modules up to CR individually, and then work on integration issues, then decide if we go with separate modules or a monolithic spec

JW: sounds like a good idea

DS: i'm not suggesting that integration issues are done late, but that they're done as an ongoing task
... but with extra focus at the end
... we don't want to lose track of the features of the language

JW: so we stick things into the bucket spec we don't know yet where they should go
... are we aiming for the moduels to result in a tiny spec or a full spec?

DS: there's only one spec going forward, for both mobile and desktop

RESOLUTION: we'll continue making modules (with ongoing integration work) and we'll park each of them in CR until they're all in CR and then we'll do a final integration pass before publishing modules for reuse with older specs and a single monolithic spec defining the full language. We will only publish modules to REC if they're needed for reuse by others, otherwise just leave it as chapters in the full spec

DS: JF will you check with JIPDEC/JIS to see if this works for them?

<scribe> ACTION: jun to follow up with SVG IG JP on the svg wg roadmap [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action08]

<trackbot> Created ACTION-2465 - Follow up with SVG IG JP on the svg wg roadmap [on Jun Fujisawa - due 2009-02-23].

JF: as new modules are proposed, how do we decide what goes into svg 2.0?
... and what stays a module

DS: we decide on what's a good set of features for svg and go with that

JF: maybe a message on the 1.2 full spec page to say that it's not going to REC?

JW: seems like a good idea
... and say what we are going to do

<scribe> ACTION: DS to update link http://www.w3.org/TR/SVG12 to point at 1.2T and to change the dated link to say that work is aborted on 1.2 full, svg 2.0 will be the next version, the latest rec is 1.2T [recorded in http://www.w3.org/2009/02/15-svg-minutes.html#action09]

<trackbot> Created ACTION-2466 - Update link http://www.w3.org/TR/SVG12 to point at 1.2T and to change the dated link to say that work is aborted on 1.2 full, svg 2.0 will be the next version, the latest rec is 1.2T [on Doug Schepers - due 2009-02-23].

AG: we should also communicate the plans to the community

- DRAFT -

SVG Working Group Teleconference

15 Feb 2009

Attendees

Contents