SVG Working Group Teleconference -- 17 Oct 2008

<trackbot> Date: 17 October 2008

trackbot, code?

<trackbot> Sorry, anthony, I don't understand 'trackbot, code?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

trackbot, pass code?

<trackbot> Sorry, anthony, I don't understand 'trackbot, pass code?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<ed_work> heh

NH, you there?

<NH> Sorry I wont be able to join before ~12.30 CET

ahh ok - no worries

http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement

<ed_work> 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> http://www.w3.org/Graphics/SVG/WG/track/issues/2055

<ed_work> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0160.html

<ed_work> 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> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0183.html (sorry, missed to put in the issue/action)

<ed_work> 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> 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> 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> 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 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> 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> 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

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

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> http://www.w3.org/Graphics/SVG/WG/track/issues/2055

ED: I did some changes to the spec

<ed_work> 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> 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> 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> 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 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> 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> 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> [[

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 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> 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 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> 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> http://www.w3.org/Graphics/SVG/WG/track/issues/2130

<shepazu> ISSUE-2134?

<trackbot> ISSUE-2134 -- Ambiguities in the 'use' element -- RAISED

<trackbot> 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> 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 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> 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> 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 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> http://www.w3.org/Graphics/SVG/WG/track/issues/2145

<shepazu> ISSUE-2147?

<trackbot> ISSUE-2147 -- Section on externally referenced documents confusing -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2147

<shepazu> ISSUE-2149?

<trackbot> ISSUE-2149 -- Paced interpolation of polygons -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2149

<shepazu> ISSUE-2150?

<trackbot> ISSUE-2150 -- Clarify 'required' attribute -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2150

<scribe> ACTION: Doug to Respond to ISSUE-2149 [recorded in 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].

- DRAFT -

SVG Working Group Teleconference

17 Oct 2008

Attendees

Contents

ISSUE-2134

ISSUE-2094

ISSUE-2089

ISSUE-2055

ISSUE-2083

ISSUE-2084

ISSUE-2093

ISSUE-2130

ISSUE-2139

ISSUE-2140

Summary of Action Items

Scribe.perl diagnostic output