John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Paul Butcher, WebBackplane
Charlie Wiecha, IBM
Keith Wells, IBM
xforms-idref-exceptionJohn Boyer: I gave a talk on "Interactive Office Documents," applications in office documents, using XForms. Also, Jack Jansen's paper at http://www.ibm.com/developerworks/blogs/page/JohnBoyer?entry=on_the_best_paper_at which uses XForms for video.
John Boyer: October 15-16 Virtual,
Oct. 20-21 Cannes. Please post particular agenda items you want
discussed. Steven, we need Zakim booked.
Steven Pemberton: During the
F2F?
John Boyer: I have asked for a phone.
It's an admin req.
Steven Pemberton: I'll make sure for
the F2F and the virtual days.
John Boyer: What times? Six hours and
an hour break?
Steven Pemberton: Yes, I thought last
time was quite good, though I was in the US.
John Boyer: Steven, if you want to do
what we did before, that's OK. The hour long break is time to get
home and eat; for us on the west coast, it's breakfast time, and
for east coast, I think it's 9-3.
Charlie Wiecha: That's what I have in
my calendar.
Action 2008-09-24.1: Steven Pemberton to book Zakim for F2F and Virtual Days same time as last year, which we believe is 9AM-3PM Eastern, with an hour break.
John Boyer: And what about the
meeting hour times?
Steven Pemberton: We're stuck with the
hours there.
John Boyer: I think it would be a
waste of time to meet in the morning, but after lunch is OK.
Nick van: [off] I'm going to
Cannes.
Keith Wells: [off] I will attend
remotely, best I can.
John Boyer: I would like to meet
with them to discuss some of issues with the signatures on live,
running documents. I'm not sure if 90 minutes is too long, but
they're wondering if 11-12:30 is a good time. I understand there's
two lunch periods, and we tend to go to the earlier one so we have
an extra hour of teleconference.
Charlie Wiecha: How about
WebApps?
John Boyer: That's next. So is
11-12:30 a good time? Would you like to hear what I have to
say?
Keith Wells: Yes.
Nick van: [off] I'm interested
John Boyer: We'll go to their room. If
they can make our lives easier in the future, it's good.
Charlie Wiecha: What day?
John Boyer: Monday.
Charlie Wiecha: I have 3:00 with MMI
on Monday and 1:00 on A11Y, for Backplane.
John Boyer: So the later lunch, or
just go at 12:30-1:30?
Steven Pemberton: It may still take an
hour to eat.
John Boyer: Chris Wilson has planned for an hour for us to describe Ubiquity and streamlined syntax. I'll be giving him the first round. We're hoping to re-energize interest.
John Boyer: The chair, Art Barstow,
has declined the invitation. I gave reasons for why I think there's
overlap, but he didn't provide any reasons, so I asked, and only
four people responded saying they were interested. I suggested he
ask if anyone was opposed. I didn't see anything on the mailing
list. I have sent yet another email back saying that TPAC is where
groups with overlapping work discuss their common interests. The
response was that he agreed with TPAC and overlapping concerns and
so we have decided we're going to work on our work during this
meeting. I have not gotten a response back.
Steven Pemberton: Is WebApps still
alive?
John Boyer: Yes, they have 700 emails
in their last set. They have merged two groups. So the list is
active. Doug Scheppers suggested I join the list and discuss XForms
streamlined syntax. I thought I might raise this at HCG, though I
can't try too hard to force a meeting.
John Boyer: We're not able to
pursue this as there's not much activity there, though we would
like to discuss mustUnderstand
Charlie Wiecha: We're planning to
show XForms-based patterns to coordinate across components, for
example Jack's SMIL+XForms. I have data model voice interaction
(not X+V which is on-the-glass.) And some data model submission
from Ubiquity in Dojo and YUI. There's a hope that Mark will talk
on Wednesday about abstractions of behavior independent of markup,
but we don't know if he's going to talk.
John Boyer: Holding his talk
afterwards may be better after our talk.
John Boyer: Steven, can you ask for
the talks to ordered?
Steven Pemberton: Yes, if Mark is
coming.
John Boyer: Paul, can you confirm with
Mark?
Paul Butcher: Yes.
Steven Pemberton: It's moved up on
my todo list.
John Boyer: We can also have the news
item about Jack's paper.
Steven Pemberton: I'll work on it
now.
Action 2008-09-24.2: Steven to work on news right now.
Keith Wells: All but submission headers is done.
Leigh Klotz: No progress as I was working on submission headers.
John Boyer: I was trying to find
it.
Leigh Klotz: I'm not sure where to put
the note about HTTP and a non-normative note warning about the
specifics of how it works with headers.
John Boyer: What's the RFC?
Leigh Klotz: Google search says it's
RFC 2616.
John Boyer: Who says we don't need
an actions module if we move to XML Events 2?!? our actions,
event() properties, deferred update behavior, specialized
context
Nick van: I thought that would go in
our driver module.
John Boyer: Let's back up. For
setvalue?
Nick van: It should go in the instance
module; if you have no instance, you can't have setvalue, so it
doesn't belong in a general action module.
John Boyer: The troublesome bit is how
does the instance module enhance the non-existent actions
module?
Nick van: There are actions; the
action element is defined in XML Events 2.
Charlie Wiecha: I think the idea is
that the atomic actions are distributed to separate modules; there
should be a companion module to instance adding insert, delete, and
setvalue.
Nick van: ...
John Boyer: That makes more sense now;
thank you.
John Boyer: The XML Events 2 spec
description of the event function says it will return a value
corresponding to a property. Actually, I should check the return
type.
Nick van: Same type as ours.
John Boyer: It doesn't define any
properties at all. I know that we define event-specific properties
and I agree those should live in the event description in whichever
module is adding that event, so I'm good there; but we have had a
problem that we have never defined a set of properties that are or
are should be available to all events such as who is the target and
whether you are cancellable or bubbles.
Nick van: target
John Boyer: I know that the name
target is another issue. But maybe we should send feedback to XML
Events 2 and say that they should define this information available
to every event, because we've found that saying "do this only if
event-target is such" is useful. So maybe that needs to get
pushed.
Nick van: Yes. I want to send mail to
the list. We decided some changes were needed to XML Events 2
module, but I haven't sent the mail yet. We support child elements
for dynamic values, but we can ask, and some attributes with
different names. There are some problems with XHTML and naming
attributes that collide.
John Boyer: I noticed the change from
target to destid. That's the second point
I starred. It's hard to name stuff. Steven asked for suggestions,
so how about receiver? We talk about objects receiving
events, and I looked at other event systems and saw that
receiver is used, so that's a suggestion. It seems
better than destid.
John Boyer: Deferred update would be
in the model module, so I'm good there. How about specialized
context?
Nick van: ...
John Boyer: Charlie, you're doing a
module for data.
Charlie Wiecha: The residual stuff
after we factored out instance: setvalue, etc.
John Boyer: The data actions module.
So when someone writes the repeat or switch module, it seems a
little odd to get specialized context from the data actions
module.
Nick van: You need the instance module
to have data.
John Boyer: But you don't need the
data actions module. So maybe a tiny, irritating spec on
specialized context.
Leigh Klotz: Is this the dot-dot
problem?
John Boyer: The XPath context for @if
and such would be no context node and a size of zero. So it would
be the in-scope evaluation context, defined by the context
attribute.
Leigh Klotz: So we say that the
context attribute has this behavior.
John Boyer: Good. But there are some
where you can't.
Nick van: In XML events you can use
the null function in an if.
John Boyer: Toggle, setfocus, and
index have an in-scope evaluation context but no @context.
Leigh Klotz: So add @context to
them.
John Boyer: I see what you're saying.
That fixes it.
Nick van: At the last
teleconference, we discussed the binding exception. I'll republish
that. It will be only for binding exceptions. In XForms 1.1 we have
other things that use it and those will get another
exception.
John Boyer: For failing to match an ID
can you call that something like xforms-idref-exception.
Nick van: That doesn't go in this
module. There's an editorial note that says that other modules need
their own exceptions now.
John Boyer: So bind doesn't have any
id references?
Nick van: If it does, our idref system
needs to be defined elsewhere.
John Boyer: I thought that bind module
would define the bind element and its ID, and add the bind
attribute.
Nick van: Yes, but the module can
refer to an ID. On submission, you can refer to an instance, and
that's an IDREF that might not exist. Or a model attribute on a
control. Those are idrefs that aren't available and aren't
bind.
Nick van: ...
John Boyer: Perhaps you should make
that change to the bind module. Two MIPs to the same node is a
different type of exception. So either a new name or more context
information.
John Boyer: Do you think you might
be able to start the submission module?
Uli Lissé: Not yet, but for the
TPAC.
John Boyer: Break out the spec, take
out relevance and validity and come up with a way to have a
placeholder where other modules might be able to inject their
behavior into the processing stream of the XForms submit
event.
Uli Lissé: I've thought about
it.
John Boyer: I'm wondering if we need
to add more context information to the event to allow modules to
communicate on processing, but action handler ordering issues might
be a problem. The xforms-submit-event might have additional
properties such as valid or invalid or validation failure and the
validation module could change the results. You might need to add a
pre-processing event and/or some context information.
Steven Pemberton: http://www.w3.org/MarkUp/Forms/#news
Keith Wells: I don't think it's a
big deal. I've been doing due diligence.
John Boyer: What does it say? BSD
license?
Keith Wells: Yes. You can modify test
cases. So we need to find out what it means.
John Boyer: It seems weird to put a
license on a test suite.
Keith Wells: Yes.
John Boyer: Please keep us posted.
John Boyer: The resolutions are useless because there's no action items. Leigh manages minutes and Nick manages action items; a quick thanks. But I noticed in the past couple of telecons there were resolutions without action items.
xforms-idref-exceptionJohn Boyer: Someone needs to own
this. Which modules?
Nick van: I will look it up.
Action 2008-09-24.3: Nick to ensure that
http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0037/2008-09-17.html#resolution1
is handled by module owners, whatever the eventual name is.
John Boyer: Someone can own the action
to check (Nick) and someone can do (John and Uli and model and
others).
John Boyer: I can accept this. It
would behave similar to the index function, which is now acting
like implicit instance data that the index function creates a
computational dependency, so that UI bindings automatically update.
I believe we need to have the case function work the same
way.
Leigh Klotz: We invented this by
analogy to index. I sent a message back to the original author. I
don't think I mentioned details of how case would work.
John Boyer: The data-based version of
XForms switch may be how we answer his use case. We looked at doing
something like @using for case.
Leigh Klotz: It may be that the
authors just want to say it more directly, which is why we
discussed XBL and macros.
Action 2008-09-24.4: John Boyer to provide spec-ready text for case() http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0037/2008-09-17.html#resolution2
Paul Butcher: Can you accept this?
Action 2008-09-24.5: Paul Butcher to ensure that boolean-from-string proposal is handled in XForms 1.1 modules: http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0025/2008-09-10.html#resolution1
John Boyer: Charlie I noticed you
mentioned XFormsA instead of XForms-A.
Steven Pemberton: [irc] RDFa instead
of RDF/A to make it Google friendly.
Nick van: [irc] if you search for
RDF/A on google the first item is RDFa Primer ;)
John Boyer: Attribute decoration gets the discussion away from XML well-formedness. So they are either local or global attributes. By the time someone wants to scale up from attribute to element versions of the behavior, then they might need some proper XML elements within their document format.
John Boyer: There's the model-view-controller-connector architecture, with connector replacing submission. During the runtime and at the end of the form, there's an ability to interface with the server.
John Boyer: There are four possibilities for attributes:
adopt them without xf: as unprefixed
Leigh Klotz: Maybe xf- is not the
right prefix, for marketing purposes.
John Boyer: In the examples I'm not
using xf-.
Leigh Klotz: Nobody wants a simplified
version of something they already don't want.
Charlie Wiecha: fa? forms
attributes?
Leigh Klotz: "XFormsA" is a good start
but I think it needs a new name that isn't XForms.
Uli Lissé: [irc] formsx
;-)
John Boyer: It still needs to be able
to scale up to the real namespace, or maybe it doesn't.
Leigh Klotz: I'd like to not get
caught up in namespace discussions for the namespace-free
version...
John Boyer: The next section is
about form containment. The toughest part of an attribute approach
is the form element in HTML. It seems like there should be an
attribute way of indicating that something is the root element of a
form, so I added for a form attribute with a qname. The HTML form
element would give you a generated instance whose root element is
data in the empty namespace; the attributes allow you
to override.
Steven Pemberton: [irc] My time is
up
John Boyer: A form element or an
attribute still identifies the root element of the form; anything
inside is a potentially a form control. A name
attribute identifies form elements: name which gets
you data, value, default, and
checked, startSize for repeat, and more
in the spec. There are starter examples with generated instance
data. Please send comments.