- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Sat, 18 Oct 2008 01:14:14 +1100
- To: W3C SVG Public Working Group <public-svg-wg@w3.org>
http://www.w3.org/2008/10/17-svg-minutes.html
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
17 Oct 2008
See also: [2]IRC log
[2] http://www.w3.org/2008/10/17-svg-irc
Attendees
Present
ed_work, NH, Doug_Schepers, [IPcaller], anthony, aemmons
Regrets
Chair
Andrew Emmons
Scribe
anthony
Contents
* [3]Topics
1. [4]ISSUE-2134
2. [5]ISSUE-2094
3. [6]ISSUE-2089
4. [7]ISSUE-2055
5. [8]ISSUE-2083
6. [9]ISSUE-2084
7. [10]ISSUE-2093
8. [11]ISSUE-2130
9. [12]ISSUE-2139
10. [13]ISSUE-2140
* [14]Summary of Action Items
_________________________________________________________
<trackbot> Date: 17 October 2008
trackbot, code?
<trackbot> Sorry, anthony, I don't understand 'trackbot, code?'.
Please refer to [15]http://www.w3.org/2005/06/tracker/irc for help
[15] http://www.w3.org/2005/06/tracker/irc
trackbot, pass code?
<trackbot> Sorry, anthony, I don't understand 'trackbot, pass
code?'. Please refer to [16]http://www.w3.org/2005/06/tracker/irc
for help
[16] http://www.w3.org/2005/06/tracker/irc
<ed_work> heh
NH, you there?
<NH> Sorry I wont be able to join before ~12.30 CET
ahh ok - no worries
[17]http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformEl
ement
[17] http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement
<ed_work>
[18]http://dev.w3.org/SVG/profiles/1.2T/publish/script.html#HandlerE
lement
[18] http://dev.w3.org/SVG/profiles/1.2T/publish/script.html#HandlerElement
ISSUE-2055?
<trackbot> ISSUE-2055 -- Define 'evt'/'event' relationship more
formally -- RAISED
<trackbot> [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2055
[19] http://www.w3.org/Graphics/SVG/WG/track/issues/2055
<ed_work>
[20]http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/016
0.html
[20] http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0160.html
<ed_work> [21]http://www.w3.org/Graphics/SVG/WG/track/actions/2306
[21] http://www.w3.org/Graphics/SVG/WG/track/actions/2306
<ed_work> time for another telcon round?
<ed_work> trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 17 October 2008
Hey ed_work, is this too wordy for ISSUE-2098?
If a script within the <a href='#ScriptElement'><span
class='element-name'>'script'</span></a> element causes
the element to be removed, the script must continue to be execution
as normal.
I have come up with shorter wording
<ed_work> Modifying or removing the script content (or element)
after the script has started its execution has no effect on the
script execution.
<ed_work> isn't there something similar to that already?
<ed_work> perhaps "must have no effect"
ok, looks fine to me
I couldn't see anything in the scripting chapter about this
<ed_work> I have a draft response to cyril on ISSUE-2134 now, but
maybe we should go through it before I send it off
sure
other than looking in the scripting chapter is there anywhere else
you can think of that I should check?
<ed_work> impl. requirements? intro?
<ed_work> conformance?
check those... nothing
I'll add your wording into the scripting chapter
<ed_work> time for another telcon then
<NH> ok
<scribe> scribe: anthony
<ed_work>
[22]http://lists.w3.org/Archives/Public/www-svg/2008Oct/0183.html
(sorry, missed to put in the issue/action)
[22] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0183.html
<ed_work>
[23]http://lists.w3.org/Archives/Public/www-svg/2008Oct/0182.html
[23] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0182.html
ED: Those issues were done
ISSUE-2134
ISSUE-2134?
<trackbot> ISSUE-2134 -- Ambiguities in the 'use' element -- RAISED
<trackbot> [24]http://www.w3.org/Graphics/SVG/WG/track/issues/2134
[24] http://www.w3.org/Graphics/SVG/WG/track/issues/2134
ED: Wording taken from 1.1 for the first bit
... I would prefer not to change anything
... wording is simplified
... almost all of the use element is taken from 1.1
... I think the first paragraph is a high level description
... at least that's how I read it
... I'd prefer to leave it in
AE: I think it make sense keeping it as it is
... it's not a major issue
ED: Second paragraph of the issue
... is it's not according to the spec
... I think it's just a miss reading
... the Third paragraph
... is this strange half sentence
... and it was added in response to our last LC
... it's suppose to be joined to the bullet point list
AG: I think we should merge that last bit with the bullet point
<ed_work> "A 'use' element has the same visual effect as if the
'use' element were replaced by the following generated content" +
"except for resolution of relative IRI references as noted above and
until the referenced elements are modified."
DS: As noted above should be as noted below
ED: The XML resolving base is still above
<ed_work> xml:base resolving
ED: about 4/5 paragraphs above
AE: If could just get rid of the "as noted above"
DS: And say as noted
... I'd suggest edit to remove that sentence above
... make it into one sentence
ED: [Suggests change]
... next thing that is being asked for is clarification of examples
... and he's asking what's happening with id's and xml:id's
... I'd prefer to leave the example as is
... I think it would be very confusing showing the cloning of ids
... because that doesn't really happen anyway
AE: I agree
... it's just a shadow tree anyway
ED: In any case I'd prefer to leave the examples as they are
... Image use base had some errors
... so I removed those
... the last part is find the process xml is transfered
AE: linking-refs-205
... I'd review it first before putting it into your response
ISSUE-2094
ISSUE-2094?
<trackbot> ISSUE-2094 -- accessing rules for traitAccess -- RAISED
<trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/issues/2094
[25] http://www.w3.org/Graphics/SVG/WG/track/issues/2094
ED: Just need to decide on what to do with traitAccess on animation
elements
... currently we throw exceptions if your try to modify traits on
animation elements
... only if they are in the tree already
AE: I think it's significantly simplified the UA
... but it's not just the ID it's all the attributes of the
animation
... sure the xml:id is just one, but I do believe it simplifies it
<ed_work>
[26]http://lists.w3.org/Archives/Public/www-svg/2008Oct/0055.html
[26] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0055.html
AE: removing it will change what implementations have to do
ED: I would disagree with his last comment
AE: There are many other attributes on the animation element
ED: I got to the bit about changing the document while it's parsed
... and I'm not sure it's stated anywhere when you evaluate or
re-evaluate an attribute
... I'm pretty sure it says once it's been resolved you can't change
it
DS: I think it does
ED: It's an edge case, and I wouldn't count on it working
DS: What's the minimum thing we can do to resolve this?
ED: Say that it's forbidden for good reasons
AE: His question is why do we have the restrictions
RESOLUTION: We will not change the animation restrictions
RATIONAL: Implementation experience shows that it simplifies
implementations even when considering xml:id
<scribe> ACTION: Emmons to Reply to ISSUE-2094 [recorded in
[27]http://www.w3.org/2008/10/17-svg-minutes.html#action01]
<trackbot> Created ACTION-2316 - Reply to ISSUE-2094 [on Andrew
Emmons - due 2008-10-24].
ISSUE-2089
ISSUE-2089?
<trackbot> ISSUE-2089 -- animateTransform and underlying value --
OPEN
<trackbot> [28]http://www.w3.org/Graphics/SVG/WG/track/issues/2089
[28] http://www.w3.org/Graphics/SVG/WG/track/issues/2089
DS: We could say this behavior is not defined so don't use it
... it leaves it open to being defined in the future
<shepazu> [[
<shepazu> The 'problem' with the underlying value for
<shepazu> animateTransform is none, if the sentence is
<shepazu> simply skipped. If required, one can replace
<shepazu> it with the sentence, that currently the behaviour
<shepazu> for to-animateTransfrom is explictly unspecified.
<shepazu> Then the reader is informed about the remaining
<shepazu> problem and will not start to write tough
<shepazu> tests as I did.
<shepazu> ]]
<shepazu> [[
<shepazu> [[
<shepazu> Therefore, if critical things are specified to be
<shepazu> 'unspecified', implementors do not have to change
<shepazu> the current behaviour of programs currently and
<shepazu> authors are at least warned, that they must not
<shepazu> rely on anything for these remaining issues.
<shepazu> It cannot be expected, that all problems are
<shepazu> perfectly solved already now, but it is no use to
<shepazu> leave it in an unconsistent state to make sketchy
<shepazu> readers believe, that the work is already done ..
<shepazu> ]]
DS: You can't specify every behavior
... there are cases where we leave things up to the implementers
... we're not saying that an implementation can't do it
AG: If we remove the sentence then we have to remove the bullet
points I think
[29]http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformEl
ement
[29] http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement
DS: Say instead, this behavior is unspecified in Tiny 1.2 and will
be defined in a later specification
ED: If we remove the sentence we should say it's undefined and we
will define it later
DS: Before you make the change and say we will take his advice and
say that this behavior is unspecified
... and say it means removing this entire section and let us know if
that's the case
... and quote the section
[30]http://www.w3.org/TR/SVGMobile12/animate.html#AnimationAttribute
sAndProperties
[30]
http://www.w3.org/TR/SVGMobile12/animate.html#AnimationAttributesAndProperties
ED: It has a note for additive in that table already
... at least in the working draft that was published
... we already have a not in the table there
... he's suggesting to mention the underlying value in that sentence
ISSUE-2055
ISSUE-2055?
<trackbot> ISSUE-2055 -- Define 'evt'/'event' relationship more
formally -- RAISED
<trackbot> [31]http://www.w3.org/Graphics/SVG/WG/track/issues/2055
[31] http://www.w3.org/Graphics/SVG/WG/track/issues/2055
ED: I did some changes to the spec
<ed_work>
[32]http://dev.w3.org/SVG/profiles/1.2T/publish/script.html#HandlerE
lement
[32] http://dev.w3.org/SVG/profiles/1.2T/publish/script.html#HandlerElement
ED: I removed the wording saying this keyword was bound
... it was an old action on Cameron
... so it's removed now
... and I also added in the aliasing explicitly in the example
... I think this is closer to what people are doing
... in implementations are doing currently
... not sure if everyone treats it as function either
... I know we don't
AE: You mean the 'this' keyword
ED: Correct
DS: If there is no 'this' key word aren't we moving away from HTML?
ED: HMTL doesn't do events
... we have tests for both arguments and this
... there were not passes
... one thing to not here, is Opera doesn't currently handle it as a
function
... you can't break out of the function
... I'd like to brainstorm how to reword this
... for thus it's like script content block but with the evt and
event available
... but I'm not sure how to describe that accurately
AE: How is the script element described
ED: Probably not very much I'd guess
... I read the thread there and all the discussion
... and I didn't agree with the more ECMA script equivalent
... I couldn't get that to work and it wasn't any more clear
AE: Could we say it's conceptually like a function object
NH: We have it as a function
ED: Which is why I'd like to have it as a smallest subset possible
AE: Maybe say "Conceptually behave as if"
DS: I agree with Andrew
... and we could say in the reply that we realise that this may not
be complete but we will work
... with webaps and HTML to define it better
ED: Another change we could make is we don't require access to the
arguments property
... and in a later spec say we do require it
NH: Will this give us better conformance to the test suite?
DS: Problem is this is a real problem with SVG, it's incompatible
with other specs
... we need to resolve it in a way that allows better integration
later on
ED: I did make another change there
... and said that the event object is the event and evt is an alias
NH: Why take it out this release and put it in the next version?
ED: Because implementations fail the tests
... I think at this point we should make it easy for implementations
to pass
AE: What ED said there about not having the args available
... for Tiny
... we should add that wording
ED: Ikivo would still be conform
<ed_work> so, resolution is to change this sentence:
<ed_work> In ECMAScript, the contents of the 'handler' element
behave as if they are the contents of a new Function object, created
as shown:
<ed_work> to this:
<ed_work> In ECMAScript, the contents of the 'handler' element
behave conceptually as if they are the contents of a new Function
object, created as shown:
DS: Does that resolve the issue?
ED: The issue itself is asking for a more formal way of defining
event and event variables
<ed_work>
[33]http://lists.w3.org/Archives/Public/www-svg/2008Sep/0061.html
[33] http://lists.w3.org/Archives/Public/www-svg/2008Sep/0061.html
ED: In the email he says to do what I've pretty much done there
... so I think he'll be satisfied with this change
... I will fix the conceptually there and respond to the original
commenter
<shepazu>
[34]http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/015
6.html
[34] http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0156.html
ISSUE-2083
ISSUE-2083?
<trackbot> ISSUE-2083 -- Paced animation and complex types -- RAISED
<trackbot> [35]http://www.w3.org/Graphics/SVG/WG/track/issues/2083
[35] http://www.w3.org/Graphics/SVG/WG/track/issues/2083
<shepazu> [[
<shepazu> Current problems with paced animation were
<shepazu> introduced mainly with some funny formulas in
<shepazu> SVGT 1.2, not before.
<shepazu> If SVGT1.2 implementors do not want to change their
<shepazu> current implementations, one can simply
<shepazu> 1) remove the formulas for lists and path-data
<shepazu> 2) note, that the behavior is explictly unspecified
<shepazu> 3) discourage authors from using calcMode paced for
<shepazu> other constructions than scalars and colors currently,
<shepazu> because due to nonsense in SVG1.1 and in
<shepazu> some implementations, the behavior is unpredictable,
<shepazu> which also applies for animateTransform, if backwards
<shepazu> compatibility is important.
<shepazu> 4) encourage authors to calculate keyTimes for
<shepazu> calcMode linear for the critical unspecified cases,
<shepazu> to get a predictable behavior, because this is
<shepazu> always possible to get the behavior that they would expect
that 'paced'
<shepazu> might mean in their specific case.
<shepazu> This has the big advantage, that readers are warned
<shepazu> and do not start to use the wrong formulas or even
<shepazu> worse to waste their time to understand, how they
<shepazu> are related to calcMode paced, as I did.
<shepazu> ]]
AE: Removing the formulas for list and path data
... is subtle way of fixing some of the issues
DS: This is very sensible
... we should at least warn authors
<scribe> ACTION: Anthony to make changes as suggested by DOH
[recorded in
[36]http://www.w3.org/2008/10/17-svg-minutes.html#action02]
<trackbot> Created ACTION-2317 - Make changes as suggested by DOH
[on Anthony Grasso - due 2008-10-24].
<shepazu> [37]http://www.w3.org/Graphics/SVG/WG/track/issues/2084
[37] http://www.w3.org/Graphics/SVG/WG/track/issues/2084
ISSUE-2084
DS: I have an action on it
... I have some more input on it
... Dr Hoffmann didn't like the extended syntax thing
... When he says extended syntax I think he's talking about the
trailing semicolon
<shepazu>
[38]http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#ValueAt
tributes
[38] http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#ValueAttributes
<shepazu> [[
<shepazu> For compatibility with existing content, SVG extends the
syntax of this attribute to allow a trailing semicolon (with
optional surrounding whitespace) without creating a new value in the
list. Thus, for example, "10; 20; 30;" has the same meaning as "10;
20; 30" and specifies a list of three values. Note that a
zero-length string is a valid value for IRIs, which means that to
use such a value as the final value in a 'values' attribute an
addition semicolon i
<shepazu> ]]
<shepazu> [[
<shepazu> For compatibility with existing content, SVG extends the
syntax of this attribute to allow a trailing semicolon (with
optional surrounding whitespace) without creating a new value in the
list. Thus, for example, "10; 20; 30;" has the same meaning as "10;
20; 30" and specifies a list of three values. Note that a
zero-length string is a valid value for IRIs, which means that to
use such a value as the final value in a 'values' attribute an
addition semicolon i
DS: What if we replaced with something like
<ed_work> trackbot, close ACTION-2303
<trackbot> ACTION-2303 Take over the scope-chain removal action from
heycam and address ISSUE-2055 closed
<shepazu> "For compatibility with existing content, a user agent may
allow a trailing semicolon... . In later specifications, this
behavior may be more strictly defined, so authors and content
generation tools are discouraged from using trailing semicolons."
DS: Instead of mandating that this is the case we'll say the above
... but we might change this later on
RESOLUTION: We will change the trailing semicolon syntax to allow
but not mandate the trailing semicolon and discourage its use
<shepazu> ACTION: shepazu to change the trailing semicolon syntax to
allow but not mandate the trailing semicolon and discourage its use,
per ISSUE-2084 [recorded in
[39]http://www.w3.org/2008/10/17-svg-minutes.html#action03]
<trackbot> Created ACTION-2318 - Change the trailing semicolon
syntax to allow but not mandate the trailing semicolon and
discourage its use, per ISSUE-2084 [on Doug Schepers - due
2008-10-24].
<shepazu> ISSUE-2093?
<trackbot> ISSUE-2093 -- 16.2.9 by 'identity' -- OPEN
<trackbot> [40]http://www.w3.org/Graphics/SVG/WG/track/issues/2093
[40] http://www.w3.org/Graphics/SVG/WG/track/issues/2093
ISSUE-2093
DS: I can follow up with him on this
ED: Seems like an easy change
<shepazu> [[
<shepazu> The 'problem' with the by animation is none for
<shepazu> the future, because this is already clarified in
<shepazu> SMIL3, therefore any comments about this can
<shepazu> be completely skipped in SVG, especially because
<shepazu> in SMIL 2 and 3 it is precisely described, that and how
<shepazu> from-to, from-by and by animations are equivalent
<shepazu> to the related values animations.
<shepazu> ]]
<scribe> ACTION: Doug to Follow up on ISSUE-2093 [recorded in
[41]http://www.w3.org/2008/10/17-svg-minutes.html#action04]
<trackbot> Created ACTION-2319 - Follow up on ISSUE-2093 [on Doug
Schepers - due 2008-10-24].
<shepazu> [42]http://www.w3.org/Graphics/SVG/WG/track/products/11
[42] http://www.w3.org/Graphics/SVG/WG/track/products/11
ISSUE-2130
ISSUE-2130?
<trackbot> ISSUE-2130 -- Basic Data Types section needs
clarifications -- OPEN
<trackbot> [43]http://www.w3.org/Graphics/SVG/WG/track/issues/2130
[43] http://www.w3.org/Graphics/SVG/WG/track/issues/2130
<shepazu> ISSUE-2134?
<trackbot> ISSUE-2134 -- Ambiguities in the 'use' element -- RAISED
<trackbot> [44]http://www.w3.org/Graphics/SVG/WG/track/issues/2134
[44] http://www.w3.org/Graphics/SVG/WG/track/issues/2134
<shepazu> ISSUE-2137?
<trackbot> ISSUE-2137 -- Add clarification about begin time for
canvas negotiation -- RAISED
<trackbot> [45]http://www.w3.org/Graphics/SVG/WG/track/issues/2137
[45] http://www.w3.org/Graphics/SVG/WG/track/issues/2137
ED: I don't think it happens on parse time
... but I could be wrong
DS: So it would happen on rendering?
ED: Before rendering
DS: Why don't we say that Tiny doesn't specify this but we will
clarify this in later specification
ED: Sure
RESOLUTION: The negotiation time is implementation specific
<shepazu> ACTION: shepazu to reply to ISSUE-2137 saying this is
implementation-specific [recorded in
[46]http://www.w3.org/2008/10/17-svg-minutes.html#action05]
<trackbot> Created ACTION-2320 - Reply to ISSUE-2137 saying this is
implementation-specific [on Doug Schepers - due 2008-10-24].
ISSUE-2139
ISSUE-2139?
<trackbot> ISSUE-2139 -- Add note regarding eRR attribute and
prefetch element -- RAISED
<trackbot> [47]http://www.w3.org/Graphics/SVG/WG/track/issues/2139
[47] http://www.w3.org/Graphics/SVG/WG/track/issues/2139
DS: Was discussed to days ago
<shepazu> ISSUE-2140?
<trackbot> ISSUE-2140 -- Ambiguities in mediaSize -- RAISED
<trackbot> [48]http://www.w3.org/Graphics/SVG/WG/track/issues/2140
[48] http://www.w3.org/Graphics/SVG/WG/track/issues/2140
ISSUE-2140
AG: I had a quick look at this
DS: I think what we mean is with regards to file size of the media
AG: Change required?
<shepazu> Clarify this means that ""Defines how much of the media to
fetch in bytes with regards to the file size of the media."
<scribe> ACTION: Doug to Clarify the meaning function in ISSUE-2140
[recorded in
[49]http://www.w3.org/2008/10/17-svg-minutes.html#action06]
<trackbot> Created ACTION-2321 - Clarify the meaning function in
ISSUE-2140 [on Doug Schepers - due 2008-10-24].
<shepazu> ISSUE-2145?
<trackbot> ISSUE-2145 -- Clarify media timeline and document
timeline -- RAISED
<trackbot> [50]http://www.w3.org/Graphics/SVG/WG/track/issues/2145
[50] http://www.w3.org/Graphics/SVG/WG/track/issues/2145
<shepazu> ISSUE-2147?
<trackbot> ISSUE-2147 -- Section on externally referenced documents
confusing -- OPEN
<trackbot> [51]http://www.w3.org/Graphics/SVG/WG/track/issues/2147
[51] http://www.w3.org/Graphics/SVG/WG/track/issues/2147
<shepazu> ISSUE-2149?
<trackbot> ISSUE-2149 -- Paced interpolation of polygons -- RAISED
<trackbot> [52]http://www.w3.org/Graphics/SVG/WG/track/issues/2149
[52] http://www.w3.org/Graphics/SVG/WG/track/issues/2149
<shepazu> ISSUE-2150?
<trackbot> ISSUE-2150 -- Clarify 'required' attribute -- OPEN
<trackbot> [53]http://www.w3.org/Graphics/SVG/WG/track/issues/2150
[53] http://www.w3.org/Graphics/SVG/WG/track/issues/2150
<scribe> ACTION: Doug to Respond to ISSUE-2149 [recorded in
[54]http://www.w3.org/2008/10/17-svg-minutes.html#action07]
<trackbot> Created ACTION-2322 - Respond to ISSUE-2149 [on Doug
Schepers - due 2008-10-24].
Summary of Action Items
[NEW] ACTION: Anthony to make changes as suggested by DOH [recorded
in [55]http://www.w3.org/2008/10/17-svg-minutes.html#action02]
[NEW] ACTION: Doug to Clarify the meaning function in ISSUE-2140
[recorded in
[56]http://www.w3.org/2008/10/17-svg-minutes.html#action06]
[NEW] ACTION: Doug to Follow up on ISSUE-2093 [recorded in
[57]http://www.w3.org/2008/10/17-svg-minutes.html#action04]
[NEW] ACTION: Doug to Respond to ISSUE-2149 [recorded in
[58]http://www.w3.org/2008/10/17-svg-minutes.html#action07]
[NEW] ACTION: Emmons to Reply to ISSUE-2094 [recorded in
[59]http://www.w3.org/2008/10/17-svg-minutes.html#action01]
[NEW] ACTION: shepazu to change the trailing semicolon syntax to
allow but not mandate the trailing semicolon and discourage its use,
per ISSUE-2084 [recorded in
[60]http://www.w3.org/2008/10/17-svg-minutes.html#action03]
[NEW] ACTION: shepazu to reply to ISSUE-2137 saying this is
implementation-specific [recorded in
[61]http://www.w3.org/2008/10/17-svg-minutes.html#action05]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [62]scribe.perl version 1.133
([63]CVS log)
$Date: 2008/10/17 14:06:17 $
_________________________________________________________
[62] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[63] 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 [64]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[64] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/evt/evt and event/
Succeeded: s/whoever raised the issue initially/the original commenter/
Succeeded: s/... doing number 1 suggestion is the best way to go//
Succeeded: s/onit/on it/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: ed_work, NH, Doug_Schepers, [IPcaller], anthony, aemmo
ns
Present: ed_work NH Doug_Schepers [IPcaller] anthony aemmons
Found Date: 17 Oct 2008
Guessing minutes URL: [65]http://www.w3.org/2008/10/17-svg-minutes.html
People with action items: anthony doug emmons shepazu
[65] http://www.w3.org/2008/10/17-svg-minutes.html
End of [66]scribe.perl diagnostic output]
[66] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Friday, 17 October 2008 14:15:00 UTC