Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Leigh Klotz, Xerox (minutes)
Uli Lissé, DreamLab
Nick van: Are we going to be as
compatible as possible with XPath 1.0 or be as friendly as possible
to XPath 2.0?
Nick van: What do we do if the context
is empty? In XPath 1.0, it means expressions cannot be evaluated
and relevance means that form controls are disabled.
Erik Bruchez: I have some doubt about
context item formally allowed to be empty. Perhaps that is only in
Saxon.
John Boyer: That's not really specific
to groups; any control behaves as not relevant if the UI doesn't
bind to anything. If you can't evaluate the XPath expression that's
the degenerate case. The absence of a context node means you can't
run the XPath and so degenerately it doesn't bind to anything. If
the XPath returns an empty nodeset, in XPath 2.0 I'd still expect
that would work. Even without a context node, if you ruin the
expression and it's empty nodeset, that still gives non-relevant
behavior.
Nick van: That's also what I
think.
Leigh Klotz: How can you get an empty
context concretely?
John Boyer: Using a predicate.
Leigh Klotz: How can it arise in
XForms, though?
Erik Bruchez: If you style the
non-relevant group contents to display, as we said a couple of days
ago, would the binding still apply and the value display?
John Boyer: Even in XForms 1.0 we have
the styling issue because a group can become non-relevant by
binding to a node whose MIP is relevant=false.
Erik Bruchez: ...
John Boyer: We could get rid of that
feature. But we do have it and if we make this choice we're
eliminating that feature.
Erik Bruchez: I think it would be
better to find a more consistent way to obtain the feature, in a
more author-friendly way, perhaps using readonly, or something else
more explicit.
John Boyer: I think styling
non-relevant things as visible but disabled seems non-sensical. If
it's not relevant but you can see it, how is it not relevant?
Erik Bruchez: As Steven put it, it
doesn't belong to the form anymore.
John Boyer: We had these cases where
people don't want something to disappear, but we want it grayed
out.
Steven Pemberton: In menu systems,
entries are grayed out.
Leigh Klotz: Some
John Boyer: It could be non-relevant
or it could be disabled.
Leigh Klotz: We had greyed-out menu
items that had a hint showing why there were disabled.
Steven Pemberton: I think it's the
same thing.
Erik Bruchez: Being there is different
from not being there.
John Boyer: This is a comment about
menu items; data relevance is about data nodes whose values we
intend to collect.
Leigh Klotz: Yes, we don't say what
relevance means to itemset nodes. We've also seen the same hack
with trigger and readonly.
Erik Bruchez: Yes, we got some
pushback for doing that. If it's confusing for us, imagine form
authors! We need to shift the balance from being abstract to
hidden/readonly/visible-relevance for our sanity and for form
authors, and for interoperability.
Steven Pemberton: I don't agree, I'm
afraid. I think there's a to say in some situations items disappear
and in some situations they are greyed out. I'm not sure about
worrying about the updates of grayed-out things.
Erik Bruchez: Some implementations
want to show values for non-relevant sections, but if the values
don't update, users will think it's a bug. On the other hand, we
make it hard to optimize out the other pages or cases.
Steven Pemberton: In our system, if it
was visible, we did it, and if it wasn't we didn't.
Nick van: XForms is independent in
principle of the host language, which drives visibility. So you'd
have to fully support, say, CSS.
Steven Pemberton: So there may be no
feedback from the CSS.
Nick van: Server-based systems might
not.
Erik Bruchez: You need feedback from
the UI layer to tell you whether to compute it.
Leigh Klotz: CSS also has both show
and visible, meaning different things.
John Boyer: The most basic atomic
case is a node (name) with a value ("A") and a relevance bind, and
xf:input ref="name" and a CSS rules that says to show as disabled,
do you expect to see A in the input?
Leigh Klotz: Ignoring the name of the
CSS property you use to obtain that, that to me says you want it
readonly.
John Boyer: Never mind if the value
changes; for the first time, the form says relevant=false(), do you
expect the UI control to show you the value in the name
element?
Charlie Wiecha: I would hope
not.
Erik Bruchez: It seems clear to
me.
John Boyer: That is the same way as
saying that there's no way to style non-relevant controls as
disabled.
Charlie Wiecha: That what I got from
the discussion two days ago.
Erik Bruchez: It's all based on the
notion of relevance; it up to anybody to figure out what it
means?
John Boyer: irrelevant means ...
Steven Pemberton: If I'm paying for
something and the system reads my info, it may still have my credit
card info but if I pay cash it's not relevant. It doesn't mean the
data isn't there. It's not readonly.
Erik Bruchez: You might not see
it.
Steven Pemberton: If my bank data has
all my details, I'm not convinced that we have to force
applications to say that we can't show it.
Erik Bruchez: Say readonly.
Steven Pemberton: But it's not
readonly.
John Boyer: If the form author has not
relevant but must show to user, then the form author has made two
contradictory decisions.
Steven Pemberton: It's not right. I
don't see how we say that. It's not relevant because it's not used
for that payment.
John Boyer: If the form author has to
show it, it's relevant.
Steven Pemberton: Don't flicker the
screen; grey out the data.
John Boyer: So just don't show the
data.
Steven Pemberton: That works for
me.
John Boyer: But outputs won't show. So
maybe it won't work.
Steven Pemberton: We should cover
these use cases.
Erik Bruchez: We are taking one word
and trying to interpret it. Users use relevance to hide things now,
in groups of forms. I can't show it because there is no xpath
evaluation context. On the other hand use cases call for showing it
sometimes.
Nick van: We talked about model vs UI
readonly. Now we have maybe the same thing for relevant.
Leigh Klotz: That's why I proposed
prune.
Erik Bruchez: It's never been clear
what relevance means.
Steven Pemberton: So we need to
improve the UI part and make it possible to hide without
relevance.
John Boyer: Relevance of the form
control instead of relevance of the data.
Steven Pemberton: If a control becomes
non-relevant because the data is non-relevant, that's our
relevance. But if it's because there's no context, that's
different. That's our confusion.
John Boyer: That's not the only
confusion.
Steven Pemberton: XPath 2.0?
Erik Bruchez: We can't agree what
relevance means.
Steven Pemberton: We've confused
ourselves.
Leigh Klotz: There's actually
three...
John Boyer: Let's ignore the empty
nodeset trick and discuss only relevant MIP. They're different. But
even if we called that something else, you still have the problem
that a piece of data is not relevant but then we claim you can
style that as shown.
Steven Pemberton: The data doesn't go
away. Binding to a non-existent thing means there is nothing to
show. It is very different.
John Boyer: It feels more like
non-relevance.
Steven Pemberton: We've exposed this;
I don't think it's related. I agree with the use case of
controlling existence of controls by data existence but I don't
want that to call that relevance.
Charlie Wiecha: By analogy with
repeat.
Erik Bruchez: In my example with 20
pages and one visible: is that relevance?
Steven Pemberton: No.
Erik Bruchez: You want all the data
but control visibility.
Steven Pemberton: repeat rows that
don't bind disappear. Group is the same concept.
Charlie Wiecha: They're statically in
the DOM, but we emulate it.
John Boyer: We called bind with
relevant model-based switching.
Leigh Klotz: We asked for model-based
switching in our requirements document; we added on Roland
Merrick's suggestion that non-existent nodes would be not-shown
instead of an error, and then we added that group relevance
inherited downward, and one day we decided that fulfilled
model-based switching.
Steven Pemberton: We went wrong
there.
Erik Bruchez: If we have two separate
concepts. You can style them separately.
Leigh Klotz: A new MIP or a new
control property?
Erik Bruchez: A new concept.
Charlie Wiecha: We now have
informal rules for repeat templates; if we had the entire document
as a template, we could do the creation there like for repeat
items.
Erik Bruchez: xf:input is markup, not
a control.
Charlie Wiecha: We never said that was
separate. In Ubiquity, the object is the elaborated xf:input.
Leigh Klotz: And in PicoForms, there
is a shadow DOM but I don't think there is a different turtle under
xf:input.
Charlie Wiecha: This new MIP would
affect that part of the lifecycle.
Erik Bruchez: It's like div with
display:none which you can change with JavaScript. It's still
there.
Steven Pemberton: It has to be
there.
John Boyer: How we get from there to a
second MIP?
Steven Pemberton: We haven't concluded
it.
Erik Bruchez: What would it take to
have a new notion "visible"?
Charlie Wiecha: Is it a MIP or a
control property?
Erik Bruchez: Instead of .[]
Leigh Klotz: Just put @if on
controls.
Erik Bruchez: I don't like it. Maybe
@visible
Charlie Wiecha: Or is it data?
John Boyer: The property needs to be
decided based on data. It is reasonable to use a bind.
Erik Bruchez: It's a boolean.
Leigh Klotz: If CSS worked we'd not be
having this discussion. Mozilla puts run-time attributes
representing type of bound node, for example, and you can style
based on those.
Erik Bruchez: But we need a deeper
concept so we can optimize it, at least in my implementation.
Steven Pemberton: Maybe we need to get
switch right.
Erik Bruchez: It's heavy-handed. A
single attribute is easier.
Leigh Klotz: So it's not switch but
case we're after.
Steven Pemberton: input case="..." and
group case="..."
Erik Bruchez: I'd call it
visible.
Leigh Klotz: You want something
deeper, you said.
Steven Pemberton: Also for A11Y.
Erik Bruchez: Then enabled. But HTML
means something else. But it might conflict. disabled means grayed
out in HTML4.
Leigh Klotz: @valuable?
Erik Bruchez: Out of focus, grayed
out, not in tab order. It's a dead control.
Leigh Klotz: So this is no-space
display at all?
Steven Pemberton: Like switch.
John Boyer: If you you change the
disabled control value does it show the value?
Nick van: Yes.
Leigh Klotz: If you send events to one
of these @case ones, what happens?
Steven Pemberton: It's like switch. It
disables events.
John Boyer: We said that a
non-selected switch case behaves the same as a non-relevant group.
We consolidated all that disabledness/non-visibility under one
concept but now we seem to want two.
Erik Bruchez: We could define it as
visibility and make switch/case use that.
Steven Pemberton: That's what I said,
generalize switch.
Erik Bruchez: If we did that, how can
we go about saying this in XForms 1.2? Is it too big of a
change?
Steven Pemberton: group referencing a
non-existent set of nodes could perform the same way, but you can't
style things that don't exist.
Leigh Klotz: It may be that people are
less interested in styling things that don't exist than things that
are MIP non-relevant.
John Boyer: In the case where I've
used an xpath predicate on a UI binding, I'm interested in making
the control disappear regardless of styling when it exists but is
not relevant.
Erik Bruchez: It makes sense.
John Boyer: For the questionnaires
blog post we see only one of a set, like a switch/case that's data
based. The non-selected cases are simply not there.
Leigh Klotz: I've seen bugs in more
than one XForms implementation where repeat nodeset changes and the
input controls are type-based and the presentation fails to notice
the type changes.
Erik Bruchez: Can we call it
visible?
Steven Pemberton: No. I don't
agree.
Leigh Klotz: presence
Erik Bruchez: existence
Erik Bruchez: It would be stuff bound
to no node as opposed to relevance. It would be the creation and
destruction of the control.
Leigh Klotz: That's why I like
"presence" as in "the control is not present."
Erik Bruchez: Yeah, naming...
Erik Bruchez: We would need to have
control be absent, not present when a control has a binding but
points to a non-empty nodeset, it would have the disabled
property.
Leigh Klotz: It would not have any
properties as it would not be present.
Erik Bruchez: I would still like to
have switch/case that receives events.
John Boyer: You want the multi-tabbed
wizard experience.
Erik Bruchez: And accordion. A
multi-case would be nice.
Nick van: switch and switch1
Leigh Klotz: So data-controlled
switch, multi-case switch, tabbed view, or accordion but no change
in control presence and no change in relevance.
Steven Pemberton: So can we say that
with the group things are invalid?
Erik Bruchez: You can catch
events.
Leigh Klotz: You could display it on
the label of the tabbed view.
Erik Bruchez: ...
Nick van: We will need to change
relevant to some other word. Many implementations don't show
non-relevance. Now we're going to introduce a new concept and force
you to use the new concept.
Erik Bruchez: It's a challenge to
reconcile.
Erik Bruchez: So do we need to
introduce a new concept, presence/absence, or possibly even
visibility?
Steven Pemberton: So one concept is
that everything is disabled and taken out.
Leigh Klotz: Absent.
Steven Pemberton: And the other is not
available to the user.
Nick van: Absence is the
default.
Erik Bruchez: The challenge can be met
with versioning.
Nick van: But users can't use relevant
anymore.
Erik Bruchez: You can hide
non-relevant or show it.
Nick van: But the processor can't
optimize it.
Leigh Klotz: So if you bind to an
empty nodeset, the control would be absent.
Nick van: And not styleable or
visible.
Leigh Klotz: Would you ever be able
to bind something to be absent?
Erik Bruchez: I don't see why not. You
can evaluate bindings and see if it is bound.
Leigh Klotz: So a MIP for
absence?
Steven Pemberton: absence is about
control, not about data.
Leigh Klotz: So we could have
group/@present=xyz, a node.
Erik Bruchez: An expression.
Steven Pemberton: We absent,
unavailable, and regular.
Erik Bruchez: What's non-visible and
not absent.
Leigh Klotz: If it's not visible, it
still gets events.
Steven Pemberton: It's not two
booleans, it's one three-valued.
Erik Bruchez: boolean expressions are
easier.
Steven Pemberton: There are three
states, with one impossible combination if we use booleans.
Leigh Klotz: absent but visible would
be the impossible state.
Erik Bruchez: There are few names left
that would be friendly.
Leigh Klotz: But Steven won't want to
call it visible.
Erik Bruchez: Does Dojo have the
visibility control?
Nick van: CSS
John Boyer: What's wrong with
enabled?
Nick van: disabled means
greyed-out.
John Boyer: Use disabled/enabled to
mean greyed out and use relevance to mean gone.
John Boyer: There's two ways to do
this: leave relevant to that which you can style, or
Steven Pemberton: Then it wouldn't be
a MIP.
John Boyer: Or the other thing.
There's two ways to attack the problem that we have two things. One
is to find a name we can't find and the other is to redefine the
thing we have and use relevant to describe the new thing.
Leigh Klotz: So call presence
relevance?
Steven Pemberton: But not as a
MIP.
Erik Bruchez: We can have a MIP for
consumption by the view. Or we can put a boolean on a view. It's
not the same as specying that condition in the model. It's a little
like P3P.
Erik Bruchez: It is type
information.
John Boyer: Like constraint, required,
or type.
Erik Bruchez: So MIPs are for
properties to data for whoever.
John Boyer: A consolidation as a UI
MIP would be fine.
Leigh Klotz: But not backward
many-to-one. So maybe we can leave it as a UI expression and work
with live documents for the consolidation?