Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Paul Butcher, WebBackplane
Keith Wells, IBM
Nick van den Bleeken, Inventive Designers
http://lists.w3.org/Archives/Public/public-forms/2008Dec/0011.html
Action 2008-12-10.1: John to fix typo in first step of submission (udate instead of update)
Action 2008-12-10.2: Paul to look at http://lists.w3.org/Archives/Public/www-forms/2008Nov/0008.html and send a reply
Action 2008-12-10.3: John to fix two examples in spec where event() is used in a ref and should be in a value attribute
John Boyer: I've added two items to the news section: the Lotus Forms (XForms-enabled product) and the Firefox implementation reports.
John Boyer: It would help to get to the public list responses with some urgency this week.
John Boyer: public list response
needed
Paul Butcher: I haven't done it
yet.
John Boyer: Leigh, public list
response needed.
Leigh Klotz: I'll get to it today.
John Boyer: We had a disconnect in
understanding about whether these attributes repeat the element or
its content. We now have time to get to consensus. The spec says
that it repeats the content of the element. Some people believe it
could repeat the content of the element. Perhaps we could have a
new attribute that defaults to what the spec says now but give
flexibility.
Charlie Wiecha: This sounds like Rube
and Goldberg.
Paul Butcher: It's what we'd call
"Heath Robinson."
Charlie Wiecha: I think we should make
the decision and do what's right.
John Boyer: Offhand, does anybody know
if the tests could distinguish between the two possibilities.
Keith Wells: I'll have to look at the
test cases.
John Boyer: My conjecture is that
there's no conformance issue.
Charlie Wiecha: Is this 1.1?
John Boyer: Once we decide we can
decide that.
Charlie Wiecha: Is there any
motivation to keep it the same? Technically?
Nick van: We use it the way it's
specified and don't have any problems with it.
John Boyer: It's more philosophical
view than a technical problem. Do attributes say something about
the element or the content?
Nick van: Here's a test case that
tests it and we'll need to change the test.
http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/Chapt09/9.3/9.3.5/9.3.5.a.xhtml
John Boyer: There's some consistency;
the repeat element repeats its content, so attributes should as
well. The technical power comes from...you might have to attach
them to a tbody to repeat the trs within it. If you could attach
them to tbars you could create a repeating tr table with multiple
repeats.
Charlie Wiecha: Maybe we extend the
core repeat function and carry that attribute in. That sounds like
a nice function to have...children of repeat element with subsets
of repeated items.
Nick van: You can have multiple tbody
in HTML.
Leigh Klotz: We verified that last
time we discussed this. They can't nest.
John Boyer: I don't think I need
that.
Nick van: You only need the tbody if
you need to repeat the tr.
Charlie Wiecha: Leaving it on the
parent works well with Dojo. There's a nice parallellism with the
repeat element construct. My first inclination was to move it down
but...
John Boyer: In XForms for HTML, I
think it was necessary...really important to ensure that repetition
happened on the element that had the named attribute.
John Boyer:
http://www.w3.org/MarkUp/Forms/specs/XForms1.2/XFormsForHTML/index-all.html#default-data-instance-startsize
John Boyer: The startsize attribute is
what is repeated and it has the name.
Nick van: If you put startsize on the
parent element (tbody) and you need to repeat two rows every time
with a different name, then you can't accomplish it with this
construct.
John Boyer: So you move them both to
the same element?
Nick van: Why?
John Boyer: A form control is an
element that has a name and startsize iterates a form
control.
Nick van: Can't it the same?
John Boyer: It's not a big deal to
move them both. If I put startsize on tbody and left name on tr,
then startsize would be on an element which isn't a form control
because it doesn't have a name. It makes it harder to specify
what's going on. It would not be a big deal to move them both up
though. We need to fix this pretty soon.
John Boyer: I haven't heard anything
from our first public working draft request yet. I'll ping after
the call.
John Boyer: Leaving it as repeating
content seems the best idea.
Charlie Wiecha: Yes, I think so.
John Boyer: I didn't know or remember
the multiple tbody.
John Boyer: We have test suite
conformance, and we have a clear statement of current markup so I
think.
Resolution 2008-12-10.1: We keep repeat-* attributes in XForms 1.1 the way that they are, as repeating content, as tested by http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/Chapt09/9.3/9.3.5/9.3.5.a.xhtml
John Boyer: We don't have FPWD yet
but I wonder if we're getting to the point where we can respond to
this email. He's looking at Dave Raggett's Forms Lite
work, which has similarities to what we're doing with XForms for
HTML, and commenting that he doesn't see a need for declarative
expressions containing JavaScript instead of XPath, which I think
causes anapylactic shock.
Charlie Wiecha: JavaScript or
XPath?
John Boyer: XPath. So if you can't
track dependencies, he argues you don't need it.
John Boyer: ...
John Boyer: I think it comes down to
calculate.
John Boyer: Do we need to respond
now?
Charlie Wiecha: We're producing this
document because our charter calls for it.
John Boyer: I think he's saying that
one particular feature is not required; perhaps that's conformance
feedback.
Charlie Wiecha: So make calculate
optional?
John Boyer: Or recommended.
John Boyer: Here is the conformance:
http://www.w3.org/MarkUp/Forms/specs/XForms1.2/XFormsForHTML/index-all.html#conformance
John Boyer: It might be pared down to
names, /, .., arithmetical operations, and operators. For example,
no namespaces, no predicates. Doing full XPath would be
recommended. So it profiles not just calculate, but constraint and
others. We can say that the calculate attribute is in particular
recommended (modularly). I'm not suggesting that we do that now but
if we get feedback that would resolve it.
John Boyer: I don't think we need to
respond, but we do need to consider the content. Do people feel we
have considered its content?
John Boyer: What is our plan for
XForms for HTML once we get it to FPWD? Is it parallel or do we
work with the HTML5 group?
Leigh Klotz: I thought you said you
were going to work with the Ubiquity implementation.
John Boyer: That's the short path
forward past CR phase. I heard a rumor that they removed their
repeating construct, for example, and might like this one.
Leigh Klotz: I think the route forward
is to for IBM and Mark and Paul release Ubiquity as an end-run
around HTML4 it's also an end-run around HTML5 so I see no reason
to engage directly. We work in HCG through the charter and satisfy
our objectives and if there is a task force we have materials on
it. But our success with this document will come with adoption of
the Ubiquity implementation as a peer to if not Dojo or Proptype
then JQuery. And if there are enhancements to HTML5 that can be of
general utility (in the "kitchen-sink" space) then they are likely
to be useful to the other AJAX libraries as well and so they might
as well hear it from there first.
Charlie Wiecha: That's more a WebApps
issue.
Leigh Klotz: I mean things like
keeping XML safe in the head and body without hacks, which are of
general utility but likely to be heard more from other AJAX
implementation groups.
Charlie Wiecha: Yes, there are some
hacks that are done such as XML in script that we are doing that
AJAX libraries are doing as well.
John Boyer: Maybe that's the approach
them.
Charlie Wiecha: We should have a table
of HTML5 features compared, though.
John Boyer: We need someone to do
it.
Action 2008-12-10.4: John Boyer to find reviewer to do a feature comparison of HTML5 and XForms for HTML.
Charlie Wiecha: I went back to the Wiki http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features and refactored this document. As a result, this is a skinny document that manages a loaded instance and a few bits of IDL for signalling lifecycle.
Charlie Wiecha: As Mark has asked,
what are we calling this. Is it data island or data instance? And
is it XML or more general? I've taken the point that the first
generation is XML but there's an editor's note on the issue. We're
doing refactoring here, not adding functionality, so we punt on the
non-XML for now.
John Boyer: I agree. We can do
extensions if we don't do anyting to limit ourselves. But it's
modularization.
Charlie Wiecha: It's not clear what
we'd do to preserve the future extensibility. Child elements of
instance? Separate variables? It's not clear...I won't speculate
here.
John Boyer: You can't tell this is XML
until you exercise IDL that returns XML. If you call load with a
URL, for example, you don't know what is at the other end of that
URL.
Paul Butcher: Even then you don't have
to have had XML. It just has to be XML-like. JSON, for
example.
Leigh Klotz: JSON seems to have
sprouted a lot of things they said they'd never do such as
attributes. As far as XForms is concerned, ref, nodeset, and XPath,
it's pretty close. They don't have PI's and comments but we pretty
much ignore them.
Charlie Wiecha: Coercing everything
into XML may not be useful.
Leigh Klotz: I think exposing the data
island as JSON is one issue, and accepting JSON data and providing
an InfoSet is another. They're separate issues with separate
audiences. They're almost orthogonal, perhaps 80 degrees off. So we
can probably more easily treat the wire serialization format JSON
here and then leave the accessing the data as JSON to later. JSON
in that sense is merely an API for XML, just like JDOM and XOM are
better Java APIs for accessing XML than DOM is.
John Boyer: ... Serializing and
converting may be expensive for the short term.
Leigh Klotz: What's the IDL?
Charlie Wiecha: getInstanceDocument,
setInstanceDocument, and load.
Leigh Klotz: So you could just
trivially support a DOM-based view via getInstanceDocument and
allow the MIME type.
Charlie Wiecha: That's the MIME type
argument.
Paul Butcher: You don't have to say
it; you can just say that it can process other MIME types.
Leigh Klotz: I think it's trivial to
say that we can load JSON and present it as DOM. It's harder to
talk about the authoring issue of what do do with the data and use
JSON or dot notation, and I claim that Prototype...
Charlie Wiecha: And E4X
Leigh Klotz: are ways of wrapping DOM
with JSON and accessing it in JavaScript, so it's a separate
problem.
Charlie Wiecha: That's a good breaking
point between current and future features.
Charlie Wiecha: OK, next is name:
XML Data Island or XML Data Instance.
John Boyer: We went with the Island
name but Instance is what we use elsewhere.
Charlie Wiecha: Mark asks if we need a
separate load. Isn't it the same as load in DOM2? I call this from
the F2F. Do we need a separate event that says this data island is
ready vs. any other object?
John Boyer: What if the data is
specified internally? Does it still get the event?
Charlie Wiecha: It would seem to be
inconsistent not to, but it also would be a degenerate case. Would
a shadow repeat structure trigger a load event?
John Boyer: Would it show up with @src
or @resource as well?
Charlie Wiecha: Would that influence
the event we use?
John Boyer: Oh, we dispatch the event,
I see.
Charlie Wiecha: Yes, @src or
@resource, we still have to dispatch it. It seems Mark is saying it
is analogous to any other synchronized remote resource.
Action 2008-12-10.5: Charlie Wiecha to recommend whether to use DOM2 load event or custom load event in XML Data Island Module.
Charlie Wiecha: The next issue is
whether we want IDL or not. Perhaps we want language-specific
versions either instead or as well.
Leigh Klotz: DOM provides Java
bindings for example.
John Boyer: So it could be just an
example.
Charlie Wiecha: Should it be
normative?
Leigh Klotz: There's the W3C DOM
package you can get for Java, the interfaces everyone uses. DOM
Level 2 http://www.w3.org/TR/DOM-Level-2-Core/
has IDL, Java, and ECMAScript bindings.
Charlie Wiecha: I can explore this and
develop a recommendation. Are we going to do this elsewhere?
Leigh Klotz: When you do the
JavaScript binding you're going to quickly want the
getAsJSON.
Charlie Wiecha: We don't have to cross
that bridge yet.
Charlie Wiecha: Mark says that the
document is loaded already so load is a misleading name. I don't
think there's a lifecycle about traversing in an XForms container.
I had imagined that someone using this module in isolation would
have to exercise load. Does that make sense? I'd assumed it did,
and that the model module would exercise the load.
Leigh Klotz: I don't see how you can
be wrong on this, so either Mark will agree or there's something
subtle I don't get.
John Boyer: Maybe it's a distinction
between load and reset. That would be the state immediately after
src and resource; it would use the cached copy.
Charlie Wiecha: I think we moved that
out of this module and into model.
John Boyer: The model level would
invoke this reset.
Leigh Klotz: I think we took the cache
out of the lowest level to reduce its cost.
John Boyer: I remember.
Action 2008-12-10.6: Charlie Wiecha to note that DOM Level 2 http://www.w3.org/TR/DOM-Level-2-Core/ has IDL, Java, and ECMAScript bindings and decide appropriate course of action for Data Islands.
Charlie Wiecha: OK, I'll answer Mark.
Leigh Klotz: One more issue, if we
allow remote load of XML and JSON and then we allow inline JSON
we'll need a type attribute.
John Boyer: Charlie?
Charlie Wiecha: If I see inline JSON,
that's consistent with the remote case.
Charlie Wiecha: So you're saying if we
provide remote JSON, provide remote JSON. And if we provide local
JSON we need a mime type?
Leigh Klotz: Yes.
Action 2008-12-10.7: Charlie Wiecha to propose a type attribute for XML Data Islands.