Charlie Wiecha, IBM
Steven Pemberton, CWI/W3C
Uli Lissé, Dreamlabs
John Boyer, IBM (chair)
Keith Wells, IBM
Sebastian Schnitzenbaumer, Dreamlabs
Erik Bruchez, Orbeon
Roger Pérez, SATEC
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Blake Jones, DAISY/ViewPlus
Mark Birbeck, x-port.net
http://lists.w3.org/Archives/Public/public-forms/2007Nov/0083.html
John Boyer: The announcement is
supposed to go out tomorrow. Have any AC reps received the decision
yet?
Steven Pemberton: The decision is
released on the day of publication.
Charlie Wiecha: Any thing to
discuss?
Leigh Klotz: I saw Noah Megginson
announced the XForms session on the xml-dev.
Nick van: I need some confirmation
of the action item list triage.
John Boyer: Also everyone please clean
up your action list.
Steven Pemberton: After
vacation.
John Boyer: And is Mark Seaborne
on?
Steven Pemberton: On IRC.
John Boyer: I got a note from Aaron
Reed indicating that the www-forms list looks like it's not active.
But the perception is that the activity of the group has gone
down.
Leigh Klotz: Should we be posting a
monthly summary of what's been happening? I'd be happy to
that.
John Boyer: How about cross-posting
minutes?
Leigh Klotz: We can summarize what has
happened in the past month; if people want actual minutes, they can
read the public-forms list. Providing a higher-level view may have
an advantage.
Steven Pemberton: It's weird having
two public lists, but people aren't allowed to subscribe to the
working-group list.
John Boyer: That's a big part of the
problem. We can't move them over, unfortunately.
Charlie Wiecha: So you can't subscribe
to the public-forms list?
John Boyer: No.
Steven Pemberton: You can't post but
you can read via RSS.
Erik Bruchez: [irc] then we should
send instructions to www-forms about how to subscribe to the RSS
feed
Nick van: [irc] for all lists there is
a link to the RSS feed on the homepage but NOT for
public-forms@w3.org
John Boyer: So we should update the
home page.
Action 2007-11-28.1: John Boyer to update home page with link to RSS feed for public-forms.
Action 2007-11-28.2: Leigh Klotz to summarize group activity monthly to www-forms, starting this month, and include pointers to www-forms RSS feed and archives.
John Boyer: The observation is that
it doesn't seem to be useful for most actions, because you really
only do them once.
Nick van: [irc] uli replied, to it.
when you have async submission, a bit of a stretch
John Boyer:
http://lists.w3.org/Archives/Public/www-forms-editor/2007Nov/0004.html
John Boyer: I don't know that that's
the reason.
Steven Pemberton: For any action you
can wrap it with an xf:action and apply it there, so there's no
sense in disallowing it. Also, what makes sense can change over
time. We noticed this with HTML4; we talked about which elements
should get the id attribute, but then we discovered we
needed it everywhere.
Erik Bruchez: With setfocus, couldn't
setfocus cause an event to be sent while being processed? There
could be side effects.
John Boyer: Yes, that's what I thought
was a good technical answer.
Erik Bruchez: Yes, so we'd have to be
really certain that an action had no side effects. So I think
Steven's approach is better.
Nick van: And delay.
John Boyer: I had thought we'd still
have implementations not interrupt currently-running action
sequence in order to complete their jobs.
Uli Lissé: I understand; I
hadn't thought about it.
Mark Birbeck: I agree with other
comments; if we want to go in a more modular direction in the
future, these might be a separate spec anyway, SO you might have a
@while on a SMIL action.
John Boyer: Many actions you think
don't have side-effects do because of event handlers. As Steven
says, It's academic anyway because of the action wrapper, and as
Mark says, the modularity issue. Uli would you summarize it?
Action 2007-11-28.3: Uli Lissé to respond to http://lists.w3.org/Archives/Public/www-forms/2007Nov/0000.html
Mark Birbeck: I'll have to check
this out.
John Boyer: This week?
Mark Birbeck: I'll ask now.
Steven Pemberton: I don't know much
about this, but why isn't it in the XML declaration at the front of
the SOAP envelope?
Mark Birbeck: How do you put that in
the instance?
Steven Pemberton: A SOAP package is an
XML document; the XML document says what the encoding is.
John Boyer: The XML declaration in the
instance isn't preserved; there are several submission attributes
modeled after XSLT to control the serialization. He's saying that
submission/@encoding sets the character set in the XML
declaration.
Steven Pemberton: Oh, I
misunderstood.
Mark Birbeck: I thought it was a
reference to the HTTP headers; you might have two different
charsets in two different headers.
John Boyer: The content-type
header.
Mark Birbeck: The encoding sets the
charset and the mediatype sets the content-type. What if you have
both? I think this is a SOAP question; I would think the mediatype
would win out, but I'm asking.
John Boyer: The spec says the encoding
attribute affects serialization. The mediatype attribute says it
doesn't affect serialization. The issue is that I wasn't aware that
encoding affected the content-type. Now that we have a header
element you could add a content-type using the element. In the past
we said we'd just let the user agent work it out. It may be good to
have some other implementers look at this. These are part of the
group of four taken from XSLT output.
Mark Birbeck: The reference to "some
processors" is for Formsplayer, and we do indeed append; however,
mediatype wins out, because the spec is explicit about mediatype
and isn't explicit about encoding. So there's only one by the time
it gets to the server, but that's because it isn't explicit on
encoding.
John Boyer: So we need a separate
discussion about whether encoding should do that. If you have
application/xml as mediatype, the XML itself is
self-determining.
Mark Birbeck: No, we need to clarify
it; you need the harmonization. If you sent it as a MIME package,
it can be whatever you like, but if you use the XML MIME types I
think you have to be more specific.
John Boyer: We need to do a little
spec tightening.
Mark Birbeck: I'll read this more
after the call.
Sebastian Schnitzenbaumer: We have
a visitor on the IRC channel; is this allowed?
Steven Pemberton: Yes, as long as they
don't speak during the meetings.
Steven Pemberton: So XForms 1.1 has
a new shortname, xforms11. So the latest version of XForms doesn't
take you XForms11. I'm not sure what we should do about that?
John Boyer: Is that what it supposed
to do?
Steven Pemberton: That's partly up to
us. It means people who go to W3C who go to http://www.w3.org/TR/xforms
and latest version, never get XForms 1.1.
John Boyer: Should the latest-version
link produce things that aren't recommendations?
Steven Pemberton: That's also a good
question.
John Boyer: If I go to TR/xslt then I
get XSLT 1.0 from 1999. I don't know what I'd type to get XSLT
2.0.
Leigh Klotz: You type "saxon."
John Boyer: And if you want XPath 2.0
you type xpath20.
Steven Pemberton: For SVG, you wind up
at SVG 1.1. So I think we should be asking for some redirection so
that we have xforms, xforms10, and xforms11.
Nick van: So we still want the latest
version of xforms10 pointing to...
Steven Pemberton: Let's see what
TR/html.... Ah it has different latest-version links in the
specification.
Leigh Klotz: So we can't go this for
XForms 1.0 but we can do that for XForms 1.1.
Steven Pemberton: So the /xforms link
goes to the most recent version.
Leigh Klotz: And in that version we
can have the disambiguation section at the top.
Steven Pemberton: So we create a
shortname xforms10 and ask for xforms to go to xforms11.
John Boyer: Can we pass pubrules with
two latest-versions?
Steven Pemberton: Pubrules check is a
machine anyway; you just say the reason for not passing.
John Boyer: I'll have to rewrite the
XSLT.
Leigh Klotz: So in XForms 1.1 it's a
link to the TR/xforms10, not a link to a specific old
version.
John Boyer: Right. I'll add this to
teh issues list.
Steven Pemberton: I'm doing it
now.
John Boyer: We need to decide
XForms 1.0 vs. XForms 2.0.
Nick van: [irc] I made a section
XForms Simplication
John Boyer: Maybe we should start with
those.
John Boyer: Make the model
optional.
Mark Birbeck: The model element. It's
about making the page simpler.
John Boyer: Could you have multiple
instances?
Mark Birbeck: That's the kind of thing
we need to discuss, but I was thinking of two levels of
development. A new developer wants to do some basic stuff but with
a little extra, maybe input first name, input surname, and then an
output. I also suggested the form element giving you one model, one
instance, one submission. Not taking the instance out of the model.
Then gradually introduce the MVC model. If you're loading an
instance from another location, then at that point it's the model
element.
John Boyer: How do they make the
implied instance explicit?
Mark Birbeck: ...
John Boyer: How about just the
instance element?
Mark Birbeck: What you're talking
about is something like a data island. So we could break that out,
instance inline or with source. Then we can break that out into a
modular spec. It could be serialized using JSON as well. I'm not
sure where to draw the line. I'd like to turn XForms into 20
minutes, but I don't know where to draw the line. So for example,
you could define the instance element, and a couple of APIs. That's
a useful module for many situations.
John Boyer: It's hard to avoid some
modularization, where we end up with instance, submission, and bind
as modules. Instance and submission seem to have use in implied
model with a form tag. The goal of the simplification is to provide
that onramp.
Mark Birbeck: I would put in message.
A lot of them let you instantiate messages in different ways. You
can give it a DOM entry. That's the message element. We've got lots
to offer there. These low-level features don't require lots of
XForms. You wouldn't even need the xpath part.
John Boyer: The final thought might be
with multiple instances and one of them implied, how do we move
data between the declared instances and the implied.
Steven Pemberton: If there is an
implied instance, there can be no other implied ones.
Mark Birbeck: But what about declared
ones?
Steven Pemberton: The moment that
there are declared instances you lose the implied one.
Leigh Klotz: That makes it hard to
keep something working while you move.
Steven Pemberton: So people will
learn.
John Boyer: What actually
breaks?
Steven Pemberton: The ability to refer
to it.
Mark Birbeck: The first instance rule
could go.
Steven Pemberton: That's a big
change.
Mark Birbeck: We could change it to
refer to the implied instance; otherwise the first instance rule
isn't that useful once you cut and paste anyway.
John Boyer: Another way to put it is
that when you have an implied model, the implied instance is the
first one.
Leigh Klotz: If you have an
unidentified first instance then you don't have the implied
instance?
John Boyer: Good. Anywhere.
Mark Birbeck: So it's unnamed, not
implied.
Steven Pemberton: I don't like it yet.
It changes the meaning of existing forms.
Mark Birbeck: The instance() function
with no args looks like you're referring to the unnamed
instance.
Steven Pemberton: In XForms 1.0
ref="foo" is the first instance and in 1.2 it would be the
invisible instance.
Nick van: [irc] if you have xforms 1.1
then those will not work in 1.2
John Boyer: Good point Steven.