W3C home > Mailing lists > Public > www-forms-editor@w3.org > July 2002

RE: 48- Response to your issue sent to the XForms WG about the XForms Last Call WD

From: Plechsmíd Martin <Martin.Plechsmid@merlin.cz>
Date: Wed, 3 Jul 2002 19:18:57 +0200
Message-ID: <E50028F23FC6D3118B7D00609761083F01D40FE9@merkur.merlin.cz>
To: "'Thierry Michel'" <tmichel@w3.org>
Cc: www-forms-editor@w3.org

My comments are inserted in the text below.

> -----Pùvodní zpráva-----
> Od: Thierry Michel [mailto:tmichel@w3.org]
> Odesláno: 3. èervence 2002 17:36
> Komu: Martin.Plechsmid@merlin.cz
> Kopie: www-forms-editor@w3.org
> Pøedmìt: 48- Response to your issue sent to the XForms WG about the
> XForms Last Call WD
> Plechsmíd Martin,
> Your issue sent to the W3C XForms WG about the XForms Last 
> Call Working
> draft
> http://www.w3.org/TR/2002/WD-xforms-20020118/
> Your issue is archived at
> http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0068.html
> XForms WG Resolution:
> 1. Agree
> 2. Agree
> 3. No. We have the readonly functionality in the model. 
> Caption on output
> may help. This is purely presentational issue and can be 
> achieved with CSS.

OK. We're not using it yet, but still consider it as an issue. 

The model and the UI layers are currently tied too much together. They
should be controlable almost independently, though the implicit behaviour
may stay as is now. 
I think I sent a letter to the XForms mail list where I tried to explain
this point of view in more detail. If interested, I can explain it in even
more detail. If the layers are not clearly separated in the first version of
the XForms specification this will cause troubles when increasing the
version number.

Our implementation:
We currently implement this (and similarly the "relevant" attribute) as
follows: the form control is readOnly (resp. not relevant) if either the
tied data instance or the form control itself is marked as readOnly (resp.
not relevant). The "relevant" attribute on UI controls we found very useful,
and I cannot immagine how we would do without it.

> 4. No. This is for calculations in the UI. You do the 
> calculation in the
> model on temporaries and bind to those.


Our experience shows that using temporaries is TOO MUCH complicated - and
XForms are to simplify work of form authors, not complicate it. Using
temporaries makes even relatively simple forms almost unmanageable.

Our implementation:
We finally solved it a little differently. On XForms elements that do not
update instance data (like xf:output or xf:caption) we allow the "value"
attribute with the same semantics as on the xf:setValue element - that is
containing an arbitrary XPath expression.

> 5. Agree.
> 6. We agree that this is a problem. We will address the 
> problem, but not
> necessarily using this solution.

We really need to have this problem solved. We had several ideas, but none
was satisfactory, neither our current implementation.

Keep in mind, that exchange of a single XML document between client and
server is often not sufficient. A form needs to show various information at
once, e.g. some information from the user contract + a partial transaction
list + last filtering condition enetered by the user.

> 7. The effect is achievable in the following ways: toggle and relevant
> [[give examples]].

Yes and No. We can live with this solution, but the proposed solution is not

In fact, we consider the xf:switch and the xf:toggle elements
misconceptional and we suggest to remove them completely from the specs. The
xf:switch element is singular in that it is not driven by changes in the
instance data (as all the other UI controls), but it is driven by events in
other parts of the UI instead (e.g. by a click).

Our implementation:
We allow the "relevant" attribute on various UI controls, esp. on the
xf:group element, which completely replaces the xf:switch functionality in
the desired way. We find it very useful and complementary to the "relevant"
constraints put on instance data.

> 8. We agree that it is an issue, but we cannot fix it in this way for
> technical reasons [[explain]]; can you live with this decision?

OK. We don't use xf:insert anywhere, yet. But this issue should be solved.

A pretty long time have past since the Working Draft's Last Call. Since then
I've sent several other ideas into the XForms mail-list, answered mostly by
Micah Dubinko. Have the issues in these letters been reflected by the
Working Group as well, or have they been ignored (because they were sent
after the Last Call deadline)? Thank you.

Best regards,
		Martin Plechsmid.
Received on Wednesday, 3 July 2002 13:18:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:04 UTC