Erik Bruchez, Orbeon
Kenneth Sklander, PicoForms
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C (chair)
Uli Lissé, DreamLabs
Keith Wells, IBM
Charlie Wiecha, IBM
Paul Butcher, Web Backplane
http://lists.w3.org/Archives/Public/public-forms/2008Sep/att-0007/2008-09-03.html
Steven Pemberton: No change yet.
Next FtF (October 15-16 Virtual, Oct. 20-21 Cannes)Overview http://www.w3.org/2008/10/TPAC/
Steven Pemberton: Yahoo has
announced a standalone XForms platform
Charlie Wiecha: It didn't look like it
was much more XForms than a few months ago.
Steven Pemberton: It's the
tools.
Charlie Wiecha: It's no model, and
sprinkled together with their own stuff.
Uli Lissé: They merged it in
and dropped teh repetition model. I'm not sure how this affects the
task force.
Charlie Wiecha: Interesting
observation. We can hear more from John next week about TPAC.
Steven Pemberton: I'm not sure how you
can live without repetition in this day and age.
Leigh Klotz: I think the repetition
model is JavaScript and all they want is a shadow DOM for
JavaScript to scribble on.
Paul Butcher: [joins]
Steven Pemberton: We discussed this this morning. Uli, you were looking at an old draft, so not everything you discussed was valid. http://www.w3.org/MarkUp/2008/ED-xml-events-20080625/
Steven Pemberton: The question was
why did XML Events 2 rename some of the attributes? The reason is
global attributes clashing with local ones. Attribute
target is already present on XHTML2 and some in
XHTML1. So target is essentially already taken. However, we're more
than happy to have suggestions for better names than "destid." In
our last F2F in February, we spent a long time discussing and
renaming. For instance, the attribute is not called "to."
Steven Pemberton: As for Nick's question http://lists.w3.org/Archives/Public/public-forms/2008Sep/0029.html
Steven Pemberton: You noticed that
dispatch was renamed dispatchElement; we think it was because it
was different from the XForms version, so it would be wrong to use
the same name as XForms with differences. Part of the problem is
that XForms has all of XPath and XML Events restricts its use of
XPath to make it possible to implement XML Events more widely
without XPath.
Nick van: ...
Steven Pemberton: They use the whole
of XPath, really?
Nick van: Yes, context node, position,
context size, function libraries, namespace declarations in (7)
conditional expressions.
Steven Pemberton: Maybe I'm wrong.
I'll go back and look at the minutes and see if there's a real
reason. Clearly it would be nice to have it close to the forms one
and identical if possible.
Nick van: There's a possible problem
in XForms if we still use target and name. If that's a problem for
XHTML 2 and maybe for XHTML 1.0...is it a problem when XHTML 2
incorporates XForms?
Steven Pemberton: Yes, that's the
problem; we're trying to incorporate XForms without using namespace
prefixes so we have make sure attribute and element names don't
clash.
Nick van: So we have to change target
and name?
Steven Pemberton: XHTML 2 doesn't have
name anymore. HTML 4 has name in
different places meaning different things, and one of those had to
become a common attribute, so we decided to rename them all.
Nick van: So XML events could use
name.
Steven Pemberton: So we could probably
do that, but target is not safe.
Nick van: You use to in
one place and targetid in another.
Steven Pemberton: So you'd prefer
targetid over to?
Nick van: It's serving the same
purpose so you could name it targetid.
Steven Pemberton: It's different;
to directs the direction and targetid is
for listening. But targetid is common.
Nick van: There's a problem in XForms
because they are both target.
Steven Pemberton: If we're going to go
the way of not using namespaces, then we have to resolve these
conflicts one way or another. We've got to resolve them or XForms
can object to dropping namespaces.
Leigh Klotz: What about allowing XML
Events to specify common attributes abstractly and require the host
language to name them?
Steven Pemberton: It's difficult to
solve this problem which is caused by the requirement not to use
namespaces.
Erik Bruchez: The solution used by the
XHTML WG is to use prefixes such as data-. It's ugly, but you could
do it. You could use ev-.
Steven Pemberton: It begs the question
what is the difference between a dash and a colon. Would you have
to use both?
Charlie Wiecha: Yes, you would.
Erik Bruchez: I've asked the question
myself. Do we want to not use namespaces?
Steven Pemberton: What HTML calls a
common attribute is the set to be allowed on any element. We're not
talking about global attributes, which is a namespace terminology
for attributes that must be prefixed. HTML and XHTML have
attributes such as id that can be used anywhere.
Erik Bruchez: Except for the sheer
ugliness, what would be wrong with a prefix?
Steven Pemberton: I don't understand
why anybody thinks that's better than namespaces.
Leigh Klotz: It removes one level of
indirection, for people who can't understand indirection.
Steven Pemberton: ...
Leigh Klotz: How about just allowing
the name to be declared? It's a little more like architectural
forms than namespaces.
Nick van: Then our version in XForms
and the XHTML 2 version would be different.
Leigh Klotz: XForms wouldn't specify
the name; that would be up to the host language anyway.
Steven Pemberton: We did that with
id before but decided it wasn't a good idea.
Leigh Klotz: I'm just looking for a
third way.
Erik Bruchez: Renaming could work, but
the real issue is that these are names for such basic concepts.
Steven Pemberton: This discussion
arose because Nick and Uli asked why the group why we renamed
things, and the answer is because they clash.
Nick van: only for target.
Steven Pemberton: Only for
target.
Nick van: We need to decide in XForms
if we can live with the name change because XHTML is a main target
for XForms; if we can't live with it...
Steven Pemberton: Then we must find
another route. Remember that XForms was a part of XHTML originally
and it was only later that we considered hosting it elsewhere.
XHTML2 is where I hope most XForms work will be done in the
future.
Erik Bruchez: Forgetting about
XForms for a while, if there is a potential for HTML5 to use XML
Events, the ev- would be fairly natural. If you use the XML
serialization, you could keep the option to use a prefix or a
prefix ev-. That would be an alternative; XML host languages would
most likely use a namespace, but they could also use a prefix if
they prefer that approach, and certainly non-XML based HTML could
us the ev- approach.
Steven Pemberton: You lose the
property that you can have one file that works in both versions. I
believe the opposition of the colon is a way of shutting out one
representation of two formats.
Steven Pemberton: So what do we
conclude? The XForms WG decides whether it can accept these names
and if not suggests others?
Nick van: And name?
Steven Pemberton: By all means,
propose it and we'll discuss it.
Nick van: For dispatchEvent, there's
probably a reason.
Steven Pemberton: I'm not sure.
Nick van: If you go to the DOM Events,
it's called that.
Steven Pemberton: That's
possible.
Nick van: I thought perhaps.
Nick van: targetid, etc. I'm not sure
how XML Events people will feel about changing the names to what
they were in XForms.
Steven Pemberton: These things are not
set in stone so I think there's still room for discussing
this.
Steven Pemberton: Here's the link to
the discussion. We can read this later; it's here for reference.
http://www.w3.org/2008/02/19-xhtml-minutes#item03
Steven Pemberton: The second part of the events discussion is this: "Definitions of events that are targetted to elements in different modules (xforms-binding-exception)" http://lists.w3.org/Archives/Public/public-forms/2008Sep/0028
Steven Pemberton: So you'd like
some changes in the way that binding exceptions are
determined?
Nick van: I find it confusing if one
module defines it and another does something else.
Steven Pemberton: Is this a mistake in
the past for re-using events rather than a different event?
Nick van: That's what Erik's comment
was.
Paul Butcher: I think so, too. I think
whether an XPath expression works and whether an idref is valid
seems like two different things.
Steven Pemberton: So we'd define two
different events and would create a difference for XForms in a
minor release. Is that a big problem?
Erik Bruchez: Personally I don't think
it's a problem. The current way is extremely confusing and I wonder
if anyone is using them. I don't, because they don't do what I
think they should do.
Charlie Wiecha: In the data module,
we've changed from a link exception to a link error, which will
also be a deviation on a minor release.
Steven Pemberton: Are you happy with
that, Nick?
Nick van: Yes. We can create an
xforms-id-not-found exception.
Resolution 2008-09-17.1: For http://lists.w3.org/Archives/Public/public-forms/2008Sep/0028 we create a new exception tentatively named xforms-id-not-found.
Steven Pemberton: Nick, are you
happy with the comments on your modules from last week?
Nick van: Yes.
Nick van: If we go to XML Events 2,
then we don't need this module at all.
Steven Pemberton: It's that
drastic?
Nick van: Name, target, and delay on
dispatch don't support xpath so we may need a module to make them
dynamic.
Leigh Klotz: This is an uncoupled
version of switch/case.
Steven Pemberton: So you could do this
with an administrative instance of data.
Paul Butcher: It looks like a way of
duplicating the trigger. As such, I think it means it was written
before the case element of toggle came in. Because toggle here has
a case attribute that is an idref instead of an xpath, you have to
tie the toggles together with toggle and case element underneath.
But even then you need administrative data, but it's smaller.
Kenneth Sklander: I think the use case
is relevant, but I don't like this particular solution.
Leigh Klotz: Should we find somewhere
to stick this use case?
Kenneth Sklander: It's fairly common
and it's a little annoying that you need to have bind.
Erik Bruchez: There may be many
similar use cases; the question is should we have a way to make
custom widgets instead? The use case seems reasonable, but I'm not
convinced by the solution. If this is not a very common use case,
I'd propose instead using a way to re-use markup. This has been
done by Mark, Charlie, and us as well.
Paul Butcher: The only thing that
stops someone from using the case element of toggle without
instance data is the ability to query the status of a state or a
switch the same way we do with repeat. Maybe there is an Xpath
function that gives the currently-selected state of a switch.
Erik Bruchez: In our implementation we
have had such an extension function.
Leigh Klotz: Is there an issue with
the computation engine?
Erik Bruchez: There is an issue about
where you can use index, such as in the controlled bindings. It
does cause problems if you use in some places. The safest place to
use it is in action.
Leigh Klotz: So it is a lot like
action.
Erik Bruchez: It is the state of the
control. A repeat has its selected index and a repeat its selected
case. So we already have this problem. There is already some danger
using this somewhere unless you recognize it in the UI.
Leigh Klotz: What did you call your
extension function?
Erik Bruchez: We call it
xxforms:case(switch-id).
Erik Bruchez: [irc]
xxforms:case($switch-id as xs:string) as xs:string?
Leigh Klotz: Does it seem reasonable
to add this?
Erik Bruchez: I think the use case
that we have that caused us to implement it is that we didn't want
to duplicate something that was slightly different depending on
which case the event was coming from, which case was being
selected. This is meant to be used in actions.
Steven Pemberton:
http://www.w3.org/MarkUp/Forms/2006/xforms-for-html-authors-part2#Model-based
Steven Pemberton: This gives you
model-based switching.
Kenneth Sklander: This can make a
large form to solve a simple problem.
Steven Pemberton: I see. All he's
doing is reducing the code to get the effect.
Kenneth Sklander: And strain on
runtime system, and maintenance.
Leigh Klotz: Is using the case
element and the case function as easy?
Kenneth Sklander: I think it has the
same problem because you have to repeat it in each case.
Paul Butcher: You use the dynamic case
element so it's not the same.
Kenneth Sklander: It would help a
little because it would reduce 26*4 to 1*4. But do you really want
switch/case?
Kenneth Sklander: With xforms-hide he
can have multiple open.
Leigh Klotz: It sounds like this is
xf:group with lazy instance data creation.
Charlie Wiecha: [irc] would rather see
people do this in XBL. it's boiling down some existing function
into a higher level helper element
Leigh Klotz: Yes, as Erik said.
Erik Bruchez: I think it's a
higher-level construct and we should be identifying a way to do
this rather than cluttering the base language.
Leigh Klotz: Do you think this has
identified a need for the case() function?
Erik Bruchez: For 1.2 or 2.0?
Leigh Klotz: 1.2 is closed to new
features I think so 2.0.
Erik Bruchez: It's a desirable
function but I have used it only a few times.
Leigh Klotz: I think macro/meta
language is already an issue but we can just add case() function to
2.0?
Steven Pemberton: So our resolution is
that this is a good thing to include in the future?
Resolution 2008-09-17.2: We keep on hand the use case for http://lists.w3.org/Archives/Public/public-forms/2008Jun/0035.html but plan to solve it with a higher-level meta language such as XBL, not XForms.
Resolution 2008-09-17.3: We add case() function from xxforms:case('switch id') to XForms 2.0 once the Wiki is back up.
Charlie Wiecha: We now have
Ubiquity on the iPhone.
Steven Pemberton: Screenshots?