See also: IRC log
<trackbot> Date: 22 June 2009
<scribe> Scribe: anthony
http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition
AG: I have about two or three tests to write
CM: Still a few errata that needs
to be folded in still
... clip path one
... and Liveness of getIntersectionList
JW: Still have to do that one
DS: JW had a few problems with the clip path one
JW: Re pointer events
DS: Yes
... don't think we should think about rolling this out until JW
can get back and finish his quota
JW: I should get back to that next week
AG: Still need to run the script over test suite
CM: Is the comment history lost in the conversion?
AG: Yes
... I like what Erik has done on the wiki page with commenting
what tests have been done
... and what needs to be done
CM: Good idea
... Mobile 1.1 spec was fixed to have dated links
... so we will be ok for publishing
AG: You did the changes CM?
CM: Yes
CM: DS You've emailed out about this?
DS: I saw your reminder and have
done it
... thought it would be a good idea before minutes get sent
out
CM: It would be good if CL was here to discuss it further
AG: I'm ok with proposal
JW: Do we need to discuss further the disclaimer on each email?
DS: Don't think so
JW: Don't think we need to put a disclaimer when we send minutes?
DS: Anyone who is already
subscribed to the list is already going to know about it
... lets not bother with sending a disclaimer
... so what this means when we send the minutes we will send
them to www-svg like we would normally and BCC the
public-svg-wg list
AG: Usage of public-svg-wg?
CM: Still used for technical discussion
DS: It says in the minutes it
says most of our technical work will take place on the working
group list
... that is what we are charted to do
... I think we should do what comes naturally next
... CL will probably want to conduct work on the working group
list
... for conversations that start from minutes will be on the
www-svg list
... the public might have comments
CM: We'd expect most of the comments from the public to be positive
<heycam> (joke)
DS: conversations will happen wherever it seems more natural, even though charter historically says we'll work on WG list
CM: I emailed Dominic on W3C who
works part time on the systems team
... and asked if it was possible to set up DVCS
... JW you have good experience with Mercurial
... Dominic replied to me saying the systems team doesn't have
enough resources to set that up
... During the F2F we discussed one of us hosting the
repository
... That has the downside of the repository not being on a W3C
address
DS: Didn't Dom say that we could host it on W3C but someone in the team would have to do it
CM: He said it would be more cost effective for someone in the group to host it
DS: Wondering if I could put it
on my personal space
... I think I can run scripts
... I'd need root access?
JW: It's a repository where
people can copy from
... but can't push back
... unless you have root access
... If the team doesn't have the resources we either continue
working with stuff
... that's getting further behind
... or break away and move to something new
DS: I'm not particularly
comfortable with having work on another server
... makes it hard to find out what's going on
<ed_work> nothing prevents someone from running a dvcs solution locally and then committing changes to cvs
DS: would rather tackle it head
on and find resources for W3C space
... rather than push work out
... I'd rather push the issue with the systems team
<ed_work> and yes, I agree with DS that the main repo should be hosted at w3c
DS: and at least get them to give
me root access to set those things up
... are we experienced enough to know exactly what needs
doing?
JW: No
DS: Step 1 is to know exactly what we are asking of them
JW: I can start step 2 or 3
before going to them
... another step to take is to set up a dummy repository
... so that people who are not familiar with DVCS can get to
know it better
... does that make sense?
DS: No
JW: So it's just the members that will be using DVCS?
DS: Yes
... so you're saying we should test it out to see if that's
what we really really want?
CM: I have a feeling that the
systems team want to set it up
... so it will integrate into their Database
... to make it easier to set permissions
JW: I've tried an SSH key thing
with this and I don't know if it will that bigger change
... but I will check with the Mozilla people
... and get step by step instructions on what's involved
DS: You could check with them if
they are willing to help the systems team to set it up
... should find other resources that are willing to help out
the systems team
... not sure if they're open to that
... but if you can find out, we can go from there
CM: I do have root access on my
hosted machine
... So if we want to set up a test machine
... I can put it on there
... one of the worries you had DS was it moves things more out
of the team
DS: Yes and I think it's harder
for people to discover what's going on
... and decreases the W3 value and brand
CM: It would be a shame to lose
some of the services
... well experimenting with the system and JW finding out if he
can get information on setting it up
... is a good way forward
... not sure how open the systems team is with getting help
DS: One problem is some things
are team confidential
... we have people who are members of the team who are W3C
fellows
... they have team access but work for another employer
... I don't see how it would be much different
http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A715E3A0A7E@mailkeeper.mdigitalm.com
CM: Someone from Quickoffice
pointing out an error in one of the tests
... One of the tests is testing for calling beginElement and
endElement for methods on timeControl
... and they insert begin and end on the elements
... and he thinks one of tests shouldn't begin an animation
when beginElement is called
... the test description assumes that should work
... but according to the SMIL spec it shouldn't work
... he attached a reduced version of the test slide
... and I read through the SMIL spec
... and went through the test slide
... and I agree with him, at least for the reduced version
AG: Is there any problems in Tiny at all?
CM: All the info is in SMIL spec.
We refer to it
... I will confirm that the actual problem is in the test
... and email back to the list
<scribe> ACTION: Cameron to Check udom-svg-209.svg test case for the problem of beginElement pointed out by Quickoffice [recorded in http://www.w3.org/2009/06/22-svg-minutes.html#action01]
<trackbot> Created ACTION-2626 - Check udom-svg-209.svg test case for the problem of beginElement pointed out by Quickoffice [on Cameron McCormack - due 2009-06-29].
CM: We should fix any issues pointed out and republish the test suite
http://www.w3.org/mid/9a7916a70906200154i3991d5e3sfda2ce940d7d6f20@mail.gmail.com
CM: Email about what are valid
names for icc-profile
... CL added some syntax the colour module
... I have an action to port those changes back to 1.1 2nd
edition
... someone should reply to him point back to the module
... and mention it will be ported across
http://www.w3.org/mid/op.uvn9opyyidj3kv@zcorpandell.linkoping.osa
CM: Simon was asking about
accessKeys
... I think he's asking about giving a particular label to
animation starting and animation finishing
... and wants to extract from the document
... start animation and have some associated access key
... suggests a couple of ways to include that information
<ed_work> hmm...I was almost certain that I did respond to this
<ed_work> the problem with the label() syntax is that it causes the begin/end value to be interpreted as "indefinite"
CM: I guess it's syntax currently not allowed
<ed_work> I'd originally thought it was per list-item, but it's actually the whole value
DS: I think accessKey is pretty
crappy
... the access specification on XHTML 2 Access spec also has
the same functionality along with some interesting
functionality
... This is also something I'm looking at in the context of
DOM3 Events
... on problem with accessKey is it only allows you to type
characters
... it doesn't allow you to say on tap do this or on shift do
this
... this is something that could be solved by the key
identifiers in DOM3 Events
... so rather than giving a list of keys
<ed_work> that's not the concern he's raising though, it's more about labelling what accesskey actions there are (for discoverability)
DS: they give a list of key
identifiers
... I understand what ED is saying
... I'm just saying that patching up an old system is probably
not a good idea
... I don't mind patching it up
... but I'd rather we came up with a better solution
<heycam> ed_work, did your reply deal with the labelling aspect (modulo where you'd put that information)?
<ed_work> it's really not about patching up, even in ARIA there's no way to label an attribute in a way that can be used for begin/end
<ed_work> one solution might be to have some attribute to associate a <title> with a particular attribute, role or aria-*
DS: Within the constraints that Dr Olaf mentioned, I don't mind making the accessKey in SVG similar to the accessKey in HTML5 I just don't think it's a very good long term solution
CM: What about the issue of labeling?
DS: You mean discoverability?
CM: Yes
DS: Comes down to UA dependent
CM: I think he has particular UI in mind and wants to have some custom label string so it can be put in UI somewhere
DS: You mean labeling?
CM: Yes
<shepazu> http://www.w3.org/MarkUp/2009/ED-xhtml-access-20090423/
<ed_work> adding an 'aria-attributelabel' that has as value the name of the attribute it describes maybe, then having multiple title elements as children of the animate/animateMotion or whatever
DS: Basically mimics a screen
reader in some ways
... Tie something to a role or class
... Having the child text content of this element can be used
the label for the navigation ring or something
CM: Instead of the title ement?
DS: Yes
... It doesn't define what the behaviour would be, you can
either navigate to it or navigate to other elements
... in the case of SVG animation you might want to define a set
of behaviours
... stop, start
CM: With the animation element, but with other elements perhaps other things
DS: I'd like to do things declaratively. I'd like to describe what those keys map to and then describe them in the body of the element
CM: Let's wait for ED to find the email reply and forward it to the thread
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/It would be CL if he was here to discuss it further/It would be good if CL was here to discuss it further/ Succeeded: s/public-svg/public-svg-wg/ Succeeded: s/Group will evolve how it wants to evolve/conversations will happen wherever it seems more natural, even though charter historically says we'll work on WG list/ Succeeded: s/Domenic/Dominic/ Succeeded: s/with him/with him, at least for the reduced version/ Succeeded: s/not so good/pretty crappy/ Found Scribe: anthony Inferring ScribeNick: anthony Default Present: Shepazu, anthony, heycam, jwatt Present: Shepazu anthony heycam jwatt Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0232.html Found Date: 22 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/22-svg-minutes.html People with action items: cameron[End of scribe.perl diagnostic output]