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

Minutes, Raleigh F2F 2009 day 5

From: Cameron McCormack <cam@mcc.id.au>
Date: Sat, 13 Jun 2009 10:40:07 +1000
To: public-svg-wg@w3.org
Message-ID: <20090613004007.GG27596@arc.mcc.id.au>


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

                               - DRAFT -

                   SVG Working Group Teleconference

12 Jun 2009

   See also: [2]IRC log

      [2] http://www.w3.org/2009/06/12-svg-irc





     * [3]Topics
         1. [4]Layout
         2. [5]Simple keywords
         3. [6]ISSUE-2042 - Consider adding adding non-NS linking
         4. [7]xlink:href
         5. [8]New DOM syntax
         6. [9]Test suite
         7. [10]Mailing minutes to www-svg
     * [11]Summary of Action Items

   <trackbot> Date: 12 June 2009

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam


   CM: flex box is progressing in css, what about other layout?

   CL: there's multi column
   ... might be dropped in implementations
   ... there's grid, which is mainly used for asian typography

   CM: not intended for big boxes of content in the grid?

   CL: no

   CM: template too


     [12] http://www.w3.org/TR/2009/WD-css3-layout-20090402/

   DS: xsl wants areas that text flows in to, and areas that grow to
   fit the text
   ... we should make sure that whatever we do for text shape should
   work for those
   ... need to gather use cases & reqs for text flow shapes

   CM: a good way forward might be for someone to look at the flex
   layout and see how applicable it is to svg

   CL: as for the text flow problem, our flowText from the 1.2 draft is
   pretty different from what xsl needs

   ED: i'm more interested in the graphical content layout problem

   DS: i'm still interested in the one way constraints stuff

   <shepazu> DS: part of flexbox, as I understand it, is essentially
   the springs-and-struts model

   CM: i feel like high level layout (like flex boxes) plus one way for
   relative positioning might be a good balance
   ... the springs can't cross boxes, with flex boxes

   DS: if i have a rectangle and i want it to be a particular size,
   relative to other things around it, with a min height/width, seems
   like you could do that with the constraints

   CM: one way constraints are less useful than i'd thought a while ago

   DS: for some things i still want to use calc(bbox(some object) + 5)
   kind of functionality
   ... it's possible people would misuse the simple stuff and try to
   make things that are too complex

   CM: also seems bad to require complex implementations to solve
   simple use cases

   CL: for text flow, we limited our 1.2 draft solution to just simple
   ... to avoid arbitrarily complex xsl-like formatting within svg
   ... want the sweet spot where small amount of functionality gets you
   lots of use

   DS: two problems with canned layout solutions
   ... one, they each only solve a particular problem
   ... if there's no underlying model, then it becomes harder to define
   and to understand how they work together

   CM: swing has a unifying model of rectangular components with
   min/preferred/max width and height

   CL: systems can work together fairly easily if you limit them to not
   work together
   ... if they're mutually exclusive

   DS: things tend to break down to specific syntax for those
   solutions, then
   ... so we need an underlying model to make them work together
   ... and so that people can understand how they work together

   CM: i think people will want to use multiple high level layouts

   DS: maybe some you can combine some you can't?
   ... one thing that would be an easy win:

   [doug talks about the "chain font" example]

   scribe: so let's just allow shapes flowing along a path
   ... i think what goes along with that is navigation
   ... an implicit ordering

   CM: so like implicitly determining the nav-* properties

   DS: so for this pretty much textPath, but shapePath

   ED: i've had cases where i wanted to place images along a path, it's
   pretty difficult

   CL: the trivial case where someone wants the layout and gives a
   straight line path

   DS: how do these shapes become anchored?

   JW: two things tied into this shapes on a path
   ... i'd like percentages on a path

   ED: another way of doing it is markers, but they're not easy to use

   JW: also you might want minimum distances
   ... also, places objects on vertices
   ... like putting objects on each point of a star

   DS: so reusing textpath for shapes, many of these things we're
   thinking of for shapepath could be used in textpath too
   ... so laying out glyphs and shapes are similar

   CL: <shapepath>A b c <rect> <circle> d e f</shapepath>

   DS: i've been thinking about how to do connectors, how to connect
   things to arbitrary points on a shap
   ... often you want limited connection points
   ... e.g. for circles, top bottom right and left
   ... if it's a star, only on the points
   ... so i want to identify those points through some syntax, or have
   as a child of that shape, a bunch of <point> elements with their
   actual positions
   ... those <point>s could be constrained to be at particular points
   on the shape
   ... each could have an id, and you could say that one is the anchor
   ... or you might have anchor-x, anchor-y on a shape

   CM: it's like setting the baseline for your shape
   ... if the <point>s are going to be used for other things, like
   connectors, then would make sense to reuse them
   ... otherwise, just use the anchor- attributes

   [doug draws]

   CL: can we do text on a path where each glyph has a constant

   JW: there's marker orientation

   CM: i want automatically <use>d things along a path

   <ed> there's no way to disable the rotation on textpath though, no
   @orient attribute

   CM: to fill up the path
   ... to do train line like paths

   DS: you could have a stroke-dasharray type of mechanism to specify
   those repeated things
   ... you could specify like background-repeat

   ED: it's also like gradient spread method... reflect, pad, repeat,

   DS: currently text has an interesting property where later glyphs
   are drawn on top of earlier glyphs
   ... perhaps we want to allow painting glyphs in reverse order
   ... or maybe an arbitrary order
   ... painting order
   ... maybe you want to allow specifying multiple shape repeat
   patterns that get drawn over each other

   <scribe> ACTION: doug to write up a shape path proposal [recorded in

   <trackbot> Created ACTION-2616 - Write up a shape path proposal [on
   Doug Schepers - due 2009-06-19].

   <shepazu> should also think about potential join points, might apply
   to fonts, depends on how complex it did it

   <shepazu> ... for patterns

   DS: there's a problem with tspan and the semantics of a word
   ... would be useful to define that tspan does not affect the
   underlying semantics of the text, it's just the positioning
   ... you can have multiple tspans that comprise a single word
   ... only a space in english defines a separate word

   ED: we should define how collapsed whitespace is assigned to
   particular text elements

   CL: <text font-size='50'>a[space]<tspan
   font-size='10'>[space]</tspan></text> -- how big is the single
   collapsed space?

   <jwatt> JW: I'd say the smaller of the two

   <ed> raised ISSUE-2280

   CL: you can consider the shape-flowing-to-variable-width-path as a
   displacement map problem
   ... the path defines a complex gradient
   ... which you use as the displacement map

   <scribe> ACTION: cameron to play with css flex box to see how
   applicable it could be to svg [recorded in

   <trackbot> Created ACTION-2617 - Play with css flex box to see how
   applicable it could be to svg [on Cameron McCormack - due

Simple keywords

   CM: i was thinking about vector-effect='strokeBelowFill'

   ED: or filter='drop-shadow'

   <scribe> ACTION: chris to add a strokeBelowFill canned vector effect
   [recorded in

   <trackbot> Created ACTION-2618 - Add a strokeBelowFill canned vector
   effect [on Chris Lilley - due 2009-06-19].

   DS: i want to make sure that large stroke on text, where the stroke
   is behind the fill, works. where the stroke around the individual
   glyphs doesn't overlap.

   CL: yes that's possible with vector effects

   <shepazu> [16]http://chapelhillcomics.com/sample/TOP-LOGO.jpg

     [16] http://chapelhillcomics.com/sample/TOP-LOGO.jpg

   <ed> (discussion on vector-effects)

ISSUE-2042 - Consider adding adding non-NS linking syntax



   <trackbot> ISSUE-2042 -- Consider adding adding non-NS linking
   syntax -- RAISED

   <trackbot> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2042

     [17] http://www.w3.org/Graphics/SVG/WG/track/issues/2042

   CL: at one point i suggested combining the thing that holds the IRI
   and the thing that holds the type into one attribute
   ... so <image> would have src, and <a> would have href
   ... and have a generic category for other

   DS: so define it in terms of xlink

   CL: we'd define the mapping to xlink for the subset of xlink that we
   ... xlink would have had a network effect if a bunch of specs used
   it, but they didn't
   ... what xlink was going to be changed mid-design

   [explains what xlink was meant to be and what it ended up as]

   scribe: so xlink:type="" doesn't tell you what to do (refer, embed);
   instead it's just a hint to the xlink processor
   ... so xlink gives you some generality, but not full generality
   ... it has enough generality to get in the way, though
   ... the promise of serving domain specific xml has been lost

   DS: for backwards compat and existing UAs we've still held on to

   CL: you could come up with new attributes and deprecate xlink:href
   ... UAs need to support both, new content targetting new browsers
   can just use the new attrs, content supporting both needs both, etc.
   ... i propose svg 2 prefer a new xlink-less syntax that does just
   what we need
   ... and say what's the mapping of the new way to the old way

   DS: this is also applicable to svg in text/html

   JW: we need to decide which takes precedence
   ... we don't implement xlink, but we don't take some notice of some
   of the xlink attrs
   ... if we take the href attribute instead of xlink:href, should it
   then ignore all the other xlink attrs? or should the href override
   all of the xlink attributes?

   CL: suppose we had src, and it means xlink:type=embed.

   ED: the only two that are used are xlink:title and xlink:href

   CL: i've never seen xlink:role used in the wild

   JW: we pay attention to xlink:show

   <scribe> ... new or replace

   CM: like target

   CL: all the implementations took target in preference to xlink:show

   JW: if the target attr is empty or not specified, it will look at
   ... if href overrides xlink:href, should we then ignore xlink:show?

   CL: my off the cuff response to that is that when you find the new
   attribute, it overrides all xlink attrs

   DS: title and xlink:title are two different things
   ... xlink:title is the title of the linked to thing, and title is
   the title of the element it's on

   CL: we shouldn't force people to type xlink:type just to do that

   <ed> <a href="foo" title="bar" xlink:href="foo" xlink:title="bar"/>
   but should be possible to just do <a href="foo" title="bar"> in new

   CM: hreflang exists, you could have hreftitle

   ED: seems like we all prefer new xlink-less attrs to override xlink

   JW: i'm not sure about that
   ... say now someone sticks xlink:href and href on the content
   ... the behaviour will be that impls follow the href

   DS: href and src

   CM: i'd rather align with html's attr names

   DS: i propose href to outgoing links and src for incoming links

   CL: not sure what you mean by incoming links

   DS: i mean for embedding type elements, like <image>

   CL: i don't think they all fall in to two different categories
   ... e.g. xlink:href on gradients
   ... what type is that?
   ... one aspect is whether it's embedded, one aspect is whether it's
   user actuated

   DS: the ability for us to adopt href and src for some of our
   elements, where the align, has a clear case
   ... i'd like to propose we resolve to, where there's a clear mapping
   to html, that we use the same attr name

   JW: i see the academic argument for distinct attr names

   ED: but it's confusing since it's not the same as in html

   JW: it's confusing because people are used to typing xlink:href for
   ... two reasons to consider doing them with different names
   ... one is for recognition that they're different types of links
   ... the other one is consistency
   ... with html, specifically

   DS: html doesn't have some of these kinds of links, like gradient

   CM: they have <label for>, but it's not a url

   <ed> break for lunch


   <ed> back for more of xlink

   <ed> ACTION: CL to research where svg uses links, and make a
   proposal for how to resolve ISSUE-2042 [recorded in

   <trackbot> Created ACTION-2619 - Research where svg uses links, and
   make a proposal for how to resolve ISSUE-2042 [on Chris Lilley - due

New DOM syntax

   <ed> ISSUE-2044?

   <trackbot> ISSUE-2044 -- Consider improving the SVG DOM interfaces
   for attribute access -- RAISED

   <trackbot> [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2044

     [19] http://www.w3.org/Graphics/SVG/WG/track/issues/2044

   CM: so ecmascript allows host objects to do that
   ... rectElement.x = 20; is just implemented with a custom [[Put]] on
   the SVGRectElement host object

   JW: not sure if xpcom will allow you to do that

   ED: it's just in the dom, just forwarding on the assignment
   ... in my quick test, just depending on the type of value you're
   assigning, you either use .baseVal.value or .baseVal.valueAsString

   CM: in html there's already something like this, window.location
   ... it's a Location object, but you can assign a string to it
   ... getting the values is a bit harder
   ... you can define [[DefaultValue]] on the SVGAnimatedLength
   ... that works ok for most types, but not for SVGAnimatedBoolean
   ... since ToBoolean in ecma-262 doesn't use [[DefaultValue]]

   JW: it's probably not feasible to throw away the current SVG DOM
   ... unless we come up with something exceptionally good, we'll need
   to stick with it

   ED: we should try to make it more useful as we can, though
   ... maybe deprecate some parts going forward

   DS: is it possible to make this in such a way such that we can also
   make it work for canvas?

   ED: i thought about it, it's not that simple
   ... it's not easy to generate something that would make any sense if
   you record all the drawing commands

   DS: we could make jquery-like or kevlin's createCircle()
   ... and allow dot syntax with that object

   CM: so maybe getContext('svg') then canvas drawing commands gets you
   an svg tree

   <scribe> ACTION: doug to write up a proposal for joint canvas/svg
   api, ISSUE-2044 [recorded in

   <trackbot> Created ACTION-2620 - Write up a proposal for joint
   canvas/svg api, ISSUE-2044 [on Doug Schepers - due 2009-06-19].

   ED: for all of the list types, it feels very unnatural to use
   getItem() and getNumberOfItems()
   ... it's very un-javascript like

   JW: you already can use []-indexing on list objects

   ED: it's not in the spec though

   JW: it might be in DOM spec

   CM: but SVG doesn't say it

   <ed> would prefer .length and [i] instead of .numberOfItems and

   CM: instead of or in addition to?

   ED: the hard one is the numberOfItems one

   CM: we could always just have .length as well
   ... also, SVGNumber is a bit sucky
   ... why not just have floats in an SVGNumberList
   ... you could do the same thing as with SVGLength, and have
   SVGNumber have a [[DefaultValue]] that turns it into a Number

   ED: another silly aspect is that you have to get the SVGSVGElement
   ... to create SVG types
   ... most of the times they're not inserted until later
   ... so having a constructor would be nice for the basic types

   JW: i think that works already in mozilla


     [21] http://dev.w3.org/SVG/proposals/type-constructors/type-constructors.txt

   CM: i didn't propose constructors PathSegItem interfaces
   ... not sure how useful they would be
   ... but probably just improving SVGPathSegList would be better

   ED: so we want to move forward on these?

   CM: yes i think we could put these in a blank SVG 2.0 spec

   <scribe> ACTION: update template directory with build scripts
   [recorded in

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

   <scribe> ACTION: cameron update template directory with build
   scripts [recorded in

   <trackbot> Created ACTION-2621 - Update template directory with
   build scripts [on Cameron McCormack - due 2009-06-19].

   <scribe> ACTION: cameron add these dom suggestions to a new svg 2.0
   spec [recorded in

   <trackbot> Created ACTION-2622 - Add these dom suggestions to a new
   svg 2.0 spec [on Cameron McCormack - due 2009-06-19].

Test suite


     [25] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0218.html

   <ed> ACTION-2385?

   <trackbot> ACTION-2385 -- Anthony Grasso to make an XSLT to change
   the template of the 1.1 tests to the new one -- due 2008-12-25 --

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

     [26] http://www.w3.org/Graphics/SVG/WG/track/actions/2385

   CL: dbaron explained reftests to us at csswg f2f

   JW: i demoed them to svgwg last f2f
   ... the important thing for us is that you can do pixel-perfect
   ... and thus automated testing
   ... i've written up some short docs on it

   CL: we use image patches, which are like ref tests
   ... but more for compensating for bugs in batik, to generate the
   reference png

   JW: it's very important for interop
   ... the references should be in svg, i think
   ... don't need a harness, implementors can write their own
   ... and have by-hand harnesses for people to use (not automatic test
   suite running)
   ... not sure if there's the need for a raster fallback

   CM: what's in the baseline?
   ... paths?

   JW: depends on the test

   <ChrisL> benefir of a reftest is that the set of fonts, the
   anti-aliasng, are the same for the reference and the test (both run
   on same machine)

   JW: you might want to start off with testing a rectangle with a
   fill, for example
   ... from that level you would build up from it
   ... so some tests depend on functionality tested in previous tests
   ... we call the basic ones "sanity tests"
   ... whatever assumptions you make in the reference for a test, make
   sure there are tests for those basic functionality in the test suite
   ... resolution independence is pretty much the only reason not to
   use raster reference images, for simple things like testing <rect>
   ... my further plans, as well as technical issues like test format,
   there are social issues and political issues around getting
   implementors to agree on things
   ... especially implementors allowing you to have automated ways of
   running the test suite in the browser
   ... organisation of tests, naming, how detailed they should be,
   should each test do one feature, or many features in one
   ... a few other things i was working on; how to structure the tree
   of tests so that different implementors could mark things as 'we
   fail this"
   ... e.g. if moz sends all their tests to opera, a bunch will
   probably faily
   ... you want to mark them as known fails, so that if they suddenly
   start passing they notify you
   ... but wouldn't keep the tree red
   ... this is one of the places where ref tests falls down, it doesn't
   support multiple implementors tagging this

   DS: danc says he's been interested in it for a while
   ... plh was really interested

   CL: related to passing tests around is the licence
   ... currently w3c licence is fairly restrictive
   ... the aim was to prevent vendors from grabbing a test suite,
   fiddling with it, then saying they pass the test
   ... but more important is to give ppl the freedom to modify the
   tests for their purposes
   ... so you can now licence them under a modified MIT licence
   ... i propose we use this in the future

   JW: i'd rather creative commons zero licence
   ... it's essentially public domain
   ... it frees people up for snippets of code etc.
   ... MIT requires you to have a header
   ... and say who the contributors were
   ... it's a very open licence, but is still a licence, and has these

   CL: the advantage of doing it with the modified MIT licence is that
   it's currently allowed by w3c

   DS: i was skeptical there was a reason to push for CC0, and thought
   that there were useful aspects to a licence that requires
   attribution etc.
   ... if everyone wants to go for CC0, then that's fine

   JW: i'm happy with having provenance information in comments or
   metadata in the document
   ... but it's not a licence

   <ChrisL> So CC Attribution 3.0 Unported looks good to me

   <ChrisL> [27]http://creativecommons.org/licenses/by/3.0/

     [27] http://creativecommons.org/licenses/by/3.0/

   JW: to me, whether it's a licence or not, the point is that we don't
   want people to propagate modified tests

   DS: that's the non-malicious case
   ... what if a group want to remove some features from a test suite
   that they don't want, and distribute that?

   ED: i wonder if there's a licence that fits out of the box

   <ChrisL> actually this one is better

   <ChrisL> [28]http://creativecommons.org/licenses/BSD/

     [28] http://creativecommons.org/licenses/BSD/

   <ChrisL> and arguably more applicable to markup (code)


     [29] http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html

   CL: a three-clause bsd licence

   JW: that's what the current test suite is under

   <ChrisL> is it really iunder that?

   JW: i want people to be able to take snippets out of the test slides
   ... and reuse them at will

   DS: can we have the individual tests under once license, and the
   test suite as a whole under another?

   CL: for the new template, i'd like a link to this licence
   ... not the wall of capital letters

   <ChrisL> lets just have a link to W3C 3-clause BSD License in the
   test harness

   ED: i think it would be good to move to the bsd licence

   CM: will other implementors want to contribute with w3c 3-clause bsd
   licenced tests?
   ... or would they be unhappy with anything but something like public
   domain / cc0

   JW: are we still open to discussion on using other licences in the

   DS: yes

   RESOLUTION: We will move the SVG test suite to the new W3C 3-clause
   BSD licence

   <scribe> ACTION: erik to convert the test suites to use the 3-clause
   bsd licence [recorded in

   <trackbot> Created ACTION-2623 - Convert the test suites to use the
   3-clause bsd licence [on Erik Dahlström - due 2009-06-19].


     [31] http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/test/script/f11_1st_2_f11_2nd.pl

   ED: we'll wait for anthony to finish the test suite conversion
   script, then convert it and check it
   ... there are some 1.1 tests that need review

   <scribe> ACTION: erik to go through the test suite to see which ones
   need reviewing, and put that list on a wiki page [recorded in

   <trackbot> Created ACTION-2624 - Go through the test suite to see
   which ones need reviewing, and put that list on a wiki page [on Erik
   Dahlström - due 2009-06-19].

Mailing minutes to www-svg

   JW: i propose that we CC the minutes to www-svg

   ED: i don't disagree with that, but they should still be on

   DS: charter says we have to send to public-svg-wg at least

   ED: i'm concerned conversations will fork

   CM: i don't think that forking is a problem
   ... i'd be happy with doing technical discussion on www-svg

   DS: we can't just CC the mail
   ... we could send to www-svg and bcc public-svg-wg
   ... we should have a disclaimer about the minutes being sent out
   ... when this was mentioned to chris yesterday (sending minutes to
   www-svg) he was concerned about that as a policy and i suspect that
   his concern may in part have been that the minutes are not clear if
   you weren't there
   ... and also that it might generate a lot of noise, feedback before
   our ideas are fully baked
   ... but that's just my guess on his concern is

   CM: personally i'm happy if people can see our half baked ideas

   JW: i suggest some disclaimer text

   <jwatt> DISCLAIMER: The SVG Working Group provides these minutes,
   unedited, in the interest of timely openness. The lack of editing
   may make them difficult to understand or subject to
   misinterpretation outside of context. If you find that to be the
   case, polite requests for clarification are welcome.

   DS: i think it's a worthwhile experiment to see if the policy causes
   ... i'll note that this is how we operate in the Web Apps WG, and it
   has caused a lot of discussion, but not problems
   ... work with the dom has generated helpful input

   JW: if everything is done out of public view, and presented all at
   once, you get a flood of comments
   ... which is hard to deal with
   ... if you send the minutes gradually, it heads off a whole swamp of
   upset people
   ... by giving them a chance to voice their concerns at an earlier

   DS: before we've put too much work in to a solution that has

   CM: we had the thread on style/script in text/html on www-svg
   ... that worked ok

   DS: since the svg wg has shown that we are trying harder towards
   being better integrated into the web architecture, open web
   platform, i think people are less prone to jump to bad conclusions

   JW: one thing not in the disclaimer is about new ideas here not
   being final
   ... often discussion about embryonic ideas
   ... and many of them could be thrown away

   DS: or may not be the solution we settle on

   JW: i'd like to keep the disclaimer short

   DS: we should send something to www-svg before we start doing this,
   signalling our intentions/concerns/...
   ... brainstorming
   ... "we were encouraged by recent conversations on www-svg and we
   want to see as an experiment if working completely in the open works
   for us"

   RESOLUTION: We will send minutes to www-svg as well as public-svg-wg
   as a first step

   <scribe> ACTION: doug to send mail to www-svg with explanation of
   what we'll be doing with minutes sending [recorded in

   <trackbot> Created ACTION-2625 - Send mail to www-svg with
   explanation of what we'll be doing with minutes sending [on Doug
   Schepers - due 2009-06-19].

   <ed> trackbot, make minutes

   <trackbot> Sorry, ed, I don't understand 'trackbot, make minutes'.
   Please refer to [34]http://www.w3.org/2005/06/tracker/irc for help

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

Summary of Action Items

   [NEW] ACTION: cameron add these dom suggestions to a new svg 2.0
   spec [recorded in
   [NEW] ACTION: cameron to play with css flex box to see how
   applicable it could be to svg [recorded in
   [NEW] ACTION: cameron update template directory with build scripts
   [recorded in
   [NEW] ACTION: chris to add a strokeBelowFill canned vector effect
   [recorded in
   [NEW] ACTION: CL to research where svg uses links, and make a
   proposal for how to resolve ISSUE-2042 [recorded in
   [NEW] ACTION: doug to send mail to www-svg with explanation of what
   we'll be doing with minutes sending [recorded in
   [NEW] ACTION: doug to write up a proposal for joint canvas/svg api,
   ISSUE-2044 [recorded in
   [NEW] ACTION: doug to write up a shape path proposal [recorded in
   [NEW] ACTION: erik to convert the test suites to use the 3-clause
   bsd licence [recorded in
   [NEW] ACTION: erik to go through the test suite to see which ones
   need reviewing, and put that list on a wiki page [recorded in
   [NEW] ACTION: update template directory with build scripts [recorded
   in [45]http://www.w3.org/2009/06/12-svg-minutes.html#action06]

   [End of minutes]

    Minutes formatted by David Booth's [46]scribe.perl version 1.135
    ([47]CVS log)
    $Date: 2009/06/12 22:45:52 $

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

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/pad/pad, repeat/
Succeeded: s/the PathSegList/PathSegItem/
Succeeded: s/ideass/ideas/
Succeeded: s/sohrt/short/
Found Scribe: Cameron
Found ScribeNick: heycam

WARNING: No "Present: ... " found!
Possibly Present: CL CM ChrisL DISCLAIMER DS JW ScribeNick ed eseidel j
oined jwatt left shepazu svg trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

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

Found Date: 12 Jun 2009
Guessing minutes URL: [49]http://www.w3.org/2009/06/12-svg-minutes.html
People with action items: add cameron chris cl dom doug erik suggestion
s these update

     [49] http://www.w3.org/2009/06/12-svg-minutes.html

   End of [50]scribe.perl diagnostic output]

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

Cameron McCormack ≝ http://mcc.id.au/
Received on Saturday, 13 June 2009 00:40:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 13 June 2009 00:40:59 GMT