TV Raman, Google (briefly)
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, Dreamlabs
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net (briefly)
Nick van den Bleeken, Inventive Designers
Rafael Benito, SATEC
Roger Perez, SATEC
Uli Lissé, Dreamlabs
Keith Wells, IBM
http://lists.w3.org/Archives/Public/public-forms/2007Dec/0004.html
John Boyer: We are still needing
the new short names, but would you like to send it out with just
the /xforms and /xforms11 short names?
Leigh Klotz: Sure. I'll do that.
Leigh Klotz: Lets you configure what
resources can be reached from this resource, using HTTP headers and
PI's
Leigh Klotz: It looks a bit weak, and
will not enable mashups, because these others URI's need to specify
what is allowed
Leigh Klotz: We could ask if they use
XForms as a test case
Leigh Klotz: I want some input from
implementers, bcz I'm not a real expert on this
Leigh Klotz: They are moving forward
fast, so the time to respond is limited
Leigh Klotz: the problem is that the
client checks the security, no tickets, tokens, so it is weak
John Boyer: how can they increase
their security
Leigh Klotz: I don't want to comment
on this, it seems that this is what they want to solve
Leigh Klotz: XForms implementations
should check if they could implement it and give feedback
Leigh Klotz: explains how it
works
Leigh Klotz: before a POST you do a
get to check security
John Boyer: what if the server doesn't
implement the GET
Leigh Klotz: then you can not access
this resource
John Boyer: do they only check if you
try to cross a domain boundary
Leigh Klotz: yes indeed
John Boyer: If we implement it we
should do a GET before a POST
John Boyer: So we need to consider it
in a future version in the submission model
Leigh Klotz: we need ensure that if it
is done, we can incorporate it
John Boyer: Do you want to post your
e-mail
Leigh Klotz: I want an implementer to
look at it
Leigh Klotz: I think MarkB or Aaron
should look at it
John Boyer: We could ask Aaron to join
a future call
Leigh Klotz: I will send a response
and say that we are working on it
John Boyer: Would you cross post it to
www-forms
Action 2007-12-12.1: Leigh Klotz to post updated message on access-control to comments list, and indicate that we continue to study the isssue. http://lists.w3.org/Archives/Public/public-forms/2007Dec/0012.html
Wiki http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
John Boyer: The main theme is glass
authoring and there are a number of steps we need to achieve it
(model-free, etc.) But for now before we get started on discussion
of technical details, who is available to write down these
technical details?
Nick van: I can do some work in it but
I think we first need a requirements document, or something like
that, then go for the details.
John Boyer: Our XForms 1.1
requirements document was detailed, but we already have a
functional requirement to simplify glass-to-data forms authoring.
There are specific things we've come up with which we believe
answer that requirement; those specific things are the level at
which our past requirements documents have been written. We do need
a requirements document, but the section header and bullet points
would be detailed requirements, with one paragraph each of rough
properties, not full spec'd out. Is that a reasonable model for
proceeeding?
Nick van: If we do something
high-level it could be done for the next F2F.
John Boyer: The XForms 1.1
requirements, http://www.w3.org/TR/xforms-11-req/
went to from "improve client-server interaction" to a solution
(SOAP). For the second one, we went from one base requirement on
submission improvement to three specific recommendations, but those
recommendations were brief. The level of discussion of these
features we're discussing now is at that level: for example, "make
the model optional."
Nick van: So we don't need to know
them before we write the requirements document.
John Boyer: True. Focusing on the
requirements... It's not going to take long to produce the document
once we decide which things to produce in the documents. Someone
could start working on the technical details then. Nick, are you
thinking of pulling together the 1.2 requirements document?
Nick van: I can try to write some
detail about the points in there now and we can try to discuss
which goes where.
John Boyer: In some cases we'd have a
paragraph describing what's going wrong and then the requirements
statement would be to fix that.
John Boyer: Are there any concerns
about having the glass-to-data issues in XForms 1.2: optional
model, MIPS on UI controls, submission without model, instance
without model.
Nick van: I'm not sure we need
instance without model, as I commented, because of default values.
In my opinion, the SOAP submission is the only thing that isn't
fixed, but that's for advanced users; we might want to solve the
SOAP submission problem separately.
John Boyer: I wonder if it makes sense
to put an instance element inside a submission. If our intent is to
get the instances to contain the request and response SOAP
envelopes, then putting them inside the instance would make sense.
Something you could throw in your document and have it more or less
work. Then action handlers to put the data in and out.
Leigh Klotz: That sounds like
XAC.
Nick van: Or higher-level actions, a
simple SOAP call with simple arguments. It's still quite difficult
to make the SOAP envelope.
Leigh Klotz: When people do SOAP in
programming languages, they use tools do to it. It's already fairly
easy for document style but not RPC style, so perhaps some XSLT or
something to let people do RPC-style SOAP in XForms.
John Boyer: So maybe allowing SOAP
submissions to occur with an implicit instance is the issue. We
still want the implicit instance but we don't want to lose web
services in the meantime.
John Boyer: Number five on the list is
default values on UI controls. Even our current way of doing
default values in the model is a bit of a hack. It's easy in HTML,
but we don't have the corresponding capability.
Leigh Klotz: At the UI layer. We have
it at the data layer.
John Boyer: We're talking about only a
UI layer version, so the default value issue needs to be
included.
Leigh Klotz: If we step back and take
out model, what breaks? I think events break. But events are broken
already. Josef Dietl and I proposed it as an implementation and
expository technique but it isn't satisfactory.
John Boyer: ...
Erik Bruchez: We discussed a related
issue at the Madrid F2F. The UI events don't cover the use cases.
The decision was to consider this as an issue. One way of solving
it would be a new architecture for UI events.
Leigh Klotz: Yes, both model-based
events and UI events need to be looked at. Let's just add events
the list of 5 things that we're looking at for XForms 1.2.
John Boyer: We have a model that the
XForms model pushes out the information based on the recalculation
engine; that's seems to be a part of the problem.
Leigh Klotz: Josef and I proposed
using events as a spec and implementation technology for the
processor, as a parallel to the UI events, but I think the
experiment hasn't worked, and if we're removing model we should
look at removing this.
John Boyer: This sounds like a
conversation that's going somewhere positive. Can we flesh out a
bit more of the details about what would actually change?
Leigh Klotz: I'd like to have
something like "simplify and provide use cases for UI events and
model events" on the list of five things for XForms 1.2.
Resolution 2007-12-12.1: We add something like "simplify and provide use cases for UI events and model events" on the list of five things for XForms 1.2.
John Boyer: Try to take your own pass through this week and contribute to getting us further along. We do have a meeting next week.