Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, webBackplane
Paul Butcher, webBackplane
Uli Lissé, DreamLabs
Charlie Wiecha, IBM
Charlie Wiecha: Briefly, there was
a panel discussion Monday morning to kick off the day. Monday was
dedicated to the future of the browser, with the subtext being the
future of HTML5 and other languages. The minutes are transcribed.
It wasn't super controversional. The real substance of the
discussion happened in the breakout sessions. In Tuesday we
discussed the WGs. On Monday, there was a fair amount of detail on
extensibility in HTML and in particular distributed extensibility,
groups other than the HTML WG needing the ability to have a
well-architected, well-implemented mechanism for adding
extensibility to the language. We differentiated two kinds of
extensibility: language extensibility (new markup without runtime
support in the core browser; no new media, or SIF), including
Ubiquity XForms and ODF, which define behaviors without new plugins
or deployable components at the browser level. That distinction was
quite eye-opening at the meeting and then fairly well endorsed in
the breakout as a useful distinction. The consensus was that
distributed extensibility was quired, and the debate was about
mechanism. There was a distinction between XHTML and HTML; there
was not 100% consensus but there was some agreement that to the
degree that a WG has an ownership for an XML language it ought be
using the XML mechanism for extensibility, i.e. namespaces, and
that if they did not it was a contradiction in the ownership. There
wasn't 100% agreement but that ought to apply use of namespaces in
XHTML. Steven also discussed namespaces in HTML, but that wasn't
broadly agreed, so the question is still open for exactly how to
handle distributed extensibility in HTML. The comments are in the
minutes.
John Boyer: That particular point is
an interesting one; they say on the one hand if you own an XML
vocabulary you should advocate namespaces. On the other hand they
say they want the HTML to have ownership of the "HTML Namespace" so
that XHTML is the HTML serialization of XHTML, so in that sense the
HTML WG has ownership of the XML vocabulary. That leads to the
logical conclusion due to Steven that namespaces should be used in
HTML.
Charlie Wiecha: I don't know the
history, but that last step wasn't accepted. That leaves open the
door that there would be non-namespaced mechanisms in HTML.
Charlie Wiecha: Another point is that
extensibility is a requirement and unrecognized elements should be
tolerated, the concern was that the HTML WG effort for fixup
algorithms for non-WF HTML shouldn't interfere with the
straight-through parsing of the DOM. So the Ubiquity mechanism
depends on the DOM internalization. This also got put on the table
as part of the extensibility mechanism: do no harm to elements you
don't recognize.
Charlie Wiecha: So we came back on
Tuesday to discuss the XHTML and XHTML2 WG relationship. We took
forms of the table for that discussion; that was my suggestion.
There had been a fairly good email discussion before the AC meeting
in response to the straw-man discussion about the design-time
rebranding for XForms, showing it is used in ODF and other places.
Also, I wanted to avoid deep-ending and wanted to discuss the
deeper convergence issues before forms. That was good. It helped
keeping the discussion at a broader level. Steven itemized the
non-forms technologies: RDFa, XML Events, M12N. That was an
eye-opener to other people at the breakout.
Charlie Wiecha: At the end, there was
a challenge to Steven and Sam Ruby to come up with a more detailed
technical analysis of the connection points on a merged activity.
They said this didn't mean ending the XHTML2 WG, but then a new
group to have some scope of work reflective of the analysis that
Steven and Sam are undertaking. See Sam Ruby's history of the
evolution of HTML and where he would see things go in the future.
He seems to say that we need a new direction. He points to Ubiquity
XForms as an example of the kind of thing that needs to be
supported.
Charlie Wiecha: The room was guardedly
optimistic. The different use cases and requirements were not
necessarily an issue.
Charlie Wiecha: For my opinions on
forms, I believe we have a two-by-two design space and we haven't
covered all four. The two axes are MVC or not, and the other is XML
or HTML markup format. We've covered XML+MVC with classic XForms.
We haven't covered HTML+MVC, with data models, instances, bind,
etc. It may be grandfathering those elements into HTML, but it
might be more complicated. We need to describe this.
John Boyer: I had thought that was the
ramp-up trajectory X4H was on. With attributes only, it's
generating a data model. The spec itself has space for your own
model and instances.
Charlie Wiecha: We ought to have a
valid design point of HTML with XForms elements.
John Boyer: That's what XHTML2 is
doing, chameleoning in the elements.
Charlie Wiecha: The point here is that
it's done in a non-XML language.
John Boyer: The tag grammar is
slightly different. For bind, submission, what's the difference
syntactically? How does it change?
Charlie Wiecha: I don't know, but I
want to describe the requirement. The excution will have subtleties
I don't yet appreciate.
John Boyer: The "certain things" that
end tags have is the bucket we want to add to. Otherwise there's
really not much difference.
Charlie Wiecha: We were chartered to
have architectural consistency. We ought to be consistent across
the design space and haven't evangelized that.
John Boyer: Is that the full
story?
Charlie Wiecha: Yes. I was happy about
the AC endorsement of full extensibility.
John Boyer:
http://www.w3.org/MarkUp/Forms/specs/XForms1.2/XFormsForHTML/index-all.html#form-containment
John Boyer: This says that a form can
contain an XForms model using the model element.
Charlie Wiecha: That's wrong; we don't
need the xf: namespace. Moreover, why shouldn't HTML have a model
element.
John Boyer: Maybe we need to tweak the
X4H document.
Charlie Wiecha: That's an execution
issue. Or maybe we need to go back to the core XForms
document.
John Boyer: We need WF only in the
instance data.
Charlie Wiecha: It's more about the
patterns than the transport of the XML language. We need to reflect
that more strongly in our spec. Tongue in cheek, I say there's only
two things wrong with the name XForms: one is the X and the other
is the Forms.
John Boyer: On the X piece, it's clear
that what we have is a general MVC-connector architecture; there
can be alternate syntactic means of activating it.
Charlie Wiecha: ...
John Boyer: We make client-side
interactive technologies, produce implementation reports, follow
the W3C process, etc.
Charlie Wiecha: I was able to book
small rooms at the London location; I have 8 and 10.
John Boyer: Sounds like a go for
London then.
Paul Butcher: Mark was talking about a
company near us that hosts user groups and potentially would run a
mini-conference for users if anyone's interested in pursuing
it.
John Boyer: That was one of the
potential rationales of holding it on London.
Paul Butcher: Mark is
investigating.
John Boyer: Thursday and Friday?
Paul Butcher: Something like
that.
John Boyer: Is the hosting IBM and
webBackplane?
Charlie Wiecha: One of us must attend
to interface with the building people.
John Boyer: We are also slated to have
a virtual day on Thursday June 4th.
John Boyer: Who is the audience?
Paul Butcher: People who want to use
XForms.
John Boyer: OK, so that's a customer
event.
John Boyer: When might we know if
that's going to happen?
Paul Butcher: I'll find out when I
next speak to Mark.
Charlie Wiecha: I posted some notes
about things needed for the SVG controls. A space to construct
visualizations, such as for SVG, related to an underlying repeat.
The work in Ubiquity XForms is a preview. I have three SVG things:
the pie chart, Line Graphs in SVG (from Apple Developer
Conference), and a Circular Histogram from Yorktown.
Charlie Wiecha: Jack is pushing on his
SMIL controller. We thought about using that for a Wizard to
control the SVG.
Charlie Wiecha: Phillipe had a demo at
the AC meeting with Firefox 3.1 with video.
Charlie Wiecha: ... bindings vs the
elements ...
John Boyer: Everybody here
understands that forms are dynamic client-side applications, not
static pizza forms. We mean a generalized data-collection
application with binding to presentations such as the circular
histogram you mentioned.
Charlie Wiecha: There's probably a
layered story in the Backplane. You could use binding, or you could
deal with the binding yourself. It's a little tricky to make sure
the repeat worked properly in Ubiquity XForms implementation. We
might talk about how to make decorated repeats.
John Boyer: Is there room for using
the repeat attributes.
Charlie Wiecha: That's an interesting
attack.
John Boyer: The flaw in that might be
that they aren't there. It might help. There is some scant
commentary in the XForms spec about using these UI-binding
attributes on other elements.
Charlie Wiecha: The roles helped. One
role was value, the other label.
Leigh Klotz: What's the markup look
like?
Charlie Wiecha:
http://ubiquity-xforms.googlecode.com/svn-history/r2616/changes/cwiecha@gmail.com/svg-custom-repeat/samples/svg/svg-loan.xhtml
<xforms:repeat nodeset="wedges/w" role="output-proportional">
<xforms:output ref="num" role="value"></xforms:output>
<xforms:output ref="text" role="label"></xforms:output>
</xforms:repeat>
John Boyer: Are these pie charts
and line graphs predominantly outputs?
Charlie Wiecha: I looked at itemset
vs. repeat. Currently they're just outputs.
John Boyer: That's commensurate with
video output.
Erik Bruchez: We need to know if
the value is submitted as a part, or if it's just the data. The
spec says two things. For one, it says that the node xs:anyURI and
xs:base64Binary should be serialized as a part. The other says it's
only when done by an upload control. I can see how it's useful that
nodes of type xs:anyURI not populated by an upload serialized as a
part, but there may be some useful values.
Leigh Klotz: I wrote it.. it's a magic
step. It's not supposed to be settable, just the upload can set
it.
Erik Bruchez: So you have be able to
copy over the value and use a special value?
Leigh Klotz: You use a special
non-readable model item property.
John Boyer: When you do an upload, it
seems like whatever file has been selected needs to be moved to a
magic internal area. The URL shouldn't be equal to the exact
pathname of the file that's being uploaded.
Leigh Klotz: I don't think it does
that in serialization.
John Boyer: It doesn't say what to
do.
Leigh Klotz: The serialization is
specified by the MIME RFCs. The xml-base type version is one way,
but the CID: URI schema works better and that's what we show in
examples.
Erik Bruchez: It is necessary for the
client to transfer the file to the server. In a server-side
implementation we copy the file over to the server. And we put the
URI in the temporary file.
Leigh Klotz: It's unspecified what the
URI is during processing. I don't think it causes interop
problems.
John Boyer: You can submit afterwards
in a different submission format.
Erik Bruchez: IE6 uses the full path;
Firefox uses the last part only.
Leigh Klotz: I think these are
security concerns and we ask vendors to address security concerns
and give them implementation freedom. We recommend via example CID
and used to specify it but a public comment asked us not to profile
the MIME RFC. We might need to add a note saying to pay attention
to security concerns when an upload is applied to a node which is
later serialized with urlencoded (i.e. in GET).
John Boyer: I don't know that the spec
needs to change, but we may need to ...
Erik Bruchez: Do you put the uploaded
file as base64Binary or update the attachment? if you do a
submission again, then those elements are not sent as separate
parts.
Leigh Klotz: The unchanged URIs will
be kept the same and so the server should understand what HTTP urls
are just like it understands CIDs.
John Boyer: As written the 5th bullet
point doesn't suggest an upload, just an xsd:anyURI.
Erik Bruchez: I'm not sure what we
want by the behavior.
John Boyer: What does the test case
do?
John Boyer: There's what the spec says
and what it perhaps should say.
Leigh Klotz: It says "Element nodes of
any data type populated by upload" and "of any data type" means
"regardless of data type."
John Boyer: That's what you think it
means but it's not clear.
Leigh Klotz: OK. When we hear Erik's
use case we can decide how to fix it.
Erik Bruchez: I'd like to have
control over serialization I can't in 1.1.
Leigh Klotz: I believe implementations
should use a hidden MIP and it sounds reasonable to expose
it.
Erik Bruchez: Even if you clarify the
language, what happens if you use xf:insert to move the node. What
happens if you use setvalue? It it moved? Is it checked?
John Boyer: I'd say it's not kept.
setvalue and insert move data around. They don't have any magic
data nor do they move it.
John Boyer: We can take the
requirement for how to broaden the way to specify multiple parts
and it could be 1.2 or beyond. For 1.1, we can be clearer in the
spec that they only thing that creates a part is something
populated by an upload.
Leigh Klotz: setvalue should clear the
hidden data, and leave the text.
John Boyer: Yes.
Leigh Klotz: If you do repeat and a
series of nodes and upload bound to them, an insert should produce
a new row but not copy the uploaded data, just the URI text.
John Boyer: Yes.
Leigh Klotz: So anything else such as
the use case for downloading a profile with embedded photo and then
uploading it again (GET/PUT in the REST sense) is not possible in
XForms 1.1 series, though we can imagine it for the future.
Erik Bruchez: OK.
John Boyer: So we can make the
language clearer and keep the requirement for later.
Action 2009-04-1.1: John Boyer to clarify http://www.w3.org/TR/xforms/#serialize-multipart and http://www.w3.org/TR/xforms/#serialize-multipart to show that for upload content serialization to occur, the node must have been directly populated by an upload; subsequent setvalue operations will negate the upload; a node copied by some operation such as insert or select/copy will not copy the uploaded content, only the lexical value of the node.
Resolution 2009-04-1.1: We agree to consider control of serialization of attachments in a future version of XForms.