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