Minutes, 26 August 2009 SVG WG telcon

http://www.w3.org/2009/08/26-svg-minutes.html

---


    [1]W3C

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

                                - DRAFT -

                    SVG Working Group Teleconference

26 Aug 2009

    [2]Agenda

       [2] http://www.w3.org/mid/20090825234450.GA11429@wok.mcc.id.au

    See also: [3]IRC log

       [3] http://www.w3.org/2009/08/26-svg-irc

Attendees

    Present
           heycam, anthony, Doug_Schepers, ChrisL

    Regrets
    Chair
           Cameron

    Scribe
           anthony

Contents

      * [4]Topics
          1. [5]Substitute for onload event in XSLT-generated graphics
             [www-svg]
          2. [6]filterRes Issue
          3. [7]Substitute for onload event in XSLT-generated graphics
             [www-svg] again
          4. [8]painting-render-02-b.svg review
          5. [9]MIME type registration
      * [10]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 26 August 2009

    <scribe> scribe: anthony

    <scribe> chair: Cameron

    <ChrisL> Agenda:
    [11]http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/005
    4.html

      [11] http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0054.html

Substitute for onload event in XSLT-generated graphics [www-svg]

    <ChrisL>
    [12]http://www.w3.org/mid/17608.193.8.177.17.1251183912.squirrel@web
    mail22.mirsky.de

      [12] 
http://www.w3.org/mid/17608.193.8.177.17.1251183912.squirrel@webmail22.mirsky.de

    CM: This about events and whether it should be dispached if the
    document you opened is the result of an XSL transformation

    CL: You don't automatically have parsing happening when XSLT is
    running
    ... it generates source?

    CM: It generates the DOM
    ... then installs the document
    ... that's how I thought it work
    ... not sure if incremental XSLT exists

    CL: Basically it's another data source
    ... either way it should be parsed
    ... and when it's finished you should get a load event

    CM: I haven't checked the wording we've got
    ... to see if it focuses on the parsing tags

    CL: I don't hear any disagreement if that should happen

    CM: If you have a whole DOM in memory and you wanted to do the thing
    where script elements run
    ... as soon as you see the closing script tag

    <ChrisL>
    [13]http://www.w3.org/TR/2009/PER-xslt20-20090421/#result-trees

      [13] http://www.w3.org/TR/2009/PER-xslt20-20090421/#result-trees

    <ChrisL> The output of a transformation is a set of one or more
    final result trees.

    <ChrisL> A final result tree can be created explicitly, by
    evaluating an xsl:result-document instruction. As explained in 2.4
    Executing a Transformation, a final result tree is also created
    implicitly if no xsl:result-document instruction is evaluated, or if
    the result of evaluating the initial template is a non-empty
    sequence.

    <ChrisL> The way in which a final result tree is delivered to an
    application is implementation-defined.

    CL: [reads out above text]
    ... so XSL itself says nothing
    ... about how it gets load etc
    ... talks in terms about what the grammar is and what the out put is

    CM: I wonder if the HTML5 spec says anything XML style sheet
    processing instructions
    ... maybe they've already covered that
    ... about script elements and when they get run

    <shepazu>
    [14]http://dev.w3.org/html5/spec/the-xhtml-syntax.html#the-xhtml-syn
    tax

      [14] http://dev.w3.org/html5/spec/the-xhtml-syntax.html#the-xhtml-syntax

    <shepazu> "Certain algorithms in this specification spoon-feed the
    parser characters one string at a time. In such cases, the XML
    parser must act as it would have if faced with a single string
    consisting of the concatenation of all those characters."

    DS: specifically the section 10.4

    <shepazu> 10.4 Parsing XHTML fragments

    DS: I'm not sure if it's at the same level that you guys were
    talking

    CM: Maybe the stuff in 10.2, 5th paragraph is talking about
    ... the script element
    ... and what you do with it
    ... It seems to me that SVGLoad gets dispatched to the root

    CL: One thing about the original message is it about the spec or an
    unnamed implementation being used?

    CM: Think it being used in FireFox

    CL: We seem to agree that SVGLoad event should be fired
    ... and there is nothing in HTML5 that is very definitive

    CM: I think the trick is whether you have half a document in memory
    (in the DOM) when you encounter a script element
    ... if the output of your XSLT is the whole DOM or whether you need
    to reconstruct everything

    <scribe> ACTION: Cameron to Look more into the HTML 5 specification
    to see if there is wording about how the result of XSLT are parsed
    when script element is encountered [recorded in
    [15]http://www.w3.org/2009/08/26-svg-minutes.html#action01]

    <trackbot> Created ACTION-2661 - Look more into the HTML 5
    specification to see if there is wording about how the result of
    XSLT are parsed when script element is encountered [on Cameron
    McCormack - due 2009-09-02].

filterRes Issue

    [16]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0014.html

      [16] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0014.html

    AG: As far as I can tell the filterRes is used to calculate a
    scaling factor for the filter primitive
    ... you divide the filterRes by the bounds in device space
    ... to get the scaling factor
    ... I'm pretty sure it's a DPI measurement

    <ChrisL> (by the way, on previous topic,
    [17]http://www.astrotexte.ch/sources/svgonload.html fails to fire
    load in Firefox 3.6a1 but does throw in Opera 10 b2)

      [17] http://www.astrotexte.ch/sources/svgonload.html

    CM: It should be it's used to determine intermediate width and
    height of the primitive
    ... the current wording makes it sound like they are the actual
    width and height

    AG: I think the current wording is wrong
    ... I'd like to hear what Eric thinks about this issue as well

Substitute for onload event in XSLT-generated graphics [www-svg] again

    CL: I tried the example
    ... in Firefox it's not thrown
    ... in Opera it is
    ... couldn't test Safari can't get it working on my PC atm
    ... What we need is a test which uses XSLT to generate HTML with a
    script that fires onload
    ... to see what they do with that

    <ChrisL> [18]http://www.astrotexte.ch/sources/svgonload.html

      [18] http://www.astrotexte.ch/sources/svgonload.html

    CL: I suspect all the browsers will throw a load event

    AG: Do you think it's worth making this a test case?

    CL: Would be an interesting test

    CM: Do we require XSL instructions to be processed in SVG?

    CL: Optional addition

    <ChrisL> safari on windows seems to crash on any svg file. odd

    CL: sort of like inline TIFF, you can display it
    ... but don't have to
    ... In fire fox in the top case all you see is a blue circles

    DS: When I load it in Safari it produces astrological symbols
    ... top and bottom

    CM: So Safari does dispatch the event then
    ... next interesting test
    ... will be a document with a script halfway through it

    CL: If you look on the bugzilla, the same comment is made there as
    was made to us
    ... I think it would be useful to find out what HTML does in
    practice
    ... I'd rather have the same load event dispatched

    CM: Even if you don't go the root of reconstructing the DOM in the
    right order we can say
    ... dispatch the event to the root element

    <scribe> ACTION: Cameron to Test XSLT generating HTML with a script
    that fires an onload event [recorded in
    [19]http://www.w3.org/2009/08/26-svg-minutes.html#action02]

    <trackbot> Created ACTION-2662 - Test XSLT generating HTML with a
    script that fires an onload event [on Cameron McCormack - due
    2009-09-02].

painting-render-02-b.svg review

    CL: Currently writing a program to test the different versions of
    sRGB
    ... there's the original version invented by MS and HP
    ... then there's another version presented to the W3C that rounds
    off
    ... the constants
    ... produced a discontinuity
    ... then there's another version that got standardised in IEC
    ... how did you derive your value?

    AG: I used the W3C sRGB to calculate it

    CM: Which is the correct one?

    CL: The IEC sRGB

    <ChrisL>
    [20]http://en.wikipedia.org/wiki/SRGB#Theory_of_the_transformation

      [20] http://en.wikipedia.org/wiki/SRGB#Theory_of_the_transformation

    CM: Does that mean the W3C one should be updated to match?

    CL: It should, I had considered submitting something about this

    <ChrisL> w3c has K0 = 0.03928

    <ChrisL> iec has K0 = 0.04045

    CM: Is this in a spec or is this a note?
    ... Is this something worth pointing out in the W3C spec?

    CL: Yes, this may contribute to some of the variations between
    results

    <scribe> ACTION: Chris to Investigate the discontinuities in the
    sRGB gamut and correct any notes on the W3C website and any colour
    tests that are incorrect [recorded in
    [21]http://www.w3.org/2009/08/26-svg-minutes.html#action03]

    <trackbot> Created ACTION-2663 - Investigate the discontinuities in
    the sRGB gamut and correct any notes on the W3C website and any
    colour tests that are incorrect [on Chris Lilley - due 2009-09-02].

    <scribe> ACTION: Chris to Propose wording for the colour section in
    F1.1 which clarifies which sRGB colour gamut to use [recorded in
    [22]http://www.w3.org/2009/08/26-svg-minutes.html#action04]

    <trackbot> Created ACTION-2664 - Propose wording for the colour
    section in F1.1 which clarifies which sRGB colour gamut to use [on
    Chris Lilley - due 2009-09-02].

MIME type registration

    <ChrisL>
    [23]http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-x
    ml-02.html

      [23] 
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-02.html

    CL: The latest version can be found in the above link
    ... I submitted a draft in July
    ... ISO still have some issues with what 5th edition spec references
    ... The bit about parsing the ascii characters hasn't changed in
    editions
    ... I'm going to put explicit wording which will help address this
    issue
    ... I'll probably be making a draft 0.3 that will incorporate the
    change
    ... I've also started making some tests
    ... my draft also deprecates text/XML and says to used
    application/XML

    DS: What time frame are we talking about for the maturity such that
    it would register the SVG MIME type

    CL: All you have to do is show a two week period with no outstanding
    comments

    DS: So we could have SVG MIME type registered by SVG Open

    CL: Depends on how things go

Summary of Action Items

    [NEW] ACTION: Cameron to Look more into the HTML 5 specification to
    see if there is wording about how the result of XSLT are parsed when
    script element is encountered [recorded in
    [24]http://www.w3.org/2009/08/26-svg-minutes.html#action01]
    [NEW] ACTION: Cameron to Test XSLT generating HTML with a script
    that fires an onload event [recorded in
    [25]http://www.w3.org/2009/08/26-svg-minutes.html#action02]
    [NEW] ACTION: Chris to Investigate the discontinuities in the sRGB
    gamut and correct any notes on the W3C website and any colour tests
    that are incorrect [recorded in
    [26]http://www.w3.org/2009/08/26-svg-minutes.html#action03]
    [NEW] ACTION: Chris to Propose wording for the colour section in
    F1.1 which clarifies which sRGB colour gamut to use [recorded in
    [27]http://www.w3.org/2009/08/26-svg-minutes.html#action04]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [28]scribe.perl version 1.135
     ([29]CVS log)
     $Date: 2009/08/26 08:07:49 $
      _________________________________________________________

      [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [29] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [30]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/CL/CM/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: heycam, anthony, Doug_Schepers, ChrisL
Present: heycam anthony Doug_Schepers ChrisL
Agenda: [31]http://www.w3.org/mid/20090825234450.GA11429@wok.mcc.id.au
Found Date: 26 Aug 2009
Guessing minutes URL: [32]http://www.w3.org/2009/08/26-svg-minutes.html
People with action items: cameron chris

      [31] http://www.w3.org/mid/20090825234450.GA11429@wok.mcc.id.au
      [32] http://www.w3.org/2009/08/26-svg-minutes.html

    End of [33]scribe.perl diagnostic output]

      [33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Wednesday, 26 August 2009 08:16:15 UTC