W3C home > Mailing lists > Public > www-forms@w3.org > November 2005

Re: @number attribute on xforms:repeat

From: T.V Raman <raman@google.com>
Date: Mon, 28 Nov 2005 09:27:53 -0800
Message-ID: <17291.15897.785790.95678@retriever.corp.google.com>
To: erik@bruchez.org
Cc: www-forms@w3.org


Eric,
But since an xforms+xhtml instance might be run on different
screen sizes and different device form factors, number on
xf:repeat will still have to remain a hint at best.

The design intent behind  this hint was that it allowed the
author to state a preference for the number of items that would
be displayed.

As far as interoperability goes, XForms was never intended to
display the same form *identically* in different environments, in
fact the contrary. 
Given its intent-based authoring focus, interoperability amongst
XForms user agents means you get the "same answer" when you fill
out the form independent of implementation --- but that "answer"
does not include visual appearance (or for that matter auditory
appearance).

XForms among 

>>>>> "Erik" == Erik Bruchez <erik@bruchez.org> writes:
    Erik> Mark Birbeck wrote:
    >> It is a hint, and as such can rightly be ignored.
    >> 
    >> Just in terms of why it's a hint, the problem is more the
    >> other way round; how would we come up with a
    >> cross-platform, device-independent way of defining
    >> @number? Obviously we could say that it is used to
    >> indicate how many 'rows' of a xf:repeat are rendered, but
    >> then is a photocopier or a fax machine non-conformant if
    >> it can only show one row at a time?
    Erik> 
    Erik> I agree with this. But now I can reformulate my
    Erik> question for XForms engine with HTML or XHTML as host
    Erik> language, since this is my main focus. In this case,
    Erik> there should be agreement among XForms engines
    Erik> implementors as to what the desired behavior should be.
    Erik> 
    >> At one time I was keen for at least number="1" to have
    >> mandated behaviour (i.e., the device could process any
    >> other values of @number as best they could, but '1' should
    >> always only show one iteration), since that makes
    >> wizard-style forms really easy to write, safe in the
    >> knowledge that they will be the same on all devices. But
    >> even with that we found that there were other ways to do
    >> it, and so the enthusiasm for mandating that waned!
    Erik> 
    Erik> Understandable.
    Erik> 
    >> Finally, on the specific questions raised in this thread:
    >> no, @number doesn't affect index() or setindex
    Erik> 
    Erik> Makes perfect sense to me.
    Erik> 
    >> and no, it can't be used for things like paging. The
    >> latter needs to be set up by the form author (there are a
    >> number of examples on our site).
    Erik> 
    Erik> We have also done paging using other means, but why
    Erik> couldn't @number be used for such a purpose? I would
    Erik> argue that this would be a great use of this
    Erik> attribute. If I put together these two sentences from
    Erik> the spec:
    Erik> 
    Erik>    "number - Optional hint to the XForms Processor as
    Erik> to how many elements from the collection to display."
    Erik> 
    Erik> and:
    Erik> 
    Erik>    "Attributes on this element specify how many members
    Erik> of the collection are presented to the user at any
    Erik> given time."
    Erik> 
    Erik> This rings to me such words as "scrolling" or "paging",
    Erik> hence my original question as to what people's
    Erik> interpretation is. Certainly, it doesn't seem like the
    Erik> spec precludes an XForms engine to implement scrolling
    Erik> or paging of repeated sections based on this attribute.
    Erik> 
    Erik> -Erik
    Erik> 

-- 
-- T. V. Raman 
Received on Monday, 28 November 2005 17:29:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:02 GMT