Re: XForms WG comments on SMIL 3.0 LCWD

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: boyerj@ca.ibm.com 

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





Charles F Wiecha <wiecha@us.ibm.com> 
Sent by: public-forms-request@w3.org
09/19/2007 11:54 AM

To
www-smil@w3.org
cc
Jack Jansen <Jack.Jansen@cwi.nl>, <public-forms@w3.org>
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
wiecha@us.ibm.com