W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2013

RE: Memory element

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Tue, 12 Feb 2013 20:58:14 +0000
To: chris nuernberger <cnuernber@gmail.com>, "VBWG Public (www-voice@w3.org)" <www-voice@w3.org>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810204F8@GENSJZMBX03.msg.int.genesyslab.com>
Chris,
<history> nodes are required to have a <transition> child  giving the default history state (if they haven't been visited.)

For the <memory> element, if you'll look back at earlier drafts, you'll see an <anchor> element with similar semantics (it took a  snapshot of the data model).  We took it out because of performance concerns.  It may be very difficult  or expensive to snapshot certain data models, and there is no limit to the number of times the author might ask you to do this.  So, on the one hand, people have certainly thought about this kind of functionality, but it's probably best to try it for a specific use case with a specific data model, rather than trying to define it generically.


-          Jim

From: chris nuernberger [mailto:cnuernber@gmail.com]
Sent: Tuesday, February 12, 2013 10:25 AM
To: VBWG Public (www-voice@w3.org)
Subject: Memory element

A slightly different element that we could perhaps consider would be a <memory> element.

It would have the same deep/shallow semantics of history but you would have commands from the scripting system explicitly to store.  Aside from only storing information if explicitly asked to, it would function just as a history node.  It would probably be required to have a transition inside it.

On that note, I am somewhat surprised that history nodes are not required to have a transition inside them for if they are targetted and have no history.

In any case I think there are use cases for <memory/> that may be interesting/useful with more complex UI metaphors.

Chris

--
A foolish consistency is the hobgoblin of little minds - Emerson
Received on Tuesday, 12 February 2013 20:58:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 12 February 2013 20:58:52 GMT