RE: Memory element

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