W3C Forms teleconference September 17, 2008

* Present

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

* Agenda


* Previous minutes

* Wiki


Steven Pemberton: No change yet.

Next FtF (October 15-16 Virtual, Oct. 20-21 Cannes)

* News (Yahoo)

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.

* News (Merging of Web Forms 2 into HTML 5)


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]

* XML Events


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

* xforms-binding-exception


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.

* Review of Actions module


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.

* xforms-hide


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.

* Ubiquity Progress

Charlie Wiecha: We now have Ubiquity on the iPhone.
Steven Pemberton: Screenshots?

* IRC Log


* Meeting Ends