W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Minutes, SVG Marathon telcon Friday October 17 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Sat, 18 Oct 2008 01:14:14 +1100
Message-ID: <48F89DB6.8000305@cisra.canon.com.au>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 17 October 2008 14:15:01 GMT