XForms WG comments on SMIL 3.0 LCWD

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

XForms WG comments on SMIL 3.0 LCWD

Charles F Wiecha


For the XForms working group, I am forwarding the following comments on the
SMIL 3.0 Last Call Working Draft as reviewed during our F2F in Madrid last
week.  Draft minutes of the SMIL 3.0 discussion are available at [1].
Please send replies to each point by separate email so that we can track
comments more easily.

1. Use of the "expr" attribute name is too generic

We understand that the "expr" attribute functions like a gating condition
on the execution of a SMIL element which otherwise is under the control of
the normal SMIL timing mechanism.  "expr", meaning "expression", seems to
us to be too generic a name for this function as the meaning of the
expression in terms of the overall control logic of SMIL is not indicated
by this choice of name.  In XForms 1.1 we have introduced the "if"
attribute which, although it's function may not be equivalent, could be
considered as an alternative name for this attribute.

2. Relationship between language profile and execution context not clear

Section 15.5.3 states that "The SMIL 3.0 Language Profile specifies that
XPath 1.0 is used as the expression language. "  This section also
describes the potential for other expression languages to be used with SMIL
3.0.  Perhaps there is just a wording change required in the first sentence
to clarify that XPath 1.0 is the preferred or default expression language.

In addition, the description of the XPath evaluation context being out of
scope is not clear -- perhaps a link to the defined language profiles would
clarify where the expression context and other issues relevant to XPath are
defined.

3. Are attributes supported in the SMIL 3.0 data model?

We don't see examples where attributes are used or supported in the SMIL
3.0 data model -- for example in the setvalue action.  Please clarify
whether SMIL 3.0 supports only elements or attributes as well.  If
attributes are supported, will a setvalue that references a non-existent
attribute also create that attribute as it does in XForms?

4. Missing delete action?

We note the use of newvalue to create a new entry in the data model...is
delete also supported?  Once created, are data model entries able to be
deleted by other means?

5. How is the position for new data model entries determined?

The "ref" attribute is used to specify the position of new entries in the
data model, as described in Section 15.6.3: "Therefore, name is used to
give the name for the new item and ref specifies where it is inserted."
Where is the new entry created relative to the entry given in "ref" -- as a
child element, and if so where in the possibly existing set of children.
If as a sibling, before or after the ref'd item?

Does the SMIL 3.0 data model have the notion of order as in XML or not,
perhaps depending again on the language profile used (some environments
such as ECMAScript or Servlet attributes may not support the notion of
document order)?

6. Section 15.6.5 additional data model examples would be quite useful.

Additional examples in this section could be provided to clarify some of
the questions raised above -- e.g. the support for attributes, insert
position, whether delete is supported etc.

7. In Section 15.6.6 do we assume XML/DOM event processing?

It is not clear whether the events listed, stateChange and
contentControlChange, follow DOM/XML event processing including
bubble/capture processing etc.

8. Additional event required for data model deletion?

If delete is in fact supported as mentioned above, will another event be
required to notify authors on deletion?  If so what notation will be used
to refer to the deleted node since it no longer exists?

9. Multiple contentControlChange events dispatched?

There are two signatures for the contentControlChange event, one that fires
on any change and the other that indicates a specific change.  Will
application authors in general receive both events for each change?

10.  Section 15.6.6 namespace terminology

The phrase "Rationale: Raising the stateChange event on the state element
instead of on the data model element itself allows for external data models
(which have a distinct xmlid namespace) and on non-XML data models
(depending on the expression language)." refers to distinct xmlid
*namespaces* when probably what is meant are distinct xmlid *spaces*.
Seems not to be a namespace issue rather one of allowing for distinct XML
documents each of which would have its own space for IDs.

11. Are events supported in SMIL 3.0 submission?

Section 15.7.3 indicates that SMIL 3.0 submission follows the design of
submission in XForms -- does this include the events in XForms submission
as well?  If so, do they follow XML/DOM event processing?

12. Please consider XForms 1.1 submission

XForms 1.1 contains significant extensions and clarifications to submission
processing and could be used as a pattern for SMIL 3.0 rather than
submission in XForms 1.0.  XForms 1.1 is now concluding Last Call and
should enter CR shortly and hence could be used in a Last Call SMIL 3.0
Working Draft at that time.

13. Support for replace=instance on submission

It appears that only a single state element is allowed in SMIL 3.0.  If
this is the case, is replace=instance also supported on submission?  If so,
then only the single, original "instance" in the state element could be
targeted -- making some use cases difficult.  A common use case is to query
for data that is dependent on some values first obtained from the user (for
example a US state) then to return the list of valid city names in that
state in a second instance.  Lacking support for multiple state elements
this pattern would be difficult.  XForms 1.1 does allow targeting subtrees
of an instance hence the author could partition the single data model to
support this pattern by convention, albeit with more difficulty than if
multiple state elements are supported.

14, If multiple state elements are desired, then perhaps renaming them
"instance" and introducing the containing "model" element would further
alignment with XForms.

15. Synchronous or asynchronous submission?

Is submission synchronous in SMIL 3.0 as in XForms 1.0?  If so, what is the
behavior of the main timing control cycle during submission -- is there the
potential for blocking user or other interaction/presentation unacceptably
while waiting for a response to a submission?  What is the behavior of
submission notification events relative to the execution of normal SMIL
timing behavior, e.g. are submission events queued for execution and if so
with what relationship to other SMIL processing?

Thanks, Charlie Wiecha

[1] http://www.w3.org/2007/09/14-forms-minutes.html#item06?


Charles Wiecha
Manager, Multichannel Web Interaction
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, N.Y.  10598
Phone: (914) 784-6180, T/L 863-6180, Cell: (914) 320-2614
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: XForms WG comments on SMIL 3.0 LCWD

Dick Bulterman

Hi XForms guys,

Thanks for the LC Comments: we'll consider them this week and get back
to you by the end of the month.

regards,
Dick Bulterman
Eric Hyche

Chairs, SYMM

Reply | Threaded
Open this post in threaded view
|

Re: XForms WG comments on SMIL 3.0 LCWD

John Boyer
In reply to this post by Charles F Wiecha

Please consider an alternate form of #3 below.

The XForms setvalue action does not create a non-existing attribute.  The ref binds to a node, and if that node does not exist, then the setvalue does a no-op.

The alternate form of #3 is to ask that you consider the XForms 1.1 insert and delete actions rather than newvalue and nothing.  We have put a great deal of effort into rigorously specifying these two actions, so it would save you a lot of work if they were simply referenced.  Basically, setvalue, insert and delete are the full package of data manipulation actions.

In terms of process, note that XForms 1.1 is rapidly approaching CR, so we are probably in ahead of SMIL 3.0 in terms of advancement.  It turns out that you are allowed to normatively reference a document that is one stage behind you, so considering we are at least in a "companion" state in the process, I would claim it is very safe to make a normative reference to the full bundle of insert, delete and setvalue from XForms 1.1.

As a separate note, I think you could also use the text in XForms 1.1 on submission to help deal with a number of the issues we raised about submissions in SMIL 3.0.  For example, I think a simple variation of our language about how asynchronous submissions are streamed into the process flow would allow SMIL 3.0 to have the desired asynchronous submission without any "surgery" being needed on your processing model.

Finally, note that the most up-to-date wording that you need, which reflects resolution of *all* of our substantive last call issues pertaining to insert, delete and submission, can be found in the editor's draft available from our group site.  Of course, you cannot cite that version in your technical report.  However, as I said, we should be going to CR relatively quickly.   But if you gave me a timeframe by which you *needed* to have a referenceable document in order for you to proceed to CR, and that date happened to be before we advance, then I could quickly arrange a post-last-call working draft.  In other words, I commit to ensuring that we do not hold up your process in the unlikely event that you need the citation prior to, say, the tech plenary.

Please let us know.

Thanks,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: [hidden email]  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer




Charles F Wiecha <[hidden email]>
Sent by: [hidden email]

09/19/2007 11:54 AM

To
[hidden email]
cc
Jack Jansen <[hidden email]>, <[hidden email]>
Subject
XForms WG comments on SMIL 3.0 LCWD







For the XForms working group, I am forwarding the following comments on the
SMIL 3.0 Last Call Working Draft as reviewed during our F2F in Madrid last
week.  Draft minutes of the SMIL 3.0 discussion are available at [1].
Please send replies to each point by separate email so that we can track
comments more easily.

1. Use of the "expr" attribute name is too generic

We understand that the "expr" attribute functions like a gating condition
on the execution of a SMIL element which otherwise is under the control of
the normal SMIL timing mechanism.  "expr", meaning "expression", seems to
us to be too generic a name for this function as the meaning of the
expression in terms of the overall control logic of SMIL is not indicated
by this choice of name.  In XForms 1.1 we have introduced the "if"
attribute which, although it's function may not be equivalent, could be
considered as an alternative name for this attribute.

2. Relationship between language profile and execution context not clear

Section 15.5.3 states that "The SMIL 3.0 Language Profile specifies that
XPath 1.0 is used as the expression language. "  This section also
describes the potential for other expression languages to be used with SMIL
3.0.  Perhaps there is just a wording change required in the first sentence
to clarify that XPath 1.0 is the preferred or default expression language.

In addition, the description of the XPath evaluation context being out of
scope is not clear -- perhaps a link to the defined language profiles would
clarify where the expression context and other issues relevant to XPath are
defined.

3. Are attributes supported in the SMIL 3.0 data model?

We don't see examples where attributes are used or supported in the SMIL
3.0 data model -- for example in the setvalue action.  Please clarify
whether SMIL 3.0 supports only elements or attributes as well.  If
attributes are supported, will a setvalue that references a non-existent
attribute also create that attribute as it does in XForms?

4. Missing delete action?

We note the use of newvalue to create a new entry in the data model...is
delete also supported?  Once created, are data model entries able to be
deleted by other means?

5. How is the position for new data model entries determined?

The "ref" attribute is used to specify the position of new entries in the
data model, as described in Section 15.6.3: "Therefore, name is used to
give the name for the new item and ref specifies where it is inserted."
Where is the new entry created relative to the entry given in "ref" -- as a
child element, and if so where in the possibly existing set of children.
If as a sibling, before or after the ref'd item?

Does the SMIL 3.0 data model have the notion of order as in XML or not,
perhaps depending again on the language profile used (some environments
such as ECMAScript or Servlet attributes may not support the notion of
document order)?

6. Section 15.6.5 additional data model examples would be quite useful.

Additional examples in this section could be provided to clarify some of
the questions raised above -- e.g. the support for attributes, insert
position, whether delete is supported etc.

7. In Section 15.6.6 do we assume XML/DOM event processing?

It is not clear whether the events listed, stateChange and
contentControlChange, follow DOM/XML event processing including
bubble/capture processing etc.

8. Additional event required for data model deletion?

If delete is in fact supported as mentioned above, will another event be
required to notify authors on deletion?  If so what notation will be used
to refer to the deleted node since it no longer exists?

9. Multiple contentControlChange events dispatched?

There are two signatures for the contentControlChange event, one that fires
on any change and the other that indicates a specific change.  Will
application authors in general receive both events for each change?

10.  Section 15.6.6 namespace terminology

The phrase "Rationale: Raising the stateChange event on the state element
instead of on the data model element itself allows for external data models
(which have a distinct xmlid namespace) and on non-XML data models
(depending on the expression language)." refers to distinct xmlid
*namespaces* when probably what is meant are distinct xmlid *spaces*.
Seems not to be a namespace issue rather one of allowing for distinct XML
documents each of which would have its own space for IDs.

11. Are events supported in SMIL 3.0 submission?

Section 15.7.3 indicates that SMIL 3.0 submission follows the design of
submission in XForms -- does this include the events in XForms submission
as well?  If so, do they follow XML/DOM event processing?

12. Please consider XForms 1.1 submission

XForms 1.1 contains significant extensions and clarifications to submission
processing and could be used as a pattern for SMIL 3.0 rather than
submission in XForms 1.0.  XForms 1.1 is now concluding Last Call and
should enter CR shortly and hence could be used in a Last Call SMIL 3.0
Working Draft at that time.

13. Support for replace=instance on submission

It appears that only a single state element is allowed in SMIL 3.0.  If
this is the case, is replace=instance also supported on submission?  If so,
then only the single, original "instance" in the state element could be
targeted -- making some use cases difficult.  A common use case is to query
for data that is dependent on some values first obtained from the user (for
example a US state) then to return the list of valid city names in that
state in a second instance.  Lacking support for multiple state elements
this pattern would be difficult.  XForms 1.1 does allow targeting subtrees
of an instance hence the author could partition the single data model to
support this pattern by convention, albeit with more difficulty than if
multiple state elements are supported.

14, If multiple state elements are desired, then perhaps renaming them
"instance" and introducing the containing "model" element would further
alignment with XForms.

15. Synchronous or asynchronous submission?

Is submission synchronous in SMIL 3.0 as in XForms 1.0?  If so, what is the
behavior of the main timing control cycle during submission -- is there the
potential for blocking user or other interaction/presentation unacceptably
while waiting for a response to a submission?  What is the behavior of
submission notification events relative to the execution of normal SMIL
timing behavior, e.g. are submission events queued for execution and if so
with what relationship to other SMIL processing?

Thanks, Charlie Wiecha

[1]
http://www.w3.org/2007/09/14-forms-minutes.html#item06?


Charles Wiecha
Manager, Multichannel Web Interaction
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, N.Y.  10598
Phone: (914) 784-6180, T/L 863-6180, Cell: (914) 320-2614
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: XForms WG comments on SMIL 3.0 LCWD

Thierry Michel
In reply to this post by Charles F Wiecha


 Dear Charles F Wiecha ,

The SYMM Working Group has reviewed the comments you sent [1] on the Last
Call Working Draft [2] of the Synchronized Multimedia Integration Language
(SMIL 3.0) published on 13 Jul 2007. Thank you for having taken the time to
review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at [hidden email] if
you agree with it or not before 02 nov 2007. In case of disagreement, you
are requested to provide a specific solution for or a path to a consensus
with the Working Group. If such a consensus cannot be achieved, you will
be given the opportunity to raise a formal objection which will then be
reviewed by the Director during the transition of this document to the
next stage in the W3C Recommendation Track.

Thanks,

For the SYMM Working Group,
Thierry Michel
W3C Staff Contact

 1.
http://www.w3.org/mid/OF09CAE136.C0901DD0-ON8525735B.0061F75D-8525735B.0067DD64@...
 2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/


=====

Your comment on 15. SMIL 3.0 State:
> 8. Additional event required for data model deletion?
>
> If delete is in fact supported as mentioned above, will another event
> be
> required to notify authors on deletion?  If so what notation will be
> used
> to refer to the deleted node since it no longer exists?


Working Group Resolution (LC-1844):
For SMIL 3.0 we decided not to add a notification for the deletion of
nodes, for reasons of simplicity. If applications require this
functionality they can always incorporate the full XForms data model
through an xml namespace.

----

Your comment on 15. SMIL 3.0 State:
> 4. Missing delete action?
>
> We note the use of newvalue to create a new entry in the data
> model...is
> delete also supported?  Once created, are data model entries able to
> be
> deleted by other means?


Working Group Resolution (LC-1840):
Omitting delete was an oversight. We will add it.

----

Your comment on 15. SMIL 3.0 State:

> 5. How is the position for new data model entries determined?
>
> The "ref" attribute is used to specify the position of new entries in
> the
> data model, as described in Section 15.6.3: "Therefore, name is used
> to
> give the name for the new item and ref specifies where it is
> inserted."
> Where is the new entry created relative to the entry given in "ref" --
> as a
> child element, and if so where in the possibly existing set of
> children.
> If as a sibling, before or after the ref'd item?
>
> Does the SMIL 3.0 data model have the notion of order as in XML or
> not,
> perhaps depending again on the language profile used (some
> environments
> such as ECMAScript or Servlet attributes may not support the notion of
> document order)?


Working Group Resolution (LC-1841):
We will add an attribute to allow specifying the position of the new
element.

----

Your comment on 15. SMIL 3.0 State:

> 13. Support for replace=instance on submission
>
> It appears that only a single state element is allowed in SMIL 3.0.
> If
> this is the case, is replace=instance also supported on submission?  If
> so,
> then only the single, original "instance" in the state element could
> be
> targeted -- making some use cases difficult.  A common use case is to
> query
> for data that is dependent on some values first obtained from the user
> (for
> example a US state) then to return the list of valid city names in
> that
> state in a second instance.  Lacking support for multiple state
> elements
> this pattern would be difficult.  XForms 1.1 does allow targeting
> subtrees
> of an instance hence the author could partition the single data model
> to
> support this pattern by convention, albeit with more difficulty than
> if
> multiple state elements are supported.


Working Group Resolution (LC-1849):
We have picked up the target attribute from XForms 1.1 submission.

----

Your comment on 15. SMIL 3.0 State:
> 3. Are attributes supported in the SMIL 3.0 data model?
>
> We don't see examples where attributes are used or supported in the
> SMIL
> 3.0 data model -- for example in the setvalue action.  Please clarify
> whether SMIL 3.0 supports only elements or attributes as well.  If
> attributes are supported, will a setvalue that references a
> non-existent
> attribute also create that attribute as it does in XForms?


Working Group Resolution (LC-1839):
The examples were picked to be as simple as possible, as to be easily
translated to other data model languages than XPath. That said, the
expressions and lvalues allowed are completely governed by that language,
so setting attributes with XPath is definitely allowed, as is, for
example, accessing complex datastructures if Python is used as the data
model language. We will add an informative note to that effect.

----

Your comment on 15. SMIL 3.0 State:
> 6. Section 15.6.5 additional data model examples would be quite useful.
>
> Additional examples in this section could be provided to clarify some
> of
> the questions raised above -- e.g. the support for attributes, insert
> position, whether delete is supported etc.


Working Group Resolution (LC-1842):
We will add some more examples.

----

Your comment on 15. SMIL 3.0 State:
> 7. In Section 15.6.6 do we assume XML/DOM event processing?
>
> It is not clear whether the events listed, stateChange and
> contentControlChange, follow DOM/XML event processing including
> bubble/capture processing etc.


Working Group Resolution (LC-1843):
The section has been updated to state that no these events don't bubble. A
similar change has been made to the normative section in the SMIL Language
Profile.

----

Your comment on 15. SMIL 3.0 State:
> 9. Multiple contentControlChange events dispatched?
>
> There are two signatures for the contentControlChange event, one that
> fires
> on any change and the other that indicates a specific change.  Will
> application authors in general receive both events for each change?
>


Working Group Resolution (LC-1845):
Yes, both events fire. We have clarified this both the the referenced
(non-normative) section and in the normative text in the SMIL Language
Profile.

----

Your comment on 15. SMIL 3.0 State:

> 10.  Section 15.6.6 namespace terminology
>
> The phrase "Rationale: Raising the stateChange event on the state
> element
> instead of on the data model element itself allows for external data
> models
> (which have a distinct xmlid namespace) and on non-XML data models
> (depending on the expression language)." refers to distinct xmlid
> *namespaces* when probably what is meant are distinct xmlid *spaces*.
> Seems not to be a namespace issue rather one of allowing for distinct
> XML
> documents each of which would have its own space for IDs.


Working Group Resolution (LC-1846):
We will change the paragraph as suggested.

----

Your comment on 15. SMIL 3.0 State:

> 15. Synchronous or asynchronous submission?
>
> Is submission synchronous in SMIL 3.0 as in XForms 1.0?  If so, what is
> the
> behavior of the main timing control cycle during submission -- is there
> the
> potential for blocking user or other interaction/presentation
> unacceptably
> while waiting for a response to a submission?  What is the behavior of
> submission notification events relative to the execution of normal
> SMIL
> timing behavior, e.g. are submission events queued for execution and if
> so
> with what relationship to other SMIL processing?


Working Group Resolution (LC-1851):
Submission is synchronous, as in XForms 1.0. Because SMIL has its own
timing model this does not present the same problems as in HTML: by
placing the <submit> in a <par> right
at the root of the document an author can get fully asynchronous
behaviour. Think of this as similar to starting an extra thread in a
normal programming language.

In addition, by selecting a different location for the <submit> an author
can also get fork/join behaviour. We feel this obviates the need for
submission notification events. We will add an example of this usage
pattern.

----



Reply | Threaded
Open this post in threaded view
|

Re: XForms WG comments on SMIL 3.0 LCWD

Charles F Wiecha

For the Forms WG, thank you for your response to our earlier comments on
the SMIL 3.0 LCWD.  As background for our F2F meeting later today, here are
the remaining questions which we would like to discuss.  Thanks, Charlie
Wiecha

=====

Your comment on 15. SMIL 3.0 State:
> 8. Additional event required for data model deletion?
>
> If delete is in fact supported as mentioned above, will another event
> be
> required to notify authors on deletion?  If so what notation will be
> used
> to refer to the deleted node since it no longer exists?


Working Group Resolution (LC-1844):
For SMIL 3.0 we decided not to add a notification for the deletion of
nodes, for reasons of simplicity. If applications require this
functionality they can always incorporate the full XForms data model
through an xml namespace.

Forms comments: how would authors receive notification if nodes are
deleted?  Given the case where there is no full XForms data model, nodes
can still be deleted without any notification.  However, nodes when
inserted generate events, it is not clear to us why there is not parallel
function for the delete case.

The SYMM group has decided to add delete action, but not the corresponding
event.  So, for example, why are events supported on inserting?  It seems
that they're either important/useful or not to the author.

In XForms, for example, index management in the repeat module is now in
terms of listening for insert/delete events.  Both are required... we're
not sure SMIL has equivalent constructs to repeat, but for us we need both
to properly manage anything operating over the data model.

----

Your comment on 15. SMIL 3.0 State:
> 4. Missing delete action?
>
> We note the use of newvalue to create a new entry in the data
> model...is
> delete also supported?  Once created, are data model entries able to
> be
> deleted by other means?


Working Group Resolution (LC-1840):
Omitting delete was an oversight. We will add it.

No further Forms comments.

----

Your comment on 15. SMIL 3.0 State:

> 5. How is the position for new data model entries determined?
>
> The "ref" attribute is used to specify the position of new entries in
> the
> data model, as described in Section 15.6.3: "Therefore, name is used
> to
> give the name for the new item and ref specifies where it is
> inserted."
> Where is the new entry created relative to the entry given in "ref" --
> as a
> child element, and if so where in the possibly existing set of
> children.
> If as a sibling, before or after the ref'd item?
>
> Does the SMIL 3.0 data model have the notion of order as in XML or
> not,
> perhaps depending again on the language profile used (some
> environments
> such as ECMAScript or Servlet attributes may not support the notion of
> document order)?


Working Group Resolution (LC-1841):
We will add an attribute to allow specifying the position of the new
element.

No further Forms comments.

----

Your comment on 15. SMIL 3.0 State:

> 13. Support for replace=instance on submission
>
> It appears that only a single state element is allowed in SMIL 3.0.
> If
> this is the case, is replace=instance also supported on submission?  If
> so,
> then only the single, original "instance" in the state element could
> be
> targeted -- making some use cases difficult.  A common use case is to
> query
> for data that is dependent on some values first obtained from the user
> (for
> example a US state) then to return the list of valid city names in
> that
> state in a second instance.  Lacking support for multiple state
> elements
> this pattern would be difficult.  XForms 1.1 does allow targeting
> subtrees
> of an instance hence the author could partition the single data model
> to
> support this pattern by convention, albeit with more difficulty than
> if
> multiple state elements are supported.


Working Group Resolution (LC-1849):
We have picked up the target attribute from XForms 1.1 submission.

No further Forms comments.

----

Your comment on 15. SMIL 3.0 State:
> 3. Are attributes supported in the SMIL 3.0 data model?
>
> We don't see examples where attributes are used or supported in the
> SMIL
> 3.0 data model -- for example in the setvalue action.  Please clarify
> whether SMIL 3.0 supports only elements or attributes as well.  If
> attributes are supported, will a setvalue that references a
> non-existent
> attribute also create that attribute as it does in XForms?


Working Group Resolution (LC-1839):
The examples were picked to be as simple as possible, as to be easily
translated to other data model languages than XPath. That said, the
expressions and lvalues allowed are completely governed by that language,
so setting attributes with XPath is definitely allowed, as is, for
example, accessing complex datastructures if Python is used as the data
model language. We will add an informative note to that effect.

No further Forms comments.

----

Your comment on 15. SMIL 3.0 State:
> 6. Section 15.6.5 additional data model examples would be quite useful.
>
> Additional examples in this section could be provided to clarify some
> of
> the questions raised above -- e.g. the support for attributes, insert
> position, whether delete is supported etc.


Working Group Resolution (LC-1842):
We will add some more examples.

No further Forms comments.

----

Your comment on 15. SMIL 3.0 State:
> 7. In Section 15.6.6 do we assume XML/DOM event processing?
>
> It is not clear whether the events listed, stateChange and
> contentControlChange, follow DOM/XML event processing including
> bubble/capture processing etc.


Working Group Resolution (LC-1843):
The section has been updated to state that no these events don't bubble. A
similar change has been made to the normative section in the SMIL Language
Profile.

Forms comments: We see there is no bubble phase, but do they have a capture
phase? Could you please clarify if SMIL is using is this some level of DOM
eventing or another processing model?

----

Your comment on 15. SMIL 3.0 State:
> 9. Multiple contentControlChange events dispatched?
>
> There are two signatures for the contentControlChange event, one that
> fires
> on any change and the other that indicates a specific change.  Will
> application authors in general receive both events for each change?
>


Working Group Resolution (LC-1845):
Yes, both events fire. We have clarified this both the the referenced
(non-normative) section and in the normative text in the SMIL Language
Profile.

Forms comments: we remain concerned about the approach of firing both
contentControlChange events, could you please clarify the need for doing
this?  Question which arise include: which comes first?  Is there the
potential for the 2nd event to be invalidated by some aspect of handling
the first?  For example, we've had similar problems where as you're firing
events want to fire two that are related to the same activity: what happens
if you dispatch first one, its action handler makes 2nd event stale...no
longer relevant?  Does this case perhaps not apply to SMIL?

----

Your comment on 15. SMIL 3.0 State:

> 10.  Section 15.6.6 namespace terminology
>
> The phrase "Rationale: Raising the stateChange event on the state
> element
> instead of on the data model element itself allows for external data
> models
> (which have a distinct xmlid namespace) and on non-XML data models
> (depending on the expression language)." refers to distinct xmlid
> *namespaces* when probably what is meant are distinct xmlid *spaces*.
> Seems not to be a namespace issue rather one of allowing for distinct
> XML
> documents each of which would have its own space for IDs.


Working Group Resolution (LC-1846):
We will change the paragraph as suggested.

No further Forms comments.

----

Your comment on 15. SMIL 3.0 State:

> 15. Synchronous or asynchronous submission?
>
> Is submission synchronous in SMIL 3.0 as in XForms 1.0?  If so, what is
> the
> behavior of the main timing control cycle during submission -- is there
> the
> potential for blocking user or other interaction/presentation
> unacceptably
> while waiting for a response to a submission?  What is the behavior of
> submission notification events relative to the execution of normal
> SMIL
> timing behavior, e.g. are submission events queued for execution and if
> so
> with what relationship to other SMIL processing?


Working Group Resolution (LC-1851):
Submission is synchronous, as in XForms 1.0. Because SMIL has its own
timing model this does not present the same problems as in HTML: by
placing the <submit> in a <par> right
at the root of the document an author can get fully asynchronous
behaviour. Think of this as similar to starting an extra thread in a
normal programming language.

In addition, by selecting a different location for the <submit> an author
can also get fork/join behaviour. We feel this obviates the need for
submission notification events. We will add an example of this usage
pattern.

Forms comments: doesn't SMIL have a particular need for async submission
given the need to maintain responsiveness to the user in the midst of a
timed multimedia interaction?  Would the fork/join case handles this
scenario?

Further, does submission in SMIL allow for pre and post processing of
submission perhaps via an appropriate set of submission related events?

Finally, is there a need for control over submission serialization or is
this future requirement?  Would this perhaps be accomplished by adopting
more of xforms submission in the future?


----


Reply | Threaded
Open this post in threaded view
|

Re: XForms WG comments on SMIL 3.0 LCWD

Thierry Michel

Charles,


Following our joint F2F XForms and SYMM WG, I beleive we have resolved
all issues.
Could you please reply that you agree with all the SYMM WG responses to
your SMIL 3.0 LC comments

# LC-1844 XForms-8, Charles F Wiecha , 15. SMIL 3.0 State, question,
# LC-1845 XForms-9, Charles F Wiecha , 15. SMIL 3.0 State, question,
# LC-1847 XForms-11, Charles F Wiecha , 15. SMIL 3.0 State, question,
# LC-1851 XForms-15, Charles F Wiecha , 15. SMIL 3.0 State, question,
# LC-1837 XForms -1, Charles F Wiecha , 15. SMIL 3.0 State, general
# LC-1840 XForms-4, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1841 XForms-5, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1848 XForms-12, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1849 XForms-13, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1850 XForms-14, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1838 XForms-2, Charles F Wiecha , 15. SMIL 3.0 State, editorial,
# LC-1839 XForms-3, Charles F Wiecha , 15. SMIL 3.0 State, editorial,
# LC-1842 XForms-6, Charles F Wiecha , 15. SMIL 3.0 State, editorial,
# LC-1843 XForms-7, Charles F Wiecha , 15. SMIL 3.0 State, editorial,
# LC-1846 XForms-10, Charles F Wiecha , 15. SMIL 3.0 State, editorial,


Thank you.


  F Wiecha wrote:

> For the Forms WG, thank you for your response to our earlier comments on
> the SMIL 3.0 LCWD.  As background for our F2F meeting later today, here are
> the remaining questions which we would like to discuss.  Thanks, Charlie
> Wiecha
>
> =====
>
> Your comment on 15. SMIL 3.0 State:
>> 8. Additional event required for data model deletion?
>>
>> If delete is in fact supported as mentioned above, will another event
>> be
>> required to notify authors on deletion?  If so what notation will be
>> used
>> to refer to the deleted node since it no longer exists?
>
>
> Working Group Resolution (LC-1844):
> For SMIL 3.0 we decided not to add a notification for the deletion of
> nodes, for reasons of simplicity. If applications require this
> functionality they can always incorporate the full XForms data model
> through an xml namespace.
>
> Forms comments: how would authors receive notification if nodes are
> deleted?  Given the case where there is no full XForms data model, nodes
> can still be deleted without any notification.  However, nodes when
> inserted generate events, it is not clear to us why there is not parallel
> function for the delete case.
>
> The SYMM group has decided to add delete action, but not the corresponding
> event.  So, for example, why are events supported on inserting?  It seems
> that they're either important/useful or not to the author.
>
> In XForms, for example, index management in the repeat module is now in
> terms of listening for insert/delete events.  Both are required... we're
> not sure SMIL has equivalent constructs to repeat, but for us we need both
> to properly manage anything operating over the data model.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 4. Missing delete action?
>>
>> We note the use of newvalue to create a new entry in the data
>> model...is
>> delete also supported?  Once created, are data model entries able to
>> be
>> deleted by other means?
>
>
> Working Group Resolution (LC-1840):
> Omitting delete was an oversight. We will add it.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 5. How is the position for new data model entries determined?
>>
>> The "ref" attribute is used to specify the position of new entries in
>> the
>> data model, as described in Section 15.6.3: "Therefore, name is used
>> to
>> give the name for the new item and ref specifies where it is
>> inserted."
>> Where is the new entry created relative to the entry given in "ref" --
>> as a
>> child element, and if so where in the possibly existing set of
>> children.
>> If as a sibling, before or after the ref'd item?
>>
>> Does the SMIL 3.0 data model have the notion of order as in XML or
>> not,
>> perhaps depending again on the language profile used (some
>> environments
>> such as ECMAScript or Servlet attributes may not support the notion of
>> document order)?
>
>
> Working Group Resolution (LC-1841):
> We will add an attribute to allow specifying the position of the new
> element.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 13. Support for replace=instance on submission
>>
>> It appears that only a single state element is allowed in SMIL 3.0.
>> If
>> this is the case, is replace=instance also supported on submission?  If
>> so,
>> then only the single, original "instance" in the state element could
>> be
>> targeted -- making some use cases difficult.  A common use case is to
>> query
>> for data that is dependent on some values first obtained from the user
>> (for
>> example a US state) then to return the list of valid city names in
>> that
>> state in a second instance.  Lacking support for multiple state
>> elements
>> this pattern would be difficult.  XForms 1.1 does allow targeting
>> subtrees
>> of an instance hence the author could partition the single data model
>> to
>> support this pattern by convention, albeit with more difficulty than
>> if
>> multiple state elements are supported.
>
>
> Working Group Resolution (LC-1849):
> We have picked up the target attribute from XForms 1.1 submission.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 3. Are attributes supported in the SMIL 3.0 data model?
>>
>> We don't see examples where attributes are used or supported in the
>> SMIL
>> 3.0 data model -- for example in the setvalue action.  Please clarify
>> whether SMIL 3.0 supports only elements or attributes as well.  If
>> attributes are supported, will a setvalue that references a
>> non-existent
>> attribute also create that attribute as it does in XForms?
>
>
> Working Group Resolution (LC-1839):
> The examples were picked to be as simple as possible, as to be easily
> translated to other data model languages than XPath. That said, the
> expressions and lvalues allowed are completely governed by that language,
> so setting attributes with XPath is definitely allowed, as is, for
> example, accessing complex datastructures if Python is used as the data
> model language. We will add an informative note to that effect.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 6. Section 15.6.5 additional data model examples would be quite useful.
>>
>> Additional examples in this section could be provided to clarify some
>> of
>> the questions raised above -- e.g. the support for attributes, insert
>> position, whether delete is supported etc.
>
>
> Working Group Resolution (LC-1842):
> We will add some more examples.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 7. In Section 15.6.6 do we assume XML/DOM event processing?
>>
>> It is not clear whether the events listed, stateChange and
>> contentControlChange, follow DOM/XML event processing including
>> bubble/capture processing etc.
>
>
> Working Group Resolution (LC-1843):
> The section has been updated to state that no these events don't bubble. A
> similar change has been made to the normative section in the SMIL Language
> Profile.
>
> Forms comments: We see there is no bubble phase, but do they have a capture
> phase? Could you please clarify if SMIL is using is this some level of DOM
> eventing or another processing model?
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 9. Multiple contentControlChange events dispatched?
>>
>> There are two signatures for the contentControlChange event, one that
>> fires
>> on any change and the other that indicates a specific change.  Will
>> application authors in general receive both events for each change?
>>
>
>
> Working Group Resolution (LC-1845):
> Yes, both events fire. We have clarified this both the the referenced
> (non-normative) section and in the normative text in the SMIL Language
> Profile.
>
> Forms comments: we remain concerned about the approach of firing both
> contentControlChange events, could you please clarify the need for doing
> this?  Question which arise include: which comes first?  Is there the
> potential for the 2nd event to be invalidated by some aspect of handling
> the first?  For example, we've had similar problems where as you're firing
> events want to fire two that are related to the same activity: what happens
> if you dispatch first one, its action handler makes 2nd event stale...no
> longer relevant?  Does this case perhaps not apply to SMIL?
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 10.  Section 15.6.6 namespace terminology
>>
>> The phrase "Rationale: Raising the stateChange event on the state
>> element
>> instead of on the data model element itself allows for external data
>> models
>> (which have a distinct xmlid namespace) and on non-XML data models
>> (depending on the expression language)." refers to distinct xmlid
>> *namespaces* when probably what is meant are distinct xmlid *spaces*.
>> Seems not to be a namespace issue rather one of allowing for distinct
>> XML
>> documents each of which would have its own space for IDs.
>
>
> Working Group Resolution (LC-1846):
> We will change the paragraph as suggested.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 15. Synchronous or asynchronous submission?
>>
>> Is submission synchronous in SMIL 3.0 as in XForms 1.0?  If so, what is
>> the
>> behavior of the main timing control cycle during submission -- is there
>> the
>> potential for blocking user or other interaction/presentation
>> unacceptably
>> while waiting for a response to a submission?  What is the behavior of
>> submission notification events relative to the execution of normal
>> SMIL
>> timing behavior, e.g. are submission events queued for execution and if
>> so
>> with what relationship to other SMIL processing?
>
>
> Working Group Resolution (LC-1851):
> Submission is synchronous, as in XForms 1.0. Because SMIL has its own
> timing model this does not present the same problems as in HTML: by
> placing the <submit> in a <par> right
> at the root of the document an author can get fully asynchronous
> behaviour. Think of this as similar to starting an extra thread in a
> normal programming language.
>
> In addition, by selecting a different location for the <submit> an author
> can also get fork/join behaviour. We feel this obviates the need for
> submission notification events. We will add an example of this usage
> pattern.
>
> Forms comments: doesn't SMIL have a particular need for async submission
> given the need to maintain responsiveness to the user in the midst of a
> timed multimedia interaction?  Would the fork/join case handles this
> scenario?
>
> Further, does submission in SMIL allow for pre and post processing of
> submission perhaps via an appropriate set of submission related events?
>
> Finally, is there a need for control over submission serialization or is
> this future requirement?  Would this perhaps be accomplished by adopting
> more of xforms submission in the future?
>
>
> ----
>


Reply | Threaded
Open this post in threaded view
|

Re: XForms WG comments on SMIL 3.0 LCWD

Charles F Wiecha

Thierry -- for the Forms WG, this is to acknowledge that we accept the
resolution of all of our comments on the SMIL 3.0 LC working draft, as
discussed during our joint F2F last week.

Thanks, Charlie Wiecha



                                                                                 
                                                                                 
                                                                                 
         Re: XForms WG comments on SMIL 3.0 LCWD                                  
                                                                                 
                                                                                 
         Thierry Michel                                                          
                      to:                                                        
                        Charles F Wiecha                                          
                                                                                1
                                                                                1
                                                                                /
                                                                                1
                                                                                3
                                                                                /
                                                                                0
                                                                                7
                                                                                0
                                                                                9
                                                                                :
                                                                                0
                                                                                2
                                                                                A
                                                                                M
                                                                                 
                                                                                 
                                                                                 
                                                                                 
         Cc:                                                                      
            public-forms, www-smil                                                
                                                                                 
                                                                                 
                                                                                 
                                                                                 






Charles,


Following our joint F2F XForms and SYMM WG, I beleive we have resolved
all issues.
Could you please reply that you agree with all the SYMM WG responses to
your SMIL 3.0 LC comments

# LC-1844 XForms-8, Charles F Wiecha , 15. SMIL 3.0 State, question,
# LC-1845 XForms-9, Charles F Wiecha , 15. SMIL 3.0 State, question,
# LC-1847 XForms-11, Charles F Wiecha , 15. SMIL 3.0 State, question,
# LC-1851 XForms-15, Charles F Wiecha , 15. SMIL 3.0 State, question,
# LC-1837 XForms -1, Charles F Wiecha , 15. SMIL 3.0 State, general
# LC-1840 XForms-4, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1841 XForms-5, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1848 XForms-12, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1849 XForms-13, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1850 XForms-14, Charles F Wiecha , 15. SMIL 3.0 State, substantive,
# LC-1838 XForms-2, Charles F Wiecha , 15. SMIL 3.0 State, editorial,
# LC-1839 XForms-3, Charles F Wiecha , 15. SMIL 3.0 State, editorial,
# LC-1842 XForms-6, Charles F Wiecha , 15. SMIL 3.0 State, editorial,
# LC-1843 XForms-7, Charles F Wiecha , 15. SMIL 3.0 State, editorial,
# LC-1846 XForms-10, Charles F Wiecha , 15. SMIL 3.0 State, editorial,


Thank you.


  F Wiecha wrote:
> For the Forms WG, thank you for your response to our earlier comments on
> the SMIL 3.0 LCWD.  As background for our F2F meeting later today, here
are

> the remaining questions which we would like to discuss.  Thanks, Charlie
> Wiecha
>
> =====
>
> Your comment on 15. SMIL 3.0 State:
>> 8. Additional event required for data model deletion?
>>
>> If delete is in fact supported as mentioned above, will another event
>> be
>> required to notify authors on deletion?  If so what notation will be
>> used
>> to refer to the deleted node since it no longer exists?
>
>
> Working Group Resolution (LC-1844):
> For SMIL 3.0 we decided not to add a notification for the deletion of
> nodes, for reasons of simplicity. If applications require this
> functionality they can always incorporate the full XForms data model
> through an xml namespace.
>
> Forms comments: how would authors receive notification if nodes are
> deleted?  Given the case where there is no full XForms data model, nodes
> can still be deleted without any notification.  However, nodes when
> inserted generate events, it is not clear to us why there is not parallel
> function for the delete case.
>
> The SYMM group has decided to add delete action, but not the
corresponding
> event.  So, for example, why are events supported on inserting?  It seems
> that they're either important/useful or not to the author.
>
> In XForms, for example, index management in the repeat module is now in
> terms of listening for insert/delete events.  Both are required... we're
> not sure SMIL has equivalent constructs to repeat, but for us we need
both

> to properly manage anything operating over the data model.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 4. Missing delete action?
>>
>> We note the use of newvalue to create a new entry in the data
>> model...is
>> delete also supported?  Once created, are data model entries able to
>> be
>> deleted by other means?
>
>
> Working Group Resolution (LC-1840):
> Omitting delete was an oversight. We will add it.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 5. How is the position for new data model entries determined?
>>
>> The "ref" attribute is used to specify the position of new entries in
>> the
>> data model, as described in Section 15.6.3: "Therefore, name is used
>> to
>> give the name for the new item and ref specifies where it is
>> inserted."
>> Where is the new entry created relative to the entry given in "ref" --
>> as a
>> child element, and if so where in the possibly existing set of
>> children.
>> If as a sibling, before or after the ref'd item?
>>
>> Does the SMIL 3.0 data model have the notion of order as in XML or
>> not,
>> perhaps depending again on the language profile used (some
>> environments
>> such as ECMAScript or Servlet attributes may not support the notion of
>> document order)?
>
>
> Working Group Resolution (LC-1841):
> We will add an attribute to allow specifying the position of the new
> element.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 13. Support for replace=instance on submission
>>
>> It appears that only a single state element is allowed in SMIL 3.0.
>> If
>> this is the case, is replace=instance also supported on submission?  If
>> so,
>> then only the single, original "instance" in the state element could
>> be
>> targeted -- making some use cases difficult.  A common use case is to
>> query
>> for data that is dependent on some values first obtained from the user
>> (for
>> example a US state) then to return the list of valid city names in
>> that
>> state in a second instance.  Lacking support for multiple state
>> elements
>> this pattern would be difficult.  XForms 1.1 does allow targeting
>> subtrees
>> of an instance hence the author could partition the single data model
>> to
>> support this pattern by convention, albeit with more difficulty than
>> if
>> multiple state elements are supported.
>
>
> Working Group Resolution (LC-1849):
> We have picked up the target attribute from XForms 1.1 submission.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 3. Are attributes supported in the SMIL 3.0 data model?
>>
>> We don't see examples where attributes are used or supported in the
>> SMIL
>> 3.0 data model -- for example in the setvalue action.  Please clarify
>> whether SMIL 3.0 supports only elements or attributes as well.  If
>> attributes are supported, will a setvalue that references a
>> non-existent
>> attribute also create that attribute as it does in XForms?
>
>
> Working Group Resolution (LC-1839):
> The examples were picked to be as simple as possible, as to be easily
> translated to other data model languages than XPath. That said, the
> expressions and lvalues allowed are completely governed by that language,
> so setting attributes with XPath is definitely allowed, as is, for
> example, accessing complex datastructures if Python is used as the data
> model language. We will add an informative note to that effect.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 6. Section 15.6.5 additional data model examples would be quite useful.
>>
>> Additional examples in this section could be provided to clarify some
>> of
>> the questions raised above -- e.g. the support for attributes, insert
>> position, whether delete is supported etc.
>
>
> Working Group Resolution (LC-1842):
> We will add some more examples.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 7. In Section 15.6.6 do we assume XML/DOM event processing?
>>
>> It is not clear whether the events listed, stateChange and
>> contentControlChange, follow DOM/XML event processing including
>> bubble/capture processing etc.
>
>
> Working Group Resolution (LC-1843):
> The section has been updated to state that no these events don't bubble.
A
> similar change has been made to the normative section in the SMIL
Language
> Profile.
>
> Forms comments: We see there is no bubble phase, but do they have a
capture
> phase? Could you please clarify if SMIL is using is this some level of
DOM

> eventing or another processing model?
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 9. Multiple contentControlChange events dispatched?
>>
>> There are two signatures for the contentControlChange event, one that
>> fires
>> on any change and the other that indicates a specific change.  Will
>> application authors in general receive both events for each change?
>>
>
>
> Working Group Resolution (LC-1845):
> Yes, both events fire. We have clarified this both the the referenced
> (non-normative) section and in the normative text in the SMIL Language
> Profile.
>
> Forms comments: we remain concerned about the approach of firing both
> contentControlChange events, could you please clarify the need for doing
> this?  Question which arise include: which comes first?  Is there the
> potential for the 2nd event to be invalidated by some aspect of handling
> the first?  For example, we've had similar problems where as you're
firing
> events want to fire two that are related to the same activity: what
happens

> if you dispatch first one, its action handler makes 2nd event stale...no
> longer relevant?  Does this case perhaps not apply to SMIL?
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 10.  Section 15.6.6 namespace terminology
>>
>> The phrase "Rationale: Raising the stateChange event on the state
>> element
>> instead of on the data model element itself allows for external data
>> models
>> (which have a distinct xmlid namespace) and on non-XML data models
>> (depending on the expression language)." refers to distinct xmlid
>> *namespaces* when probably what is meant are distinct xmlid *spaces*.
>> Seems not to be a namespace issue rather one of allowing for distinct
>> XML
>> documents each of which would have its own space for IDs.
>
>
> Working Group Resolution (LC-1846):
> We will change the paragraph as suggested.
>
> No further Forms comments.
>
> ----
>
> Your comment on 15. SMIL 3.0 State:
>> 15. Synchronous or asynchronous submission?
>>
>> Is submission synchronous in SMIL 3.0 as in XForms 1.0?  If so, what is
>> the
>> behavior of the main timing control cycle during submission -- is there
>> the
>> potential for blocking user or other interaction/presentation
>> unacceptably
>> while waiting for a response to a submission?  What is the behavior of
>> submission notification events relative to the execution of normal
>> SMIL
>> timing behavior, e.g. are submission events queued for execution and if
>> so
>> with what relationship to other SMIL processing?
>
>
> Working Group Resolution (LC-1851):
> Submission is synchronous, as in XForms 1.0. Because SMIL has its own
> timing model this does not present the same problems as in HTML: by
> placing the <submit> in a <par> right
> at the root of the document an author can get fully asynchronous
> behaviour. Think of this as similar to starting an extra thread in a
> normal programming language.
>
> In addition, by selecting a different location for the <submit> an author
> can also get fork/join behaviour. We feel this obviates the need for
> submission notification events. We will add an example of this usage
> pattern.
>
> Forms comments: doesn't SMIL have a particular need for async submission
> given the need to maintain responsiveness to the user in the midst of a
> timed multimedia interaction?  Would the fork/join case handles this
> scenario?
>
> Further, does submission in SMIL allow for pre and post processing of
> submission perhaps via an appropriate set of submission related events?
>
> Finally, is there a need for control over submission serialization or is
> this future requirement?  Would this perhaps be accomplished by adopting
> more of xforms submission in the future?
>
>
> ----
>