W3C Forms teleconference February 13, 2008

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Roger Péerez, SATEC
Doug Schepers, W3C
Steven Pemberton, CWI/W3C
Susan Borgrink, Progeny
Uli von Lissé, DreamLabs
Keith Wells, IBM

* Agenda


* Previous Minutes

* The Forms Newsletter - end of Jan. 2008

John Boyer: What should we be reporting?
Steven Pemberton: The Yahoo news
Leigh Klotz: The F2F
John Boyer: Maybe we should do this in February because there's not enough news.
Erik Bruchez: Can we talk about the F2F decisions?
John Boyer: It's for February.
Leigh Klotz: We don't need to issue on calendar month boundaries.
John Boyer: We can wait until the end of the month and have two more weeks.
Charlie Wiecha: I kind of agree with Leigh; we can send it out when we have something to say.
Leigh Klotz: So we send it out now with the January F2F and last month or we wait until February?
Charlie Wiecha: I think we send it out now.
John Boyer: So, Yahoo, F2F, modularization, future features XForms 1.2/2.0.
Leigh Klotz: What do I say about modularization?
John Boyer: We're taking that on as a direction and it will help us deliver more of the features of XForms independently of version and independently of one another, so they can be used in a more "mashup" kind of way, to onramp to those features more quickly.

* XML 1.0 Fifth Edition


John Boyer: The interesting new feature adds I18N characters to the set of valid characters for tag names and attribute names. So they can create XML 1.0 content that doesn't work in existing processors.
Steven Pemberton: They did this for XML 1.1 and nobody implemented it, so they're merging those changes back into 1.0 in the hope that somebody will adopt them. It seems a failure of versioning, but on the other hand it's not hard to implement and it's generally harmless, and it's a good thing, in that it allows people to use letters in their alphabet that aren't generally allowed. Nick:[irc] not all changes Nick:[irc] only a few changes are back-ported
Nick van: XSL and XML Core has asked most of the XML implementers and the said they were going to implement it. For XML 1.1, Microsoft and another parser vendor didn't want to implement it for some other reason, so those things weren't passed on.
John Boyer: I wonder if this is a failure of versioning per se, but also a failure of XML 1.1, that there are features in it that important members of the community essentially reject.
Nick van: The main problem with it was the 0 character, because IBM requested it, but IBM doesn't want to implement it. Microsoft said C libraries depend on the zero character.
John Boyer: It's one thing to say that all parser implementers will make the change, but at first I was worried about the reverberation through the W3C stack. Within IBM there've been people saying this changes the semantics of SOAP in that SOAP relies on the correctness and understandability of messages for SOAP nodes. It's not just all XML parsers, but things that update them as well. But, I guess the more I thought about it the more I realized that when we look at from the standpoint of the content and not the software, it's not a nightmare scenario of upgrading and things not working together. Right now if you want to use those I18N characters in your tagnames you'd use XML 1.1. If someone did create XML 1.1 content, then that software would fail when it hits the version=1.1 listing in the XML declaration. If we let the characters through, then it fails to parse anyway. So the failures are stable. No instances of that schema with the special characters are going to be processed by software that hasn't been upgrades. So if we let the business case of those characters drive the upgrades, it's OK. The content isn't changed, just the tags, so it's new systems, new schemas, new tags.
Nick van: Isn't it also in the content?
John Boyer: I thought it was tags.
Nick van: It's also the content. The problem was it pointed to a certain version of Unicode.
John Boyer: During the parse it's UTF-8 not Unicode.
Nick van: The spec points to a particular version of Unicode to say which characters are allowed, and the allowed characters are not in the range.
Erik Bruchez: I think the issue is that the new version of Unicode adds more code points as "characters," "letters," etc. and those new characters are now allowed. Outside of elements and attributes in XML 1.0 you can use every single Unicode character, which I think already covers those new characters. There is no restriction on text content.
Nick van: [irc] ...the mechanism for encoding character code points into bit patterns MAY vary from entity to entity. All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode 3.1 [Unicode3];
Nick van: [irc] Character Range[2]Char::=#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
Nick van: http://www.w3.org/TR/2004/REC-xml-20040204/#charsets
Nick van: [irc] new version : http://www.w3.org/TR/2008/PER-xml-20080205/#charsets
Leigh Klotz: I agree with Steven; it's mostly harmless, and the issues associated with changes seem to affect us no differently from any other working group.
Nick van: I was worried about existing software no longer being compatible with XML 1.0, but I talked with an XML Core WG member and became convinced this is the best solution.
John Boyer: I think this is probably not so bad. The transition will happen over time as there is demand for this content.
Leigh Klotz: Do we not respond or do we respond with no objections?
Steven Pemberton: Personally I feel we should let it through. The XML community will shake it out. As XForms group I don't think we should come with an opinion; we should accept the opinion of the XML community.
John Boyer: What do we express?
Steven Pemberton: Perhaps a no comment, saying we have no opinion on the matter.
Leigh Klotz: I had proposed "no objections" but you suggest "no comment" so we should decide.
Steven Pemberton: There are people in the I18N community who feel strongly about this.
John Boyer: Anybody opposed to saying we accept it? OK, so resolved.

Resolution 2008-02-13.1: We respond to say that we have no objections to XML 1.0 PER 5.

John Boyer: The association between namespace URI and tag names isn't specified anywhere; the closest is a schema, and you can declare as many as you want.

Action 2008-02-13.1: Leigh Klotz to respond on behalf of Forms WG to say that we have no objections to XML 1.0 PER 5.



John Boyer: Most of the "1.2 or 2.0" features I put into 2.0 because they didn't fit into the existing patterns of web applications for 1.2. We can discuss them and move them back. Another problem I had with XForms 2.0 was that it said "constraints and componentiation and ..." and what else. To me it seemed more with 2.0 was refactorization across the board. So I decided to characterize 2.0 as refactoring.
John Boyer: The model bullet points are about constraints, plus the not-yet-categorized stuff. For example, generating data based on a schema, as a counterpoint to implying one from the UI, growing it over time. Then there's I18N mail addresses, also for 1.2.
John Boyer: Down into the view layer, there's subtree controls, including user-defined and forms as subcomponents. It includes tree controls, dialogs, XHTML textarea.
John Boyer: Another was creating a node out of nowhere. When we talked about XSLT-like declarations for elements, it started to feel less urgent. There's so much we can already do with insert, it wasn't clear we needed to rush.
Erik Bruchez: If you support multiple expression languages, you could use XQuery instead of XPath. That could allow this.
John Boyer: In XForms modularization, above XForms 2, that's support for multiple expression languages. We tried hard not to create nodes from with the expression language; the DOM doesn't mutate in an expression.
Erik Bruchez: I was looking at XQuery 1.0, which follows the same philosophy, but it can return an element or an attribute. But it's beyond XQuery 1.0.
Leigh Klotz: I really think XQuery is great, having tried the example for ATOM from the developerworks site; it's nothing like the SQL-for-XML it's often billed as, and it's easier than XSLT for many of the things you might want to use XSLT for.
Erik Bruchez: I agree with Leigh; XQuery is in line with XPath, and saxon mixes XSLT, XPath, and XQuery in the same engine.

John Boyer: This looks solid and I'd like to get a first WD out in this quarter.
Erik Bruchez: As a form author, there are high priority things for me. One of my favorite topics is attribute value templates. We've discussed it many times, but unfortunately it's not part of the ease-of-authoring pattern.
John Boyer: AVTs, variables, and XPath are in the refactoring.
Erik Bruchez: How do we as a WG pick whether something is... I see XForms modularization SCXML. Why is this there rather than simple things like AVT?
John Boyer: I think it's not quite the right title; the semantic there is meant to imply that we're making XForms more accessible to web developers, not that we're making it easier for experts to write more complicated applications. That's the bulk of these modifications, optional model etc. I agree it's useful but it has processing model implications. Binding updates are consolidated into ref, nodeset, value, etc. If you don't have one of those, then you'd don't have to follow it. The avt path makes more complicated use cases easer, but it doesn't get at web developers want to get their feet wet.
Erik Bruchez: I agree it's convenient. We spent time designing elements in XForms 1.1 for certain use cases that could be solved by AVT's. So, how do we get to pick what gets in to 1.2 and what doesn't. On the topic of AVTs I recall at least one F2F where there were several people weighing in. We should consider this.

Steven Pemberton: I agree that AVTs would be really useful and valuable, or at least the functionality we tried to achieve. I have a couple of worries, and also want to note we have a couple of other ways to do this. XForms is not a host language; grabbing all attributes for XForms use potentially causes problems. For example, combining XForms with another language that uses AVTs would be trouble. On the other hand we noticed if we could access the hosting document through XForms, you could achieve the same functionality without having to claim the syntax. I think that's the better approach, in a more XForms way, without stepping on other host languages possible toes.
John Boyer: So for example setvalue could ref something in the document.
Steven Pemberton: Yes, an instance with binds that put constraints on attributes. You could set the class if the value became negative; that could affect the styling.
Erik Bruchez: I can see how that could work.
Steven Pemberton: Then we wouldn't be changing the syntax of the class attribute in HTML but we could change it.
Erik Bruchez: There are two uses cases: AVTs in attributes of XForms, and AVTs in attributes of the host language.
John Boyer: I think Steven means it's a slippery slope and people will expect AVTs everywhere.
Erik Bruchez: XHTML doesn't support AVTS. You would to design things in a way that that works. You can put a string with brackets in HTML but it is up to HTML. My primary concern is a lighterweight syntax for XForms.
John Boyer: You could do it for XForms as well; one mechanism to rule them all, so to speak.
Erik Bruchez: Possibly; look at dynamic resource load. You wouldn't write a bind to change the value. I think there is a substantial difference between modifying XForms attributes and XHTML attributes.
John Boyer: How does that get assigned to a particular space? Modularization will ultimately make some of this a bit moot. At the charter level, 1.2 is about the "transitional" work, which is a name everybody hates but is a way to make the basis use cases more consumable. For example, under UI patterns, how do we make it easier to create table alignments? Under composition patterns, we ask reasonable questions about putting different components together. They don't seem to rock the foundations quite the same way; they are targeted at easier authors.
Nick van: [irc] But if Erik wants to create an AVT module, I think we shouldn't stop him of doing that...

John Boyer: That's a good segue.. I don't have clarity on what constitutes a module. Something like AVTs touches everything across other modules. It seems a foundational change.
Erik Bruchez: [irc] Sure, but for a given feature, you do want working group support
Nick van: We have the child element for submission that provides the data; can we say the same for curly brackets. My understanding is that modules add elements or attributes.
John Boyer: Steven?
Steven Pemberton: They can attributes and elements; I don't know if they can add syntactic structure, but I suspect the answer is yes. If you can map those two cases onto XSD types then it's probably not a problem in itself.
Leigh Klotz: [irc] If there is a way to express the effect of AVTs as self-modifying documents then there is likely a way to programmatically transform AVT 's into equivalent AVT-free self-modifying markup.
Nick van: That's what I was trying to say.
John Boyer: They're fairly declarative. You note that the stuff that changes in a document is the stuff in xforms:instance and all changes at the document level flow out from that.
Leigh Klotz: That breaks if you allow instance() or document() to access the host document.
John Boyer: Yes, that's the downside. Javascript that alters the classes...
Leigh Klotz: It's more advanced than document.write and so ...
John Boyer: I don't have to worry about the document changing for signing documents. So AVTs are easier for that. So, that transcends the 1.2=transitional/simplified discussion. So is there too much or too little in here?

Charlie Wiecha: I'm fuzzy on the 1.2 bucket vs. the modularization bucket. What's the relationship between modularization and 1.2 or 2.0?
John Boyer: I expect late binding for modules. If we have a message module or an instance module by last call for 1.2, then they would be 1.2; otherwise, they would be in the bulk of the document as things yet to be modularized. We can actually get a fair ways down the path for most of these because most of the module are refactoring. In modularization we have stuff that used to be in 2.0: signature, validation.
Charlie Wiecha: I thought that schema magic was one thing, but there was a separate document for each that allowed it to have an independent identity and not look at the 1.2 document. Now it sounds like they're 1.2 document chapters. I'm fuzzy on the mechanics.
John Boyer: 1.2 will be a thin spec with feature description; we may turn that into a full spec or a modularized spec. We can decide later. If we create a module now in the XForms 1.2 timeframe, what is the versioning path for later modules?
Steven Pemberton: That's not a problem. It's like updating a DTD, except now you update the driver DTD to point to a newly-versioned module. The language is created with a driver which points to the modules you want to use.
John Boyer: So we could use a model module in XForms 1.2 and further elaborate it (validation with pluggable schema engines) for 2.0.
Leigh Klotz: So modularize the model module later?
John Boyer: Modularize it earlier but not break out the validation module. We might start out with instance in 1.2 with an interface but not plug in multiple expression languages. It would be better to have a module than leave it as monolithic spec?
Leigh Klotz: In the 2.0 era would the model module have its own driver and be pluggable with validation, or does the end point language decide to use one module for model and another for validation.
John Boyer: I would hope it's decided by the equipment that's presented at runtime with IDL for setValidationModule. I'd rather have no pluggable engines in the first version.Leigh: So pluggable means not modularized but alterable by process model definition.>
John Boyer: Charlie, does that answer your question?
Charlie Wiecha: I guess. I'd like to see these documents as separate documents.
John Boyer: They need to be published. XForms 1.2 can then say it depends on them as Steven says, by module and version.
Charlie Wiecha: Then 1.2 wouldn't go to last call, but the set of those.
John Boyer: They both normatively go to last call.
Leigh Klotz: So we would hope for the success of the XSL WG, which produced XSLT, XSL/FO, and XPath separately.
Steven Pemberton: That's the argument at the F2F, that the parts would be usable separately.
Leigh Klotz: It's nice to have a success model to emulate.

Charlie Wiecha: So for independent usage, there needs to be a requirements document.
John Boyer: So we should change XForms modularization to have a picture under XForms 1.2 and then again revised under XForms 2.0.
Charlie Wiecha: Yes.
John Boyer: I think off the cuff, signature, SCXML and separable validation are 2.0; the oths are potentially 1.2. Having a separate submission, instance, and model module is just looser coupling in our existing concepts, corresponding to our ease-of-authoring efforts.
Charlie Wiecha: Then we refactor the modules in 2.0 to have finer-grain.
John Boyer: Such as pluggable schema.
Leigh Klotz: Coincidentally or not, in the wiki you can refactor the http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features page to use the include feature for each bucket and have the buckets be separately editable pages.

John Boyer: The stuff on the wiki is the strawman proposal. There is just one user interface pattern, the wizard, that doesn't have a strawman champion right now. So this is the pattern which attempts to come up with easier markup for sequentially stepping through a process, whatever that means. Is that in or out? Is someone willing to champion that in the 1.2 release? Please think about this during the week. If there's no champion, it won't make it into the release, which is a problem for requirements.

Charlie Wiecha: I think the wizard is important, but I can't volunteer. It's something involving switches I think.
John Boyer: Steven, you're writing the repeat strawman. When might you have something?
Steven Pemberton: After the XHTML F2F next week.
John Boyer: The author can use that as a model.
Charlie Wiecha: We can start using current stuff then.

* IRC Log


* Meeting Ends