08:36:07 RRSAgent has joined #svg 08:36:07 logging to http://www.w3.org/2008/10/17-svg-irc 08:36:09 RRSAgent, make logs public 08:36:09 Zakim has joined #svg 08:36:11 Zakim, this will be GA_SVGWG 08:36:11 ok, trackbot; I see GA_SVGWG()4:30AM scheduled to start 6 minutes ago 08:36:12 Meeting: SVG Working Group Teleconference 08:36:12 Date: 17 October 2008 08:36:26 trackbot, code? 08:36:26 Sorry, anthony, I don't understand 'trackbot, code?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 08:36:30 trackbot, pass code? 08:36:30 Sorry, anthony, I don't understand 'trackbot, pass code?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 08:36:45 zakim, code? 08:36:45 the conference code is 7841 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), anthony 08:38:03 heh 08:39:07 GA_SVGWG()4:30AM has now started 08:39:15 +??P0 08:39:20 Zakim, ?? is me 08:39:20 +ed_work; got it 08:39:55 +??P1 08:40:04 Zakim, ??P1 is me 08:40:04 +anthony; got it 08:41:46 NH, you there? 08:42:59 Sorry I wont be able to join before ~12.30 CET 08:43:12 ahh ok - no worries 08:44:39 http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement 08:54:12 -ed_work 08:55:01 +??P0 08:55:41 http://dev.w3.org/SVG/profiles/1.2T/publish/script.html#HandlerElement 08:56:49 ed_ has joined #svg 08:59:03 ISSUE-2055? 08:59:04 ISSUE-2055 -- Define 'evt'/'event' relationship more formally -- RAISED 08:59:04 http://www.w3.org/Graphics/SVG/WG/track/issues/2055 09:01:59 ed_work has joined #svg 09:03:07 http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0160.html 09:06:10 http://www.w3.org/Graphics/SVG/WG/track/actions/2306 09:07:44 -??P0 09:07:46 -anthony 09:07:46 GA_SVGWG()4:30AM has ended 09:07:47 Attendees were ed_work, anthony 10:41:42 Zakim has left #svg 10:44:08 time for another telcon round? 10:44:21 trackbot, start telcon 10:44:23 RRSAgent, make logs public 10:44:23 Zakim has joined #svg 10:44:25 Zakim, this will be GA_SVGWG 10:44:25 ok, trackbot; I see GA_SVGWG()4:30AM scheduled to start 134 minutes ago 10:44:26 Meeting: SVG Working Group Teleconference 10:44:26 Date: 17 October 2008 10:45:02 GA_SVGWG()4:30AM has now started 10:45:09 +[IPcaller] 10:45:13 Zakim, [ is me 10:45:13 +ed_work; got it 10:46:35 +??P1 10:46:47 Zakim, ??P1 is me 10:46:47 +anthony; got it 10:46:55 +NH 10:51:12 Zakim, call Doug 10:51:12 I am sorry, anthony; I do not know a number for Doug 10:51:23 Zakim, call Doug_Schepers 10:51:23 I am sorry, anthony; I do not know a number for Doug_Schepers 10:51:35 Zakim, call +Doug 10:51:35 I am sorry, anthony; I do not know a number for +Doug 10:53:27 Zakim, call doug 10:53:27 I am sorry, anthony; I do not know a number for doug 10:55:01 -ed_work 10:55:03 -NH 10:55:03 -anthony 10:55:03 GA_SVGWG()4:30AM has ended 10:55:04 Attendees were [IPcaller], ed_work, anthony, NH 11:04:10 Hey ed_work, is this too wordy for ISSUE-2098? 11:04:13 If a script within the 'script' element causes 11:04:15 the element to be removed, the script must continue to be execution as normal. 11:05:03 I have come up with shorter wording 11:05:51 Modifying or removing the script content (or element) after the script has started its execution has no effect on the script execution. 11:06:08 isn't there something similar to that already? 11:06:33 perhaps "must have no effect" 11:07:50 ok, looks fine to me 11:08:06 I couldn't see anything in the scripting chapter about this 11:08:36 I have a draft response to cyril on ISSUE-2134 now, but maybe we should go through it before I send it off 11:09:03 sure 11:10:55 other than looking in the scripting chapter is there anywhere else you can think of that I should check? 11:11:33 impl. requirements? intro? 11:11:48 conformance? 11:15:39 check those... nothing 11:16:09 I'll add your wording into the scripting chapter 11:39:56 erm has joined #svg 11:41:18 time for another telcon then 11:41:44 ok 11:41:46 GA_SVGWG()4:30AM has now started 11:41:53 +??P0 11:42:08 Zakim, ? is me 11:42:08 +ed_work; got it 11:42:40 +NH 11:43:11 +Doug_Schepers 11:44:38 +[IPcaller] 11:44:42 aemmons has joined #svg 11:44:56 Zakim, [IP is me 11:44:56 +anthony; got it 11:45:10 +??P4 11:45:15 zakim, ??p4 is me 11:45:15 +aemmons; got it 11:45:56 scribe: anthony 11:46:07 chair: Andrew Emmons 11:47:54 http://lists.w3.org/Archives/Public/www-svg/2008Oct/0183.html (sorry, missed to put in the issue/action) 11:48:18 http://lists.w3.org/Archives/Public/www-svg/2008Oct/0182.html 11:49:05 ED: Those issues were done 11:49:57 Topic: ISSUE-2134 11:50:00 ISSUE-2134? 11:50:00 ISSUE-2134 -- Ambiguities in the 'use' element -- RAISED 11:50:00 http://www.w3.org/Graphics/SVG/WG/track/issues/2134 11:50:23 ED: Wording taken from 1.1 for the first bit 11:50:33 ... I would prefer not to change anything 11:50:38 ... wording is simplified 11:50:55 ... almost all of the use element is taken from 1.1 11:51:44 ... I think the first paragraph is a high level description 11:51:51 ... at least that's how I read it 11:52:27 ... I'd prefer to leave it in 11:52:50 AE: I think it make sense keeping it as it is 11:52:54 ... it's not a major issue 11:53:01 ED: Second paragraph of the issue 11:53:13 ... is it's not according to the spec 11:53:21 ... I think it's just a miss reading 11:53:27 ... the Third paragraph 11:53:38 ... is this strange half sentence 11:53:47 ... and it was added in response to our last LC 11:53:57 ... it's suppose to be joined to the bullet point list 11:54:12 AG: I think we should merge that last bit with the bullet point 11:54:17 "A 'use' element has the same visual effect as if the 'use' element were replaced by the following generated content" + "except for resolution of relative IRI references as noted above and until the referenced elements are modified." 11:55:31 DS: As noted above should be as noted below 11:55:41 ED: The XML resolving base is still above 11:55:57 xml:base resolving 11:56:25 ED: about 4/5 paragraphs above 11:58:03 AE: If could just get rid of the "as noted above" 11:58:06 DS: And say as noted 11:59:01 ... I'd suggest edit to remove that sentence above 11:59:07 ... make it into one sentence 11:59:42 ED: [Suggests change] 11:59:59 ... next thing that is being asked for is clarification of examples 12:00:28 ... and he's asking what's happening with id's and xml:id's 12:00:55 ... I'd prefer to leave the example as is 12:01:30 ... I think it would be very confusing showing the cloning of ids 12:01:36 ... because that doesn't really happen anyway 12:01:39 AE: I agree 12:01:45 ... it's just a shadow tree anyway 12:05:00 ED: In any case I'd prefer to leave the examples as they are 12:05:11 ... Image use base had some errors 12:05:15 ... so I removed those 12:06:00 ... the last part is find the process xml is transfered 12:07:10 AE: linking-refs-205 12:07:26 ... I'd review it first before putting it into your response 12:08:25 Topic: ISSUE-2094 12:08:30 ISSUE-2094? 12:08:30 ISSUE-2094 -- accessing rules for traitAccess -- RAISED 12:08:30 http://www.w3.org/Graphics/SVG/WG/track/issues/2094 12:08:48 ED: Just need to decide on what to do with traitAccess on animation elements 12:09:47 ... currently we throw exceptions if your try to modify traits on animation elements 12:09:58 ... only if they are in the tree already 12:10:24 AE: I think it's significantly simplified the UA 12:10:37 ... but it's not just the ID it's all the attributes of the animation 12:11:00 ... sure the xml:id is just one, but I do believe it simplifies it 12:11:09 http://lists.w3.org/Archives/Public/www-svg/2008Oct/0055.html 12:11:30 ... removing it will change what implementations have to do 12:11:54 ED: I would disagree with his last comment 12:12:20 AE: There are many other attributes on the animation element 12:12:44 ED: I got to the bit about changing the document while it's parsed 12:13:12 ... and I'm not sure it's stated anywhere when you evaluate or re-evaluate an attribute 12:13:28 ... I'm pretty sure it says once it's been resolved you can't change it 12:13:32 DS: I think it does 12:13:51 ED: It's an edge case, and I wouldn't count on it working 12:14:04 DS: What's the minimum thing we can do to resolve this? 12:14:13 ED: Say that it's forbidden for good reasons 12:15:23 AE: His question is why do we have the restrictions 12:15:34 RESOLUTION: We will not change the animation restrictions 12:16:26 RATIONAL: Implementation experience shows that it simplifies implementations even when considering xml:id 12:17:09 ACTION: Emmons to Reply to ISSUE-2094 12:17:09 Created ACTION-2316 - Reply to ISSUE-2094 [on Andrew Emmons - due 2008-10-24]. 12:18:52 Topic: ISSUE-2089 12:18:54 ISSUE-2089? 12:18:54 ISSUE-2089 -- animateTransform and underlying value -- OPEN 12:18:54 http://www.w3.org/Graphics/SVG/WG/track/issues/2089 12:20:13 DS: We could say this behavior is not defined so don't use it 12:20:24 ... it leaves it open to being defined in the future 12:27:12 [[ 12:27:14 The 'problem' with the underlying value for 12:27:14 animateTransform is none, if the sentence is 12:27:14 simply skipped. If required, one can replace 12:27:15 it with the sentence, that currently the behaviour 12:27:15 for to-animateTransfrom is explictly unspecified. 12:27:15 Then the reader is informed about the remaining 12:27:17 problem and will not start to write tough 12:27:19 tests as I did. 12:27:22 ]] 12:28:03 [[ 12:28:06 [[ 12:28:10 Therefore, if critical things are specified to be 12:28:10 'unspecified', implementors do not have to change 12:28:10 the current behaviour of programs currently and 12:28:10 authors are at least warned, that they must not 12:28:11 rely on anything for these remaining issues. 12:28:11 It cannot be expected, that all problems are 12:28:13 perfectly solved already now, but it is no use to 12:28:15 leave it in an unconsistent state to make sketchy 12:28:17 readers believe, that the work is already done .. 12:28:19 ]] 12:29:12 DS: You can't specify every behavior 12:29:29 ... there are cases where we leave things up to the implementers 12:30:29 ... we're not saying that an implementation can't do it 12:32:44 AG: If we remove the sentence then we have to remove the bullet points I think 12:32:48 Zakim, who is noisy? 12:32:59 ed_work, listening for 10 seconds I heard sound from the following: ed_work (4%), Doug_Schepers (19%) 12:33:22 http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement 12:35:50 DS: Say instead, this behavior is unspecified in Tiny 1.2 and will be defined in a later specification 12:36:06 ED: If we remove the sentence we should say it's undefined and we will define it later 12:38:56 DS: Before you make the change and say we will take his advice and say that this behavior is unspecified 12:39:10 ... and say it means removing this entire section and let us know if that's the case 12:39:14 ... and quote the section 12:40:46 http://www.w3.org/TR/SVGMobile12/animate.html#AnimationAttributesAndProperties 12:41:28 ED: It has a note for additive in that table already 12:41:37 ... at least in the working draft that was published 12:42:56 ... we already have a not in the table there 12:43:19 ... he's suggesting to mention the underlying value in that sentence 12:46:18 Topic: ISSUE-2055 12:46:22 ISSUE-2055? 12:46:22 ISSUE-2055 -- Define 'evt'/'event' relationship more formally -- RAISED 12:46:22 http://www.w3.org/Graphics/SVG/WG/track/issues/2055 12:46:27 ED: I did some changes to the spec 12:46:50 http://dev.w3.org/SVG/profiles/1.2T/publish/script.html#HandlerElement 12:47:22 ED: I removed the wording saying this keyword was bound 12:47:30 ... it was an old action on Cameron 12:47:35 ... so it's removed now 12:47:54 ... and I also added in the aliasing explicitly in the example 12:48:07 ... I think this is closer to what people are doing 12:48:20 ... in implementations are doing currently 12:48:35 ... not sure if everyone treats it as function either 12:48:40 ... I know we don't 12:48:56 AE: You mean the 'this' keyword 12:49:01 ED: Correct 12:49:17 DS: If there is no 'this' key word aren't we moving away from HTML? 12:49:27 ED: HMTL doesn't do events 12:49:41 .... we have tests for both arguments and this 12:49:45 ... there were not passes 12:50:05 ... one thing to not here, is Opera doesn't currently handle it as a function 12:50:14 ... you can't break out of the function 12:50:49 ... I'd like to brainstorm how to reword this 12:51:06 ... for thus it's like script content block but with the evt available 12:51:18 ... but I'm not sure how to describe that accurately 12:51:31 s/evt/evt and event/ 12:51:40 AE: How is the script element described 12:51:48 ED: Probably not very much I'd guess 12:52:51 ... I read the thread there and all the discussion 12:53:07 ... and I didn't agree with the more ECMA script equivalent 12:53:20 ... I couldn't get that to work and it wasn't any more clear 12:53:33 AE: Could we say it's conceptually like a function object 12:53:40 NH: We have it as a function 12:54:09 ED: Which is why I'd like to have it as a smallest subset possible 12:54:37 AE: Maybe say "Conceptually behave as if" 12:54:42 DS: I agree with Andrew 12:55:08 ... and we could say in the reply that we realise that this may not be complete but we will work 12:55:22 ... with webaps and HTML to define it better 12:55:44 ED: Another change we could make is we don't require access to the arguments property 12:56:01 ... and in a later spec say we do require it 12:56:28 NH: Will this give us better conformance to the test suite? 12:56:47 DS: Problem is this is a real problem with SVG, it's incompatible with other specs 12:57:07 ...we need to resolve it in a way that allows better integration later on 12:57:23 ED: I did make another change there 12:57:38 ... and said that the event object is the event and evt is an alias 12:58:19 NH: Why take it out this release and put it in the next version? 12:58:30 ED: Because implementations fail the tests 12:58:45 ... I think at this point we should make it easy for implementations to pass 12:59:52 AE: What ED said there about not having the args available 13:00:31 ... for Tiny 13:00:38 ... we should add that wording 13:01:03 ED: Ikivo would still be conform 13:02:22 so, resolution is to change this sentence: 13:02:23 In ECMAScript, the contents of the 'handler' element behave as if they are the contents of a new Function object, created as shown: 13:02:30 to this: 13:02:40 In ECMAScript, the contents of the 'handler' element behave conceptually as if they are the contents of a new Function object, created as shown: 13:03:03 DS: Does that resolve the issue? 13:03:25 ED: The issue itself is asking for a more formal way of defining event and event variables 13:03:29 http://lists.w3.org/Archives/Public/www-svg/2008Sep/0061.html 13:03:58 ED: In the email he says to do what I've pretty much done there 13:04:05 ... so I think he'll be satisfied with this change 13:04:29 ... I will fix the conceptually there and respond to whoever raised the issue initially 13:07:44 http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0156.html 13:08:14 s/whoever raised the issue initially/the original commenter/ 13:10:50 Topic: ISSUE-2083 13:10:52 ISSUE-2083? 13:10:52 ISSUE-2083 -- Paced animation and complex types -- RAISED 13:10:52 http://www.w3.org/Graphics/SVG/WG/track/issues/2083 13:15:27 [[ 13:15:29 Current problems with paced animation were 13:15:29 introduced mainly with some funny formulas in 13:15:30 SVGT 1.2, not before. 13:15:30 If SVGT1.2 implementors do not want to change their 13:15:30 current implementations, one can simply 13:15:31 1) remove the formulas for lists and path-data 13:15:32 2) note, that the behavior is explictly unspecified 13:15:34 3) discourage authors from using calcMode paced for 13:15:36 other constructions than scalars and colors currently, 13:15:38 because due to nonsense in SVG1.1 and in 13:15:40 some implementations, the behavior is unpredictable, 13:15:42 which also applies for animateTransform, if backwards 13:15:44 compatibility is important. 13:15:46 4) encourage authors to calculate keyTimes for 13:15:48 calcMode linear for the critical unspecified cases, 13:15:50 to get a predictable behavior, because this is 13:15:52 always possible to get the behavior that they would expect that 'paced' 13:15:54 might mean in their specific case. 13:15:56 This has the big advantage, that readers are warned 13:15:58 and do not start to use the wrong formulas or even 13:16:00 worse to waste their time to understand, how they 13:16:03 are related to calcMode paced, as I did. 13:16:04 ]] 13:17:05 AE: Removing the formulas for list and path data 13:17:17 ... is subtle way of fixing some of the issues 13:17:32 ... doing number 1 suggestion is the best way to go 13:17:49 s/... doing number 1 suggestion is the best way to go// 13:18:19 DS: This is very sensible 13:20:49 ... we should at least warn authors 13:22:45 ACTION: Anthony to make changes as suggested by DOH 13:22:46 Created ACTION-2317 - Make changes as suggested by DOH [on Anthony Grasso - due 2008-10-24]. 13:25:00 http://www.w3.org/Graphics/SVG/WG/track/issues/2084 13:25:05 Topic: ISSUE-2084 13:25:15 DS: I have an action onit 13:25:21 s/onit/on it/ 13:25:35 DS: I have some more input on it 13:26:04 ... Dr Hoffmann didn't like the extended syntax thing 13:27:34 DS: When he says extended syntax I think he's talking about the trailing semicolon 13:28:56 http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#ValueAttributes 13:29:08 [[ 13:29:10 For compatibility with existing content, SVG extends the syntax of this attribute to allow a trailing semicolon (with optional surrounding whitespace) without creating a new value in the list. Thus, for example, "10; 20; 30;" has the same meaning as "10; 20; 30" and specifies a list of three values. Note that a zero-length string is a valid value for IRIs, which means that to use such a value as the final value in a 'values' attribute an addition semicolon i 13:29:12 ]] 13:29:29 [[ 13:29:38 For compatibility with existing content, SVG extends the syntax of this attribute to allow a trailing semicolon (with optional surrounding whitespace) without creating a new value in the list. Thus, for example, "10; 20; 30;" has the same meaning as "10; 20; 30" and specifies a list of three values. Note that a zero-length string is a valid value for IRIs, which means that to use such a value as the final value in a 'values' attribute an addition semicolon i 13:30:32 DS: What if we replaced with something like 13:32:04 trackbot, close ACTION-2303 13:32:05 ACTION-2303 Take over the scope-chain removal action from heycam and address ISSUE-2055 closed 13:32:25 "For compatibility with existing content, a user agent may allow a trailing semicolon... . In later specifications, this behavior may be more strictly defined, so authors and content generation tools are discouraged from using trailing semicolons." 13:33:04 DS: Instead of mandating that this is the case we'll say the above 13:33:11 ... but we might change this later on 13:36:03 -aemmons 13:36:32 RESOLUTION: We will change the trailing semicolon syntax to allow but not mandate the trailing semicolon and discourage its use 13:38:11 Action: shepazu to change the trailing semicolon syntax to allow but not mandate the trailing semicolon and discourage its use, per ISSUE-2084 13:38:11 Created ACTION-2318 - Change the trailing semicolon syntax to allow but not mandate the trailing semicolon and discourage its use, per ISSUE-2084 [on Doug Schepers - due 2008-10-24]. 13:39:17 ISSUE-2093? 13:39:17 ISSUE-2093 -- 16.2.9 by 'identity' -- OPEN 13:39:17 http://www.w3.org/Graphics/SVG/WG/track/issues/2093 13:39:22 Topic: ISSUE-2093 13:41:32 -anthony 13:42:03 +??P3 13:42:20 Zakim, ??P3 is me 13:42:20 +anthony; got it 13:43:18 DS: I can follow up with him on this 13:43:27 ED: Seems like an easy change 13:43:39 [[ 13:43:43 The 'problem' with the by animation is none for 13:43:43 the future, because this is already clarified in 13:43:44 SMIL3, therefore any comments about this can 13:43:44 be completely skipped in SVG, especially because 13:43:44 in SMIL 2 and 3 it is precisely described, that and how 13:43:44 from-to, from-by and by animations are equivalent 13:43:46 to the related values animations. 13:43:48 ]] 13:45:51 ACTION: Doug to Follow up on ISSUE-2093 13:45:51 Created ACTION-2319 - Follow up on ISSUE-2093 [on Doug Schepers - due 2008-10-24]. 13:46:30 http://www.w3.org/Graphics/SVG/WG/track/products/11 13:47:10 Topic: ISSUE-2130 13:47:16 ISSUE-2130? 13:47:16 ISSUE-2130 -- Basic Data Types section needs clarifications -- OPEN 13:47:16 http://www.w3.org/Graphics/SVG/WG/track/issues/2130 13:48:47 ISSUE-2134? 13:48:48 ISSUE-2134 -- Ambiguities in the 'use' element -- RAISED 13:48:48 http://www.w3.org/Graphics/SVG/WG/track/issues/2134 13:49:12 ISSUE-2137? 13:49:12 ISSUE-2137 -- Add clarification about begin time for canvas negotiation -- RAISED 13:49:12 http://www.w3.org/Graphics/SVG/WG/track/issues/2137 13:49:38 ED: I don't think it happens on parse time 13:49:42 ... but I could be wrong 13:50:10 DS: So it would happen on rendering? 13:50:18 ED: Before rendering 13:50:39 DS: Why don't we say that Tiny doesn't specify this but we will clarify this in later specification 13:50:42 ED: Sure 13:52:19 RESOLUTION: The negotiation time is implementation specific 13:52:36 Action: shepazu to reply to ISSUE-2137 saying this is implementation-specific 13:52:36 Created ACTION-2320 - Reply to ISSUE-2137 saying this is implementation-specific [on Doug Schepers - due 2008-10-24]. 13:52:41 Topic: ISSUE-2139 13:52:43 ISSUE-2139? 13:52:43 ISSUE-2139 -- Add note regarding eRR attribute and prefetch element -- RAISED 13:52:43 http://www.w3.org/Graphics/SVG/WG/track/issues/2139 13:53:05 DS: Was discussed to days ago 13:53:29 ISSUE-2140? 13:53:29 ISSUE-2140 -- Ambiguities in mediaSize -- RAISED 13:53:29 http://www.w3.org/Graphics/SVG/WG/track/issues/2140 13:53:40 Topic: ISSUE-2140 13:55:09 AG: I had a quick look at this 13:55:24 DS: I think what we mean is with regards to file size of the media 13:55:50 AG: Change required? 13:56:03 Clarify this means that ""Defines how much of the media to fetch in bytes with regards to the file size of the media." 13:57:34 ACTION: Doug to Clarify the meaning function in ISSUE-2140 13:57:34