Steven Pemberton, CWI/W3C
Leigh Klotz, Xerox (minutes)
Charlie Wiecha, IBM
John Boyer, IBM (chair)
Uli Lissé, Dreamlabs
Erik Bruchez, Orbeon
Nick van den Bleeken, Inventive Designers
http://lists.w3.org/Archives/Public/public-forms/2009Apr/0003.html
Charlie Wiecha: I've reserved rooms
at the IBM South Bank location.
Steven Pemberton: It's a wonderful
location in London.
John Boyer: Location details?
Action 2009-04-22.1: Charlie Wiecha to put location details for next F2F on the wiki.
Steven Pemberton: Mark is
organizing a meeting.
Charlie Wiecha: Yes, and the
presentations.
John Boyer: And a sign-up
page.
Charlie Wiecha: Maybe Mark or Paul who
are co-hosting could list the accomodations.
Steven Pemberton: Here's my London
guide: http://www.internetguideto.com/london/
John Boyer: We need the agenda
items.
Steven Pemberton: The is the
last-but-one in this current charter. I'd like to talk about XForms
2.0 so we could start planning a charter.
John Boyer: We're pushing ahead
with our finance application, and integration with SVG components,
and structural transformations. One of the XForms 2.0 topics is
structural binds in addition to value binds; we need a list over
another.
John Boyer: We also discussed
df-dojo-type=repeat. Have you followed Sam Ruby's blog post about
HTML re-unification? http://intertwingly.net/blog/2009/04/08/HTML-Reunification
It mentions Ubiquity as a project using an HTML parser to provide
extensibility. It comes down to DOM consistency (colons, local
names). I did respond after a few days; there wasn't any discussion
after it. We have a lot of concepts in the Backplane that apply
here, even in a non-XML way. There has been some disagreement and
discussion.
John Boyer: We're still looking at
integrating Jacks' Ubiquity-SMIL that Mark did. There's some
sequential parallel execution work there and Jack has picked it
back up.
John Boyer: I'll posted a revised
draft of the XG report. We did get a charter extension through
October and then wrap up the report.
Leigh Klotz: Which of these should
I add the attributes to?
John Boyer: It ould be more HTML5 and
XHTML5.
Leigh Klotz: Which does Ubiquity
XForms work with?
John Boyer: Mostly HTML4. There are
some XHTML issues.
Charlie Wiecha: There are a couple of
settings. The XHTML one is mostly OK. You sometimes have to tweak
browser setings.
John Boyer: So they should work in
current and future.
Charlie Wiecha: It does point out the
topic of modularity, that we have to have this diiscussion.
Leigh Klotz: Parser is the syntax;
Preset is the Schema.
John Boyer: So hopefully it would
appear as a new option on each. That helps makes the modularity
point.
Leigh Klotz: As Charlie pointed
out.
John Boyer: Erik asks if "known" at
serialization means it must be known from the instance.
Steven Pemberton: So "if the filename
is available" is about the file coming from a scanner?
John Boyer: Yes, it's about device
independence.
Leigh Klotz: We put in these binding
sites because I said there was no way to serialize the info in XML
instead of MIME headers. I think Dave Hyatt suggested the bindings
and Micah Dubinko did it. There was no thought given to reading it
back in from the instance.
Erik Bruchez: Yes, this is the same as
the question before. Are they available through magic means as the
file is, and it's up to the XForms implementation what available
means? The filename may be available, but the mediatype may not.
After that step is over, does available mean stored in the instance
or obtained?
Leigh Klotz: Historically this was
designed to work by magic, and when we added the bindings we
considered only writes to the instance. So if someone changes the
instance afterward, we gave no thought to what happens to
serialization after.
Erik Bruchez: You can expect a
serialization to pick them up.
John Boyer: Upload makes the setting
and you can change it after.
Leigh Klotz: Yes, but when you
serialize, say as multipart/form-data, do we follow the binding and
serialize it based on the changed data?
Erik Bruchez: You can imagine an input
field that lets the user to provide a mediatype. However, if the
form author doesn't do that, what happens during serialization? Is
it unknown, or obtained magically?
Leigh Klotz: I think personally both
use cases ought to work, but I don't think we've given much thought
to it and I don't know that the spec says it.
Erik Bruchez: I think there's two
things: do we want to do it that way, and if so, clarify the
spec?
Leigh Klotz: What do you currently
do?
Erik Bruchez: We look at bindings; and
we decide they are not available if there are no bindings. We do
not implement the magic aspects. We do implement the modified
versions. But I would have to double check that.
Leigh Klotz: What do you do about
xs:anyURI binding?
Erik Bruchez: We do not implement what
the group decided; we check all the URIs and dereference them all.
Actually, I will have to check the code. As we saw last week we
have some issues.
Leigh Klotz: I think last time we
discussed an internal MIP (covered under security reasons) that
marks a node as an uploaded content, so that you prevent script
from uploading password files. You might as well store the filename
and mediatype internally there, so you can serialize it as MIME
headers even if there is no filename or mediatype binding into the
instance.
Erik Bruchez: Yes, it's not hard to
implement, but do we do this and then do we clarify the spec? We
need to clarify what "available" means.
Leigh Klotz: It always worked before
we added the binding, and that's what "avaialble" referered
to.
John Boyer: I got the action to
clarify the spec. We need to say what it does with the node values
and the values that were gathered by the form control.
John Boyer: "Clarify that upload
activation produces content and possibly filename and mediatype
info as metadata. If available, filename and mediatype are copied
to instance data if upload filename and mediatype elements are
specified. At serialization, filename and mediatype from instance
data are used if upload filename and mediatype are specified;
otherwise, filename and mediatype are drawn from upload metadata,
if they were available at time of upload activation."
Leigh Klotz: It works for me.
John Boyer: Does that work for you
Erik?
Erik Bruchez: Looks good.
Action 2009-04-22.2: John Boyer to clarify upload filename and mediatype handling as described in minutes.
John Boyer: This is from Vlad, who
works with me. I dealt with the 8.1.1 editorial issue.
John Boyer: The question is why a
repeat does not receive relevance events. The reason is that it
does not have a single-node binding. However, as a container, it
could be based on all of the things which it contains. As a triage,
it doesn't sound like 1.1; it could be 1.2 or beyond. Is that
fair?
Charlie Wiecha: Yes. I have sympathy
and I have some related issues. Also filtering value-changed events
at the repeat level. I think it's not 2.0, but I think the event
functionality at the container level is limited.
Leigh Klotz: I've also had some issues
in a project we did with disabled items in itemsets.
Charlie Wiecha: We need to think
through the hierarchy of those events.
John Boyer: And XML Signatures and
repeat: the repeat itself at a visual level you can think of it
styled with a border, so it has a visual countenance, so it starts
to matter when you're deciding what's signed.
Charlie Wiecha: The pie chart is a
visualization of repeat items. It's hard in Ubiquity to figure out
when to change the visualization because we don't have repeat-level
event support.
John Boyer: We thought about the
context attribute everywhere with a defined run order. So if we put
a context or a nodeset on a repeat, it's not a big stretch to put a
single-node binding ref to provide a context for the subsequent
nodeset, but also relevance.
Charlie Wiecha: There's a useful
combination that's useful elsewhere.
John Boyer: You could wrap a group
around the repeat; it's like select/itemset. Maybe that's good
enough. But in terms of issue classification, it's an issue, but
not 1.1. So move to 1.2+ discussion.
Resolution 2009-04-22.1: http://lists.w3.org/Archives/Public/www-forms/2009Mar/0007.html is an issue but beyond 1.1.
target on submission
http://lists.w3.org/Archives/Public/public-forms/2009Mar/0048.html
Steven Pemberton: We have a virtual
F2F tomorrow and will be talking about this as well.
John Boyer: The big issue is the
target attribute on submission.
Steven Pemberton: And
http://lists.w3.org/Archives/Public/public-forms/2008Sep/0029.html
Steven Pemberton: Markus Gylling
noticed this when he started producing the RNG Schema for
XHTML2.
John Boyer: It looks like resource,
encoding, and target.
Steven Pemberton: For encoding I don't
think there's a clash.
John Boyer: And resource.
Steven Pemberton: I believe it was
Mark's opinion that resource wasn't a problem.
John Boyer: That boils down to
target. We have it to submission and dispatch.
John Boyer: Have you had further
discussion on alternatives?
Steven Pemberton: It would be a bad
idea to have the same attribute mean different things in different
places, since the general one appears everywhere. It makes life
difficult for the author to have target mean something
different in one place and have a different syntax. If the syntax
is the same it doesn't matter that the meaning is slightly
different.
John Boyer: The last one doesn't
solve it because there's no namespace so you don't know what comes
from XForms and what doesn't. So use xf:target?
Nick van: What does
target in XHTML2 do other than an a element?
Steven Pemberton: href is also common
now. You can put it on any element.
Nick van: Does href need to appear on
submission? Does it make sense?
Steven Pemberton: XForms is full of
things that have unexpected uses so I'm reluctant to say no.
Nick van: How about in the head? You
can't click on it.
Steven Pemberton: But you could send
DOMActivate. If the syntax is compatible, but they'er not. The
normal target is just an identifier; XForms has an
XPath syntax.
Leigh Klotz: Do we have a
target element?
John Boyer: No, because it's already
XPath.
Leigh Klotz: So just turn
target into an child element of submission and use
@ref and @value.
John Boyer: But what about
dispatch/@target?
Leigh Klotz: But that's different; so
we have to problems. @target means two things and
@target clashes with XHTML2
@target.
John Boyer: Or just rename
target.
John Boyer: How about having XHTML2
rename submission/@target on import.
Nick van: It's already out in XForms
1.1.
John Boyer: When the attribute is on
xf:submission it's called target, but when you have
xhtml2's submission, the attribute name could be
@dest.
Steven Pemberton: We could make it an
operation of introducing a new attribute and deprecating the old
one, so in XForms outside XHTML2 it continues to work, but we have
an alternative which is the only one that works in XHTML2. In XML
Events 2 it's already called targetid for dispatch. That that one
is less of a problem, I think. So we could have target
and targetid on dispatch to allow for a transition period.
Charlie Wiecha: That lets the same
content be used in both contexts.
Steven Pemberton: We don't rename it;
we add an extra equivalent attribute and deprecate the old
one.
Leigh Klotz: And say what to do when
both are there.
John Boyer: Use the new one.
Steven Pemberton: back in a minute.
John Boyer: So on XForms
submission, what do we call that new attribute.
Leigh Klotz: Just make it a child
element and don't add an attribute.
Nick van: We've never done that.
John Boyer: mediatype child element
and @mediatype on upload are different.
Nick van: I personally prefer to have
attributes.
Steven Pemberton:
@targetref
John Boyer: By calling it targetref we
can still have our target at some later point in
time.
John Boyer: What do you think is
best?
Steven Pemberton:
targetref
Charlie Wiecha: yup
Nick van: I prefer an attribute
John Boyer: +1
targetref
Nick van: +1 targetref
(no strong opinion about the name)
John Boyer: This is an XForms 1.1
change, right Steven?
Steven Pemberton: Yes.
John Boyer: So we add
@targetid and @targetref and in XHTML2
you ignore the deprecated attributes @target on
dispatch and submission.
Steven Pemberton: Yes.
John Boyer: But you're comfortable
with leaving @resource?
Steven Pemberton: Yes, because the
syntax is the same?
John Boyer: So are we resolved to add
@targetid to dispatch and @targetref to
submission?
Resolution 2009-04-22.2: We add
@targetid to dispatch and @targetref to
submission in XForms 1.1 and deprecate @target.
Action 2009-04-22.3: John Boyer to add
@targetid to dispatch and @targetref to
submission in XForms 1.1 and deprecate @target.
John Boyer: And test cases? And the schema?
Leigh Klotz: Should we remove the
test for deprecated features?
Nick van: Or make them not
required?
Charlie Wiecha: We do test
@resource and @action.
Nick van: Is it mandatory?
John Boyer: Yes.
Leigh Klotz: But @target
can't be mandatory since XHTML2 isn't going to do it?
John Boyer: Let's just add the
test.
Leigh Klotz: But how can it be
required?
John Boyer: It's the XForms 1.1
namespace. We can change the status of tests for deprecated
attributes to be recommended.
Action 2009-04-22.4: Nick van den Bleeken to add
required tests for @target to @targetid
to dispatch and @targetref to submission in XForms 1.1
tests and change the @target tests on dispatch and
submission to be recommended.