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

Minutes, SVG F2F Day 4 Thursday 22 May 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Fri, 23 May 2008 08:10:45 +1000
Message-ID: <4835EF65.60102@cisra.canon.com.au>
To: W3C SVG Public Working Group <public-svg-wg@w3.org>




       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

22 May 2008

    See also: [2]IRC log

       [2] http://www.w3.org/2008/05/22-svg-irc



           erik, anthony


      * [3]Topics
          1. [4]1.2 testsuite cont.
          2. [5]Progress Events
          3. [6]Interest Group
          4. [7]SVG in HTML
          5. [8]XHTML role
      * [9]Summary of Action Items

    <trackbot-ng> Date: 22 May 2008

    <ed> scribe: erik

    <ed> scribeNick: ed

1.2 testsuite cont.



    (WG) approved

    AE: need to generate a reference image





    struct-use-205-t is tentatively approved, opera generates the
    correct result, will be used for the reference image

    we will revisit the issue of how reference images are generated

    scribe: since the revision changes we have to generate a new
    reference image after actually approving the test

    AE: need to change the description on udom-svg-228



    ED: has no pass criteria in description



    ED: should only check the lower bound of the getCurrentTime
    ... since the resolution of the documettime isn't defined in spec

    (WG) ok, approved after those changes



    (WG) approved



    AE: using e.name, e.message

    vg/TraitAccess.common.es is also using e.name and e.message


    AG: the test is using id instead of xml:id

    (WG) approved

    <ChrisL> hi cam

    <heycam> hi ChrisL

    <ChrisL> we are doing test approvals

    <heycam> cool, i saw yesterday's irc log



    (WG) approved



    ED: the pass criteria are missing

    (WG) approved



    <heycam> itaccess-*

    AE: e.name, e.message

    (WG) approved



    ED: add note about security exceptions (local -> external domain)
    and running the servlet locally
    ... why is this script using addEventListener("load", onload...? if
    it reaches this point it's already run all the code in the script

    AE: ok, changed

    (WG) approved

    ED: there was a test like this one yesterday, should be fixed in the
    same manner



    CL: some strange wording in the description

    (WG) approved

    ED: opera passes this, should be used for reference



    (WG) approve



    CL: should mark output in green and red

    <scribe> ACTION: AE to update udom-svgpath-202-t.svg to color the
    output text in red and green depending on status [recorded in

    <trackbot-ng> Created ACTION-2029 - Update udom-svgpath-202-t.svg to
    color the output text in red and green depending on status [on
    Andrew Emmons - due 2008-05-29].



    ED: it's assuming getTrait("fill") doesn't normalize the color
    value, but that's not guaranteed
    ... would like this test to get some more review

    <scribe> ACTION: ED to review
    vg/udom-svg-230-t.svg and fix the color normalization mismatches in
    the test [recorded in


    <trackbot-ng> Created ACTION-2030 - Review
    vg/udom-svg-230-t.svg and fix the color normalization mismatches in
    the test [on Erik DahlstrŲm - due 2008-05-29].




    AG: id instead of xml:id

    CL: needs change in operatorscript

    ED: text isn't colored



    (WG) tentatively approved, pending reference image from opera



    (WG) approved



    (WG) approved



    CL: not wellformed



    (WG) approved



    ED: the spec needs to be clarified on how many parameters each path
    command has, and how close is normalized

    (WG) approved, but the spec needs to be updated



    ED: so this is assuming QUAD_TO isn't normalized to CURVE_TO, but
    the spec says you must do that

    <ChrisL> 452 of 574 tests are now approved

    (WG) revoke approval of udom-svgpath-201

    (WG) revoke approval of udom-svgpath-202



    (WG) approved

    <ChrisL> [39]http://en.wikipedia.org/wiki/Invertible_matrix

      [39] http://en.wikipedia.org/wiki/Invertible_matrix

    CL: SVG_MATRIX_NOT_INVERTABLE is what it says in spec, but it's
    really a typo
    ... can't change it now, since the constant is used in 1.1 as well,
    but we should make a note of it

    <ChrisL> after a cvs update .... 464 of 574 tests are approved

    <shepazu> scribeNick: shepazu

    <scribe> chair: Erik

Progress Events

    <ChrisL> [40]http://www.w3.org/TR/2007/WD-progress-events-20071023

      [40] http://www.w3.org/TR/2007/WD-progress-events-20071023


      [41] http://www.w3.org/TR/2008/WD-progress-events-20080521/


      [42] http://www.w3.org/TR/2008/WD-progress-events-20080521/#Change

    aemmons: progressEvents is referenced by JSR-287
    ... but not in the SVG namespace

    ed: one difference it that it doesn't bubble in the WebAPI spec

    shepazu: do we need that?
    ... I can think of a use case... if you have a group with a lot of
    resources, you might want to put the listener on that group and see
    which resources resolve...
    ... we can bring that up to WebAPI

    ed: maybe we could remove this from SVG 1.2 Tiny

    aemmons: I'd be concerned about other specs that reference us...
    they rely on this
    ... if the ProgressEvents spec become stable we could make a later
    revision of SVG that normatively references it

    first version is here

      [43] http://www.w3.org/TR/2007/WD-progress-events-20070419/



    ChrisL: there are some incompatibilities, especially regarding event

    ed: I'm not sure there are serious incompatibilities... as long as
    the interface remains the same, we can map our names to theirs

    aemmons: it looks like ProgressEvents is a superset of our
    interface, modulo the event names, which is good

    Resolution: SVG 1.2 Tiny will keep its progress events, but we will
    monitor the ProgressEvents spec and encourage compatibility, with
    the intent to normatively reference it in a later SVG spec

    aemmons: so we need test for our progress events

    <ChrisL> scribenick: zlatinski

Interest Group

    ED: Interest group is the starting topic

    <shepazu> DS: SVG IG started from 2 sources

    <shepazu> 1) long-standing desire to get more designers involved in
    SVG WG

    <shepazu> (note: the CSS WG tried this, not very successfully... it
    backfired when the designers were assumed to be comfortable with the
    spec-producing process, and got frustrated... it came out as
    negative PR in their blogs)

    <shepazu> 2) a conversation with MikeSmith about getting Japanese
    members more involved by allowing them to communicate in their
    native language and cultural environment

    <ChrisL> SVG IG home [45]http://www.w3.org/Graphics/SVG/IG/

      [45] http://www.w3.org/Graphics/SVG/IG/

    <ChrisL> charter

      [46] http://www.w3.org/2007/11/SVG_rechartering/SVG-IG-charter.html

    <ChrisL> participants

      [47] http://www.w3.org/2000/09/dbwg/details?group=42368

    <ChrisL> patent policy status

      [48] http://www.w3.org/2004/01/pp-impl/42368/status

    DS: the current Micron thinking is to use the current community of
    helping with testing, or similar or leverage the community to get
    better results.

    CL: I've sent some links on that topic

    <ChrisL> We need to figure out a chair, then get wider involvement

    AE: We need to brainstormed

    ED: Some people are frustrated of the apparent lack of progress on
    SVG 1.2 full

    <ChrisL> I promoted the SVG IG at LGM3 (my slides:
    [49]http://www.w3.org/Talks/2008/LGM3/cover.svg )

      [49] http://www.w3.org/Talks/2008/LGM3/cover.svg

    AE: Can somebody write a white paper of the relationship of the
    different SVG standards?

    DS: We need to assign somebody to do that, otherwise it would not

    AE: Something like SVG tiny and SVG full is superset of it and also
    different modules

    <ChrisL> Good to talk with some designers who are using SVG now, get
    them to interview us to get the speaking points, then design a flyer
    that makes that communication

    <anthony> scribe: anthony

    ED: Should we assign someone to reach out

    AE: We need to get designers who use Inkscape and authoring tools to
    join the IG

    DS: Yes we also need to get people who are designers that aren't
    using SVG
    ... we need their input to find out what would make it more
    persuasive to use

    AE: We need to get at the SVG experts who are currently making SVG
    services on the IG as well

    DS: We need to make SVG such that they don't care its SVG until they
    start associating it with cool graphical features
    ... Some people are using SVG for its openess

    <ChrisL> in particular for interchange between authoring tools

    TZ: You could make it more known graphical designers for example if
    they knew that browsers displayed
    ... as soon as they start caring that whatever they do doesn't work
    on their platform they will start finding tools that do

    DS: Maybe we can sell the idea that you can get the source of the
    SVG and change it to make it how they like and repost

    <ChrisL> [50]http://www.codedread.com/ adds the renesis plugin to
    the support matrix

      [50] http://www.codedread.com/

    <ChrisL> [51]http://www.codedread.com/svg-support.php

      [51] http://www.codedread.com/svg-support.php

    <scribe> ACTION: Doug to approach potential chairs and activity
    leaders for the SVG IG [recorded in

    <trackbot-ng> Created ACTION-2031 - Approach potential chairs and
    activity leaders for the SVG IG [on Doug Schepers - due 2008-05-29].

    <scribe> ACTION: DS to find a leader for the Japanese chapter of the
    SVG IG [recorded in

    <trackbot-ng> Created ACTION-2032 - Find a leader for the Japanese
    chapter of the SVG IG [on Doug Schepers - due 2008-05-29].

    <shepazu> patent policy says "This group does not produce
    deliverables that are covered by the W3C Patent Policy and therefore
    have no licensing obligations related to the deliverables they
    produce. "

    <ChrisL> From the IG charter: "The SVG Interest Group provides an
    opportunity to share perspectives on the topic addressed by this
    charter. W3C reminds Interest Group participants of their obligation
    to comply with patent disclosure obligations as set out in Section 6
    of the W3C Patent Policy. While the Interest Group does not produce
    Recommendation-track documents, when Interest Group participants
    review Recommendation-track specifications from Working Groups, the

    <ChrisL> Thus, contributions to the IG would need an RF license from
    the authors same as for a submission)

    <ChrisL> above truncated quote from

      [54] http://www.w3.org/2007/11/SVG_rechartering/SVG-IG-charter.html

    DS: We need to make all the patent stuff obvious on the IG Wiki and
    front page

    <ChrisL> [55]http://www.w3.org/Graphics/SVG/IG/

      [55] http://www.w3.org/Graphics/SVG/IG/

    CL: If they are employed by a member company, they are nominated by
    their AC rep
    ... if they are not part of a member company then we go through
    invited expert root

    DS: We need to have some easy we to have someone join the interest

    <scribe> ACTION: Doug to Update the SVG IG page with instructions on
    how to join [recorded in

    <trackbot-ng> Created ACTION-2033 - Update the SVG IG page with
    instructions on how to join [on Doug Schepers - due 2008-05-29].

    <ChrisL> invited expert approval

      [57] http://www.w3.org/2004/08/invexp.html

    <ed> [58]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html

      [58] http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html


    DS: I wondered why in my absence this page was edited

    AE: So we had discussed finalised requirements before coming to the
    ... those changes I did were from the telcons we had
    ... it's not set in stone

    DS: I disagree with removing where the requirements were coming from
    ... some of these requirements conflict

    AE: I don't agree with that

    CL: So the previous page had details of where things where coming
    ... it's useful information to retrain

    ED: So you can go back in the history and readd it

    CL: Get the previous revision and paste it up the top

    AE: Our intention was to have unified requirements that didn't

    CL: Maceij makes a point in his email that the SVG in XHTML already
    ... I think this should be style that is encouraged for SVG in HTML
    otherwise authors will get confused.
    ... XHTML should be the format encouraged to use
    ... because it's known to work today - proven deployment format for

    AE: Doug what is your preference to approach the problem?
    ... do we want to hand it off to an XML parser or do we want to
    define a parsing model that works in HTML

    DS: Neither the extension element or bare root element doesn't
    require one of those. That problem is different to the parsing
    ... So I'm not an implementor but the implements have been
    represented as saying they do not want to switch parsers in the
    middle of parsing
    ... not sure how legitimate that is, I've heard reports from
    different people

    ED: I guess that was Opera's statement
    ... the developer I spoke to at Opera was more in favor of using an
    XML parser
    ... because it's already implemented
    ... saves time and energy in testing

    AE: I 100% agree
    ... sending the XML portion to the XML parser is the natural thing
    to do

    <aemmons> AE: The argument that it breaks streaming parsers is
    invalid, we've been able to stream and send to other parsers fine.

    DS: [presents example]
    ... What do you do?
    ... at what point do you chunk it out and send it to another parser?
    ... after parsing the ext element
    ... ?
    ... where does it end?/

    AE: So do we need a little bit of information about their parser
    ... but I don't know how the parsing model works I've never looked
    at it

    ED: you can define parsing modes for particular element names
    ... and that's what they proposed
    ... they added a special parsing state for SVG and MathML
    ... and flags for switching between the states

    AE: One simplistic way of doing it is parsing it the way of the HTML
    model and then you send it to the XML

    DS: No wait that's not the end of the ext element
    ... so this is my point
    ... when we have content that is not well formed their argument is
    the strongest
    ... when content is well formed SVG doesn't have a problem

    [Brain storming about the problem]

    AE: Even though the HTML parser is going to parse the SVG it's going
    to parse unquoted attributes etc and that's what we don't want

    TZ: Mozilla uses a 3 phase approach for parsing
    ... so when they see something that is HTML they use HTML parser and
    when there i something they don't recognise they switch to XHTML

    ED: That's something similar I was discussing with people in Opera

    TZ: Mozilla uses expat with a patch to parse HTML
    ... the 2nd phase is creating the nodes
    ... the 3rd phase is doing the reflow
    ... they push chunks to the reflow
    ... then after the reflow they start drawing
    ... if the parser doesn't recognise that unformed element we get an
    element error
    ... if we don't recognise the namespace you keep it in the DOM
    ... but just don't know how to handle it

    DS: So it puts it in the DOM but don't do anything with it
    ... would it kickback to HTML?

    TZ: this content provider will tell you what nodes you allow
    ... or don't allow
    ... as soon as you encounter an SVG element you start using
    something like an XML parser
    ... so you keep parsing until you encounter something that you don't
    ... so you go back to the invoker and say you are at an element
    condition what to do. The content provider may say
    ... if I break here the everything breaks, so you may want to find
    the last closing string

    DS: So saying parsing something off to the XML parser is not helpful
    we'll just get mocked

    TZ: So there is a draw back, the host language needs to pass down
    information to tell you where to render at. In SVG you know the

    ED: In XTML itís the same. You can use CSS to define the width and
    the height
    ... You can also use the containing element thing using a div,
    choose different block nodes
    ... So thatís the box model thatís used.

    TZ: Need some guidelines

    ED: So HTML 5 would have to write something about the problem
    ... I don't see how it's different from XHTML

    DS: This area we can all explore with out much pain
    ... we that problem is the parsing model
    ... we all agree that the negotiation needs be defined
    ... the first problem is defining the parsing model

    <scribe> ACTION: latinski to Draft a proposal for the 3 phase parse
    model and the SACs based parse model [recorded in

    <trackbot-ng> Sorry, couldn't find user - latinski

    <scribe> ACTION: antanas to Draft a proposal for the 3 phase parse
    model and the SACs based parse model [recorded in

    <trackbot-ng> Sorry, couldn't find user - antanas

    <scribe> ACTION: atanas to Draft a proposal for the 3 phase parse
    model and the SACs based parse model [recorded in

    <trackbot-ng> Created ACTION-2034 - Draft a proposal for the 3 phase
    parse model and the SACs based parse model [on Atanas (Tony)
    Zlatinski - due 2008-05-29].

    DS: We need to draw up some error cases we need to handle

    ED: So this example on the right so encountering the unknown element
    in the middle
    ... what happens?
    ... does it switch back?

    TZ: As soon as you switch back to the content provider the content
    provider takes over
    ... until it reaches a known token

    <scribe> ACTION: Doug to draw up error case examples of SVG and HTML
    [recorded in

    <trackbot-ng> Created ACTION-2035 - Draw up error case examples of
    SVG and HTML [on Doug Schepers - due 2008-05-29].

    <shepazu> [63]http://www.w3.org/Graphics/SVG/WG/wiki/Ext_element

      [63] http://www.w3.org/Graphics/SVG/WG/wiki/Ext_element

    <shepazu> this is my <ext> proposal



XHTML role



    AE: So these are comments they sent back to us?

    ED: So they are asking if this resolves our comments
    ... and I'm not sure it has
    ... so for example they are saying they don't have a RelaxNG schema
    ... and they are kind of writing that they will do it eventually

    AE: So you asked them for the second point there to add some
    ... to help align prose in SVG

    CL: What I suggest is we prepare response that has a RelaxNG
    ... and tell them that it doesn't require as much infrastructure as
    DTDs etc

    <ed> [66]http://www.w3.org/1999/xhtml/vocab/

      [66] http://www.w3.org/1999/xhtml/vocab/

    CL: What's this XHML vocab document?
    ... once we define some we should ask them how to get them in the

    <ChrisL> ok thanks for the link

    <ChrisL> it says its for all vocabularies that use xhtml mod (like
    SVG 1.1 for example)

    ED: So according to this if we have to specify the roles ourself
    they would have to be prefixed with a qualifier
    ... Judging by that it would be favorable to have them in this
    document [link above]
    ... I guess we are still not clear which roles we want to have

    CL: That would be another thing we could hand off to an IG
    ... we could define a bunch of roles to do with maps for example
    ... and same for charts
    ... they are the two big things

    DS: Diagrams

    CL: By charts I mean graphs

    DS: Subway maps, flow charts, that class of thing

    CL: We can share some in common
    ... have a call out box saying that this means that

    DS: A legend would be common to a map and a chart

    <scribe> ACTION: Chris to Try to write the RNG for XHTML role module
    and respond to the email [recorded in

    <trackbot-ng> Created ACTION-2036 - Try to write the RNG for XHTML
    role module and respond to the email [on Chris Lilley - due

    DS: How would you guys would prefer to add role to SVG
    ... as an attribute

    AE: Would that add a dependency to 1.2/

    DS: It says that we can reference it in our name space

    CL: That's probably the best way forward

    DS: I agree with you that we should put it in our own module
    ... because along with it we define a list of roles to do
    ... and how they work
    ... and incorporate the aria stuff

    CL: There are various ways to combine that
    ... so the reason we want it there is so it's unprefixed

    DS: We wouldn't have to prefix it because it's part of our language

    AE: Kind of makes sense to define our own module with our roles

    Resolution: We will make a module that incorporates the role
    attribute and work with Wai Aria as well as other domain experts to
    define a set of roles in our module

    <shepazu> [68]http://www.w3.org/2004/01/pp-impl/42368/instructions

      [68] http://www.w3.org/2004/01/pp-impl/42368/instructions

Summary of Action Items

    [NEW] ACTION: AE to update udom-svgpath-202-t.svg to color the
    output text in red and green depending on status [recorded in
    [NEW] ACTION: antanas to Draft a proposal for the 3 phase parse
    model and the SACs based parse model [recorded in
    [NEW] ACTION: atanas to Draft a proposal for the 3 phase parse model
    and the SACs based parse model [recorded in
    [NEW] ACTION: Chris to Try to write the RNG for XHTML role module
    and respond to the email [recorded in
    [NEW] ACTION: Doug to approach potential chairs and activity leaders
    for the SVG IG [recorded in
    [NEW] ACTION: Doug to draw up error case examples of SVG and HTML
    [recorded in
    [NEW] ACTION: Doug to Update the SVG IG page with instructions on
    how to join [recorded in
    [NEW] ACTION: DS to find a leader for the Japanese chapter of the
    SVG IG [recorded in
    [NEW] ACTION: ED to review
    vg/udom-svg-230-t.svg and fix the color normalization mismatches in
    the test [recorded in
    [NEW] ACTION: latinski to Draft a proposal for the 3 phase parse
    model and the SACs based parse model [recorded in


    [End of minutes]

     Minutes formatted by David Booth's [80]scribe.perl version 1.133
     ([81]CVS log)
     $Date: 2008/05/22 16:32:59 $

      [80] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [81] 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 [82]http://dev.w3.org/cvsweb/~checkout~/2002

      [82] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/it was/the constant is used/
Succeeded: s/DS>/DS:/
Succeeded: s/kEED>/ED:/
Succeeded: s/of not working on SVG full/of the apparent lack of progres
s on SVG 1.2 full/
Succeeded: s/CL:/DS:/
Succeeded: s/CL: /DS: /
Succeeded: s/IF Wiki/IG Wiki/
Succeeded: s/define a parsing/define a parsing model that works in HTML
Succeeded: s/persers/parsers/
Succeeded: s/parers/parsers/
Succeeded: s/pros/prose/
Found Scribe: erik
Found ScribeNick: ed
Found ScribeNick: shepazu
Found ScribeNick: zlatinski
Found Scribe: anthony
Inferring ScribeNick: anthony
Scribes: erik, anthony
ScribeNicks: ed, shepazu, zlatinski, anthony

WARNING: No "Present: ... " found!
Possibly Present: AE AG CL ChrisL DS MikeSmith TZ aemmons anthony ed he
ycam joined left scribenick shepazu svg trackbot-ng zlatinski
You can indicate people for the Present list like this:
         <dbooth> Present: dbooth jonathan mary
         <dbooth> Present+ amy

Found Date: 22 May 2008
Guessing minutes URL: [83]http://www.w3.org/2008/05/22-svg-minutes.html
People with action items: ae antanas atanas chris doug ds ed latinski

      [83] http://www.w3.org/2008/05/22-svg-minutes.html

    End of [84]scribe.perl diagnostic output]

      [84] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 22 May 2008 22:11:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:38 UTC