Re: XForms WG comments on SMIL 3.0 LCWD

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?
> 
> 
> ----
>

Received on Tuesday, 13 November 2007 13:55:13 UTC