06:30:21 <RRSAgent> RRSAgent has joined #svg
06:30:21 <RRSAgent> logging to http://www.w3.org/2009/07/01-svg-irc
06:30:23 <trackbot> RRSAgent, make logs public
06:30:23 <Zakim> Zakim has joined #svg
06:30:25 <trackbot> Zakim, this will be GA_SVGWG
06:30:25 <Zakim> ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start now
06:30:26 <trackbot> Meeting: SVG Working Group Teleconference
06:30:26 <trackbot> Date: 01 July 2009
06:30:53 <Zakim> GA_SVGWG()2:30AM has now started
06:31:01 <Zakim> +Doug_Schepers
06:31:32 <Zakim> +??P1
06:31:38 <ed> Zakim, ??P1 is me
06:31:38 <Zakim> +ed; got it
06:31:39 <Zakim> +??P2
06:31:41 <heycam> Zakim, ??P2 is me
06:31:41 <Zakim> +heycam; got it
06:33:04 <Zakim> +??P3
06:33:09 <anthony> Zakim, ??P3 is me
06:33:09 <Zakim> +anthony; got it
06:33:31 <ChrisL> ChrisL has joined #svg
06:33:51 <ChrisL> rrsagent, here
06:33:51 <RRSAgent> See http://www.w3.org/2009/07/01-svg-irc#T06-33-51
06:33:52 <Zakim> +??P4
06:34:11 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0247.html
06:34:17 <jwatt> Zakim, ??P4 is me
06:34:17 <Zakim> +jwatt; got it
06:34:25 <heycam> Chair: Erik
06:34:27 <heycam> Scribe: Cameron
06:34:30 <heycam> ScribeNick: heycam
06:34:43 <Zakim> +??P5
06:35:36 <ChrisL> agenda+ svg color
06:35:45 <heycam> Zakim, take up agendum 1
06:35:45 <Zakim> agendum 1. "svg color" taken up [from ChrisL]
06:35:50 <ChrisL> http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html
06:36:09 <heycam> CL: all of the commentors are in green now, they agree with our chnages
06:36:15 <heycam> s/chnages/changes/
06:36:54 <ChrisL> http://dev.w3.org/SVG/modules/color/master/SVGColor.html
06:37:02 <heycam> [we agree to publish fpwd]
06:37:04 <ChrisL> http://dev.w3.org/SVG/modules/color/master/SVGColorPrimer.html
06:37:21 <heycam> RESOLUTION: We will publish SVG Color as a FPWD
06:37:53 <heycam> CM: how about the syntax for icc named colours?
06:38:04 <heycam> CL: i don't mind restricting it to XML Name (though you can't start with a digit there)
06:38:08 <heycam> ... same thing with IDs
06:38:19 <heycam> ... not sure what CSS has for ident, how restricted that is
06:38:28 <heycam> ... i'm happy to restrict it down
06:38:42 <heycam> ... what i put in was what erik suggested, which was anything that didn't clash with the other syntax
06:39:19 <ChrisL> http://www.w3.org/TR/CSS21/grammar.html
06:39:58 <heycam> http://www.w3.org/TR/CSS21/syndata.html
06:40:03 <heycam> [-]?{nmstart}{nmchar}*
06:40:12 <heycam> nmstart 	[_a-z]|{nonascii}|{escape}
06:40:19 <heycam> nmchar 	[_a-z0-9-]|{nonascii}|{escape}
06:40:39 <heycam> CL: so the same as an xml name, can't have digits at the beginning
06:40:53 <heycam> ... we should document that you can't start with a digit
06:40:57 <heycam> ... i can live with that
06:41:08 <heycam> ED: that'll go in before publication?
06:41:08 <heycam> CL: yes
06:41:14 <heycam> ... i'll respond to anne saying we agree
06:41:59 <heycam> Topic: ISSUE-2287 - Consider clarifying empty clipPath behaviour
06:42:01 <heycam> ISSUE-2287?
06:42:01 <trackbot> ISSUE-2287 -- Consider clarifying empty clipPath behaviour -- RAISED
06:42:01 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2287
06:42:13 <heycam> ED: this is an issue i can across from some test cases
06:42:23 <heycam> ... seems that implementations differ on how empty clip paths behave
06:42:30 <heycam> ... i made a ua test
06:42:37 <heycam> ... and tested the four cases i found
06:42:48 <heycam> ... i think we should consider adding this to 1.1 second edition spec
06:42:56 <heycam> ... i can go through each of the cases
06:43:09 <heycam> ... the first to agree on is what should happen if you have an empty clip path
06:43:18 <heycam> ... most impls agree that that would mean everything is clipped away
06:43:31 <heycam> ... not sure why batik thinks that it means nothing is clipped
06:43:42 <heycam> CM: yes i think it should clip everything away
06:43:48 <heycam> ED: the spec doesn't say anything about the case
06:43:53 <heycam> ... but it's logical
06:44:04 <heycam> ... if you have an empty area, you'll have nothing left
06:44:11 <heycam> ... we could consider adding a note there
06:44:27 <heycam> ... second case is similar to the first, when you have children that have display:none set
06:44:35 <heycam> ... third is visibility:hidden
06:44:41 <heycam> ... those are interpreted differently in safari
06:44:49 <heycam> ... where visibility:hidden objects contribute to the clipping path
06:44:56 <heycam> ... which i think is a bit strange
06:45:19 <heycam> CM: does the spec say anything about display:none?
06:45:33 <heycam> ... i thought all objects contribute to the clip path regardless of display/visibility
06:45:42 <ed> http://www.w3.org/TR/SVG11/masking.html#EstablishingANewClippingPath
06:45:42 <heycam> ED: i think it's just talking about the <clipPath> element itself
06:46:12 <heycam> "The 'display' property does not apply to the 'clipPath' element; thus, 'clipPath' elements are not directly rendered even if the 'display' property is set to a value other than none, and 'clipPath' elements are available for referencing even when the 'display' property on the 'clipPath' element or any of its ancestors is set to none."
06:46:20 <heycam> ED: but it doesn't talk about children of the clipPath
06:46:29 <heycam> ... and sometimes it's useful to remove elements from the clipPath easily with display:none
06:47:12 <heycam> "The raw geometry of each child element exclusive of rendering properties such as 'fill', 'stroke', 'stroke-width' within a 'clipPath' conceptually defines a 1-bit mask..."
06:47:22 <heycam> ED: depends what rendering properties includes
06:48:00 <heycam> AG: does 1.2T say something about this?
06:48:15 <heycam> CM: tiny doesn't have clipping
06:48:21 <heycam> AG: but i think we had some wording in there that relates to this
06:49:27 <heycam> ED: there's a definition for rendering tree, but that's the closest i could find
06:49:52 <heycam> CM: perhaps "rendering tree" is what we could reference
06:49:56 <heycam> ... if it's in 1.1
06:50:15 <heycam> CM: what's your suggestion on which ones contribute to clipping paths?
06:50:24 <heycam> ED: i'd prefer the more graphical sense of it
06:50:42 <heycam> ... it's intuitive to me that the things that show up and render (if not in a clipPath) would contribute
06:50:49 <heycam> ... and if you hide them in any way they wouldn't
06:50:58 <heycam> AG: so visibility would affect it?
06:51:07 <heycam> ED: i think visibility:hidden should contribute to the clip path
06:51:16 <heycam> ... but we could try to list all of the rendering properties
06:51:27 <heycam> ... if fill/stroke/stroke-width are not the only ones
06:51:36 <heycam> CL: tends to trip us up if we list them all, harder to add new ones in other specs
06:52:33 <heycam> CM: i would think intuitively that visibility:hidden wouldn't make a difference
06:52:39 <heycam> ... but that display:none would prevent contribution to the clip path
06:52:56 <heycam> JW: i think visibility:hidden shouldn't contribute
06:53:10 <heycam> ... the only place i can think of it being useful is if you're referencing geometry that is the thing you're clipping
06:53:18 <heycam> ... trying to think of scenarios where it matters
06:53:46 <heycam> DS: from the perspective of authoring, what's the most intuitive behaviour?  what happens if for some reason that thing is not there.
06:54:00 <heycam> ... i think it would be easier to debug if it would be ignored
06:54:46 <heycam> ED: when i debug clippath i find it easier to remove the clippath element and to draw it, to visualise how it gets applied
06:54:57 <heycam> ... so in that sense i think it's easier to understand what it does if it's the same as the rendering
06:55:02 <heycam> ... so visibility:hidden wouldn't contribute to the clippath
06:55:34 <heycam> JW: the only time it would matter is if you're clipping something that's visually on the screen
06:55:38 <heycam> ... otherwise the author could use display:none
06:55:58 <heycam> ... maybe using visibility:hidden for some reason in referenced geometry
06:56:13 <heycam> CM: ah so if you're referencing clippath geometry that has some visibility:hidden stuff already
06:56:30 <heycam> AG: i'm leaning towards erik's side
06:56:41 <anthony> http://www.w3.org/TR/SVGTiny12/painting.html#VisibilityControl
06:57:46 <ChrisL> (message re IDENT sent ... http://lists.w3.org/Archives/Public/www-svg/2009Jul/0000.html )
06:59:27 <heycam> ED: i think the first one we can conclude that empty clippaths mean everything is clipped away
06:59:53 <heycam> ... we can also agree that any children with display:none do not contribute to the clipping path
07:00:20 <heycam> ... and we're not concluded on visibility:hidden
07:01:00 <heycam> AG: is it pain for implementations?
07:01:06 <heycam> ED: just an if statement, not a huge deal
07:01:18 <heycam> JW: all implementations other than safari do that?
07:01:30 <heycam> ED: safari lets visibility:hidden contribute to the clipping path, batik too
07:01:34 <heycam> ... opera and firefox don't
07:02:54 <heycam> JW: i'm struggling to think of a use case either way, and preventing visibility:hidden from contributing seems intuitive to me
07:02:58 <heycam> ED: ok we'll go with that
07:03:15 <heycam> ... the last case is clip-path="url(#brokenlink)"
07:03:25 <heycam> ... would that mean everything is clipped or nothing is clipped?
07:03:36 <heycam> ... batik thinks a broken link there is an error, while the others don't agree
07:03:46 <heycam> AG: IMO nothing should be clipped
07:04:13 <heycam> ED: don't know what's meant to happen for other CSS properties with invalid urls in SVG 1.1
07:04:20 <heycam> ... such as fill="url(#bad)"
07:04:28 <heycam> AG: i think it's intuitive that it doens't clip
07:04:36 <heycam> ... if it doesn't work, then it's obvious if everything renders
07:04:47 <heycam> ED: for fill you would use the initial value
07:04:50 <heycam> JW: as if it weren't specified
07:04:55 <heycam> ED: so for clip-path that would be none
07:04:58 <heycam> ... so no cipping
07:05:00 <heycam> s/cipping/clipping/
07:05:02 <heycam> CM: i agree
07:05:54 <heycam> ACTION: Erik to add these decisions to the 1.1SE spec, and make the clippath example into a test case
07:05:54 <trackbot> Created ACTION-2628 - Add these decisions to the 1.1SE spec, and make the clippath example into a test case [on Erik Dahlström - due 2009-07-08].
07:06:59 <heycam> Topic: ISSUE-2283 - Make it possible to get the bounding box of an element in a particular coordinate system
07:07:01 <heycam> ISSUE-2283?
07:07:01 <trackbot> ISSUE-2283 -- Make it possible to get the bounding box of an element in a particular coordinate system -- RAISED
07:07:01 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2283
07:08:30 <heycam> CM: [essentially reads out the issue]
07:09:20 <heycam> ED: suggestion on how to do this?
07:09:22 <heycam> CM: three ways
07:09:33 <heycam> ... have SVGRect be transformable
07:09:53 <heycam> ... extend getBBox() with an argument
07:10:03 <heycam> ... or introduce a new getBBoxInAnotherElementsCoordSystem(elt)
07:10:11 <heycam> ED: people have asked for transformable SVGRect before
07:10:57 <heycam> CM: transforming an SVGRect might give you a quadrangle
07:11:02 <heycam> ... so the return type couldn't be another SVGRect
07:11:03 <eseidel> eseidel has joined #svg
07:11:48 <heycam> ED: you could return a rectangle but it wouldn't be the transformed rectangle
07:11:57 <heycam> CL: you could return a path
07:12:52 <heycam> JW: the first option, having SVGRect be transformable, i was dismissing out of hand
07:13:12 <heycam> ... you've no longer got tight bounds, if you want to still return a SVGRect
07:13:28 <heycam> ... for getBBox() i was hoping to pass in an argument for the different type of bounds (including fill, stroke, clipping)
07:13:37 <heycam> ... so i didn't want to pass in an Element argument to that
07:13:58 <heycam> ... i was thinking of something like the third option, but more like otherElement.getBBox(firstElement)
07:14:05 <heycam> s/getBBox/getBBoxOf/
07:14:16 <heycam> ... that allows getBBoxOf() to have the type-of-bounds argument
07:15:33 <heycam> CM: getBBoxOf() seems like the simplest solution
07:16:27 <heycam> ACTION: Cameron to add a proposal for getBBoxOf() to the proposals directory
07:16:28 <trackbot> Created ACTION-2629 - Add a proposal for getBBoxOf() to the proposals directory [on Cameron McCormack - due 2009-07-08].
07:16:55 <heycam> Topic: ISSUE-2282 - Consider adding new path syntax for points on path
07:16:57 <heycam> ISSUE-2282?
07:16:57 <trackbot> ISSUE-2282 -- Consider adding new path syntax for points on path -- RAISED
07:16:57 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2282
07:17:21 <heycam> ED: this is about new path syntax/interpolation
07:18:00 <heycam> CL: patrick gave us a bunch of math, but not sure that's good to go with
07:18:07 <heycam> ... not sure it's helps us concretely enough
07:18:11 <heycam> DS: yep
07:18:19 <heycam> CL: otoh he does have some java code that implements it
07:18:39 <heycam> AG: there is quite a bit to specify for it
07:18:56 <heycam> ... for example, when you have a bend in the curve where abouts in the curve does it go through the point
07:19:10 <heycam> ... or if you're trying to fit paths to points it can be tricky
07:19:25 <heycam> CL: normally with this kind of thing you can allow an amount of error, because it's not always possible get a solution
07:19:43 <heycam> ... which might be ok for a new element, but to add into existing path syntax it's hard to add parameters
07:20:05 <heycam> ... if you want to say "go through these points within 0.1 units" it's hard to pass that in with the current path syntax
07:20:40 <heycam> ED: anyone interested in looking at this?  do we need to try to contact someone to make something from this?
07:21:02 <heycam> DS: i think it's potentially interesting, but i don't have the math to make it interesting enough to myself
07:21:11 <heycam> CL: too much conceptual gap between his math and what we need
07:21:19 <heycam> ... otoh i think he's quite interested in this
07:21:41 <heycam> ... so in general if you've got n points, what's the algorithm to produce the path?
07:21:49 <heycam> ... does it decompose into other curve segments?
07:21:56 <heycam> ... need to get patrick to explain what's entailed there
07:22:14 <heycam> DS: if i could see the java implementation, that would give me a better sense
07:22:39 <heycam> ... want to see two things: one, what such curves look like visually, and two what the syntax might be
07:23:09 <heycam> ... so i'd like to see a bunch of points have a path go through it in a predictable way
07:23:18 <heycam> ... maybe the syntax would just be like a <polyline>, but i don't know that
07:23:41 <heycam> CL: for a basic shape that's easy, we could have another attribute that says accuracy="whatever" with a default of 0, e.g.
07:23:52 <heycam> ... and other constraints, how tight the "cord" is pulled
07:24:03 <heycam> ... you could imagine floppy shapes and mostly straight line curves
07:24:10 <heycam> ... exactly the kind of thing the java testing app would help us see
07:24:34 <heycam> DS: another aspect is that i don't know how it deals with shapes where the line crosses itself several times
07:24:41 <heycam> ... don't know if that would lead to funky behaviour
07:24:59 <ed> http://www-personal.umich.edu/~pion/WebGeom/sketch-test5.html
07:25:17 <heycam> ED: that app isn't showing any nice curves
07:25:27 <heycam> DS: curves would be more interesting
07:25:45 <heycam> ... for a graph where you want to plot the points, for example
07:25:58 <heycam> CL: if the java applet doesn't do it, but he thinks it's simple, we could ask him to do it
07:27:21 <heycam> AG: this applet looks like the constraint stuff we were talking about, applying constraints to the movement
07:27:25 <heycam> ... and you get some sort of mechanical effect
07:27:55 <heycam> ACTION: Chris to contact Patrick Ion for an applet that demonstrates these curves
07:27:55 <trackbot> Created ACTION-2630 - Contact Patrick Ion for an applet that demonstrates these curves [on Chris Lilley - due 2009-07-08].
07:28:15 <heycam> AG: you could do some cool stuff with constraints on these curves
07:28:27 <heycam> Topic: ISSUE-2274 - Consider adding drag and drop functionality
07:28:29 <heycam> ISSUE-2274?
07:28:29 <trackbot> ISSUE-2274 -- Consider adding drag and drop functionality -- RAISED
07:28:29 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2274
07:28:49 <heycam> ED: don't know if there's anything to discuss, but there should be an action to research what would be needed from svg
07:28:58 <heycam> ... this might be related to webapps work
07:29:32 <heycam> DS: drag and drop has been added to html5
07:29:40 <heycam> ... but not exactly in the way we'd want in svg
07:29:47 <heycam> ... in html5 is like a special kind of clipboard
07:29:51 <heycam> s/is like/it's like/
07:29:54 <heycam> ... so a copy/paste thing
07:30:13 <heycam> ... i'm thinking that the OP means (and i mean) is being able to drag and drop a shape around the screen
07:30:15 <heycam> ... moving it around
07:30:26 <heycam> ... two ways of doing it
07:30:33 <heycam> ... either have drag and drop attributes, e.g.
07:30:42 <heycam> ... or a constraints mechanism where they could say what to do with it
07:30:56 <heycam> ... pointer.x-5 and pointer.y-10
07:31:11 <heycam> ... enable people to do things based on the pointer position, not using script
07:31:27 <heycam> ... activation through smil
07:31:45 <heycam> ... so i think this is SVG specific
07:31:56 <heycam> CL: if it's going to interact with smil, you'd want it to raise events so you can say onblah
07:32:03 <heycam> DS: we could create drag and drop events
07:32:10 <heycam> ... that it would dispatch when it did that
07:32:11 <Zakim> -heycam
07:32:39 <Zakim> +[IPcaller]
07:32:43 <heycam> Zakim, [ is me
07:32:43 <Zakim> +heycam; got it
07:33:20 <heycam> ... we could have it triggered on regular events mousedown, mousemove etc.
07:33:33 <heycam> ... if we did that, what we would need to do is also define how it works with a keyboard
07:33:38 <heycam> ... or some alternate pointer device
07:33:55 <heycam> ... so the more semantic thing would be grab/drag/drop
07:33:58 <heycam> ... however that's actuated
07:34:15 <heycam> ... making it accessible isn't particularly easy, i think
07:34:25 <heycam> JW: allowing drag&drop without script?
07:34:38 <heycam> CL: yes
07:34:49 <heycam> ... though i worry that it might get in the way of other things trying to affect the position
07:35:01 <heycam> DS: that could argue for real grab/drag/drop events
07:35:15 <heycam> CL: if you provide hooks then people can write script to make use of them as needed
07:35:24 <heycam> ... but if it's automatic, then it might get in the way of other things like link activation
07:35:38 <heycam> JW: that would be an issue, that it would need to set attributes x/y or whatever
07:36:10 <heycam> ... especially when we're just introducing calc() or more complex positioning, layout, it's going to become painful to define what happens when you have percentage plus pointer.x pixels
07:36:22 <ed> <animate begin="rect.mousedown" end="dropzone.mouseup" ...> is possible already
07:37:28 <shepazu> attributeName="cx" attributeValue="pointer.x+5"
07:37:35 <heycam> <animateTransformToPointer offsetX="..." offsetY="..." begin="rect.mousedown" end="rect.mouseup"/>
07:38:24 <heycam> CM: if it's a smil mechanism, it might make it easier to avoid competing things affecting the position of an object
07:38:33 <heycam> ED: sometimes you want the object to stay at its end point, sometimes to return
07:38:37 <heycam> DS: you could use fill="freeze" for that
07:38:49 <heycam> ... so this wouldn't solve all cases
07:39:06 <heycam> ... but for the cases where people want something really strange, i think that they could code something up
07:39:16 <heycam> ... would this cover say 50-70% of cases where people want to do dnd?
07:39:22 <heycam> ... my guess is yes
07:39:40 <heycam> ED: i don't know, all the cases i've seen you need to do some scripting or trigger server side actions
07:39:45 <heycam> ... depends on the use case
07:39:48 <heycam> DS: what use cases?
07:39:56 <heycam> ED: e.g. sorting some objects in some way and then storing it
07:40:23 <heycam> ... putting orders in a basket in a web shop
07:40:32 <heycam> JW: svg solitaire
07:40:56 <heycam> DS: in my mind, if you just had svg solitaire or putting items in a basket, both of those cases aren't asking for anyhting much special
07:41:00 <heycam> ... just moving the cards or the items
07:41:04 <heycam> s/anyhting/anything/
07:41:13 <heycam> JW: you need to drop near the cards
07:41:20 <heycam> DS: wouldn't say you wouldn't have to script the drag code
07:41:34 <heycam> ED: but i think you'd want to have script callbacks for dnd
07:41:39 <heycam> DS: you have those already for smil
07:41:45 <heycam> ED: you have the mouse events but don't know that it's drag/drop
07:41:51 <heycam> DS: could change that
07:41:52 <jwatt> s/you need to/you want to be able to/
07:42:16 <heycam> ... in the past bjoern wanted to be able to use arbitrary events in smil begin/end
07:42:33 <heycam> ... i think for 50-70% of the cases, dragging to move it around and then hooking that into script would handle it
07:42:43 <heycam> ... hard to think of anything funkier with dragging
07:43:01 <heycam> ... another case is if we wanted to allow people to have connectors and move nodes/edges around
07:43:15 <heycam> ... and have the connectors follow the shape, then we should try to solve that problem at the same time
07:43:29 <heycam> ... and it would be solved, if we had a way of saying "this line connects between these two shapes"
07:43:41 <heycam> ... then you would be able to drag things around and have the connectors follow
07:44:03 <heycam> ... i do think that even though it gets a little specialised, having that kind of functionality built in to svg solves a large number of use cases
07:44:11 <heycam> ... and it would make the language a lot more attractive to use
07:44:19 <heycam> ED: have you looked at the html5 dnd?
07:44:22 <heycam> DS: no but i should
07:44:29 <heycam> ED: i think that's also something that's in silverlight
07:44:36 <heycam> ... same type of specialised dnd events
07:44:52 <heycam> ... might be good to study those cases
07:46:16 <heycam> DS: not sure we're in a position yet to do anything about it
07:47:18 <heycam> ... i'm interested in this but there's so much other stuff to do
07:47:30 <heycam> ... i think we should come back to this
07:47:58 <heycam> JW: i think it's a fair bit of work to work out the events, how attributes get modified, etc.
07:48:10 <heycam> ... and since it's 10-20 lines to implement dnd in script, maybe we should be prioritising other things
07:48:22 <heycam> DS: one way to make it easier would be the "get the real point" stuff we talked about
07:48:36 <heycam> ... get the x/y position i care about, with transformations/ctm taken care of
07:48:50 <heycam> CL: that's more the kind of thing i was talking about.  adding hooks to make it more easily implemented.
07:48:57 <heycam> DS: that stuff we'd need to resolve anyway if we were to do this
07:49:03 <heycam> ... since that's the behaviour people would want
07:49:07 <heycam> ... the "absolute" value of the mouse pointer
07:49:14 <heycam> ... so let's solve that part first
07:49:51 <heycam> Topic: SVG 1.1 test suite template conversion
07:50:06 <heycam> AG: pretty much all the tests are converted
07:50:12 <heycam> ... i'm just going through and verifying that they're all good
07:50:18 <heycam> ... just 30-odd tests left to check
07:50:21 <heycam> ... then i'll commit them all as a batch
07:50:37 <heycam> ... 335 tests all done
07:50:47 <heycam> ... should be done by the end of this week
07:50:55 <heycam> CM: sounds good
07:51:01 <heycam> AG: made some minor fixes to the xslt, it's working properly now
07:51:14 <heycam> ... we can use this and the new template for the svg core tests when the spec is on its way
07:51:18 <eseidel> eseidel has joined #svg
07:51:21 <heycam> ... and for modules
07:51:47 <heycam> ED: if we make tests for modules we should use the 1.1F2 template?
07:51:57 <heycam> AG: or some variant?
07:52:20 <heycam> ... the template we use now for those tests might be ported across to modules etc.
07:52:24 <heycam> ... so it'd be good to decide
07:52:35 <heycam> ... the one we're using the 1.1F2 is very close to the 1.2T one
07:52:42 <heycam> ... apart from a couple of extra fields
07:52:48 <heycam> CL: it's using id instead of xml:id presumably?
07:52:49 <heycam> AG: yes
07:53:13 <heycam> CM: nothing specific to 1.1 that would prevent us from using that template for modules etc. would it?
07:53:24 <heycam> AG: no, it's usable for all modules
07:53:41 <heycam> ... the TestCase element, the bit that has all the metadata for the test, that bit is using xlink:href to reference into the spec
07:53:45 <heycam> ... that's the only odd thing it's doing
07:53:51 <heycam> ... otherwise it's the same as the tiny template
07:54:23 <heycam> CM: i don't know if it's useful to have xlink:href attribute named like that
07:54:33 <heycam> AG: it's on the TestComponent element
07:54:48 <heycam> ... so when we generate the harness it can generate an <a>
07:55:00 <heycam> CL: if it's being transformed anyway it doesn't matter what it's called
07:55:32 <heycam> ACTION: Anthony to draft the template for SVG 2.0 and modules and present it at the next telcon
07:55:32 <trackbot> Created ACTION-2631 - Draft the template for SVG 2.0 and modules and present it at the next telcon [on Anthony Grasso - due 2009-07-08].
07:56:26 <heycam> Topic: RNG for 1.1
07:56:34 <heycam> DS: berjon is willing to help us out and give us guidance
07:56:43 <heycam> ... but not to do the whole thing
07:57:05 <heycam> ... he's pretty busy with other stuff too
07:57:34 <heycam> ... he can't join as vodafone rep
07:58:05 <heycam> ... he sent me a fairly detailed email and i'll ask if i can forward it on to us
08:06:23 <Zakim> -ed
08:06:24 <Zakim> -heycam
08:06:24 <Zakim> -anthony
08:06:26 <Zakim> -Doug_Schepers
08:06:27 <Zakim> -jwatt
08:06:28 <Zakim> -??P5
08:06:29 <Zakim> GA_SVGWG()2:30AM has ended
08:06:30 <Zakim> Attendees were Doug_Schepers, ed, heycam, anthony, jwatt, [IPcaller]
08:23:27 <ChrisL> Present: Doug_Schepers, ed, heycam, anthony, jwatt, ChrisL
08:23:45 <ChrisL> rrsagent, make minutes
08:23:45 <RRSAgent> I have made the request to generate http://www.w3.org/2009/07/01-svg-minutes.html ChrisL
08:26:45 <shepazu> shepazu has joined #svg
08:41:45 <heycam> heycam has joined #svg
08:42:12 <heycam> RRSAgent, make minutes
08:42:12 <RRSAgent> I have made the request to generate http://www.w3.org/2009/07/01-svg-minutes.html heycam
08:44:37 <heycam> heycam has joined #svg
08:44:49 <ChrisL> cam, http://dev.w3.org/SVG/modules/color/master/SVGColor.html#syntax
08:45:40 <heycam> ChrisL, thanks i'll take a look in a while
09:01:40 <ChrisL> ChrisL has joined #svg
10:55:29 <karl> karl has joined #svg