Alain Couthures [left early]
Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C (chair)
Uli Lissé [irc only]
John Boyer, IBM [arrived late]
Alain Couthures: The extensions are
about subforms, and widgets built with Dojo. It's a big change in
XSLTForms, and it's quite interesting. The subforms are interesting
and useful in some cases. I have to see what's possible with the
widgets.
Steven Pemberton: What are rich
widgets? Controls that map to instance?
Alain Couthures: I haven't seen any
yet. It's based on Dojo. Everything possible with Dojo can be
integrated.
Steven Pemberton: For example?
Alain Couthures: I don't have any
examples yet.
Steven Pemberton: And what are
subforms?
Alain Couthures: A way to a form
inside another one. The modules are in the body and they can be
loaded and unloaded.
Steven Pemberton: Do you submit to the
upper form?
Alain Couthures: I don't know yet. As
far as I have seen, the models are fairly independent.
Steven Pemberton: Do you think there
are lessons we can learn from these?
Alain Couthures: I really think
subforms is interesting for real applications, especially in a
client implementation.
Steven Pemberton: How do we find out?
Documentation? Try it out?
Alain Couthures: I will contact the
author.
Steven Pemberton: I shall take a look
at it.
Alain Couthures: In XSLTForms,
dependencies are stored. Every time refresh is required, depending
on the modified nodes, the expressions are re-evaluated. There is
an algorithm. For circular dependencies, when detected
re-evaluations is started again. It works as it should. For
dependencies, I have added the possibility to, depending on
ancestors, re-evaluation is performed also. I sent the familiary
example evaluating for strings and children, and now it works with
XSLTForms. It's quite useful when XSLT Transformation is performed,
becuase just one child has been modified.
Leigh Klotz: Do you still have the
restriction that each bind element can be only one node?
Alain Couthures: Yes, it can be
removed, but I haven't.
Steven Pemberton: You do special work
to check to see that something hasn't already been bound?
Alain Couthures: Yes.
Steven Pemberton: Would it simplify
your work to remove that test?
Alain Couthures: Probably.
Steven Pemberton: OK, anything else?
Alain, thank you for staying.
Alain Couthures: See you Monday.
Steven Pemberton: Uli isn't coming.
It will be Nick, myself, Alain, and Lars Windauer from Betterform.
I must book teleconference times.
Steven Pemberton: We'll be on from
9AM. This Sunday, Europe goes back to winter time and stops
daylight savings time. So we go back an hour. So it will be an hour
later for the US. So it would be what you now see as 10AM.
Erik Bruchez: So that's 1AM our
Pacific Time. I might call in early in the morning.
Steven Pemberton: We end at 5PM.
Erik Bruchez: That's 9AM Pacific
Time.
Steven Pemberton: I will book the
conference tomorrow and post the teleconference code to the mailing
list.
Leigh Klotz: So it's MTRF and not
Wednesday?
Steven Pemberton: Yes, Wednesday is
the TP day.
Steven Pemberton: I'll be there Sunday
evening. Raman will be around; he might join for a while. The other
person I'm hoping might drop by is Michael Sperberg-McQueen, though
he also has other groups to go to.
Steven Pemberton: Let's see if we want to add anything. We have 33 items, quite a lot to get through.
Steven Pemberton: I have no
news.
Leigh Klotz: It's a little different
from DOM Events / XML Events, becuase it's the common model that
they want to change, not the XML expression on fhte syntax. In this
case, it's the syntax that stays the same and the processing model
changes. So perhaps the idea would be to use optional modules, for
example for namespace support.
Steven Pemberton: I'll try to talk
about it with the Team in W3C.
Leigh Klotz: I believe that anything
in HTML5 for XBL will be a benefit from all processors from
Ubiquity to Orbeon, but we also need the XBL2 specification to move
forward as we're using it outside HTML.
Steven Pemberton: I'll try to talk
about it with the Team in W3C.
Action 2010-10-27.1: Steven Pemberton to discuss XBL2 with W3C Team.
Steven Pemberton: To me, deprecate
means it will be removed in the future. Some responses indicate
that it will be deprecated but not removed, so I don't know what
that means? The risk is that they will later remove it
anyway.
Erik Bruchez: I didn't look at the
wording; it seemed that implementations (bugzilla) say that
DOMActivate report is being removed and is not being added. So it's
clear they're not going to use DOMActivate.
Steven Pemberton: In web
browsers.
Erik Bruchez: There was also a reply
that abstract activation is useful but DOMActivate isn't it. I
didn't get the feeling that anyone was keeping it around.
John Boyer: The deprecation usually
means, as in Java, that two or three versions later they remove it.
With W3C, they are actively removing it now. When they exit CR,
deprecated feature will be removed then, before Rec.
Steven Pemberton: Right.
John Boyer: Current XForms is not
based on DOM 3 events.
Steven Pemberton: Yes, DOM 2
Events.
John Boyer: So they are creating a
problem where we have to have XML Events = DOM 3 Events +
DOMActivate, or we have to move XForms from DOMActivate, which is
not without cost.
Steven Pemberton: Apple had proposed
(in the link) to all hardware events to abstract into a set of
intent-oriented events, rather than hardware-oriented. That's
currently in discussion. The editor of the Events spec said at HCG
they would like to go in that direction. They're going in both
directions at once: remove abstract DOMActivate and add new
abstract events. So instead of DOMActivate, it will have a
different name.
Erik Bruchez: Historically, in
mouse-oriented XForms processors, when we tell authors they have to
use DOMActivate, they get puzzled. An event called click (even if
not a click) ... right now browsers dispatch the click event even
if there isn't a click, for example if there is a space. For
authors, the name "click" is much more intuitive and it's
understood that it might be space bar, return key, enter in a text
field, etc. From that perspective, migrating to the DOM 3 events
names isn't a bad thing for XForms. For now, DOMActivate,
DOMFocusIn and DOMFocusOut need to be kept around in XForms.
Steven Pemberton: It would have been
nicer to call it Activate but they didn't have namespaces. The
reason you want these abstractions is for platform independence,
not just because there are different ways to activate the button.
In those days, click didn't work across browsers. For Apple, with
teh iPad, they have gestures and other things that you do
differently, so they're coming with suggestions for doing these
things abstractly instead of concretely. The name "click" is fine
until you want to distinguish between click and some other
activation. The proposal from Apple is to go in the direction of
abstraction, with hardware and abstract events, so you can
choose.
Erik Bruchez: That sounds like a good
solution.
Steven Pemberton: It seems like form
authors will be more receptive to using click, unless the world
moves entirely to touch interfaces. Right now, most form authors
will be comfortable with just a click event. If you want to make a
distinction, it might be rarer.
John Boyer: I agree with Erik, that
click has come to mean the device-independent DOMActivate; the new
hardware things will have to become HClick or something.
Leigh Klotz: Is that Apple message in
another thread? Can you send that in to this thread?
Steven Pemberton:
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html
Erik Bruchez: Will they pick
"DOMActivate"
Steven Pemberton: We've had
DOMActivate for 10 years now and the DOM3 group is saying that
they're sorry we'll have to change our language and they're making
a new name for it. They seem to be beginning to understand abstract
events and feel that it needs to be re-invented. I don't care about
the name but I do care about them removing something that's been in
use for 10 years.
Erik Bruchez: How they they reconcile
browser vendors who have never implemented it with wanting to keep
it in the implementation?
Steven Pemberton: So perhaps they
could make it optional? What I want is that languages that do use
it could carry on, and understand that it's the same event. In
mixed-namespace documents there would be a risk of different
semantics and different "DOMActivate" events. If we say it's
optional then the browsers don't have to.
Leigh Klotz: So why not say that,
making it optional?
John Boyer: They'll need a reference
implementation that needs to pass the test. They might not allow
passing specific tests without the whole test suite.
Erik Bruchez: The reaction to optional
features is that it should be mandatory or removed from the HTML5
perspective. Maybe what's lost on them is that other people are
making use of the specifications. I would imagine HTML5 would
support DOM Events and see that they would be reluctant from their
standpoint.
Steven Pemberton: If this were HTML
Events I'd be OK with that but it's DOM Events, and for a wider
range of specifications. I understand that for the moment that
HTML5 is .... they shouldn't use this one spec only for HTML events
and forgetting other specs.
Erik Bruchez: That needs to be made
clear.
Action 2010-10-27.2: Steven Pemberton to propose making DOMActivate optional in the light that there needs to be a single definition point for a definition already in place for ten yewards, to point out that HTML5 is not the only consumer of DOM Events, and that there are already DOMActivate implementations in DOM Level 2 implementations which would likely provide CR exit for the DOM 3, and that the Apple User Interface Independence proposal at http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html strengthens the future case for abstract events.
Steven Pemberton: Erik?
Erik Bruchez: My proposal is prior to
our discussion and equates relevance with visibility.
John Boyer: If this takes less than a
day to sort out I'll be amazed.
Steven Pemberton: We're proposing
to deprecate it. Is anyone using it? The potential advantage is
that it adds a hint to the markup that helps with filling it in. I
would very much like to form software that recognizes that the form
is asking for particular information so I don't have to type it in.
It could already fill in my name, for example. So either we don't
deprecate it, as it was intended to make privacy issues obvious, or
possibly that we generalize it to use RDFa and give the same
properties with an extension for other properties without changing
p3p.
John Boyer: We want to have alert and
hint at the node level instead of the form control level. There's a
lot of possibility for other MIPs about data, even though it
surfaces through the form controls.
Erik Bruchez: I believe P3P has to go;
it's clear that it's a dead technology that nobody is implementing.
There are no implementations for ten years. We can't re-write it.
Whether or not we want the features, P3P isn't the way to do
it.
Steven Pemberton: If we generalize it
to a thing to hang properties off, an implementation could use that
thing to hang things off. We don't need to specify the values; they
could use P3P, or other values more generalized, like the class
attribute. The P3P data would go there if you need it. So if John
has some facility, there's a place to hang it.
Erik Bruchez: I don't think it should
be called P3P.
Steven Pemberton: That's fine.
Leigh Klotz: This sounds like a single
MIP containing space-separated list of QNames. We've also heard
about custom MIPs with multiple MIPs. You also proposed
triples.
Steven Pemberton: I mentioned RDFa and
that incorporates triples.