Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI (chair)
Leigh Klotz, Xerox (minutes)
Erik Bruchez, Inventive Designers/Orbon [joined late]
Leigh Klotz: Alain sent a community
group message and I responded but there is nothing in the archives.
I believe it was internal-xformsusers. I'm not sure why we need the
internal-xformsusers.
Steven Pemberton: It is there.
https://lists.w3.org/Archives/Member/internal-xformsusers/2012Mar/0000.html
Leigh Klotz: I see. I misread the
page.
https://lists.w3.org/Archives/Member/internal-xformsusers/
Steven Pemberton: We need to put some
text on the main wiki page. And there is a chat.
Leigh Klotz: It's #xformsusers
Steven Pemberton: We don't yet have a
quorum today.
Steven Pemberton: We should write a
message and send it to www-forms.
Nick van: And the test suite. The
commuity group is covered for copyright.
4. Contribute to test suite
Steven Pemberton: The nice thing
about using XForms+XHTML note there is that we can just put it on
the wiki and we can turn that into a spec.
Leigh Klotz: And it comes with a
wiki.
Nick van: Maybe we can encourage
people to review modifications or additions to the spec and discuss
them there.
Steven Pemberton: Yes, we can keep
people updated on spec changes as they happen.
5. Give updates on XForms 2
Steven Pemberton: We could maintain the list of implementations there.
6. Maintain list of implementations
Nick van: Vendors can discuss proposals there instead of on their own lists.
7. Proposals for new features; discussions on features
ACTION-1877 Steven Pemberton to send welcome message to Community Group
Steven Pemberton: And how about
chair. It needn't be someone in the working group.
Leigh Klotz: The process says the
community group should elect a chair.
Steven Pemberton: Device Magic
announced a new implementation.
Leigh Klotz: We should invite them to
join the community group.
Steven Pemberton: Absolutely! It's a
mobile implementation. "Data collection." Personal for one device
is free.
Steven Pemberton: Android but no
Symbian.
ACTION-1878 Steven Pemberton to migrate implementations list to Community group
model @functions @schema
@version
function @signatureinstance @src
@resourcebind @type @p3ptype@idSteven Pemberton: Anybody think
that @type should be an AVT. No? Looks like a good
list, Nick; thank you! Could you add this to the section on
AVT?
Nick van: I did this throughout the
spec, not in one place. I can add it.
Steven Pemberton: It is handy: all
attributes are either XPath or AVT, with the exception of the
following: ...
Leigh Klotz: It could be a note.
ACTION-1879 Nick Van den Bleeken to add non-normative note to AVT section listing exception attributes; they are normatively described in their individual sections
Erik Bruchez: [joins]
Steven Pemberton: The middle line
is wrong; it says context.
Leigh Klotz: And the close tag on the
third property element.
Nick van: OK
Steven Pemberton: We leave off the xf:
prefix in all the examples. Thank you Nick.
Steven Pemberton: This is done; we're leaving as is but with a note asking for opinions.
Nick van: This would be good to
discuss:
http://lists.w3.org/Archives/Public/public-forms/2012Mar/0029.html
Nick van: Erik and Philip asked that
we drop the sequence element and just put XQuery, XPath, or
JavaScript directly.
Leigh Klotz: And Erik proposed nested
var element.
Erik Bruchez: Yes, by nesting script,
var, or result elements we create our own language, as we did for
actions. For actions it may make sense. But for functions it may be
nicer if the body were just nicer to use the language. It's
annoying that XPath 1 and XPath 2 you can use for--return, and
XPath 3 has variables. So you need not have var or return. Even
more so with JavaScript or XQuery. So to keep things simple, we
could just have the function body be in the language.
Nick van: This would be the first
place where we have an XPath expression as child text content. That
would be the same in XSLT. That's a minor issue.
Nick van: The bigger issue is that we
target XPath 2.0 and so writing functions without using variables
is not handy.
Erik Bruchez: The first doesn't bother
me as XPath is evolving. I find myself writing multi-line
expressions in attributes. As XPath progresses forward and gets
variables and inline functions, it becomes a scripting language. I
think it makes sense to put XPath a notch under XQUery and it's OK
to put XPath expressions not in attributes, for side-effect-free
scripts.
Erik Bruchez: The second part is a
letdown; there is a huge benefit of simplicity in the spec. Since
we decided XPath 1.0 is mostly out of the way, you have full
variables in XPath 2 and you can do nested for-return and as long
as you're cautious with empty sequences, you can do it. It's not
that we don't need variables: it's crazy to think we have an
expression language without variables. But we'd be doing the same
work in XPath and XQuery and JavaScript. Becuase we add variables
we also have return, and that's extra area.
Nick van: In the future, if you want
to create mixed content, text outside sequence could provide mixed
content.
Erik Bruchez: Yes, that's a downside.
But there is use even in XPath 1.0 with common-expression
functions, and moreso in 2.0 and definitely in XPath 3.0, XQuery,
and JavaScript. I'm not sure what others think about this
simplification. I'm leaning more toward this simplification. XPath
3 is not a huge departure from XPath 2. You can hope that people
would quickly move to XPath 3. So we're specifying something that's
already a little bit obsolete.
Nick van: For Saxon the XPath 3.0
engine isn't available publicly yet. It will take a while in the
home edition. It's in the professional edition. http://www.saxonica.com/feature-matrix.html
Erik Bruchez: So does Saxon plan to
support XPath 3 in the open source version?
Nick van: I don't know.
Erik Bruchez: If there are no
open-source implementations of XPath 3 then that would slow
adoption. There are cases where intermediate variables are needed,
but you have to jump through hoops. There's more beauty if you say
the script content is the spec. It come with some things that are
undesirable. It makes the functions useful. We could start this way
and see if implementors need variables and could justify adding
them to the spec.
Nick van: If we go with
content-is-expression then we can't use constant string.
Leigh Klotz: You mean you can't use
literal elements?
Nick van: You can't.
Leigh Klotz: If you use XQuery then
you can.
Nick van: But for XPath the content is
an XPath expression.
Leigh Klotz: But why invent our own
literal-template syntax when they could use XSLT or XQuery?
Nick van: The downside is that not a
lot of implementations will support it.
Leigh Klotz: Maybe we could define our
own profile of XPath 2 with added variables from XPath 3 and added
literal-result-element-as-stylesheet from XSLT and then call that
our own language, and give it a name and use it in the type of
functions, but that's a big design to do and I don't think it would
fit inside the XForms Recommendation.
Nick van: That sounds reasonable.
Leigh Klotz: Is
function=var*,text good enough or is it too little for
the complexity it costs?
Nick van: I think either our own
language or just XPath. Something that's in between isn't worth
it.
Leigh Klotz: We're still talking about
function/@type, though, right?
Nick van: Yes. If we remove the child
element, then you can have a source attribute. Does it make sense
for an XPath expression to be defined somewhere else?
Steven Pemberton: I think we need a
bit more input from the group. Can you summarize the proposed spec
changes?
Nick van: My last email is good. The
second point fro
http://lists.w3.org/Archives/Public/public-forms/2012Mar/0029.html
Steven Pemberton: I understand that
this is the third change, but it's not fully crystallized out yet.
We should not change this again until we decide on the final
version.
Nick van: I don't mind changing it
again.
Leigh Klotz: So let's say we
require XPath and we allow JavaScript or XQuery, and we don't have
variables in functions and XPath 2 has a kludge for varables, so if
you need more, tell us why you need them and aren't using
JavaScript or XQuery or XPath 3?
Steven Pemberton: What about alternate
definitions?
Nick van: I did add @override so you
can do that.
Steven Pemberton: OK, let's just add a
note for now.
Nick van: I'll add a note about
variables.