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

Minutes, SVG telcon Tuesday 10 June 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Wed, 11 Jun 2008 00:08:42 +1000
Message-ID: <484E8AEA.8040601@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

10 Jun 2008



    See also: [3]IRC log

       [3] http://www.w3.org/2008/06/10-svg-irc


           aemmons, ed, anthony, Shepazu, zlatinski

           Andrew Emmons



      * [4]Topics
          1. [5]publication of SVGT 1.2 testsuite
          2. [6]status update for moving specs to public CVS
          3. [7]XHR review
          4. [8]HTML + SVG discussion
      * [9]Summary of Action Items

    <trackbot> Date: 10 June 2008

    <scribe> Scribe: anthony



publication of SVGT 1.2 testsuite

    AE: Erik sent an email to the public list
    ... with sort of a review
    ... do we feel comfortable releasing the test as is?

    DS: Don't see what the problem is
    ... we can always add to the test suite

    ED: Miss matching reference images are a small problem
    ... The incorrect reference images are a bigger problem

    AE: Regarding the existing of tests that haven't been approved
    ... and have the draft water mark
    ... I think Chris was after feedback
    ... I don't mind either way

    ED: Some tests looked more complete than others
    ... in my opinion I think we should fix the ones with serious errors
    ... such as mismatching reference images

    AE: So what does everyone else think?
    ... there are people that may be waiting for the test suite
    ... e.g. OMA



    ED: I guess another option is to publish my mail along with the test

    AE: A list of known issues
    ... that might be a good compromise

    AG: I'm fine with that

    AE: So if we go ahead with this
    ... when can we publish it?
    ... my impression is that this is something Doug or Chris have to do

    DS: I can probably publish it this week

    RESOLUTION: We will proceed to with publication of the test suite
    package currently in CVS and we will package known issues along with

    <scribe> ACTION: Erik to Update list of known issues and add draft
    water marking back to tests that are still in their infancy
    [recorded in

    <trackbot> Created ACTION-2057 - Update list of known issues and add
    draft water marking back to tests that are still in their infancy
    [on Erik Dahlström - due 2008-06-17].

    ED: Should I put the list of known issues on the wiki

    AE: Sure

status update for moving specs to public CVS

    DS: Is that me?

    AE: I seem to remember Chris saying he could do that task

    DS: He's been a bit sick lately and hasn't been able to get to it
    ... I'd like to get to doing it this week if I can
    ... have a lot to do at the moment
    ... It shouldn't be too hard to transition it to it's new home
    ... just need a block of time to do it

    AE: We have to coordinate on the list when we are going to do it
    ... so changes don't get lost

    <ed> [13]http://www.w3.org/Graphics/SVG/WG/track/actions/2039

      [13] http://www.w3.org/Graphics/SVG/WG/track/actions/2039

    <scribe> ACTION: Doug to look into problem with new tracker having
    incorrect links to minutes and notes in issues [recorded in

    <trackbot> Created ACTION-2058 - Look into problem with new tracker
    having incorrect links to minutes and notes in issues [on Doug
    Schepers - due 2008-06-17].

XHR review

    DS: Both Erik and Cameron have sent in reviews
    ... I had already sent some comments earlier on my own
    ... I haven't had the time to do any more review
    ... I think Erik and Cameron have caught all of the big issues
    ... We should probably compile the two sets of comments together
    ... to send off

    AE: Sounds good
    ... the comments have already been put on the list for some time
    ... so if any one had any issues with it they could start a
    ... does everyone else agree with Doug's proposal?

    ED: Sounds good to me

    <scribe> ACTION: Erik to collate together Cameron's and your own
    comments for XHR and send them to the WebApps list [recorded in

    <trackbot> Created ACTION-2059 - Collate together Cameron's and your
    own comments for XHR and send them to the WebApps list [on Erik
    Dahlström - due 2008-06-17].

HTML + SVG discussion

    AE: So has everyone had a chance to read Tony's proposals?

    AG: I did

    ED: Yup

    AE: I did too

    DS: Yes

    AE: There a number of ways is to go through the document
    ... if you read it did you have comments for the list or are your
    saving them for the telcon?

    DS: Not sure on the best way to proceed

    AE: We could use Erik's email as a focus point for discussion

    ED: Is Power Point format file the way we want to present it?

    DS: Wrong format for the audience
    ... need to present it into spec format

    TZ: I was thinking of changing to HTML format after presenting it in
    Power Point
    ... what I could do is convert it to PDF

    DS: We need to rework it into HTML
    ... needs to be a single document
    ... instead of a bunch of pages
    ... I can help do that

    AE: So that make sense having it in HTML
    ... so we know it will be in a different format
    ... do we continue reviewing this?
    ... or do we transcribe this to HTML?

    DS: There is also Erik's spec text
    ... I guess we will be making a couple of different proposals

    AE: What is Erik's spec text?

    ED: I will send the spec text out

    AE: So let's just start with Erik's comments
    ... for the first comment
    ... - Slide "Interleaved Parsing of HTML - SVG"
    ... I guess it's just talking about the assertion of not being able
    to put HTML in SVG
    ... I agree with you there Erik
    ... So may it is just a matter for taking out the sentence

    TZ: Not only is there complication from the parser side
    ... I would also think about rendering side of things
    ... I'm a little bit concerned about embedding HTML
    ... lets say we have HTML table inside a group
    ... and you start rotating the group
    ... what would you do with the table inside the group?
    ... this is the concern I have
    ... would it be a more complicated rendering model
    ... does this make sense to embed HTML in SVG

    DS: Firstly there is a CSS transformations proposal by apple
    ... so I think they are very much interested way in bring in
    ... in a compatible way with SVG
    ... I don't think that from the rendering perspective that it is a
    ... I don't think that particular rendering is the problem
    ... there may be other problems

    ED: I suppose you could spec it like HTML would respect those
    ... I don't think it's a problem from the SVG point of view anyway

    DS: I think the rendering problems are orthogonal to the parsing
    ... I actually have pretty good faith to work with us and the CDF
    working group
    ... to define the kind of rendering that we think is compelling
    ... that we think users are going to want to do

    AE: So what I'm hearing is this sentence was to restrict the model
    ... we should probably put something to the effect that the HTML
    needs to be well formed when in the SVG

    TZ: One thing I didn't quite get did you want me to incorporate
    those comments into the document?
    ... or Doug did you want to incorporate it into HTML

    DS: However we want to do it is fine with me

    AE: We probably need to get the HTML one done sooner than later

    DS: If we can have somebody who wouldn't mind converting it to spec
    style HTML
    ... that would be good

    ED: I guess I could do that
    ... bit pressed on time

    DS: I have a feeling we are not acting in a timely manner

    <scribe> ACTION: Anthony to convert the Power Point slides for SVG
    in HTML to a HTML spec-ish kind of document [recorded in

    <trackbot> Created ACTION-2060 - Convert the Power Point slides for
    SVG in HTML to a HTML spec-ish kind of document [on Anthony Grasso -
    due 2008-06-17].

    AE: To answer Tony's question any changes we make will go directly
    into the HTML document
    ... so is this our secondary proposal?

    ED: So it's basically what we've started to discuss in the power

    AE: Should we start from this then?

    ED: I think the Power Point document is a pretty good high level
    view of it
    ... from the HTML side of things they are looking for something like
    ... based on the last draft that had SVG stuff in it

    AG: Where to I put this HTML proposal?

    DS: Could you just upload them into CVS?

    ED: In the public one you mean?

    DS: Yes

    AE: I guess one of my concerns is that these things stay in sync
    with HTML
    ... mean track the changes in our HTML proposal

    ED: Would be good to link to the last draft that had the svg stuff
    in it
    ... and maybe use bits from it

    AE: As far as the first point goes we will specify rules for
    embedding HTML in SVG
    ... mainly that it has to be well formed
    ... For the next point it seems faily straight forward
    ... that's just something on your end Anthony
    ... to change these things to lower case

    AG: Ok

    AE: So the next one is the cascading parser structure

    TZ: This was intended to be a high level diagram
    ... the reason why HTML parser is on the top because it is the
    primary one
    ... but maybe we need to restructure the diagram
    ... but I agree with you
    ... do we have any ideas how this should be structured?

    ED: Could group all the parsers together
    ... maybe make on block a primary initial parser
    ... it might make it more clear

    TZ: Do we want this tokeniser to be the primary parser?

    ED: I guess it's not wrong to put it inbetween
    ... but it may not be required for all parsers

    <ed> For document format XYZ: file input -> tokenizer -> parser
    (html, css, svg, xml, javascript)

    <ed> and inside the parser box show the connections between
    different parsers

    AE: So we are ok with putting the tokenizer step in between?

    TZ: I had a page explaining it
    ... but Erik you had a problem with putting it in

    ED: I had no problem with putting it in
    ... but I just wanted to point out that the the way the tokenizer is
    specced in HTML5 makes it too limited for proper use for XML

    AE: Tony are you ok to take another shot at the diagram

    <scribe> ACTION: zlatinski to Modify the cascading parser diagram
    [recorded in

    <trackbot> Created ACTION-2061 - Modify the cascading parser diagram
    [on Atanas (Tony) Zlatinski - due 2008-06-17].

    AE: The next comment there from Erik is the content provider

    TZ: I agree the comment from Erik that "content provider" is not
    quite clear\
    ... language handler or content handler sound good to me

    AE: Are there other terms used in the HTML 5 document that is
    familiar to them

    TZ: It's a particular plug to handle a particular language

    DS: I'd say content handler
    ... or sub-parser

    TZ: Content handler sounds good too

    AE: Sounds reasonable me too
    ... Anthony can you change content provider to content handler

    AG: Ok

    AE: The next one we've kind of discussed already

    TZ: Do you have any idea how to address this problem

    ED: You don't need a special tokenizer to handle each language
    ... if you read the HTML 5 spec
    ... the tokenzier throws away information about the casing
    ... You could put an additional sentence saying as long as the
    tokenizer has to keep enough information to do both HTML and XML
    parsing on the output

    AE: Makes sense to me
    ... can keep sentence about special consideration
    ... Tony does that sound fine?

    TZ: Yes

    AE: Next one is slide for element identification

    TZ: Maybe this part wasn't quite clear
    ... this is from the perspective of how you switch to a particular
    ... we have to kind of reshuffle things around to make it more clear

    ED: It still isn't clear enough to me what happens when it switches
    ... does it switch at the element you started parsing on
    ... or does it continue until it reaches something it can't handle
    ... that's my question

    AE: Tony is that something we should discuss more

    TZ: This is probably one of the major issues
    ... I could probably restructure this bit to make it more clear

    ED: Which element you're currently in my define what the element is
    ... in a HTML <a> tag
    ... or an SVG <a> tag

    TZ: From this perspective going back from the SVG to HTML

    ED: That's what we need to define
    ... when to stop
    ... when to switch back
    ... in my opinion is we find an SVG element we switch to XML parsing
    ... and when we find the closing svg element we switch to HTML

    AE: Erik when you say XML well formed HTML in SVG
    ... is that XHTML or HTML that is well formed to XML

    ED: As long as it's well formed

    AE: What about casing, upper and lower mixture

    ED: As long as the start and end tags match

    TZ: I haven't done any examples or discussed it in any detail
    ... I can look into this section into more detail
    ... I could put a bit more work into that and make it more clear

    AE: So this is the element identification section
    ... that's what you're talking about reworking those sections?

    <scribe> ACTION: zlantinski to Revisit the element identification
    slides based on our comments [recorded in

    <trackbot> Sorry, couldn't find user - zlantinski

    ED: I'm just noting if you want tag soup HTML and SVG interleaved in
    any way you like
    ... it would work in their proposal but would not be conformant XML
    on the source level

    AE: I noticed some parts are yellow, Anthony that's where you made

    AG: Yes

    AE: Continue with the Jave script content slide

    TZ: You don't see any cases where you'd like to have separate ECMA
    ... like have a separate ECMA script context

    <ed> <object data="some.svg"> will give you a separate script

    TZ: The document implied that the content handler would have a
    separate ECMA script handler
    ... you are saying that they should have the same context
    ... in the same DOM
    ... as soon as you get to a new content handler you make a new
    ... so practically you're saying the control is from the child
    content not from the parent content

    ED: Just from looking at how it works today, you get the same DOM
    ... I would expect it to be the same for HTML as it is in XHTML
    ... I think you should build the same DOM

    TZ: I should change the section to make it clear that they have to
    be the same one
    ... and that the parent passes this down to the child
    ... this being the context

    AE: Next one is CSS parsing

    TZ: If we always enforce using the same document then we should use
    the same CSS rules

    AE: Yes so it's the same as above
    ... do we need to discuss that section more or can we move on?

    TZ: With regards to SVG widgets section
    ... just clarifying your comment Erik

    AE: So you could have some CSS styling in the SVG but it will apply
    to any node in the document not just the SVG
    ... because it's a single context

    ED: I think the idea of having SVG widgets that provide alternative
    recognition for SVG
    ... sounds a bit like XSLT or XBL

    TZ: HTML doesn't have name spaces, so you put all the comment
    information inside the widget

    ED: Could do that today with an XSL style sheet

    TZ: So you're saying there is no point to talk about widgets at all?

    ED: That's my opinion

    TZ: Do you mind sending me an example
    ... of the concept

    ED: Sure

Summary of Action Items

    [NEW] ACTION: Anthony to convert the Power Point slides for SVG in
    HTML to a HTML spec-ish kind of document [recorded in
    [NEW] ACTION: Doug to look into problem with new tracker having
    incorrect links to minutes and notes in issues [recorded in
    [NEW] ACTION: Erik to collate together Cameron's and your own
    comments for XHR and send them to the WebApps list [recorded in
    [NEW] ACTION: Erik to Update list of known issues and add draft
    water marking back to tests that are still in their infancy
    [recorded in
    [NEW] ACTION: zlantinski to Revisit the element identification
    slides based on our comments [recorded in
    [NEW] ACTION: zlatinski to Modify the cascading parser diagram
    [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [25]scribe.perl version 1.133
     ([26]CVS log)
     $Date: 2008/06/10 14:06:26 $

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

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/this/the spec text/
Succeeded: s/latest draft of their spec/last draft that had the svg stu
ff in it/
Succeeded: s/current tokenizer is too limited for XML/the way the token
izer is specced in HTML5 makes it too limited for proper use for XML/
Succeeded: s/HTML a tag/HTML <a> tag/
Succeeded: s/SVG a tag/SVG <a> tag/
Succeeded: s/in away/in any way you like/
Succeeded: s/conformant XML/conformant XML on the source level/
Succeeded: s/from HTML/for HTML/
Succeeded: s/XSBL/XBL/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: aemmons, ed, anthony, Shepazu, zlatinski
Present: aemmons ed anthony Shepazu zlatinski
Agenda: [28]http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJu
Found Date: 10 Jun 2008
Guessing minutes URL: [29]http://www.w3.org/2008/06/10-svg-minutes.html
People with action items: anthony doug erik zlantinski zlatinski

      [29] http://www.w3.org/2008/06/10-svg-minutes.html

    End of [30]scribe.perl diagnostic output]

      [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Tuesday, 10 June 2008 14:09:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:08 UTC