[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: Schema Question
- Subject: RE: Schema Question
- From: Sullivan, Glenn
- Date: Tue, 23 Dec 2003 05:14:00 +0000
I am thinking of things like Voices, Pitch, Speed, Number-of-Repeats etc...
and I will make them optional items in the tts.basic.Speak (Is that proper
"dot notation" for the Speak block in the TTS.Basic class? Just
seems
natural I guess)
I guess what threw me for a loop was the change in naming convention in the
CID schema. The fact that an incoming call can trigger either a
CID.Incoming block or an Incoming.CallWithCID block (no matter what the
class) was confusing. It would seem to me that it might make more sense for
the Blocks that share a similar function at least share a name, if not the
inheritence that you speak of. For example, the CID schema (which I'm sure
has been debated in the past, and I'll be the late bloomer) could be:
Class = CID.Incoming
CID.Incoming
{
blah, blah, blah
}
Class = CID.Meteor
CID.Incoming
/*Notice the change in Block Name to match*/
{
blah, blah, blah (from the CID.Incoming class)
<Meteor specific "Incoming call with CID" items>
}
Incoming.CallWithNoCID
{
<and so on...>
That way, the application could just use the
IfBlockExists("CID.Incoming")
function, and not care about the Class.
Which essentially leads to your inheritence point, given that the
"blah,
blah, blah" is repeated, and augmented upon, in the second class.
Do you already have a TTS Schema written up? If so, I should at least
consider it... ;-)
Anyway, it is getting late, and I have to end off for the evening. More
thoughts will follow, if they come to me. But for now, I am going to use a
pseudo-inheritence in the tts schema by repeating the "basic"
items in the
MSAgent's TTS.Speak block.
This DOES consume you once you get started...
Glenn
-----Original Message-----
From: Stuart Booth
To: <a
href="/group/xAP_developer/post?postID=hywtJBXuKPI55IKD-U1u0-_31pjkZKYCXh1xxLyEmMnSvZsJtfHqsN0L0TaOOBmCnHiuXoQ4qRe62W_q5VtSH7wDXxp_">xAP_developer@xxxxxxx</a>
Sent: 12/22/03 6:21 PM
Subject: Re: [xAP_developer] Schema Question
On Mon, 22 Dec 2003 16:12:15 -0500, "Sullivan, Glenn"
<<a
href="/group/xAP_developer/post?postID=hC67Wt0ENAqtLBcYPKLQh5uy2SY8GNGNPNKXZESYb1UPwVmP8X2qeNXkGeUlkhvo5wMhVgzQdgUQVc7MEbKGr-M">gsullivan@d...</a>>
wrote:
>I guess it just seems silly to send out two messages.
Indeed, redundant traffic.
> Can't I just create
>optional parameters in the TTS.Speak block in TTS.Basic, and then the
>"simpler" tts devices will ignore them? And then only have a
class
called
>TTS.MSAgent for blocks like DefaultCharacter.Change, or Status.Request?
What sort of additional parameters were you thinking of here? My own
TTS app is incredibly basic. I don't think I've fired it up in a
looooong time so I can't even tell you what it did/does. ToDo list,
deeply lost somewhere...
Something I've been playing around with a little bit that has been
mentioned here before is that of class inheritance. I don't know what
the current thinking on this is though. These are just some ideas that
floated through my head.
Anyway, taking your example,
Class = TTS.Basic
TTS.Speak
{
Text=Speak these words of ultimate wisdom
}
Then 'derive' from this class and add further specialisation:
Class = TTS.Basic.MSAgent
TTS.Speak
{
Text=Words
}
TTS.Agent
{
Character=Trudy
}
A TTS.Basic capable app can pick out the things it knows and ignore
the rest. A MSAgent equipped app can cope with the additional data
that the basic app skipped over.
Or as even wilder alternative, how about inheriting the message block
too:
Class = TTS.Basic.MSAgent
TTS.Speak.Agent
{
Text=Words
Character=Trudy
}
There's quite an overhead in processing this kind of stuff on low
power devices however! So it's just a couple of alternatives to
consider.
Going back to your original plan, if the additional bits of optional
data are general enough, then why not stick them in your TTS.Basic as
you suggest. Are we thinking about different voices here? There are
several examples of additional optional data in basic level schema
that are often ignored.
S
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=lrBMweqhTj5tO3WhuOiapM3-YXxPbOyS5pBvTkguOm3pAxKDYE-b84TctyiaWx2vEdGD0ANydqxEx18u4ubMw2Y">stuart@x...</a>>
xAPFramework.net - a xAP software development framework for .net
<a href="http://www.xapautomation.org/">http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/">http://www.xapframework.net/</a>
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|