John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Erik Bruchez, Orbeon
Roger Pérez, Satec
Rafael Benito, Satec
Susan Borgrink, Progeny Systems
Keith Wells, IBM
Uli Lissé, DreamLabs
Joern Turner, DreamLabs
Steven Pemberton, CWI/W3C
Nick van den Bleeken, Inventive Designers
Doug Schepers, W3C
Mark Birbeck, x-port.net
http://lists.w3.org/Archives/Public/public-forms/2008Jan/0070.html
Leigh Klotz: I am not done with the
newsletter. I did respond to XML Core on PER 5, and have been
working on the ITS issue.
John Boyer: I see you also responded
to the Access Control.
Leigh Klotz: I'll try to work on the
newsletter today.
Erik Bruchez: It wasn't as clear as it could be but I don't feel a change is needed for XForms 1.1.
John Boyer: I dropped some text.
Action 2008-02-20.1: John Boyer to fix missing text in http://lists.w3.org/Archives/Public/www-forms-editor/2008Jan/0002.html
John Boyer: He seems to think that
it says you can't have any submissions concurrently.
Erik Bruchez: It's per
submission.
John Boyer: He says the wording says
that all subsequent ones submit error, which is not what we
mean.
Erik Bruchez: I'm not sure why he
thinks it is unclear; it says for a particular XForms
submission.
John Boyer: It's the second sentence,
"From the start of the default action of xforms-submit" which is a
separate sentence. We could make it clear which submission.
Erik Bruchez: For the given
submission.
John Boyer: If there are no
objections, I'll throw together a patch for XForms 1.1 CR; it's a
minor clarification.
Action 2008-02-20.2: John Boyer to clarify text for http://lists.w3.org/Archives/Public/www-forms-editor/2008Jan/0001.html as a minor editorial change for XForms 1.1 CR.
John Boyer: We've been asked to
look at the CSS3 Namespaces module. Leigh has the action to update
the CSS in our Appendix G. I wrote to Bert Bos and said that we
have these TBDs in our document and asked if they could take them
on. He felt that they were already in CSS3 and said we should
investigate and update the appendix. According to Bert, the UI and
Selectors modules are at least in CR and we could normatively
reference those, though it is an informative appendix. If they
don't have the features, providing that as feedback would be
useful.
John Boyer: Leigh would you take on
the additional action item update Appendix G?
Leigh Klotz: Sure.
Action 2008-02-20.3: Leigh Klotz to update Appendix G to match current CR version http://lists.w3.org/Archives/Public/public-forms/2008Feb/0067.html
John Boyer: We had a set of
patterns from the F2F. The ease-of-authoring pattern wasn't quite
right, but we were more getting at things that made it easier for
today's web application authors to consume XForms. We had that
bucket. Then floating up into 1.2 are user interface patterns. We
need to come up with new vocabulary to come up with larger
constructs out of sets of XForms controls together; for example,
not just repeat, but providing column headers, row headers,
triggers for insertion and deletion of rows, whether the repeat
should be allowed to be empty, etc. Things that would simplify the
authoring of the full table concept. With patterns, this got moved
to 1.2 from 2.0.
John Boyer: Also we have a bug fix on
model-based switch. In XForms 1.1 and below, it's hard to do. If
you keep the state in the model, you can't enforce that it's always
running effectively and you can't use a switch.
John Boyer: It's also difficult to
have a default action for the page, with enter for example. At the
F2F we discovered that didn't seem to be something that was well
laid-out in HTML4 forms anyway; enter seems to work there by
depending on the simplicity of the page, and they don't have a
similar construct; it is just first submit in build order, and it
does different things in different orders. We have an equivalent
level using DOMActivate in current XForms 1.0; that was new to
me.
John Boyer: Under composition
patterns, we have nested and referenced models, getting models from
elsewhere. Custom XPath function, a bit of a stretch in
composition. It would help today's web application authors;
implementation in JavaScript would help today's authors. Multiple
MIPs on the same node would have to be rationalized. That's in
composition patterns because of multiple models assigning rules to
the same node.
John Boyer: I think we should cut
down on the scope of XForms 1.2 to the things necessary for
achieving the charter and focus on the 1.2 modularization; once we
have that modularization in hand, as we go forward into XForms 20,
we can incrementally upgrade these modules without a lot of
trouble. On the mailing list, I didn't see a lot of dissenting
opinion, but maybe we should open it up.
Leigh Klotz: We have to make sure we
get the modules right to have places to plug things in.
John Boyer: Well, some patterns such
as wizard go in container module. So there's group/switch/repeat
containers.
Leigh Klotz: I was thinking about the
function extensibility, which seems hard to design without putting
it in.
John Boyer: That review is in this
link:
http://lists.w3.org/Archives/Public/public-forms/2008Feb/0055.html
John Boyer: If you scroll down a bit,
you'll see the proposal that we drop the notion of patterns and
streamline for Web Application Authors. I propose that we drop most
of the composition, except for the functions. I think we can drop
the rest. We need to keep the model-based switch.
Leigh Klotz: So you're proposing we
keep custom XPath functions? That's fine; I just objected to doing
the interface definition but postponing the implementation.
John Boyer: The JavaScript custom
functions would be nice.
Leigh Klotz: I still like XQuery as
it's upward compatible from XPath 2.0; I can see it fitting into
modularization.
John Boyer: I wasn't talking about
JavaScript as the expression language. I'm talking about functions
such as decimal-string that could be written, functions for
calculation, to give us a shield against needing new functions in
each release, even for XPath 1.0 expressions. The current web
author reaction would be to write sumproduct in JavaScript, and we
would offer a way to connect it.
John Boyer: The modularization of the
expression language itself is in XForms 2.0, along with schema
modularization.
Leigh Klotz: I thought you were
pulling that from XForms 2.0, not just the custom function.
John Boyer: It should also be possible
to define functions in terms of XForms actions, but JavaScript
could be a reasonable alternative. Custom functions have to show up
in the functions attribute of the model element, and the XForms
processor has to make sure that's available somehow.
Leigh Klotz: I thought that we
added @functions since we had no way to put functions in another
namespace because we got comments from XPath about originally using
namespaces.
John Boyer: I think it's the other
way; we got comments about using prefixes and took them out.
Erik Bruchez: Yes, every XPath
processor supports it.
John Boyer: The function attribute
declares functions that were needed and not supported by XForms
already. Early on, my processor included the XForms 1.1 functions
power and current, which are not strictly-speaking XForms 1.0
functions. So I include functions="power current" in forms, and any
other processor knows up from if it doesn't have them.
Leigh Klotz: If you look at XSLT they
declare the extensions namespace.
John Boyer: The functions attribute
lets you declare it up front and not run the application, rather
than at runtime.
Leigh Klotz: You can statically
analyze it. If you restrict extension functions to have prefixes,
then you can even ignore functions that don't have prefixes. Or are
we going to allow functions without prefixes?
John Boyer: Yes, all will be in some
namespace, we said at the F2F. http://www.w3.org/MarkUp/Forms/wiki/Custom_XPath_functions
So the name is defined in the local-function namespace and it has
to be in the local: namespace.
Erik Bruchez: Unless I'm wrong, in
XSLT 2.0, you have to use a QName for the function name. I'm not
sure should do that.
Leigh Klotz: Doesn't XQuery have the
same feature; you define without qnames and invoke with
local:
Erik Bruchez: We'll have to check the
spec.
Susan Borgrink: [irc] yes that is
correct
John Boyer: We should ask Mark Birbeck
as he says this is current practice.
Erik Bruchez: I think we should follow
XSLT 2.0. http://www.w3.org/TR/xslt20/#stylesheet-functions
Leigh Klotz: XQuery does appear to use
a prefix on the definition but I don't see how it works as there is
no declaration.
http://www.ibm.com/developerworks/library/x-xqueryrss/#N10181
Erik Bruchez: We should follow XSLT
2.0 because we're defining XPath functions.
John Boyer: We should find out from
Mark why he thinks we don't need the namespace.
Leigh Klotz: Is there a way in this
proposal to define a function in JavaScript and associate it with a
namespace?
John Boyer: I proposed a way, using
function and implementation methods.
Susan Borgrink: I'm assuming you code
it in Java. If you put it in Java, your functions are in one
package. You have to access it via that package.
Leigh Klotz: If you look at a function
package called "math" described at exforms.org, for example, I
don't see a way to implement it in script in one XForms processor,
then in Java in another, and have them both be callable as
math:foo.
Susan Borgrink: I'll have to think
about that.
Erik Bruchez: You can have libraries
this way.
Leigh Klotz: What's the mechanism to
associate the namespace with the function?
Erik Bruchez: Associate the namespace
prefix with the URI. xmlns:math="java:org.apache.utils.MyMathClass"
select="math:power()"
Nick van: [irc]
http://www-128.ibm.com/developerworks/library/x-xalanextensions.html
Nick van: It is quite the standard in
XSLT land.
Leigh Klotz: This tightly ties the
namespace declaration to the implementation and I don't see how it
can work in both Saxon and Xalan.
Erik Bruchez: I'm not sure you
can.
Nick van: Xalan and Saxon use the same
syntax. You can use the same stylesheet in both, but both
implementations are in Java.
Leigh Klotz: I don't see how this can
work as it's bound to the implementation language.
Nick van: My link uses the old Xalan;
there's one used by both Xalan and Saxon.
John Boyer: How can we support the
notion that in XForms implementation A it comes from Java and in B
it comes from JavaScript.
Erik Bruchez: So how do we do function
libraries? You have to be able to support a namespace that
identifies a library scheme, or use any URI and an
implementation-defined mechanism to bind to a library.
John Boyer: One thing we talked about
was multiple implementations. The idea might be that the function
had multiple implementations, and as long as one was viable, it
would work. You could indicate one from Java, and another from
JavaScript, on a different processor. The interpretation of the
function would look at the first, Java, then the next, JavaScript,
then one in XForms actions, probably less efficient, but portable.
If you can't, then you would get an error.
Erik Bruchez: I'm not sure we have to
do that kind of thing. It seems a lot of work to define bindings to
Java and JavaScript.
Leigh Klotz: I think it's important,
as a user of XForms, and not a vendor. This proposal causes
vendor-lock in and we should be careful.
Erik Bruchez: It does allow portable
definitions using XForms; how many language bindings do we have to
support?
John Boyer: Leigh wants access to the
extension functions either way, with multiple implementation
statements, on both Vendor A and Vendor B's processor.
Erik Bruchez: I'm not necessarily
against standardizing the way to import a Java or JavaScript method
as done in Saxon and Xalan. But I was under the impression that
much more than that would be needed. Would you want to write the
body of the function in the form? That would be complicated.
John Boyer: I hope not; just referring
to them externally would be preferable. We could just separate out
the function from the name: <implementation
name="java:org.apache.utils.MyMathClass"...<implementation
name="javascript:foo" Nick:[irc] <func:script implements-prefix
= ncname language = qname-and-not-ncname src = uri-reference
archive = uri-reference /<
Nick van: [irc] A Java class:
src="java:com.example.datestuff.DateRoutines"
Nick van: [irc] An ECMAScript library:
src="http://example.org/somecode.js"
Erik Bruchez: XSLT doesn't specify
how to invoke Java functions, but we do it in our processor because
we use Saxon. Otherwise each processor has to implement dozens of
seemingly random functions.
John Boyer: No particular XForms
processor would be required to implement any engine. But if you do
have access to say, a Java engine, a webapp author would be able to
cover differences by having the custom functions available. I guess
you're saying that they might have made it available in different
ways.
Nick van: In exslt, they have two
different concepts: you can define a function, and they have the
possibility to bind a qname to a "script" and there you can specify
the qname, the language, and the source URI that refers to the
implementation of the function. You can point to Java, or
JavaScript, for example.
John Boyer: I think you're the guy
with the ball to mature this; I realize now that we're about seven
minutes away from concluding. I'd like to take it up a level and
come up with the next version of what's here.
Nick van: For the record: Erik has
the action to write up 'Custom XPath functions''
Erik Bruchez: Yes, I did. But if Nick
wants to take it over...
Nick van: I have a lot of other
actions.
John Boyer: Erik, you seem like the
perfect guy, if you can, to make something more of this; you don't
have to stick with what's written, and it sounds like there might
be some additional questions. For this to be in XForms 1.2, I would
have it if the only way to do implementations would be JavaScript.
I'm in favor of having XForms functions as a way to work across all
implementations; maybe that's the limit in XForms 1.2. Maybe we
offer the ability to do it in JavaScript as an alternative.
John Boyer: The proposal is that we
limit XForms 1.2 to the things that are in that mail:
http://lists.w3.org/Archives/Public/public-forms/2008Feb/0055.html
Does anybody on the phone feel they want to think more?
Leigh Klotz: I think we need to cut
back, there's no question, but I think we need to retain some
fluidity, especially this early.
John Boyer: I'd like to get the
requirements document out soon, and reach that minimum bar.
Nick van: [irc] I can go with it but I
think I would prefer to add 'Same model item property on the same
node ' but this can be under the hood of Add model item properties
to UI level
Nick van: [irc] so it is fine for
me
John Boyer: Yes, that and the external
model may not be that hard. They might not have to be in the first
public working draft or the requirements. We need some
latitude.
John Boyer: So are there any
objections to limiting the scope of the requirements document for
1.2 to
http://lists.w3.org/Archives/Public/public-forms/2008Feb/0055.html
I can put an optional bucket in the wiki so we can work on it for
1.2 but it doesn't have to show up in the first initial public
documents. Does that make sense?
Erik Bruchez: [irc] fine with me to
limit the scope of 1.2
Nick van: [irc] fine for me
Susan Borgrink: [irc] ok for me
John Boyer: Seems to be a wrap. And welcome back Susan!
Resolution 2008-02-20.1: We limit XForms 1.2 requirements to http://lists.w3.org/Archives/Public/public-forms/2008Feb/0055.html and list optional items in the wiki to be done after first draft, if possible.