Re: XForms WG comments on SMIL 3.0 LCWD

 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 www-smil@w3.org 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@us.ibm.com
 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.

----

Received on Wednesday, 24 October 2007 13:21:31 UTC