SVG Working Group Teleconference -- 23 Oct 2008

<trackbot> Date: 23 October 2008

LC comments

<ed> http://lists.w3.org/Archives/Member/member-svg-editors/2008Oct/0322.html

<anthony> scribe: anthony

<ed> http://www.w3.org/Graphics/SVG/WG/track/products/11

ISSUE-2085

ISSUE-2085?

<trackbot> ISSUE-2085 -- Spec unclear where focus should initially go when a document is loaded -- OPEN

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

ED: Issue raised by Ikivo
... NH has an action to propose new wording

DS: Perhaps we should make a proposal to him

<fat_tony> scribeNick: fat_tony

<ed> http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#navigationbehaviour

ED: The thing he is complaining about is the steps for how focus navigation behaves
... You can interpreter this in a few ways
... that's not necessarily a bad thing

DS: Do we talk about document focus vs UA focus

<scribe> ACTION: Doug to Propose wording for document focus vs user agent focus that addresses ISSUE-2085 [recorded in http://www.w3.org/2008/10/23-svg-minutes.html#action01]

<trackbot> Created ACTION-2324 - Propose wording for document focus vs user agent focus that addresses ISSUE-2085 [on Doug Schepers - due 2008-10-30].

ISSUE-2094

ISSUE-2094?

<trackbot> ISSUE-2094 -- accessing rules for traitAccess -- OPEN

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

ED: We have two open actions there
... one is on me
... the other on A Emmons
... and A Emmons had the action to respond to the commenter

DS: Who was this for?

ED: Julien R
... I'll just check the public mailing list

AG: Did you make the change?

ED: No he's just asking for an answer
... it's not clear that he wants anything changed

DS: What's the justification for the ones we chose not to change?

ED: I really hoped A Emmons would take care of this
... he seemed to have a good grasp on it

AG: Can we ping him at lunchtime?

DS: We can always send him an email

ISSUE-2107

ISSUE-2107?

<trackbot> ISSUE-2107 -- i18n comment 6: Direction and bidi-override attributes -- RAISED

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

ED: Is this done?

DS: We really need Chris here for this
... and the next one 2110
... these are both internationalisation issues

OI: Bidi direction is important to the I18N
... I think there are issues with Right-to-Left and Tob-to-Bottom

DS: We do not cover vertical text in Tiny
... but we do in full

AG: The wording in the specification allows for support for Top-to-Bottom text
... but doesn't mandate it

DS: Tiny 1.1 is just subset of features in full

ED: We do have tests for Right-to-Left and Top-to-Bottom
... but they are simple tests
... we don't test all the tricky cases
... so with the issue here I do agree with it
... the last comment I believe is a miss understanding

OI: [Reads Issue]

ED: There is nothing preventing you from doing that
... [Explains feature]

OI: Is inherited like CSS?

ED: Yes it is

OI: If it is inherited like CSS that is ok

ED: We took the direction property from CSS
... so it should be the same

OI: The default is Left-to-Right

DS: Would it be worth noting that in the spec

OI: Could say that the property of RtL is inherited from the top block
... then it will be inherited to the terms inside it
... that's in CSS
... what is it in your terms

ED: text content element is the term for it

DS: I think this is just an authoring note
... if you put direction in the root of the document
... it will apply only to text elements
... it could confuse people because it's not like "text-direction"

ED: It does map to the CSS property

OI: You should note that it only applies to text blocks
... if I have a text block with direction RtL and a nested text block is also RtL

DS: And of course override-able

ED: That's one of his requests
... to have examples
... I think it would be useful to have the inheriting thing explained

OI: So people know that there is inheritance?
... may not be necessary

DS: More so for authors rather than implementers
... I think I'm going to put in a note
... because it's not really clear that direction applies to text

OI: The direction property only applies to text
... not to graphics

ED: Another comment he makes here in this issue
... that we say in the spec that authors are discouraged from using direction and unicode-bidi

DS: [Reads out issue]
... so what this sentence means for people using western languages don't mess with this

OI: Do you understand the issue if you place a dot after it
... the unicode algorithm doesn't know about the dot if it's LtR or RtL
... That's a problem with 'weak directionality'
... they don't have a directionality

ED: Just need to clean up the wording on this issue and make an example or two

OI: I can review the wording now if you want

ED: So in this issue there was not suggested text (wording)
... there's no concrete proposal on this issue

OI: I can review this issue, propose wording and make an example

ED: If you can make an example sure, that'd be great
... so he's example for the example of using RtL on the top and unicode-bidi embed

DS: Did we decide about the in most cases?

ED: Ori said he's happy to review any text proposal we have
... if you can propose some new wording that would be great

OI: I'm not on the mailing list but I will send you an email
... Here's a small HTML example
... [shows example]

<scribe> ACTION: Doug to Propose wording and examples for ISSUE-2017 [recorded in http://www.w3.org/2008/10/23-svg-minutes.html#action02]

<trackbot> Created ACTION-2325 - Propose wording and examples for ISSUE-2107 [on Doug Schepers - due 2008-10-30].

ISSUE-2110

ISSUE-2110?

<trackbot> ISSUE-2110 -- i18n comment 8: Text rendering order -- RAISED

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

OI: I think this is very similar
... oh wait, this is different
... that would be great if the direction of RtL that right glyph would be rendered first
... I think it would be nice
... but it is not a must
... that the right most glyph would be rendered first
... would be good from slow implementations so you can read the glyphs as they're being rendered

ED: I'm not sure that the sentence is saying that

OI: That's how I read it
... [reads sentence out]

DS: So when it says rendering, I don't think the rendering would be slow
... if they're overlapping then the order matters

OI: If they're not overlapping and the rendering order is not fast enough
... then you'll notice it
... do you think there'll be any slow implementation?
... do you think there'll be a slow application in a hand held device with a slow processor
... it only matters if this is a slow rendering device

DS: Honestly I'd be very surprised
... because the text is processed as a block
... and put in order for placing on the canvas

ED: I mean rendering part of text content block would be very strange

OI: If the user agent that does the rendering to a canvas is it possible
... there is actually know mean for the rendering order of blocks

DS: Individual characters in the block may over lap due to kerning

<ed> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0117.html

ED: Chris has suggested new wording there

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0179.html

DS: Here is my reply
... if the glyphs are reordered in the byte stream what happens?

OI: Why would that happen?

DS: Richard says it could; for example South East Asian characters
... we need Richard for this

ED: We may need some tests

OI: We need a Hebreu for this
... or Arabic
... and for South East Asian languages
... maybe Richard can supply us an example today

DS: There is nothing stopping us for making examples today
... but it needs to be done in two days

ED: How is this handled in HTML again?
... is this already addressed

OI: Yes, it works fine
... I'm not sure about the rendering order
... in HTML it doesn't matter

DS: Yes you can
... because of CSS
... they are adding Opacity in CSS
... so they will run into the same issues
... with letter spacing
... so HTML and CSS has the same problem

ED: For consistency we use the same algorithm

OI: For consistency can we say it's defined in HTML

DS: Probably not

OI: The issue is the running order just as Richard sent in ISSUE-2110

ED: I mentioned reasons for reordering
... so I agree to that one
... the one that Chris sent

OI: The reason we need to discuss rendering order is for when we have overlap
... I agree with Chris

ED: So essentially this is rendering the first character you'd read

OI: I agree with Chris
... not to sure about what Doug is saying
... we need a clarification from Richard

ED: Does this address the whole issue

<scribe> ACTION: Erik to Add the proposed wording for ISSUE-2110 [recorded in http://www.w3.org/2008/10/23-svg-minutes.html#action03]

<trackbot> Created ACTION-2326 - Add the proposed wording for ISSUE-2110 [on Erik Dahlström - due 2008-10-30].

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

<ChrisL> RIM states that they use SVG Tiny 1.2

<ChrisL> http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=211600037

<ChrisL> RIM engineers are looking at supporting 3-D graphics, probably through adopting the Java specification for OpenGL ES (JSR 239). The company is also broadly adopting 2-D scalable vector graphics such as SVG Tiny 1.2. It first used SVG in version 4.6 for the Blackberry Bold phone.

<ChrisL> "We are looking at doing fairly complete support for SVG in all the places an image needs support in a device," said Liam Quinn, who heads browser development at RIM.

<ChrisL> issue-2130?

<trackbot> ISSUE-2130 -- Basic Data Types section needs clarifications -- OPEN

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

CL: We had a related issue which was about xml:id and the XML Schema
... and we resolved to fix the schema
... which fixes the first part of the issue
... for the second one
... we are asked to supply an example
... this is related to XML namespacing

DS: He may simply not understand what QNames are
... I guess we could add a quick example

<ChrisL> XML namespaces has two methods, one for elements (unprefixed ones use the default namespace) and one for attributes (where unprefixed ones do not).

<ChrisL> Following the tag finding on qnames in attribute values, and common practice, qnames in attribute values also do not use default namespaces

<ChrisL> http://www.w3.org/2001/tag/doc/qnameids.html

<ChrisL> This wording needs to be clarified

<ChrisL> "If the <QName> has a prefix, then the prefix is expanded into an IRI reference using the namespace declarations in effect where the name occurs, and the default namespace is not used for unprefixed names. "

<ChrisL> ACTION: Chris to clarify QName expansion to tuples [recorded in http://www.w3.org/2008/10/23-svg-minutes.html#action04]

<trackbot> Created ACTION-2327 - Clarify QName expansion to tuples [on Chris Lilley - due 2008-10-30].

<ChrisL> "If the <QName> has a prefix, then the prefix is expanded into a tuple of an IRI reference and a local name, using the namespace declarations in effect where the name occurs. Note that, as with unprefixed attributes, the default namespace is not used for unprefixed names. "

CL: Proposed sentence in IRC

<ChrisL> The relevant part of the tag finding, that we follow, is "Specifications that use QNames to represent {URI, local-name} pairs MUST describe the algorithm that is used to map between them."

CL: So an example would be if you're animating an attribute name is stroke
... you'd be animating "stroke" and not "svg:stroke"
... [reads out rest of issue]
... so his third one is because in the schema we haven't defined anything as frame target
... do we want to patch up the schema to define something called "frame name"

DS: Do we define what a frame target is?
... we can add a definition

CL: Where is frame target used

ED: Linking, I think the <a> element

<ed> http://dev.w3.org/SVG/profiles/1.2T/publish/linking.html#AElementTargetAttribute

<ChrisL> http://www.w3.org/TR/SVGMobile12/linking.html#AElement

CL: [Reads part out in spec]

<ChrisL> "<frame-target>"

<ChrisL> Specifies the name of the frame, pane, or other relevant presentation context for display of the linked content. If this already exists, it is re-used, replacing the existing content. if it does not exist, it is created (the same as _blank, except that it now has a name). Note that frame-target must be an XML Name [XML11].

<ChrisL> we could link XML Name to the types chapter

<ChrisL> basically frame-target is of type XML Name. So there is no error in the spec

CL: The next one handler, string
... XML doesn't call string "strings"

ED: What does XML Events say?

<ChrisL> for the next two, XML-NMTOKEN is a subset of string

ED: is it just an XML token?

CL: And we have a link to the types which say NMToken

<ChrisL> NMTOKEN is correct, and links to http://www.w3.org/TR/SVGMobile12/types.html#DataTypeXML-NMTOKEN

<ChrisL> 'string' is too loose and should be corrected

CL: Which chapter is handler in?

ED: Scripting

<ChrisL> we can edit the spec where it says string

ED: Do we just have XML-NMToken as a basic type?

CL: Yes

ED: We do us XML name
... on listener
... but not on handler

CL: I've corrected handler
... I don't see it on listener

ED: It's using XMLName, it should be using NMToken in that case

CL: So this is in the scripting chapter?

ED: Yes

<ed> heycam: I have an up-to-date tools directory

<ed> note that someone might have changed the example, we did discuss it

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

ED: A Emmons did send proposed text
... and Cyril responded to say if the text is added then he'll be fine with that

<scribe> ACTION: Anthony to Add the text from the wording proposed by A Emmons to the specification regarding ISSUE2139 [recorded in http://www.w3.org/2008/10/23-svg-minutes.html#action05]

<trackbot> Created ACTION-2328 - Add the text from the wording proposed by A Emmons to the specification regarding ISSUE2139 [on Anthony Grasso - due 2008-10-30].

ISSUE-2145

ISSUE-2145?

<trackbot> ISSUE-2145 -- Clarify media timeline and document timeline -- RAISED

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

DS: He hasn't offered anything helpful regarding the issue

ED: Do we want to postpone this

DS: We will look at this one in a bit

<ed> png?

<scribe> scribe: Anthony

<scribe> scribeNick: fat_tony

SVG IG Japan

JF: Just started the activity in Japan
... for SVG IG
... created a mailing list
... had first f2f meeting on Friday
... the second is on 12th Nov
... and we invited Doug to talk to the group
... the group includes Takagi-san from KDDI and Takahashi-san fromm Indigo and Mori-san from Osaka City Uni

CL: Where is the mailing list?

JF: Yes it is in W3C
... there are several people from JIPDEC

<ChrisL> http://lists.w3.org/Archives/Public/public-svg-ig-jp/

JF: JIPDEC is a Japanese standards body

<ChrisL> JIPDEC - Japan Information Processing Development Corporation

JF: that is managing the standarisation of SVG in Japan

<ChrisL> http://www.jipdec.or.jp/eng/

DS: JIPDEC sells copies of the JIS standard

<shepazu> s/11th Nov/12th Nov/

JF: Keio W3C will have JPC meeting on the 6th November
... so we can expect more traffic on SVG IG JP

DS: If Kaz can translate the description on the public mailing list page in English to Japanese

<scribe> ACTION: Doug to Coordinate on Kaz on JP IG list description [recorded in http://www.w3.org/2008/10/23-svg-minutes.html#action06]

<trackbot> Created ACTION-2329 - Coordinate on Kaz on JP IG list description [on Doug Schepers - due 2008-10-30].

<ChrisL> list description is in english currently

<ChrisL> http://lists.w3.org/Archives/Public/public-svg-ig-jp/

JF: Currently our main activity in SVG IG JP is to support the SVG JIS standardisation
... and coordinate with other people. Another activity is to promote the usage of SVG for
... web mapping in Japan
... we will working on a new module called SVG Map module

CL: This is related to the existing JIS standard?

JF: No this is a different module and and email to promote it has been sent out
... we will work on a complete module
... so we can make a complete proposal to SVG WG
... we also considering on gathering SVG map data in Japan
... and publish the map data on the SVG community site
... possibly on planet SVG

CL: Are there minutes of the F2F meeting?

JF: Yes minutes were scribed but they are in Japanese
... by Kaz

DS: I want to thank you for all your effort you have put into this

<ChrisL> thats good. hope to see them on the mailing list

DS: The fact that you are the chair of the SVG IG is really good. I appreciate that

SVG JIS Standard

JF: On the same date we had the first SVG JIS committee meeting
... Hagino-san of W3C Keio is the manager
... and the goal is to create a JIS Standard for the SVG based format for mapping
... and that includes a complete translated specification of SVG Tiny 1.2

DS: When will they begin translation?

JF: As soon as PR is available
... in the first committee meeting we discussed the possible category of the JIS standard
... and also the structure of the standard has been discussed
... there are two possible categories, one is mapping
... and networking category

DS: Can it be in both?

JF: That is an important point
... as for the structure four possibilities was suggested
... the first is the one just for SVG
... and one for SVG map module
... the second is to have just one standard just for SVG map module and that will be different from the SVG Tiny 1.2 spec
... and the third possibility is to have a single JIS standard to have branch of map module
... and the last possibility is to have a single combined specification which has SVG map and SVG Tiny all in one

CL: There are advantages of each

JF: There are some people who think that it is not useful out side of the use case of mapping
... we had the conclusion that there will be a map module and a network module
... in the last committee meeting they decided to have a separate standard for SVG Tiny and a separate for SVG Map module

<ChrisL> Its my preference also, to have one standard which is SVGT1.2 in Japanese, and a second one which is SVG Mapping and could be submitted to W3C so we can have it as an W#C spec in English as well

JF: so we hope that we can bring the Map module to the working group

DS: I know Andreas will be interested in this module
... the other thing that KDDI is not a member of W3C

<ChrisL> I would like to see the Japanese version on the W3C site as an official translation

DS: so they can't make a submission

JF: It will be a proposal from the IG

CL: We need to get patent statements from all of the authors
... agreeing to W3C patent policy

JF: People in SVG IG JP agree to W3C patent policy

<ChrisL> http://www.svgopen.org/2004/papers/indigo/

<ChrisL> Development of location based search engine service using goSVG

<ChrisL> Yuzo Matsuzawa

<ChrisL> Indigo Corporation

JF: The goal is to come up with SVG Map profile which might be based on SVG 2.0 Core
... or some other useful module like Transforms
... SVG JIS project will be two year
... it started this April and ended in Mar 2009
... that is the goal in the first year to do the translation
... of the whole specification
... we have to finish the translation around the end of next March
... in the second year the committee will take a formal process to publish the standard
... in order to achieve this the timing for SVG Tiny to achieve PR and Rec is important
... and will start the translation as soon as the PR spec is published
... so we hope this will happen in early Nov

DS: So you will start translating when it's in PR and not Rec correct?

JF: Yes

DS: So as part of the translation I'm sure they will find typos
... I'd be surprised if reading the specification they will not be confused, will they be able to propose a question
... if the english is not clear

JF: The problem is the translation is out sourced
... but perhaps the SVG IG can review the translation

CL: If someone perhaps miss understand somethings
... then it would be nice for it to come back to us

DS: They have an investment on getting it correct
... if something is confusing to the translator they should know that they should communicate with the SVG WG

<ChrisL2> its good in that case to ask the WG for clarification. Sometimes the English is not clear to a non native speaker. (Actually some of the spec is written by non-native speakers, too)

DS: Our plan is early next week we will do our call for transition
... it is possible as early as Wed
... we think we can go to PR on Nov 3rd as PR and we will to Rec on Dec 2nd

CL: When we go to Rec we will make a press release
... it would be nice to have Canon on the press release

DS: Just so you know RIM has announced that it is developing SVG Tiny 1.2

<ed> scribe: Erik

<ed> scribeNick: ed

svg transformations module

<dino> i just sent in comments on svg transformations. Did they make it to the list?

<dino> shepazu, are you moderator?

<shepazu> dino, just modded it

<shepazu> dino: can you join us?

<dino> shepazu, thankyou!

<dino> yes, i'll come up if you promise to be nice

DS: dino sent another message (I'm moderating this now, it got caught)

http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0224.html

AG: sent the proposal to the public wg list
... tried to keep it as close as possible to the css proposal
... the one in css uses z-order
... I decided to leave that out for now and use the painters algorithm
... it's an extension of the svg 2d transforms
... it's extended to 3x4 matrix to give you the extra rotation capabilities
... we think that's all that's necessary
... obviously extending this means we need to extend the DOM interfaces

DS: does this have impacts on declarative animations?

AG: yes, we need to consider that use-case
... and we need to add a section there to say how that should be handle
... if you have a circle on top of a rectangle and you rotate both as a group you'll still see the circle because it's on top of the rect
... rotate in the 3d sense

DJ: the way css transformations work is that anything that has a transforms gets a css stacking context
... which means it goes into the z-index system
... z-index doesn't mean position, it's just like an offscreen buffer and the order you draw those
... you can have something something with a z value that puts something close to the viewer, but have a z-index that puts it below some other elements
... one question is how the svg transformations are supposed to be rendered

CL: it's hard to do a rotation of two elements that rotate in a circle in z

if you have two elements in differnt 3d coordinate systems each group is rendered in two offscreens, so you can't have one elements sometimes in front of and sometimes behind

DJ: most systems in 3d don't allow you to do grouping

CL: opengl doesn't allow that, but PHIGS does
... opengl is immidiatemode, PHIGS is more like svg, it has a structure and a DOM, it has nesting, transformations
... in PHIGS has the same concept of grouping and transformations as svg, but everything is in the same 3d coordinate system

ALG: are you talking about real 3d rendering in svg? is there any use in x3d?

CL: 3d rendering in 2d

DJ: you can position things but it's like drawing a postcard in 3d space

CL: 2.5d is 3x3 matrices

AG: the problem is that it's bad for authoring, it's difficult to write the transformations and hard to animate

DS: are we proposing 2.5d or 3d transforms?

AG: localized 3d transforms
... it's still sort of 2.5d because you don't have a single 3d coordinate system, you have localized 3d coordinate systems

CL: the 3d transforms are still affine transforms?

DJ: the proposal canon sent has non-affine transformations available
... 3d affine transforms
... they have true perspective, so they're not 2d affine transforms

CL: normally geometry are seen as structure
... in svg, and colors and such are seen as styling, so properties vs attributes

DS: but if it's going to be in css it should be properties

CL: but then the transforms in svg should also be properties?

AG: the reason for having them as properties is to keep it as close to css as possible

ED: people have been asking for transforms to be in css for some time (even for svg use-cases)

DS: can you still have the animated "starwars" effect?

AG/DJ: yes

CL: how do we move this forward?

AG: what's the priority of transforms in css?

DJ: it's not part of css until the group is rechartered
... mozilla just implemented css transforms, but only the 2d parts

DS: are you willing to work with the SVGWG to move this forward?

DJ: currently css transforms can apply to svg root elements only, like a postcard

DS: we need to figure out how SVG and CSS should work together wrt to transforms

DJ: there are no units in svg in transform values, might be a problem for example

AG: i'm happy to work with the css wg to move this

DJ: mostly the proposals are the same
... we now do a full 4x4 matrix
... things you need to be aware of
... hit testing

AG: and how do you get boundingboxes?

<ChrisL2> non-invertible matices. singularities

DJ: we have it on the phones
... what happens is that sometimes, with overflow hidden in css, you have to flatten the whole tree
... sometimes it looks like 3d but it's really not
... [draws on whiteboard]

<fantasai> There were two concerns that came up when we discussed transforms in Beijing

<fantasai> one was syntax: making the syntax match more closely CSS conventions

<fantasai> the other was the default value of the property

<fantasai> which can't be the same as the identity transform

<fantasai> because transformation needs to trigger some side effects in CSS

<fantasai> such as turning the element into a block formatting context

DJ: clipping in 3d is difficult

<fantasai> so it contains all its floating children ,etc

DJ: you can't preserve 3d and have clipping

<ChrisL2> yes. so the initial value needs to be 'no transform applied' so you dont get a css stacking context, right?

DJ: the transforms spec isn't very big, but it's probably full of things that needs further discussion
... perspective-transform ...??
... read our proposal and ask for clarifications where needed
... reason we haven't got much feedback is probably because not many have tried implementing it so far
... css has a lot of edge cases that affect the 3d transforms

CL: the initial value for transform needs to be 'none' not identity, because it sets up a stacking context

DJ: it's nice to put the perspective on a parent div or svg:g, and then use it for the child elements

AG: understand the need to the property

DJ: preserve3d is something svg would need too probably

AG: it would be nice to have DJ for another F2F for more discussion on this
... we could achieve faster progress that way

DJ: i'll join the svg mailinglist

JF: it's important to work with the CSSWG on this
... we don't want two specs on this

RESOLUTION: we won't form a joint taskforce, we'll work with DJ and the CSS WG to ensure that 3d transforms can be used in both CSS, HTML and SVG

next F2F meeting(s)

JF: canon has an experimental implementation of the 3d transforms module in svg, and we can confirm that we can easily describe 3d-based UI:s by using this
... maybe at the next F2F we can have a demo ready

<ChrisL2> Foundations of Open Media Software (FOMS)

AG: we can host the next F2F in sydney, we want to do it after the FOMS conference (http://www.foms-workshop.org/foms2009/pmwiki.php/Main/CFP)

<ChrisL2> Developer Workshop

<ChrisL2> Thursday 15 - Friday 16 January 2009

<ChrisL2> Hobart (Tasmania), Australia

<ChrisL2> http://www.foms-workshop.org/foms2009/pmwiki.php/Main/CFP

AG: so Jan 19

ED: i would prefer to have it a bit later

CL: there's is an AC meeting in march

ED: early february would be better

DS: i'll be speaking at a conference in february, *checking when*
... let's schedule the f2f for february 16-20

<fantasai> Minutes from CSSWG meeting in Beijing: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JulSep/0184.html

<ChrisL2> Scribe: Chris

<ChrisL2> scribenick: ChrisL2

More Last Call Comments

<ed> http://www.w3.org/Graphics/SVG/WG/track/products/11

ED: We now have only 9 issues

http://www.w3.org/Graphics/SVG/WG/track/products/11

ISSUE-2153

RNG link

Link to RelaxNG Schema

ISSUE-2153?

<trackbot> ISSUE-2153 -- Link to RelaxNG Schema -- RAISED

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

this can be closed, Doug has updated the spec to point to the actual correct RNG that we are all editing

also the make scrip updates this master -> publish

ISSUE-2145?

<trackbot> ISSUE-2145 -- Clarify media timeline and document timeline -- RAISED

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

ED: Prefer to have AE on this one

sync behaviours not currently impleented in Opera

postpone to tomorrow?

DS: Perfer to do not if poss

ED: Some suggested text in the comment

(we discuss 'locked')

CL: On this part "The specification should say what happens when a video/audio element points to a file or a set of streams containing multiple audio tracks (english and french, or AAC and AC3) or multiple video tracks.

the answer is that it depends on whatever fragment syntax is defined for that media type registration. Depends also on what the media fragents WG comes up with

there are other technologies that relate to this eg MPEG-21

its outside our spec. But clearly something that needs to be solved

DS: on his second-;ast para

ED: .... agree about media timeline rather than 'play time'

CL: What does smil say about sync delay and the allowed amount of sync?

ED: eg a straming video, it can be difficult to seek back. Thats an example where the media timeline cannot be controlled
... not always possible to restart from time zero

DS: Media eleents are time containers. So locking one does not lock its parent

CL: But if they are locked, and you pause the child, what happens to the parent. Thats what he is asking

http://www.w3.org/TR/SMIL2/smil-timing.html#Timing-ControllingRuntimeSync

DS; Lockimng is only in terms of timeline sync, so if you pause an element its timeline is frozen; when its playing its synced to the parent

CL: I read there "Note that the semantics of syncBehavior do not describe or require a particular approach to maintaining sync; the approach will be implementation dependent. Possible means of resolving a sync conflict may include:"

also under "Paused elements and the active duration"

"In addition, when an element is paused, the accumulated synchronization offset will increase to reflect the altered sync relationship. See also The accumulated synchronization offset."

http://www.w3.org/TR/SMIL2/smil-timing.html#Timing-PausedElementsAndActiveDur

DS: So in the end its defined by SMIL there

ED: So I can change playtime. will do that now

<scribe> ACTION: Doug respond on ISSUE-2145 citing these minutes and pointing to SMIL 2.1 to talk about elapsed time offset when paused [recorded in http://www.w3.org/2008/10/23-svg-minutes.html#action07]

<trackbot> Created ACTION-2330 - Respond on ISSUE-2145 citing these minutes and pointing to SMIL 2.1 to talk about elapsed time offset when paused [on Doug Schepers - due 2008-10-30].

ISSUE-2107?

<trackbot> ISSUE-2107 -- i18n comment 6: Direction and bidi-override attributes -- OPEN

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

CL: We are almost done on that one
... we had a native Hebrew speaker earlier today check our examples and tests
... its added to the spec, tested and impleented
... doug has an action to add an example to the spec

DS: Want a step by step example and also a template for people to follow

Still open until the examples are added

<ChrisL> ISSUE-2147?

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

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

<ChrisL> ED: Cameron wrote about this on public list. 2 script elements with same UIR, execute twice not once so section is incorrect

<ChrisL> DS: That section is badly writted

<ChrisL> ED: AE did a small rewrite of some of it

<ChrisL> DS: I sent an email with a more extensive rewrite

<ChrisL> ED: There are multiple copy pasted sentences there

<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/att-0161/externalRefs.html

<ChrisL> 14.1.6 Externally referenced documents

<ChrisL> http://www.w3.org/TR/SVGMobile12/linking.html#externalReferences

<ed> DS: my proposed text is the last one in the externalRefs.html file above

<ChrisL> ED: Scripting chapter covers the script case, Cameron fixed it

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

<ed> actually not yet

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

<ChrisL> the questions on external media and external scripts are in fact completely independent of the section on primary and resource documents, which are only about svg

Testing

<ChrisL> media-audio-206-t is passed in GPAC

<ChrisL> but animate-elem-226-t fails

- DRAFT -

SVG Working Group Teleconference

23 Oct 2008

Attendees

Contents