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
http://lists.w3.org/Archives/Public/public-forms/2008Jan/0070.html
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.
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.