SVG Working Group Teleconference -- 14 Oct 2009

<trackbot> Date: 14 October 2009

<scribe> Scribe: anthony

<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2009OctDec/0005.html

SVG 1.1 second edition + assigning heycams actions

<ed> http://www.w3.org/mid/20091009033646.GC24133@wok.mcc.id.au

CM: Put in the email
... all the things that I could think of
... that I had that were important
... went through open actions in tracker
... a few need to be done
... but some are not critical
... the ones that appear in the email
... should be done soon
... as well as in the email I listed the things that need to be done for 2nd edition

CL: How long are you taking?

CM: A few months

CL: Just wanted to know how long you were talking about

CM: For those ones where it's write a test
... they can wait

ED: If there are any time critical
... we should reassign them

CM: Ok lets go through 1 by 1
... ACTION-2514 is not that important
... bunch of old issues in the old tracker
... that hadn't been discussed
... started to go through them
... and raised issues at one point
... but most haven't been done

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Old_Issues

CM: I made a wiki page to keep a track of which ones haven't been dealt with
... see link above
... we've survived without having resolved these so far
... so when we go to do 2.0
... we look up these
... and take that into account at the time
... I don't think it needs to be reassigned
... ACTION-3291
... this is the action to look into list syntax
... so in the end I didn't get time to solve this one
... for the general case for 2nd edition
... I solved it for specific case of stroke-dasharry
... another one that can be worked on in SVG 2.0
... ACTION-2503

<ChrisL> ACTION-2503?

CM: this was an action to add the notes about which things we didn't have consensus on
... regarding SVG in HTML
... but there is a newer action

<ChrisL> close ACTION-2503

CM: which is newer than this one

ACTION-2537?

<heycam> http://www.w3.org/Graphics/SVG/WG/track/actions/2537

<ChrisL> trackbot seems to be on the blink

<trackbot> ACTION-2503 -- Cameron McCormack to add ednotes to the svg-in-html spec noting points where agreement is still lacking -- due 2009-03-30 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2503

CM: Related to a thread a while ago on parsing script and style elements in HTML
... this action was to reply on that thread
... get current status and revise it
... but Jonas said he was going to send a proposal on changing the way HTML currently says to parse these elements
... so we should wait for the proposal
... and reply to that
... he was going to propose making those elements like CDATA elements
... but have some special step that removes pre-processing markers
... currently not what HTML says to do
... that action can be closed

ACTION-2642

<heycam> http://www.w3.org/Graphics/SVG/WG/track/actions/2642

<heycam> http://www.w3.org/Graphics/SVG/WG/track/actions/2643

<trackbot> ACTION-2503 Add ednotes to the svg-in-html spec noting points where agreement is still lacking closed

CM: This one and the next one are reminders to myself
... to do edits in the spec
... when it's ready for publication of the REC
... the first one says when it's ready for a REC, someone will have to create a blank errata page
... and link to it
... given that's only something team people can only do
... maybe Doug could have this action

DS: Makes sense

CM: ACTION-2643 was to make a single page version for both HTML and PDF
... the HTML one is automatically generated
... The PDF might need a bit of work
... change the styles around
... to make it look nice

AG: Could just print to a PDF generator

<trackbot> ACTION-2537 -- Cameron McCormack to reply to the style/script thread -- due 2009-05-06 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2537

CM: Probably not that critical
... if you do a print to PDF it shouldn't be too hard
... this one could be reassigned to someone then

AG: I can probably take the action

CM: Still doesn't need to be done until we got the final REC version
... there's just some place in the index to HTML that links to the PDF version

ACTION-2644?

<heycam> http://www.w3.org/Graphics/SVG/WG/track/actions/2644

CM: Was thinking Chris might be good to do this one
... this is to make sure the DTD on w3.org is updated
... when the spec is published

ACTION-2675

<heycam> http://www.w3.org/Graphics/SVG/WG/track/actions/2675

CM: This is the one to send to the HTML WG
... And this is to send the email about what we decided at the F2F
... to the HTML WG
... and in the action there is a link to the day 3 minutes
... with all the points that we were working through

ED: I can probably take that action
... I will probably summarise that and get comments
... before sending that out

<ed> http://www.w3.org/2009/09/28-svg-minutes.html#item01

CL: I don't see an action for this

<trackbot> ACTION-2644 -- Chris Lilley to update the 1.1 DTD under /Graphics/SVG when publishing 1.1SE -- due 2009-08-12 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2644

CL: but you had that spread sheet with the test results for 1.1
... we should put in an action to say where it is

CM: I will remind myself to find that email it to the list
... is there some action you want to come out of that?

CL: Makes it easier to track

<scribe> ACTION: Chris to Take over spreadsheet implementation report for the errata tests [recorded in http://www.w3.org/2009/10/14-svg-minutes.html#action01]

ACTION-2680

<ChrisL> ACTION-2682

<ChrisL> Take over spreadsheet implementation report for the 1.1 SE errata tests

<heycam> http://www.w3.org/Graphics/SVG/WG/track/actions/2680

CM: At the f2f we were discussing the issue in the HTML WG about foreign name space data being in SVG files
... and when that is pasted into document
... it causes the SVG part to be invalid
... due to issues with the ":"

<trackbot> Created ACTION-2683 - Take over spreadsheet implementation report for the errata tests [on Chris Lilley - due 2009-10-21].

CM: we were playing on the board with mapping prefixes to fixed name spaces
... and actually I noticed that MS sent their own proposal
... to the HTML WG
... which was very similar
... parts of it were
... some of the options you could choose was close to full blown name spaces
... and restricted version that was fixed prefixes
... I think that proposal will result in a lot of discussion at TPAC
... it will not really add anything if we sent in this proposal

<ChrisL> also at the AC meeting

CL: Well it shows support\

ED: Just looking through the minutes
... there is some discussion
... I could make it as part of the other action I have

CM: Do you remember what the actual proposal was?

ED: It's not clear from the minutes

CL: One thing we could say
... is we discussed these things
... and you could do this or that
... and comment on the MS proposal
... if it meets our requirements
... we should push for it

<ChrisL> basically if the MS proposal meets our needs we should say so

CM: What we were discussing in the F2F was getting the parser to get a set of predefined prefix mapping
... the parser will know about certain prefixes
... and would be able to split the colon
... put the element in the correct name space

DS: Our proposal was simpler than MS
... and met more of the HTML needs

CL: we could position ourselves in the middle ground

DS: We could also point to the minutes
... to say we decided this before the MS proposal

CM: The other point about our proposal if the implementation didn't know about the prefix
... it would put it in an "unknown" name space URI

DS: It would be a specific name space
... to say I don't know the name space

CL: Better idea than putting it into the HTML name space

DS: In some ways it would be easier to debug
... because they'd see it be in the 'what ever' name space
... it would be an easy way to check
... and that goes towards extensibility

CM: One thing that our proposal didn't handle
... is it doesn't do anything about non-prefixed elements
... un-prefixed elements would go into the HTML name space
... and the type of output you get from Inkscape
... tends to be all prefixed anyway

ED: I think so

CM: Maybe it would be a good idea
... to go through the MS proposal
... and compare it to this one
... so ED you can do this as well?

ED: What's the time frame?

DS: I'd say before TPAC

CM: By the end of the month would be good
... not sure if they're going to stick to their schedule
... I did say I'd give comments soon after our F2F

ED: Assign the action to me anyway

CM: That's all the actions I listed
... in my email
... the other actions that are open on me are not as important

<shepazu> html wg process: http://dev.w3.org/html5/decision-policy/decision-policy.html

ED: You listed a few things regarding the 2nd edition spec

CM: I listed all the things we need to get done for 2nd edition
... some of those are related to the actions
... some them are other things

ED: For the one I didn't know anything about the Java bindings
... do we need to have them
... to publish the spec
... or is that nice to have thing?

CL: What would they use? seems odd to publish
... then say use the old ones

<ChrisL> seems odd to make people look at 1.1FE for the Java bindings

CL: problem is we don't have a method to convert IDL to Java
... and that's a non trivial problem?

CM: Don't have a method
... might be non trivial

CL: Did someone have a compiler?

CM: I thought someone did

<ChrisL> http://www.omg.org/technology/documents/formal/omg_idl_to_java_language_mapping.htm

CM: is that part of the XML spec? I don't know

CL: That's the spec
... it's not a tool

<ChrisL> http://java.sun.com/j2se/1.4.2/docs/guide/idl/mapping/jidlMapping.html

CL: However that's the tool
... As to whether it would resemble anything that's similar to the old one I don't know

ED: Someone should take an action to investigate how to do this
... or if it was a tool
... that we used to use

CM: From the description of the table the types are mapping as I'd expect them too
... the main problem is making sure the output gets put in the right package
... that sort of thing can be manually fixed up
... if that doesn't work
... if the output of the IDLJ doesn't look appropriate then we should ask Jon how he did it

DS: You will not be joining the next telcon correct?

CM: Yes

<heycam> http://www.w3.org/TR/WD-SVGReq

DS: Cameron thank you for all the help, you've been one of the main drivers of the standard
... and we'll see you when you get back

CL: Doug what's the latest status on the one you had publication denied for?

DS: It was all Anthony

AG: It was all me
... it's all fixed now

DS: I had had an embed element for there for completeness sake
... but I was told to take it out because it wasn't valid
... what do you guys think about this?

CL: Why does it have an embed in there?

DS: It's like a test sort of
... having an example in the spec that shows them how to do it
... is a good help for implementing

CL: It's more important to get it published
... you could make HTML and not XHTML
... that would be another option
... I think this can only be done for non-Rec specs

DS: Don't think that is possible
... HTML 5 couldn't be published as HTML 5
... ok you'll have do the other option

s/... ok you'll have to do the other option/CL: you'll have to do the other option/

Publication

ED: Filters spec we resolved to published
... the only one I've touched is the language one
... which include all the IDLs
... which has a lot of good fixes

<ed> http://dev.w3.org/SVG/modules/filters/publish/SVGFilter.html

ED: The only thing left to do
... is get the date link fixed
... and that's it
... wasn't sure what to put there
... because I wasn't sure date it would go out

DS: Do we have everything else that we need?

ED: All the links in the spec have been fixed as far as I know
... haven't check it for pub rules

RESOLUTION: We will publish the Filters specification

Using SVG Color in XSL

CL: Anthony you replied to my email but thought I was proposing something for SVG
... but I was proposing something for XSL

AG: Yes, I got that from your reply

CL: The proposal for device-n channel has two functions
... one with an RGB fall back
... and another with a CMYK fallback
... the CMYK fallback is not in any known name space
... so it doesn't make sense
... nesting color spaces is one way to get around that
... and I plan to propose that
... At SVG Open I did a quick lighting talk on Vector Effects
... I think there was some interest

DS: I think there was definitely interest
... the map people are particularly interested
... I look forward to seeing vector effects published but knowing it doesn't solve the problem of variable stroke width
... I know how to move forward on that
... I was thinking it would be a separate element
... I got that far

CL: It should be something like gradients

DS: Should be something more like a pattern essentially

Issue tracking for comments

ED: Is anyone assigned to this?

CL: The issue is knowing if someone has taken it
... if someone sends a quick email saying I've spotted this and raised it
... or I've spotted this but it's not a problem

DS: This would be good if it were easy to import stuff into tracker
... rather than manually copying stuff
... if we do this to tracker it will be more useful in the long term
... now that I have a bit of breathing room I will give it another try

Test Suite generation update

AG: Can generate manifest, and ref images
... harness script needs to have a few minor bugs fixed
... batik needs to be rechecked in as binary

- DRAFT -

SVG Working Group Teleconference

14 Oct 2009

Attendees

Contents

SVG 1.1 second edition + assigning heycams actions

Publication

Using SVG Color in XSL

Issue tracking for comments

Test Suite generation update

Summary of Action Items

Scribe.perl diagnostic output