13:49:23 <RRSAgent> RRSAgent has joined #svg
13:49:23 <RRSAgent> logging to http://www.w3.org/2009/06/12-svg-irc
13:49:25 <trackbot> RRSAgent, make logs public
13:49:25 <Zakim> Zakim has joined #svg
13:49:27 <trackbot> Zakim, this will be GA_SVGWG
13:49:27 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:49:28 <trackbot> Meeting: SVG Working Group Teleconference
13:49:28 <trackbot> Date: 12 June 2009
13:49:31 <ed> ed has joined #svg
13:49:41 <heycam> Scribe: Cameron
13:49:42 <heycam> ScribeNick: heycam
13:49:56 <heycam> Topic: Layout
13:53:53 <heycam> CM: flex box is progressing in css, what about other layout?
13:54:14 <heycam> CL: there's multi column
13:54:33 <heycam> ... might be dropped in implementations
13:55:39 <heycam> ... there's grid, which is mainly used for asian typography
13:56:13 <shepazu> shepazu has joined #svg
13:56:19 <heycam> CM: not intended for big boxes of content in the grid?
13:56:20 <heycam> CL: no
13:56:50 <heycam> CM: template too
13:57:24 <heycam> http://www.w3.org/TR/2009/WD-css3-layout-20090402/
13:57:38 <heycam> DS: xsl wants areas that text flows in to, and areas that grow to fit the text
13:58:51 <heycam> ... we should make sure that whatever we do for text shape should work for those
13:58:51 <heycam> ... need to gather use cases & reqs for text flow shapes
14:00:01 <heycam> CM: a good way forward might be for someone to look at the flex layout and see how applicable it is to svg
14:02:04 <heycam> CL: as for the text flow problem, our flowText from the 1.2 draft is pretty different from what xsl needs
14:02:52 <heycam> ED: i'm more interested in the graphical content layout problem
14:03:55 <heycam> DS: i'm still interested in the one way constraints stuff
14:05:26 <shepazu> DS: part of flexbox, as I understand it, is essentially the springs-and-struts model
14:05:27 <heycam> CM: i feel like high level layout (like flex boxes) plus one way for relative positioning might be a good balance
14:09:46 <heycam> CM: the springs can't cross boxes, with flex boxes
14:12:26 <heycam> DS: if i have a rectangle and i want it to be a particular size, relative to other things around it, with a min height/width, seems like you could do that with the constraints
14:14:40 <heycam> CM: one way constraints are less useful than i'd thought a while ago
14:15:33 <heycam> DS: for some things i still want to use calc(bbox(some object) + 5) kind of functionality
14:16:15 <heycam> ... it's possible people would misuse the simple stuff and try to make things that are too complex
14:17:12 <heycam> CM: also seems bad to require complex implementations to solve simple use cases
14:18:06 <heycam> CL: for text flow, we limited our 1.2 draft solution to just simple paragraphs
14:18:13 <heycam> ... to avoid arbitrarily complex xsl-like formatting within svg
14:19:11 <heycam> ... want the sweet spot where small amount of functionality gets you lots of use
14:20:24 <heycam> DS: two problems with canned layout solutions
14:20:32 <heycam> ... one, they each only solve a particular problem
14:20:50 <heycam> ... if there's no underlying model, then it becomes harder to define and to understand how they work together
14:22:38 <heycam> CM: swing has a unifying model of rectangular components with min/preferred/max width and height
14:24:21 <heycam> CL: systems can work together fairly easily if you limit them to not work together
14:24:27 <heycam> ... if they're mutually exclusive
14:24:39 <heycam> DS: things tend to break down to specific syntax for those solutions, then
14:25:00 <heycam> ... so we need an underlying model to make them work together
14:25:14 <heycam> ... and so that people can understand how they work together
14:26:53 <heycam> CM: i think people will want to use multiple high level layouts together
14:26:56 <heycam> DS: maybe some you can combine some you can't?
14:28:04 <heycam> ... one thing that would be an easy win:
14:28:12 <heycam> [doug talks about the "chain font" example]
14:28:50 <heycam> ... so let's just allow shapes flowing along a path
14:29:05 <heycam> ... i think what goes along with that is navigation
14:30:30 <heycam> ... an implicit ordering
14:30:50 <heycam> CM: so like implicitly determining the nav-* properties
14:30:50 <heycam> DS: so for this pretty much textPath, but shapePath
14:31:08 <heycam> ED: i've had cases where i wanted to place images along a path, it's pretty difficult
14:31:22 <heycam> CL: the trivial case where someone wants the layout and gives a straight line path
14:32:16 <heycam> DS: how do these shapes become anchored?
14:32:26 <heycam> JW: two things tied into this shapes on a path
14:32:31 <heycam> ... i'd like percentages on a path
14:32:52 <heycam> ED: another way of doing it is markers, but they're not easy to use
14:33:04 <heycam> JW: also you might want minimum distances
14:34:03 <heycam> ... also, places objects on vertices
14:34:12 <heycam> ... like putting objects on each point of a star
14:35:14 <heycam> DS: so reusing textpath for shapes, many of these things we're thinking of for shapepath could be used in textpath too
14:35:25 <heycam> ... so laying out glyphs and shapes are similar
14:36:28 <heycam> CL: <shapepath>A b c <rect> <circle> d e f</shapepath>
14:37:22 <heycam> DS: i've been thinking about how to do connectors, how to connect things to arbitrary points on a shap
14:37:27 <heycam> ... often you want limited connection points
14:37:32 <heycam> ... e.g. for circles, top bottom right and left
14:37:39 <heycam> ... if it's a star, only on the points
14:37:58 <heycam> ... so i want to identify those points through some syntax, or have as a child of that shape, a bunch of <point> elements with their actual positions
14:38:16 <heycam> ... those <point>s could be constrained to be at particular points on the shape
14:38:28 <heycam> ... each could have an id, and you could say that one is the anchor point
14:38:50 <heycam> ... or you might have anchor-x, anchor-y on a shape
14:38:56 <heycam> CM: it's like setting the baseline for your shape
14:39:33 <heycam> ... if the <point>s are going to be used for other things, like connectors, then would make sense to reuse them
14:39:39 <heycam> ... otherwise, just use the anchor- attributes
14:41:11 <heycam> [doug draws]
14:42:30 <heycam> CL: can we do text on a path where each glyph has a constant rotation
14:43:15 <heycam> JW: there's marker orientation
14:46:01 <heycam> CM: i want automatically <use>d things along a path
14:46:03 <ed> there's no way to disable the rotation on textpath though, no @orient attribute
14:46:05 <heycam> ... to fill up the path
14:46:20 <heycam> ... to do train line like paths
14:46:34 <heycam> DS: you could have a stroke-dasharray type of mechanism to specify those repeated things
14:48:15 <heycam> DS: you could specify like background-repeat
14:48:58 <heycam> ED: it's also like gradient spread method... reflect, pad, ...
14:49:22 <heycam> s/pad/pad, repeat/
14:49:49 <heycam> DS: currently text has an interesting property where later glyphs are drawn on top of earlier glyphs
14:51:02 <heycam> ... perhaps we want to allow painting glyphs in reverse order
14:53:29 <heycam> ... or maybe an arbitrary order
14:53:45 <heycam> ... painting order
14:55:52 <heycam> ... maybe you want to allow specifying multiple shape repeat patterns that get drawn over each other
15:00:56 <heycam> action: doug to write up a shape path proposal
15:00:56 <trackbot> Created ACTION-2616 - Write up a shape path proposal [on Doug Schepers - due 2009-06-19].
15:10:50 <shepazu> should also think about potential join points, might apply to fonts, depends on how complex it did it
15:12:26 <shepazu> ... for patterns
15:16:50 <heycam> DS: there's a problem with tspan and the semantics of a word
15:16:55 <heycam> .... would be useful to define that tspan does not affect the underlying semantics of the text, it's just the positioning
15:17:08 <heycam> ... you can have multiple tspans that comprise a single word
15:17:29 <heycam> ... only a space in english defines a separate word
15:17:55 <heycam> ED: we should define how collapsed whitespace is assigned to particular text elements
15:19:02 <heycam> CL: <text font-size='50'>a[space]<tspan font-size='10'>[space]</tspan></text>  -- how big is the single collapsed space?
15:19:44 <jwatt> JW: I'd say the smaller of the two
15:22:07 <ed> raised ISSUE-2280
15:26:50 <heycam> CL: you can consider the shape-flowing-to-variable-width-path as a displacement map problem
15:26:54 <heycam> ... the path defines a complex gradient
15:26:59 <heycam> ... which you use as the displacement map
15:30:01 <heycam> action: cameron to play with css flex box to see how applicable it could be to svg
15:30:01 <trackbot> Created ACTION-2617 - Play with css flex box to see how applicable it could be to svg [on Cameron McCormack - due 2009-06-19].
15:34:09 <heycam> Topic: Simple keywords
15:35:00 <heycam> CM: i was thinking about vector-effect='strokeBelowFill'
15:35:27 <heycam> ED: or filter='drop-shadow'
15:35:57 <heycam> ACTION: chris to add a strokeBelowFill canned vector effect
15:35:57 <trackbot> Created ACTION-2618 - Add a strokeBelowFill canned vector effect [on Chris Lilley - due 2009-06-19].
15:42:28 <heycam> DS: i want to make sure that large stroke on text, where the stroke is behind the fill, works.  where the stroke around the individual glyphs doesn't overlap.
15:42:34 <heycam> CL: yes that's possible with vector effects
15:42:48 <shepazu> http://chapelhillcomics.com/sample/TOP-LOGO.jpg
15:43:27 <ChrisL> ChrisL has joined #svg
15:43:38 <ChrisL> rrsagent, here
15:43:38 <RRSAgent> See http://www.w3.org/2009/06/12-svg-irc#T15-43-38
15:46:24 <ed> (discussion on vector-effects)
15:50:07 <ed> Topic: ISSUE-2042 - Consider adding adding non-NS linking syntax
15:54:59 <heycam> Topic: xlink:href
15:55:03 <heycam> ISSUE-2042?
15:55:03 <trackbot> ISSUE-2042 -- Consider adding adding non-NS linking syntax -- RAISED
15:55:03 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2042
15:55:39 <heycam> CL: at one point i suggested combining the thing that holds the IRI and the thing that holds the type into one attribute
15:55:51 <heycam> ... so <image> would have src, and <a> would have href
15:55:56 <heycam> ... and have a generic category for other
15:56:07 <heycam> DS: so define it in terms of xlink
15:56:15 <heycam> CL: we'd define the mapping to xlink for the subset of xlink that we use
15:56:28 <heycam> ... xlink would have had a network effect if a bunch of specs used it, but they didn't
15:56:35 <heycam> ... what xlink was going to be changed mid-design
15:59:09 <heycam> [explains what xlink was meant to be and what it ended up as]
15:59:30 <heycam> ... so xlink:type="" doesn't tell you what to do (refer, embed); instead it's just a hint to the xlink processor
16:00:22 <heycam> ... so xlink gives you some generality, but not full generality
16:00:50 <heycam> ... it has enough generality to get in the way, though
16:02:27 <Zakim> Zakim has left #svg
16:09:12 <heycam> ... the promise of serving domain specific xml has been lost
16:09:28 <heycam> DS: for backwards compat and existing UAs we've still held on to xlink:href
16:09:56 <heycam> CL: you could come up with new attributes and deprecate xlink:href
16:10:18 <heycam> ... UAs need to support both, new content targetting new browsers can just use the new attrs, content supporting both needs both, etc.
16:10:36 <heycam> ... i propose svg 2 prefer a new xlink-less syntax that does just what we need
16:10:50 <heycam> ... and say what's the mapping of the new way to the old way
16:10:50 <heycam> DS: this is also applicable to svg in text/html
16:11:11 <heycam> JW: we need to decide which takes precedence
16:11:23 <heycam> ... we don't implement xlink, but we don't take some notice of some of the xlink attrs
16:11:53 <heycam> ... if we take the href attribute instead of xlink:href, should it then ignore all the other xlink attrs?  or should the href override all of the xlink attributes?
16:12:50 <heycam> CL: suppose we had src, and it means xlink:type=embed.
16:13:05 <heycam> ED: the only two that are used are xlink:title and xlink:href
16:13:07 <heycam> CL: i've never seen xlink:role used in the wild
16:13:15 <heycam> JW: we pay attention to xlink:show
16:13:20 <heycam> ... new or replace
16:13:33 <heycam> CM: like target
16:13:57 <heycam> CL: all the implementations took target in preference to xlink:show anyway
16:14:12 <heycam> JW: if the target attr is empty or not specified, it will look at xlink:show
16:14:29 <heycam> ... if href overrides xlink:href, should we then ignore xlink:show?
16:14:50 <heycam> CL: my off the cuff response to that is that when you find the new attribute, it overrides all xlink attrs
16:15:40 <heycam> DS: title and xlink:title are two different things
16:15:56 <heycam> ... xlink:title is the title of the linked to thing, and title is the title of the element it's on
16:16:08 <heycam> CL: we shouldn't force people to type xlink:type just to do that
16:17:00 <ed> <a href="foo" title="bar" xlink:href="foo" xlink:title="bar"/> but should be possible to just do <a href="foo" title="bar"> in new content
16:17:02 <heycam> CM: hreflang exists, you could have hreftitle
16:19:12 <heycam> ED: seems like we all prefer new xlink-less attrs to override xlink ones
16:19:14 <heycam> JW: i'm not sure about that
16:19:22 <heycam> ... say now someone sticks xlink:href and href on the content
16:19:30 <heycam> ... the behaviour will be that impls follow the href
16:21:02 <heycam> DS: href and src
16:21:19 <heycam> CM: i'd rather align with html's attr names
16:21:49 <heycam> DS: i propose href to outgoing links and src for incoming links
16:23:16 <heycam> CL: not sure what you mean by incoming links
16:23:23 <heycam> DS: i mean for embedding type elements, like <image>
16:23:37 <heycam> CL: i don't think they all fall in to two different categories
16:23:43 <heycam> ... e.g. xlink:href on gradients
16:23:46 <heycam> ... what type is that?
16:24:35 <heycam> ... one aspect is whether it's embedded, one aspect is whether it's user actuated
16:26:14 <heycam> DS: the ability for us to adopt href and src for some of our elements, where the align, has a clear case
16:26:50 <heycam> ... i'd like to propose we resolve to, where there's a clear mapping to html, that we use the same attr name
16:27:18 <heycam> JW: i see the academic argument for distinct attr names
16:27:45 <heycam> ED: but it's confusing since it's not the same as in html
16:28:02 <heycam> JW: it's confusing because people are used to typing xlink:href for everyone
16:29:12 <heycam> ... two reasons to consider doing them with different names
16:29:18 <heycam> ... one is for recognition that they're different types of links
16:29:25 <heycam> ... the other one is consistency
16:29:32 <heycam> ... with html, specifically
16:29:54 <heycam> DS: html doesn't have some of these kinds of links, like gradient links
16:30:20 <heycam> CM: they have <label for>, but it's not a url
16:34:04 <ed> break for lunch
16:34:10 <heycam> ed++
18:01:48 <eseidel> eseidel has joined #svg
19:04:32 <ed> ed has joined #svg
19:11:31 <ed> back for more of xlink
19:14:40 <ed> ACTION: CL to research where svg uses links, and make a proposal for how to resolve ISSUE-2042
19:14:40 <trackbot> Created ACTION-2619 - Research where svg uses links, and make a proposal for how to resolve ISSUE-2042 [on Chris Lilley - due 2009-06-19].
19:19:16 <heycam> Topic: New DOM syntax
19:20:15 <ed> ISSUE-2044?
19:20:16 <trackbot> ISSUE-2044 -- Consider improving the SVG DOM interfaces for attribute access -- RAISED
19:20:16 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2044
19:22:50 <heycam> CM: so ecmascript allows host objects to do that
19:23:54 <heycam> ... rectElement.x = 20;  is just implemented with a custom [[Put]] on the SVGRectElement host object
19:24:10 <heycam> JW: not sure if xpcom will allow you to do that
19:24:50 <heycam> ED: it's just in the dom, just forwarding on the assignment
19:26:30 <heycam> ... in my quick test, just depending on the type of value you're assigning, you either use .baseVal.value or .baseVal.valueAsString
19:27:27 <heycam> CM: in html there's already something like this, window.location
19:27:37 <heycam> ... it's a Location object, but you can assign a string to it
19:28:40 <heycam> ... getting the values is a bit harder
19:28:51 <heycam> ... you can define [[DefaultValue]] on the SVGAnimatedLength
19:30:13 <heycam> ... that works ok for most types, but not for SVGAnimatedBoolean
19:30:19 <heycam> ... since ToBoolean in ecma-262 doesn't use [[DefaultValue]]
19:31:34 <heycam> JW: it's probably not feasible to throw away the current SVG DOM
19:31:52 <heycam> ... unless we come up with something exceptionally good, we'll need to stick with it
19:32:07 <heycam> ED: we should try to make it more useful as we can, though
19:32:11 <heycam> ... maybe deprecate some parts going forward
19:32:29 <heycam> DS: is it possible to make this in such a way such that we can also make it work for canvas?
19:32:50 <heycam> ED: i thought about it, it's not that simple
19:32:57 <heycam> ... it's not easy to generate something that would make any sense if you record all the drawing commands
19:33:26 <heycam> DS: we could make jquery-like or kevlin's createCircle()
19:33:37 <heycam> ... and allow dot syntax with that object
19:35:34 <heycam> CM: so maybe getContext('svg') then canvas drawing commands gets you an svg tree
19:38:55 <heycam> action: doug to write up a proposal for joint canvas/svg api, ISSUE-2044
19:38:55 <trackbot> Created ACTION-2620 - Write up a proposal for joint canvas/svg api, ISSUE-2044 [on Doug Schepers - due 2009-06-19].
19:41:13 <heycam> ED: for all of the list types, it feels very unnatural to use getItem() and getNumberOfItems()
19:41:16 <heycam> ... it's very un-javascript like
19:41:52 <heycam> JW: you already can use []-indexing on list objects
19:41:56 <heycam> ED: it's not in the spec though
19:42:01 <heycam> JW: it might be in DOM spec
19:42:04 <heycam> CM: but SVG doesn't say it
19:42:27 <ed> would prefer .length and [i] instead of .numberOfItems and .getItem(i)
19:43:00 <heycam> CM: instead of or in addition to?
19:43:07 <heycam> ED: the hard one is the numberOfItems one
19:43:18 <heycam> CM: we could always just have .length as well
19:45:06 <heycam> ... also, SVGNumber is a bit sucky
19:45:13 <heycam> ... why not just have floats in an SVGNumberList
19:46:05 <heycam> ... you could do the same thing as with SVGLength, and have SVGNumber have a [[DefaultValue]] that turns it into a Number
19:47:04 <heycam> ED: another silly aspect is that you have to get the SVGSVGElement
19:47:09 <heycam> ... to create SVG types
19:47:14 <heycam> ... most of the times they're not inserted until later
19:47:31 <heycam> ... so having a constructor would be nice for the basic types
19:48:07 <heycam> JW: i think that works already in mozilla
19:48:16 <heycam> http://dev.w3.org/SVG/proposals/type-constructors/type-constructors.txt
19:51:44 <heycam> CM: i didn't propose constructors the PathSegList interfaces
19:52:07 <heycam> ... not sure how useful they would be
19:52:20 <heycam> ... but probably just improving SVGPathSegList would be better
19:52:27 <heycam> s/the PathSegList/PathSegItem/
19:54:36 <jwatt> jwatt has joined #svg
20:07:24 <heycam> ED: so we want to move forward on these?
20:07:30 <heycam> CM: yes i think we could put these in a blank SVG 2.0 spec
20:09:59 <heycam> action: update template directory with build scripts
20:09:59 <trackbot> Sorry, couldn't find user - update
20:10:06 <heycam> action: cameron update template directory with build scripts
20:10:06 <trackbot> Created ACTION-2621 - Update template directory with build scripts [on Cameron McCormack - due 2009-06-19].
20:10:18 <heycam> action: cameron add these dom suggestions to a new svg 2.0 spec
20:10:18 <trackbot> Created ACTION-2622 - Add these dom suggestions to a new svg 2.0 spec [on Cameron McCormack - due 2009-06-19].
20:17:41 <heycam> Topic: Test suite
20:17:43 <ed> http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0218.html
20:17:55 <ed> ACTION-2385?
20:17:56 <trackbot> ACTION-2385 -- Anthony Grasso to make an XSLT to change the template of the 1.1 tests to the new one -- due 2008-12-25 -- OPEN
20:17:56 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2385
20:34:37 <heycam> CL: dbaron explained reftests to us at csswg f2f
20:34:50 <heycam> JW: i demoed them to svgwg last f2f
20:35:14 <heycam> ... the important thing for us is that you can do pixel-perfect testing
20:35:17 <heycam> ... and thus automated testing
20:35:39 <heycam> ... i've written up some short docs on it
20:36:36 <heycam> CL: we use image patches, which are like ref tests
20:36:50 <heycam> ... but more for compensating for bugs in batik, to generate the reference png
20:37:08 <heycam> JW: it's very important for interop
20:37:22 <heycam> ... the references should be in svg, i think
20:37:35 <heycam> ... don't need a harness, implementors can write their own
20:37:49 <heycam> ... and have by-hand harnesses for people to use (not automatic test suite running)
20:38:03 <heycam> ... not sure if there's the need for a raster fallback
20:38:35 <heycam> CM: what's in the baseline?
20:38:35 <heycam> ... paths?
20:38:37 <heycam> JW: depends on the test
20:38:57 <ChrisL> benefir of a reftest is that the set of fonts, the anti-aliasng, are the same for the reference and the test (both run on same machine)
20:39:03 <heycam> ... you might want to start off with testing a rectangle with a fill, for example
20:39:04 <heycam> ... from that level you would build up from it
20:39:23 <heycam> ... so some tests depend on functionality tested in previous tests
20:39:51 <heycam> ... we call the basic ones "sanity tests"
20:40:11 <heycam> ... whatever assumptions you make in the reference for a test, make sure there are tests for those basic functionality in the test suite
20:42:06 <heycam> ... resolution independence is pretty much the only reason not to use raster reference images, for simple things like testing <rect>
20:44:24 <heycam> ... my further plans, as well as technical issues like test format, there are social issues and political issues around getting implementors to agree on things
20:44:50 <heycam> ... especially implementors allowing you to have automated ways of running the test suite in the browser
20:45:07 <heycam> ... organisation of tests, naming, how detailed they should be, should each test do one feature, or many features in one
20:46:16 <heycam> ... a few other things i was working on; how to structure the tree of tests so that different implementors could mark things as 'we fail this"
20:46:16 <heycam> ... e.g. if moz sends all their tests to opera, a bunch will probably faily
20:46:29 <heycam> ... you want to mark them as known fails, so that if they suddenly start passing they notify you
20:46:37 <heycam> ... but wouldn't keep the tree red
20:47:34 <heycam> ... this is one of the places where ref tests falls down, it doesn't support multiple implementors tagging this
20:47:50 <heycam> DS: danc says he's been interested in it for a while
20:47:59 <heycam> ... plh was really interested
20:48:53 <heycam> CL: related to passing tests around is the licence
20:48:58 <heycam> ... currently w3c licence is fairly restrictive
20:49:12 <heycam> ... the aim was to prevent vendors from grabbing a test suite, fiddling with it, then saying they pass the test
20:49:24 <heycam> ... but more important is to give ppl the freedom to modify the tests for their purposes
20:49:40 <heycam> ... so you can now licence them under a modified MIT licence
20:49:48 <heycam> ... i propose we use this in the future
20:49:57 <heycam> JW: i'd rather creative commons zero licence
20:50:03 <heycam> ... it's essentially public domain
20:50:21 <heycam> ... it frees people up for snippets of code etc.
20:50:36 <heycam> ... MIT requires you to have a header
20:50:50 <heycam> ... and say who the contributors were
20:50:51 <heycam> ... it's a very open licence, but is still a licence, and has these requirements
20:51:43 <heycam> CL: the advantage of doing it with the modified MIT licence is that it's currently allowed by w3c
20:52:03 <eseidel> eseidel has joined #svg
20:52:55 <heycam> DS: i was skeptical there was a reason to push for CC0, and thought that there were useful aspects to a licence that requires attribution etc.
20:53:32 <heycam> ... if everyone wants to go for CC0, then that's fine
20:57:30 <heycam> JW: i'm happy with having provenance information in comments or metadata in the document
20:57:32 <heycam> ... but it's not a licence
20:58:22 <ChrisL> So CC Attribution 3.0 Unported looks good to me
20:58:30 <ChrisL> http://creativecommons.org/licenses/by/3.0/
20:58:35 <heycam> ... to me, whether it's a licence or not, the point is that we don't want people to propagate modified tests
20:58:50 <heycam> DS: that's the non-malicious case
20:59:24 <heycam> ... what if a group want to remove some features from a test suite that they don't want, and distribute that?
21:00:50 <heycam> ED: i wonder if there's a licence that fits out of the box
21:02:13 <ChrisL> actually this one is better
21:02:13 <ChrisL> http://creativecommons.org/licenses/BSD/
21:02:27 <ChrisL> and arguably more applicable to markup (code)
21:04:04 <jwatt> http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html
21:04:22 <heycam> CL: a three-clause bsd licence
21:04:27 <heycam> JW: that's what the current test suite is under
21:05:18 <ChrisL> is it really iunder that?
21:06:02 <heycam> JW: i want people to be able to take snippets out of the test slides too
21:06:06 <heycam> ... and reuse them at will
21:09:57 <heycam> DS: can we have the individual tests under once license, and the test suite as a whole under another?
21:11:18 <heycam> CL: for the new template, i'd like a link to this licence
21:11:22 <heycam> ... not the wall of capital letters
21:12:15 <ChrisL> lets just have a link to W3C 3-clause BSD License in the test harness
21:12:58 <heycam> ED: i think it would be good to move to the bsd licence
21:14:24 <heycam> CM: will other implementors want to contribute with w3c 3-clause bsd licenced tests?
21:14:38 <heycam> ... or would they be unhappy with anything but something like public domain / cc0
21:15:58 <heycam> JW: are we still open to discussion on using other licences in the future?
21:15:59 <heycam> DS: yes
21:17:05 <heycam> RESOLUTION: We will move the SVG test suite to the new W3C 3-clause BSD licence
21:55:40 <ed> ed has joined #svg
21:57:46 <heycam> ACTION: erik to convert the test suites to use the 3-clause bsd licence
21:57:46 <trackbot> Created ACTION-2623 - Convert the test suites to use the 3-clause bsd licence [on Erik Dahlström - due 2009-06-19].
21:59:01 <ed> http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/script/f11_1st_2_f11_2nd.pl
22:05:29 <heycam> ED: we'll wait for anthony to finish the test suite conversion script, then convert it and check it
22:05:36 <heycam> ... there are some 1.1 tests that need review
22:10:50 <heycam> action: erik to go through the test suite to see which ones need reviewing, and put that list on a wiki page
22:10:50 <trackbot> Created ACTION-2624 - Go through the test suite to see which ones need reviewing, and put that list on a wiki page [on Erik Dahlström - due 2009-06-19].
22:20:35 <heycam> Topic: Mailing minutes to www-svg
22:21:09 <heycam> JW: i propose that we CC the minutes to www-svg
22:21:22 <heycam> ED: i don't disagree with that, but they should still be on public-svg-wg
22:21:29 <heycam> DS: charter says we have to send to public-svg-wg at least
22:21:44 <heycam> ED: i'm concerned conversations will fork
22:22:50 <heycam> CM: i don't think that forking is a problem
22:24:08 <heycam> ... i'd be happy with doing technical discussion on www-svg
22:24:36 <heycam> DS: we can't just CC the mail
22:24:59 <heycam> ... we could send to www-svg and bcc public-svg-wg
22:25:23 <heycam> ... we should have a disclaimer about the minutes being sent out
22:27:32 <heycam> ... when this was mentioned to chris yesterday (sending minutes to www-svg) he was concerned about that as a policy and i suspect that his concern may in part have been that the minutes are not clear if you weren't there
22:27:46 <heycam> ... and also that it might generate a lot of noise, feedback before our ideas are fully baked
22:27:56 <heycam> ... but that's just my guess on his concern is
22:28:24 <heycam> CM: personally i'm happy if people can see our half baked ideas
22:28:50 <heycam> JW: i suggest some disclaimer text
22:29:11 <jwatt> DISCLAIMER: The SVG Working Group provides these minutes, unedited, in the interest of timely openness. The lack of editing may make them difficult to understand or subject to misinterpretation outside of context. If you find that to be the case, polite requests for clarification are welcome. 
22:29:23 <heycam> DS: i think it's a worthwhile experiment to see if the policy causes problems
22:29:39 <heycam> ... i'll note that this is how we operate in the Web Apps WG, and it has caused a lot of discussion, but not problems
22:29:48 <heycam> ... work with the dom has generated helpful input
22:30:04 <heycam> JW: if everything is done out of public view, and presented all at once, you get a flood of comments
22:30:07 <heycam> ... which is hard to deal with
22:30:18 <heycam> ... if you send the minutes gradually, it heads off a whole swamp of upset people
22:30:53 <heycam> ... by giving them a chance to voice their concerns at an earlier stage
22:31:08 <heycam> DS: before we've put too much work in to a solution that has problems
22:31:32 <heycam> CM: we had the thread on style/script in text/html on www-svg
22:31:34 <heycam> ... that worked ok
22:32:50 <heycam> DS: since the svg wg has shown that we are trying harder towards being better integrated into the web architecture, open web platform, i think people are less prone to jump to bad conclusions
22:34:14 <heycam> JW: one thing not in the disclaimer is about new ideas here not being final
22:34:21 <heycam> ... often discussion about embryonic ideass
22:34:25 <heycam> s/ideass/ideas/
22:34:58 <heycam> ... and many of them could be thrown away
22:35:07 <heycam> DS: or may not be the solution we settle on
22:36:09 <heycam> JW: i'd like to keep the disclaimer sohrt
22:36:12 <heycam> s/sohrt/short/
22:36:50 <heycam> DS: we should send something to www-svg before we start doing this, signalling our intentions/concerns/...
22:37:41 <heycam> ... brainstorming
22:39:49 <heycam> ... "we were encouraged by recent conversations on www-svg and we want to see as an experiment if working completely in the open works for us"
22:44:22 <heycam> RESOLUTION: We will send minutes to www-svg as well as public-svg-wg as a first step
22:45:34 <heycam> ACTION: doug to send mail to www-svg with explanation of what we'll be doing with minutes sending
22:45:34 <trackbot> Created ACTION-2625 - Send mail to www-svg with explanation of what we'll be doing with minutes sending [on Doug Schepers - due 2009-06-19].
22:45:37 <ed> trackbot, make minutes
22:45:37 <trackbot> Sorry, ed, I don't understand 'trackbot, make minutes'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
22:45:46 <ed> rrsagent, make minutes
22:45:46 <RRSAgent> I have made the request to generate http://www.w3.org/2009/06/12-svg-minutes.html ed
22:47:58 <heycam> meeting adjourned
22:58:58 <eseidel> eseidel has joined #svg