See also: IRC log
<burn> trackbot, start telcon
<trackbot> Date: 02 December 2010
<smaug_> um, seems like my network connection is pretty bad today
<bringert> I am Bjorn_Bringert
<burn> Scribe: Raj Tumuluri
<burn> Scribenick: Raj
No objections to the new requirements document
Bjorn proposed rew-wording..are there any objections?
No Objections from the group
There were some recommendation to the wording ....are there any objections?
No objections from the group
No objections recorded for the above requirement
Proposal to replace R2 with two new requirements sent through emails ( last email on Monday)
1. Recogntion w/o specifying grammars should be possible
milan: Did we agree to specify language as part of grammar
Bjorn's wording: Should be possible to specify the language completely independently of the grammar
<burn> bjorn: we already have a requirement to address this
Milan: I did not see that requirement in the document
<burn> milan: does not say "separately from the grammar"
<burn> bjorn: you're right
Milan: Are we using notes as reference or the formal Requirements as the basis
Burn: You are right..the requirements document to be the basis, and not the notes
Bjorn: Michael suggested that we use the text from the notes to reword the requirements doc
<burn> milan and bjorn: we need text for the new requirements
2. App. should be able to specify lang for each recognition
Milan: My concern is that we are NOT capturing all our discussions in the Req. Spec
Bjorn: we should not do this on the phone, but, let Michael incorporate the notes into the spec
<burn> action for michael: add text for each new requirement
<trackbot> Sorry, couldn't find user - for
Burn: to send Michael action item to update the spec incorporating the notes from minutes
<marc> ACTION: Michael to add text for each new requirement [recorded in http://www.w3.org/2010/12/02-htmlspeech-minutes.html#action01]
<trackbot> Sorry, amibiguous username (more than one match) - Michael
<trackbot> Try using a different identifier, such as family name or username (eg. mbodell2, mjohnsto)
Michael is Michael Bodell
<marc> ACTION: mbodell2 to add text for each new requirement [recorded in http://www.w3.org/2010/12/02-htmlspeech-minutes.html#action02]
<trackbot> Created ACTION-1 - Add text for each new requirement [on Michael Bodell - due 2010-12-09].
Burn: So, we do have agreement on the 2 new reqs for R2
Burn: Few more emails came on
this topic post my sending the summary earlier today
... Implementations must support SSML
Agreed to drop R10
Bjorn: Selecting a voice can be done without SSMl
being a requirement
Marc: Is it possible to indicate preference of voices ( like take female voice from among the available)
Bjorn: But you cannot specify a specific engine from a specific vendor, is that correct?
Burn: We have a req. to use SSML
but not SSML 1.1,
... SSML1.1 has many of the features for selection of language etc.
Bjorn: If there is no addtional
burden, then requiring SSML1.1 seems OK
... If there is no addtional burden, then requiring SSML1.1 seems OK
Burn: So, we can put it into the req. and deal with at the time of priorization
Marc: May be we should delay decision on this..
<marc> Proposed wording:
Marc: letting author to specify the language..Marc to type the wording
<marc> Web application authors should be able to specify the voice with which some text is to be spoken.
burn: That wording is OK by me
<bringert> Web apps should be able to specify which voice is used for TTS
Burn: Bjorn's text will replace
the text for R20
... Team agreed
<burn> there seemed to be consensus to add "When speech input is used to provide input to a web app, it should be possible for the user to select alternative input methods."
scribe: there is group agreement on this.
<burn> for the next piece: Chan's last email was http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/0207.html
Burn: Burn: There is a second
thread, initiated by Chan...since he is not on the call today,
we can defer the detailed discussion on that..
... Chan has multiple threads...on this..so, we can just let this happen through email rather than on the phone
Group has no objection with Dan Burnett's suggestion
UNKNOWN_SPEAKER: webapp developer should be able to specify name-specific Language Model
Burn: We can discuss, but check with Robert, as he has some comments on this
Dahl: The comment from Robert came just last night..and afraid many did not have a chance to review it adequately
<ddahl> actually, the requirement was only sent to the list for discussion last night
Burn: Let's not discuss MUST vs.
SHOULD now,.but if there are any other suggestions..we can
... There is no standard for that right now..
Bjorn: If the standard becomes available in future, it may be possible to specify this with URI
Burn: It seems that we have
agreement on this among the people on the call.....
... We will keep R12 as stated and confirm it on the mailing list
<Milan> Transport layer security (e.g. HTTPS) if requested by the web app.
UNKNOWN_SPEAKER: Milan to post the 3 requirements under this topic
Bjorn: We agreed on the priority level of req..
<smaug_> bringert: did you really said that ^^
Burn: There are many reqs.. that may be very relevant...
Bjorn: WebApp API and
UA-2-SpeechAPI are two separate reqs.
... Correction on Bjorns' comment on priority level...Expunge from minutes
... Core needed for any speech API and the other for WebApps..
Burn: Is there anything else that
we need to cover today?
... suggest Bjorn correct the statements himself with the appropriate wording..
<bringert> My position on grouping requirements: We should split the requirements document in two sections: 1. Requirements needed for any HTML Speech API, 2. Requirements only needed for web app specified network speech services.
<bringert> What I said about priorities: There was a discussion of the relative priorities of the core Web app - UA API, and the network speech services API, and we didn't come to a conclusion.
<bringert> My position (as I've communicated on the mailing list) is that the Web app API should be considered the core API, and the APIs for specifying and communicating with network speech services should be considered extensions of lower priority.
<burn> s/Next Topic:/Topic:/g
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/mylan/milan/ Succeeded: s/Next Topic:/Topic/ Succeeded: s/Next topic:/Topic:/g Succeeded: s/Topic/topic:/ Succeeded: s/First Topic:/topic:/ Succeeded: s/Milan/Bjorn/ Succeeded: s/March/Marc/ Succeeded: s/servies/services/ Succeeded: s/Next Topic/Topic/g FAILED: s/Next Topic:/Topic:/g Found Scribe: Raj Tumuluri Found ScribeNick: Raj Default Present: Bjorn_Bringert, Dan_Burnett, Olli_Pettay, marc, +1.732.507.aaaa, Milan_Young, Debbie_Dahl, Raj_Tumuluri, +44.207.881.aabb, Satish_Sampath, [Microsoft] Present: Bjorn_Bringert Dan_Burnett Olli_Pettay marc +1.732.507.aaaa Milan_Young Debbie_Dahl Raj_Tumuluri +44.207.881.aabb Satish_Sampath [Microsoft] Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0024.html Found Date: 02 Dec 2010 Guessing minutes URL: http://www.w3.org/2010/12/02-htmlspeech-minutes.html People with action items: mbodell2 michael[End of scribe.perl diagnostic output]