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

Minutes, SVG Nuremberg Face-to-Face Day 1, Thursday 21 August 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Fri, 22 Aug 2008 02:27:14 +1000
Message-ID: <48AD9762.4080902@cisra.canon.com.au>
To: W3C SVG Public Working Group <public-svg-wg@w3.org>

http://www.w3.org/2008/08/21-svg-minutes.html

---

    [1]W3C

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

                                - DRAFT -

                    SVG Working Group Teleconference

21 Aug 2008

    See also: [2]IRC log

       [2] http://www.w3.org/2008/08/21-svg-irc

Attendees

    Present
           Anthony, Cameron, Doug, Erik

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           Cameron, anthony

Contents

      * [3]Topics
          1. [4]Publication schedule
          2. [5]Action/issue triage
          3. [6]ISSUE-2030
          4. [7]ISSUE-2031
          5. [8]ISSUE-2032
      * [9]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 21 August 2008

    <heycam> Meeting: SVG Nuremberg F2F Day 1

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

Publication schedule

    DS: It's important that we get the 1.2 Tiny spec to Rec by the end
    of the year
    ... because we have several standards bodies that have deps on this
    spec that need it to become Rec
    ... it's important for the mobile use
    ... i think it's important that SVG start focussing more on desktop
    browser uses soon
    ... in order to do this, we need to go to LC by the end of next
    month at the latest

    ED: what do we need to get done for LC by the end of next month?
    ... the changes appendix will need to be updated

    CM: a lot of work there
    ... what level of changes should we include there?

    <ed> [10]http://www.w3.org/2007/10/htmldiff

      [10] http://www.w3.org/2007/10/htmldiff

    <ed>
    [11]http://www.w3.org/TR/SVGMobile12/http://dev.w3.org/SVG/profiles/
    1.2T/publish/changes.html

      [11] 
http://www.w3.org/TR/SVGMobile12/http://dev.w3.org/SVG/profiles/1.2T/publish/changes.html

    <ed> [12]http://dev.w3.org/SVG/profiles/1.2T/publish/changes.html

      [12] http://dev.w3.org/SVG/profiles/1.2T/publish/changes.html

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

      [13] http://www.w3.org/Graphics/SVG/WG/track/products/2

    <shepazu> [14]http://www.w3.org/Graphics/SVG/Group/track/

      [14] http://www.w3.org/Graphics/SVG/Group/track/

    <ed>
    [15]http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%
    2FTR%2FSVGMobile12%2Fintro.html&doc2=http%3A%2F%2Fdev.w3.org%2FSVG%2
    Fprofiles%2F1.2T%2Fpublish%2Fintro.html

      [15] 
http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FTR%2FSVGMobile12%2Fintro.html&doc2=http%3A%2F%2Fdev.w3.org%2FSVG%2Fprofiles%2F1.2T%2Fpublish%2Fintro.html

    <shepazu> [16]http://www.w3.org/Graphics/SVG/Group/track/issues/1

      [16] http://www.w3.org/Graphics/SVG/Group/track/issues/1

    <shepazu> [17]http://www.w3.org/Graphics/SVG/Group/track/issues/15

      [17] http://www.w3.org/Graphics/SVG/Group/track/issues/15

    <shepazu> [18]http://www.w3.org/Graphics/SVG/Group/track/issues/258

      [18] http://www.w3.org/Graphics/SVG/Group/track/issues/258

    <shepazu> [19]http://www.w3.org/Graphics/SVG/Group/track/issues/268

      [19] http://www.w3.org/Graphics/SVG/Group/track/issues/268

    <shepazu> [20]http://www.w3.org/Graphics/SVG/Group/track/issues/274

      [20] http://www.w3.org/Graphics/SVG/Group/track/issues/274

    <shepazu> [21]http://www.w3.org/Graphics/SVG/Group/track/issues/333

      [21] http://www.w3.org/Graphics/SVG/Group/track/issues/333

    <shepazu>
    [22]http://www.w3.org/Graphics/SVG/Group/track/actions/1720

      [22] http://www.w3.org/Graphics/SVG/Group/track/actions/1720

    <shepazu>
    [23]http://www.w3.org/Graphics/SVG/Group/track/actions/1865

      [23] http://www.w3.org/Graphics/SVG/Group/track/actions/1865

    <shepazu>
    [24]http://www.w3.org/Graphics/SVG/Group/track/actions/1932

      [24] http://www.w3.org/Graphics/SVG/Group/track/actions/1932

    <shepazu>
    [25]http://www.w3.org/Graphics/SVG/Group/track/actions/1942

      [25] http://www.w3.org/Graphics/SVG/Group/track/actions/1942

    <shepazu>
    [26]http://www.w3.org/Graphics/SVG/Group/track/actions/1883

      [26] http://www.w3.org/Graphics/SVG/Group/track/actions/1883

    <shepazu>
    [27]http://www.w3.org/Graphics/SVG/Group/track/actions/1440

      [27] http://www.w3.org/Graphics/SVG/Group/track/actions/1440

    <shepazu>
    [28]http://www.w3.org/Graphics/SVG/Group/track/actions/1787

      [28] http://www.w3.org/Graphics/SVG/Group/track/actions/1787

    <shepazu>
    [29]http://www.w3.org/Graphics/SVG/Group/track/actions/1904

      [29] http://www.w3.org/Graphics/SVG/Group/track/actions/1904

    <shepazu>
    [30]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/013
    1.html

      [30] 
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0131.html

Action/issue triage

    CM: All of the 1.2T relevant actions/issues have been ported across
    to the new tracker
    ... one i'm not sure about is andreas'
    [31]http://www.w3.org/Graphics/SVG/Group/track/actions/1787

      [31] http://www.w3.org/Graphics/SVG/Group/track/actions/1787

    DS: we could e-mail him

    CM: probably best
    ... it's an action to check to make sure edits have been finished, i
    think
    ... andreas hasn't replied to kalle yet (which is the second part of
    that action)

    [32]http://www.w3.org/Graphics/SVG/WG/track/products/2

      [32] http://www.w3.org/Graphics/SVG/WG/track/products/2

    [33]http://www.w3.org/Graphics/SVG/WG/track/issues/2003

      [33] http://www.w3.org/Graphics/SVG/WG/track/issues/2003

    CM: action is done, so i'll close the issue

    [34]http://www.w3.org/Graphics/SVG/WG/track/issues/2014

      [34] http://www.w3.org/Graphics/SVG/WG/track/issues/2014

    CM: what is the wording in the spec about restricting the spaces?

    <ed>
    [35]http://www.w3.org/Graphics/SVG/Group/repository/spec/mobile/1.2/
    1.2NG/publish/linking.html#IntroFragmentsViews

      [35] 
http://www.w3.org/Graphics/SVG/Group/repository/spec/mobile/1.2/1.2NG/publish/linking.html#IntroFragmentsViews

    <anthony>
    [36]http://lists.w3.org/Archives/Public/www-svg/2008Jun/0023.html

      [36] http://lists.w3.org/Archives/Public/www-svg/2008Jun/0023.html

    <anthony>
    [37]http://gbiv.com/protocols/uri/rfc/rfc3986.htmlhttp://gbiv.com/pr
    otocols/uri/rfc/rfc3986.html

      [37] 
http://gbiv.com/protocols/uri/rfc/rfc3986.htmlhttp://gbiv.com/protocols/uri/rfc/rfc3986.html

    <ed> Replace "Spaces shall not be allowed in fragment specifications
    and commas must be used to separate numeric values within an SVG
    view specification."

    <scribe> ACTION: Anthony to allow spaces in viewbox fragids and to
    suggest that percent-encoded spaces be used if spaces are used, and
    to reply to kalle [recorded in
    [38]http://www.w3.org/2008/08/21-svg-minutes.html#action01]

    <trackbot> Created ACTION-2142 - Allow spaces in viewbox fragids and
    to suggest that percent-encoded spaces be used if spaces are used,
    and to reply to kalle [on Anthony Grasso - due 2008-08-28].

    ACTION-2142?

    <trackbot> ACTION-2142 -- Anthony Grasso to allow spaces in viewbox
    fragids and to suggest that percent-encoded spaces be used if spaces
    are used, and to reply to kalle -- due 2008-08-28 -- OPEN

    <trackbot> [39]http://www.w3.org/Graphics/SVG/WG/track/actions/2142

      [39] http://www.w3.org/Graphics/SVG/WG/track/actions/2142

    trackbot, close ISSUE-2014

    <trackbot> Sorry, heycam, I don't understand 'trackbot, close
    ISSUE-2014'. Please refer to
    [40]http://www.w3.org/2005/06/tracker/irc for help

      [40] http://www.w3.org/2005/06/tracker/irc

    [41]http://www.w3.org/Graphics/SVG/WG/track/issues/2021

      [41] http://www.w3.org/Graphics/SVG/WG/track/issues/2021

    We decide to punt ISSUE-2021 to SVG Core 2.0.

    ISSUE-2021: ASV returns (0,0,400,400) for the test case.

    <trackbot> ISSUE-2021 Bounding box of <image> subject to
    aspect-ratio preservation undefined notes added

    [42]http://www.w3.org/Graphics/SVG/WG/track/issues/2022

      [42] http://www.w3.org/Graphics/SVG/WG/track/issues/2022

    We decide to move ISSUE-2021 to Core.

    CM: i don't think it should be unsupported or in error
    ... it should be valid, and then the processing due to eRR just
    happens if the resource is 404 or whatever

    ED: eRR would mean that the rendering would stop there

    <ed> so if you have an svg with three images in it, the svg has
    eRR="true" and then the second image is 404

    <ed> then no image would be visible because of eRR

    <ed> it's not in error, and the IRI isn't unsupported

    <ed> it's just an effect of eRR handling

    DS: unsupported values should be shown in the error console
    ... we can have a suggestion in the spec to say that if the UA has
    some notion of an error console or log, that it reports unsupported
    values and how they were remedied (the lacuna value used, etc.)

    <scribe> ACTION: Doug to add the suggestion to report unsupported
    values in the error console [recorded in
    [43]http://www.w3.org/2008/08/21-svg-minutes.html#action02]

    <trackbot> Created ACTION-2143 - Add the suggestion to report
    unsupported values in the error console [on Doug Schepers - due
    2008-08-28].

    DS: in Linking it says "a circular references represents an error",
    i don't like this

    we decide to leave that to be an error

    <ed>
    [44]http://dev.w3.org/SVG/profiles/1.2T/publish/struct.html#External
    ResourcesRequiredAttribute

      [44] 
http://dev.w3.org/SVG/profiles/1.2T/publish/struct.html#ExternalResourcesRequiredAttribute

    <ed> Indicates that resources external to the current document are
    required. If an external resource is not available (for example the
    request for the required resource times out), progressive rendering
    is suspended, the load event is not fired for the element, and the
    document goes into an error state (see Error processing). The
    document remains in an error state until all required resources
    become available.

    <ed> so...we should sync the wording in linking with this, saying
    "error state" but not "in error"

    <shepazu> hi, aemmons!!

    <ed> From linking: "When attribute externalResourcesRequired has
    been set to true on the referencing element or one of its ancestors,
    then an unresolved external IRI reference (i.e., a resource that
    cannot be located) shall represent an error (see Error processing)."

    [We discuss the newly introduced fallback behaviour in the Linking
    chapter, and decide it's too much of a change to introduce this
    late, and we'll move it to Core.]

    We need an action to make the following changes in this section:

    - move the first dot point about circular IRI references to a
    paragraph of its own (so it doesn't just apply to invalid IRI
    references, but any circular references

    <ed> Replace:

    <ed> When attribute externalResourcesRequired has been set to true
    on the referencing element or one of its ancestors, then an
    unresolved external IRI reference (i.e., a resource that cannot be
    located) shall represent an error (see Error processing).

    <ed> With:

    <ed> Note that when the attribute externalResourcesRequired has been
    set to true on the referencing element or one of its ancestors, then
    an unresolved external IRI reference (i.e., a resource that cannot
    be located) will result in special handling, see [definition of
    eRR].

    - Add an "invalid IRI reference" definition to intro.html

    - Check that processing for invalid IRI references is defined for
    each attribute that can have an IRI reference

    - Move the third bullet point to Core.

    <scribe> ACTION: Cameron to rework the invalid IRI reference section
    (14.1.4) as in the minutes here [recorded in
    [45]http://www.w3.org/2008/08/21-svg-minutes.html#action03]

    <trackbot> Created ACTION-2144 - Rework the invalid IRI reference
    section (14.1.4) as in the minutes here [on Cameron McCormack - due
    2008-08-28].

    [46]http://www.w3.org/Graphics/SVG/WG/track/issues/2027

      [46] http://www.w3.org/Graphics/SVG/WG/track/issues/2027

    ED: there were some files that referenced from <animation> elements
    something that had overflow
    ... i recall fixing some of those or all of those cases i found so
    that they contained the graphics within their area, so clipping
    wasn't an issue

    AG: and when i investigated julien's email, i found that opera and
    bitflash did the same thing and produced the reference image we had
    ... so i suspect julien looked at the old version of the test suite

    <ed>
    file://localhost/Users/ed2/w3.org/SVG/profiles/1.2T/publish/coords.h
    tml#EstablishingANewViewport

    <scribe> ACTION: Anthony to reply to Julien to say that the tests
    have been fixed in the new release and that there's something in the
    spec that warns against this clipping issue (in that URL above)
    [recorded in
    [47]http://www.w3.org/2008/08/21-svg-minutes.html#action04]

    <trackbot> Created ACTION-2145 - Reply to Julien to say that the
    tests have been fixed in the new release and that there's something
    in the spec that warns against this clipping issue (in that URL
    above) [on Anthony Grasso - due 2008-08-28].

    <scribe> ACTION: Cameron to take a quick look at 16.2.18 to see how
    to make it slightly better [recorded in
    [48]http://www.w3.org/2008/08/21-svg-minutes.html#action05]

    <trackbot> Created ACTION-2146 - Take a quick look at 16.2.18 to see
    how to make it slightly better [on Cameron McCormack - due
    2008-08-28].

    [49]http://www.w3.org/Graphics/SVG/WG/track/issues/2029

      [49] http://www.w3.org/Graphics/SVG/WG/track/issues/2029

    <anthony> scribe: anthony

    ED: Looks like everyone is in agreement to allow spaces

    <scribe> ACTION: Erik to change stroke-dasharray to allow space
    separated values [recorded in
    [50]http://www.w3.org/2008/08/21-svg-minutes.html#action06]

    <trackbot> Created ACTION-2147 - Change stroke-dasharray to allow
    space separated values [on Erik Dahlström - due 2008-08-28].

ISSUE-2030

    [51]http://www.w3.org/Graphics/SVG/WG/track/issues/2030

      [51] http://www.w3.org/Graphics/SVG/WG/track/issues/2030

    ED: Dino said he had an action to clean up feature string
    ... Chris says that Mobile 1.1 had incorrect feature strings
    ... compared to 1.1 Full
    ... but does Tiny 1.2 have new feature strings?

    CM: Dunno
    ... so in Tiny 1.2 does it have any of the 1.1?

    ED: Tiny doesn't have any of 1.1 feature strings
    ... not sure if this was deliberate (Tiny 1.2 new ones)

    CM: In the minutes from 2005 there was suggestion from Scott to
    change them and issue an errata for 1.1
    ... so this issue is now on Mobile 1.1
    ... and the decision was they we not going to change the 1.2 feature
    strings

    <ed> [52]http://www.w3.org/TR/SVGMobile/Tiny/feature

      [52] http://www.w3.org/TR/SVGMobile/Tiny/feature

    ED: SVG Tiny 1.1 feature strings there are 3 of them, I think

    <ed> [53]http://www.w3.org/TR/SVGMobile/Basic/feature

      [53] http://www.w3.org/TR/SVGMobile/Basic/feature

    ED: Not sure if there is anything we need to fix for 1.1 Tiny or
    Full

    CM: It does list 1.0 feature strings
    ... so it's a bit of a mess
    ... I guess we are not going to change anything for Tiny 1.2 either
    then

    ED: What exactly is the issue about?
    ... seems to have been changed
    ... but not sure
    ... I think it could be a problem that there is no hasFeatureMethod
    Tiny
    ... I wouldn't mind seeing a new Issue raised to address the problem
    of missing hasFeature method

    CM: What it says in the original mail doesn't seem to be problem
    anymore

    <heycam> ScribeNick: anthony

    RESOLUTION: We will close the ISSUE-2030 as it does not effect Tiny
    1.2

    ED: I'll raise a new issue about hasFeature to replace ISSUE-2030

ISSUE-2031

    [54]http://www.w3.org/Graphics/SVG/WG/track/issues/2031

      [54] http://www.w3.org/Graphics/SVG/WG/track/issues/2031

    CM: [Reviews minutes]

    ED: Is this something that would work in Batik?

    CM: Not implemented

    <heycam> "When an element is not displayed (i.e., when the 'display'
    property on that element or one of its ancestors has a value of
    none), that element must not be the target of pointer events."

    <heycam> -- 13.7

    ED: I think this wording is a bit unclear

    <ed> so, if the element has display=none then I don't expect any
    user interaction to create events that has that element as its
    original target

    <ed> ...but on the other hand I do expect the element (if it's in
    the document) to still be able to receive events that are dispatched
    to it

    <ed> ...with dispatchEvent, or by other means

    <aemmons> I agree with ed 100%

    <ed> so if an element that has focus is made invisible with a
    display=none, what is expected to happen with the current focus?

    <ed> is it still focused?

    <aemmons> nope, focus is re-evaluated

    <aemmons> lots of content does this

    <aemmons> a few groups of 'menus'

    <ed> that's undefined behaviour as I read the spec

    <aemmons> enable display only on one

    <aemmons> move display through various groups for a different menu

    <ed> do you have any pointers for where it says the focus must be
    moved on display=none?

    <aemmons> sure, sec..

    <aemmons> [55]http://www.w3.org/TR/SVGMobile12/interact.html#focus

      [55] http://www.w3.org/TR/SVGMobile12/interact.html#focus

    <aemmons> The SVG User Agent must not navigate to an element which
    has display='none'. (An element which has display='none' is not
    focusable.)

    <aemmons> The SVG User Agent must allow navigation to elements which
    are not visible (i.e. which has a 100% transparency or which is
    hidden by another element).

    <ed> but it wasn't display=none when it became focused

    <aemmons> Yes, Dos not explicitly say if it is changed that a new
    focus is chosen

    <aemmons> But, early on in 1.2 content and implementation, it was
    implied

    <aemmons> by us, but also content tools and developers

    <aemmons> and also I beleive other impleemntations

    <aemmons> I guess if it is not obvious something has to be added to
    clarify either way

    <aemmons> But I believe the usefulness of content would be reduced -
    how in content then would you force a change in focus without
    resorting to ECMAScript?

    <ed> I'll send an html example to the publicwg list

    <aemmons> ok, my example still stands in the original issue - this
    type of construct is very useful for making UIs with SVG

    <ed> the thing is though, focus handling is really tricky stuff, and
    I don't want HTML and SVG to be incompatible because that makes it
    even more complex

    <ed> see
    [56]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/017
    1.html

      [56] 
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0171.html

    <ed> firefox and opera keeps the first field focused, even after it
    was display=none:d, and after redisplaying it you can continue to
    type into it

    <ed> safari doesn't move the focus anywhere, but doesn't allow
    typing more characters

    <ed> (well, the field still has a focusrect in safari)

    <ed> btw, apologies for the broken html...

    DS: If that's not the specified behavior then we should examine the
    behavior
    ... we should probably coordinate with HTML on this

    <scribe> ACTION: Doug to take up ISSUE-2031 with the HTML WG
    [recorded in
    [57]http://www.w3.org/2008/08/21-svg-minutes.html#action07]

    <trackbot> Created ACTION-2148 - Take up ISSUE-2031 with the HTML WG
    [on Doug Schepers - due 2008-08-28].

    <aemmons> Ok Erik, I see where you are coming from. This is an
    interesting problem but please we should not do anyhitng hastly -
    the whole mobile content that I can see from both us and other
    relies on focus a given way

    <aemmons> to the point where if it were deiced the other way we'd
    have to be non-compliant or else tick off a lot of people

    <aemmons> I am sure this is not just us as well but others

ISSUE-2032

    [58]http://www.w3.org/Graphics/SVG/WG/track/issues/2032

      [58] http://www.w3.org/Graphics/SVG/WG/track/issues/2032

    <shepazu> [59]http://schepers.cc/w3c/svg/animationDiff/

      [59] http://schepers.cc/w3c/svg/animationDiff/

    <heycam> shepazu,
    [60]http://www.gizmodo.com.au/2008/08/real_sim_city_comes_to_life_in
    _the_desert-2.html

      [60] 
http://www.gizmodo.com.au/2008/08/real_sim_city_comes_to_life_in_the_desert-2.html

    <ed> [61]http://dev.w3.org/SVG/tools/htmldiff/ (fetches htmldiff:s
    between 1.2TCR and the 1.2Tpublish)

      [61] http://dev.w3.org/SVG/tools/htmldiff/

    ED: We should go through these one at a time
    ... need go through these tomorrow

Summary of Action Items

    [NEW] ACTION: Anthony to allow spaces in viewbox fragids and to
    suggest that percent-encoded spaces be used if spaces are used, and
    to reply to kalle [recorded in
    [62]http://www.w3.org/2008/08/21-svg-minutes.html#action01]
    [NEW] ACTION: Anthony to reply to Julien to say that the tests have
    been fixed in the new release and that there's something in the spec
    that warns against this clipping issue (in that URL above) [recorded
    in [63]http://www.w3.org/2008/08/21-svg-minutes.html#action04]
    [NEW] ACTION: Cameron to rework the invalid IRI reference section
    (14.1.4) as in the minutes here [recorded in
    [64]http://www.w3.org/2008/08/21-svg-minutes.html#action03]
    [NEW] ACTION: Cameron to take a quick look at 16.2.18 to see how to
    make it slightly better [recorded in
    [65]http://www.w3.org/2008/08/21-svg-minutes.html#action05]
    [NEW] ACTION: Doug to add the suggestion to report unsupported
    values in the error console [recorded in
    [66]http://www.w3.org/2008/08/21-svg-minutes.html#action02]
    [NEW] ACTION: Doug to take up ISSUE-2031 with the HTML WG [recorded
    in [67]http://www.w3.org/2008/08/21-svg-minutes.html#action07]
    [NEW] ACTION: Erik to change stroke-dasharray to allow space
    separated values [recorded in
    [68]http://www.w3.org/2008/08/21-svg-minutes.html#action06]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [69]scribe.perl version 1.133
     ([70]CVS log)
     $Date: 2008/08/21 16:03:13 $
      _________________________________________________________

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

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: anthony
Inferring ScribeNick: anthony
Found ScribeNick: anthony
Scribes: Cameron, anthony
ScribeNicks: heycam, anthony
Present: Anthony Cameron Doug Erik

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 21 Aug 2008
Guessing minutes URL: [72]http://www.w3.org/2008/08/21-svg-minutes.html
People with action items: anthony cameron doug erik

      [72] http://www.w3.org/2008/08/21-svg-minutes.html

    End of [73]scribe.perl diagnostic output]

      [73] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 21 August 2008 16:27:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 21 August 2008 16:27:58 GMT