Steven Pemberton, CWI/W3C
John Boyer, IBM (chair)
Charlie Wiecha, IBM
Uli Lissé, DreamLabs
Leigh Klotz, Xerox (minutes)
Keith Wells, IBM
Nick van den Bleeken, Inventive Designers
Roger Perez, SATEC
Mark Birbeck, x-port.net (remote)
John Boyer: Martin's comments refer
to Appendix E, but the draft has Appendix D.
Steven Pemberton: Schema Appendix A is
gone
Action 2007-06-14.1: John Boyer to fix missing Schema Appendix A in latest editor's draft of XForms 1.1
John Boyer: Steve Spreicher is
satisfied that XForms is not trying to give special meaning to
xsi:type, but "perhaps this can be clarified in 1.1 Drafts."
Leigh Klotz: Let's look for
xsi:type
John Boyer: Here it is in 6.2.1
Leigh Klotz: Yes, bullet point 2 "An
XML Schema xsi:type attribute in the instance data." makes it look
like the XForms processor does this, when in reality it's the
Schema processor, so the effect is defined in XML Schema.
John Boyer: So we copy the language
from 4.3.5 instead, maybe say Schema information?
Leigh Klotz: Yes, it's type info from
the Schema processor instead of type info from a Schema followed by
type info from xsi:type.
Leigh Klotz: Also in
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html#fn-id
it says that xsi:type can be used to assign type ID to an
attribute, which it clearly cannot; xsi:type can only assign types
to elements.
John Boyer: Let's treat that as a
separate issue; there was a lot of discussion from David and
Kenneth on the id function and this issue is about complex types.
You can file that as a last-call comment.
Action 2007-06-14.2: Leigh Klotz to file last-call comment on id function and xsi:type
John Boyer: The bullet point will remain as empty; before CR I have to remove it.
Action 2007-06-14.3: John Boyer to manually remove empty bullet point in model-using-atomic before CR.
John Boyer: OK, on the rest of the
points. [reads]
Leigh Klotz: Yes, we agree on the
xsi:type restriction point.
John Boyer: What about
xsi:schemaLocation. Are these two equivalent?
Leigh Klotz: No.
John Boyer: We say in section 6.2 that
we don't use xsi:schemaLocation.
Leigh Klotz: In the Schema for XForms
we say not to process Schema for inline instances when reading the
document.
John Boyer: What about external
instances?
Leigh Klotz: We don't say.
John Boyer: We do in 6.2. "Attributes
xsi:schemaLocation and xsi:noNamespaceSchemaLocation are ignored
for purposes of locating a Schema."
Leigh Klotz: So you can't use xsi:type
in instances if the source of the type library is
xsi:schemaLocation.
John Boyer: So the two are not the
same. But how do we tell the Schema processor to ignore it? Uli
said it wasn't possible a minute ago.
Uli Lissé: Sorry?
John Boyer: I think you can tell it
not to use the Schema location when you run the Schema processor,
and we claim that is is possible, and I thought you said we don't
have any control over that. Maybe not in all processors, but we may
in a number of them.
Nick van den Bleeken: XML Schema says
it's a hint. http://www.w3.org/TR/xmlschema11-1/#xsi_schemaLocation
Leigh Klotz: So in case 2 in the
message, we still ignore the xsi:schemaLocation and so if the
instance has xsi:type then the form author must explicitly list the
Schema, and this is no change.
Keith Wells: The Schema Appendix A got
moved to E.
John Boyer: Thank you. I remember now.
There is a set of normative appendices and a series of informative
appendices and the Schema is not normative.
Resolution 2007-06-14.1: http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=135 On point 1, we made the change to section 6.2.1. So on point 2 we decided it was already in agreement; on point 3, the same instance data outside of an XForms processor might have xsi:schemaLocation processing on, but it is indeed off in XForms.
John: Erik wants what happens when the optional attributes on insert are not specified. In the case where insert contains neither nodeset nor bind (using the context attribute and inserting into children), the xforms-insert event binding is the empty string. I'll dig one of these up. None of our examples have this yet. Eric is supposedly working on it.
<insert context="instance(<code>people</code>)" origin="instance('peopleProto)" ev:event="DOMActivate" />
John Boyer: So if bind and nodeset
are both missing, the binding property returns the empty
string.
Leigh Klotz: Can you get the
context?
John Boyer: Technically the context
isn't the binding.
Charlie Wiecha: It clearly says that
it's the value of the attribute.
Leigh Klotz: It's clear but it's
useless.
John Boyer: It's for the form author
to detect the insert's he's created.
Leigh Klotz: If that's the case then
there should be a way to get the id of the insert itself.
John Boyer: As long as you put an id.
But it's to see which subtree of data. Three triggers may invoke an
insert; if they express the XPath the same way (or easier using
bind) you can tell.
Leigh Klotz: It looks semi-useless to
me; it doesn't tell you whether it's a nodeset or a bind, or what
the context is.
John Boyer: As a spec writer, it would
be nice to re-express the behavior of repeats in terms of listeners
for these events. Right now we say that the inserts themselves
somehow alter the repeat indices.
Leigh Klotz: PicoForms would be
perturbed by using events there.
John Boyer: You don't have to do it
that way; we just specify it that way. Repeat should be detecting
changes of the data and manipulating its index accordingly. I
talked to Raman about this a couple of years ago. He said the
repeat index language in insert is mean to imply that the index
adjustments would occur as a side-effect of insert but not
necessarily as direct programming or implementation of the insert.
I agree with that point, but most people reading the spec who are
implementors see the language in the insert action and they assume
it has to be a property of the insert action. I guess that's what
we want to get away from. Increasingly we're using insert as a
generic DOM manipulator and there may no repeats that are bound to
exactly the same nodeset as the insert binds to. This is a real
problem for insert now; you can insert a child node into an element
via the context, and if the repeat binds to the children of that
same node, there's no way to express how to manipulate the indices
based on the nodeset the insert binds to because it's something
different that what the repeat binds to. Right now, I guess I'd say
that the insert language is technically broken because there are
lots of ways to insert and the repeat indices won't get updated.
I'm not sure how much we should go on about this.
Leigh Klotz: Back to the xforms-insert
binding property.
John Boyer: It's fairly useful. There
are limitations where we could use another property.
Leigh Klotz: I don't understand why
there isn't the correct fix isn't to have nodeset, bind, and
context (context returning the actual context).
John Boyer: So we could assign Erik
the task of doing that?
Leigh Klotz: I'd like to give Erik
latitude to fix it if he wants.
Uli Lissé: Or remove it.
John Boyer: Yes, we could just remove
that property.
Leigh Klotz: This seems
underspecified. I don't understand the usecase.
John Boyer: I'd like to understand
which homogeneous collection is being manipulated.
Leigh Klotz: You're using it as an
opaque datum, not an XPath expression (which it isn't).
John Boyer: Yes.
Leigh Klotz: So I think we should send
fix the narrow issue and then send this back to Erik for
clarification saying that the whole feature seems underspecified
and the use case is not clear.
John Boyer: OK. And the same for
delete?
Leigh Klotz: Yes, good point.
Resolution 2007-06-14.2: On http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=108 We accept Erik Bruchez's request to clarify that the empty string is returned by insert event binding if none is specified. We also ask for clarification on the feature and its use case, because in general, it is not possible for the form author to resolve the value without knowing the context and without knowing whether the binding is a bind IDREF or an XPath expression.
Uli Lissé: And it's in
delete as well.
John Boyer: I did it in 4.4.5 and
4.4.6.
Uli Lissé: Erik says he
suggests getting rid of it anyway unless there is a use case.
John Boyer: I have a use case. I have
a model and two subtrees in instance x and an instance y. For some
reason known only to me, I want to keep some parallel thing going
on in some instance. I only want to do the parallel thing based on
mutations of the second subtree, not the first. In XForms 1.0 for
every insert in the DOM you get the xforms-insert event but you
can't tell what you inserted into. If out here I want to create
some kind of action that does xforms-insert if binding is equal to
some value xyz. If I have a nodeset "abc" that
indicates the first subtree and "xyz".
Steven Pemberton: That suggests that
if neither attribute is specified you want the context.
John Boyer: That's what Leigh
said.
Leigh Klotz: Either
bind/nodeset/context or just an opaque datum, depending on the use
case. John's use case is the opaque datum. There is no use case for
bind/nodeset/context yet.
John Boyer: Can I use the context to
check against in my xpath expression? All of the operators redefine
comparisons between nodesets between comparison
Uli Lissé: You can do the id
function.
John Boyer: It doesn't have an
id.
Leigh Klotz: The other function that
does memory equality.
John Boyer: generate-id.
Leigh Klotz: Is there a way to find
the nodeset by which the position is used?
Uli Lissé:
insert-location-node.
Leigh Klotz: What if we just had the
inserted location nodeset and you could satisfy your comparison use
case with generate-id equality testing.
John Boyer: Why do we need any of
this, designing it this late?
Leigh Klotz: Let's throw it out.
John Boyer: It would be
convenient.
Leigh Klotz: Nobody has implemented it
or knows.
John Boyer: They will in CR.
Leigh Klotz: Let's just move on. It's
not that important.
John Boyer: I agree that the things
pointed out are true, but I don't agree; every time a data model
for the document is created you cannot guarantee that the
attributes are in the same order. The XPath data model lets you use
positioning on the attribute axis, at your own peril.
Charlie Wiecha: Aaron raised this as
well.
John Boyer: It isn't true that you
can't say where to insert.
Leigh Klotz: How do you say to insert
it using XPath?
Nick van den Bleeken: Does the order
stay the same?
John Boyer: The order doesn't stay the
same across XPath invocations.
Leigh Klotz: What spec to we reach
into for language about inserting, since XPath doesn't do insert.
It's an immutable data model.
Charlie Wiecha: There's no
update.
John Boyer: We define the
update.
Mark Birbeck: I can't quite
hear.
John Boyer: I was just saying there is
nothing illegal about claiming you are trying to insert an
attribute a particular location and that it doesn't mean that it's
going to be inserted at that location; it just means it's going to
be inserted in the attribute axis. Someone may say not only insert
the attribute, but also if someone puts in the additional
attributes on the insert action at position=4, I believe they can
attempt to do that and nothing should crash. The very next XPath
that they attempt to evaluate may find that it isn't there.
Steven Pemberton: So you're saying you
can say please put it here, but it doesn't necessarily go
there.
John Boyer: Yes
Steven Pemberton: So why not just say
that?
Mark Birbeck: The bit Paul is
referring to here is the "target location" which is different from
what you're saying which is that an author might say
at="*[5]".
John Boyer: It's the same issue.
Mark Birbeck: In know it's the same
issue, but we're talking about the wording.
John Boyer: So we can tweak the
wording and say that in attributes, the axis is unordered.
Charlie Wiecha: I think that would
make Aaron happy too.
Mark Birbeck: My recollection in
talking to Paul is that the XPath data model says that the
attributes are ordered but that the order is implementation
dependent, so if you insert at position 4 you should get it back at
4. That's not a problem. The problem is that it's insisting that we
write at position 1 and there's no way to guarantee that.
John Boyer: XPath supports a single
nodeset query and it doesn't support a query followed by a DOM
mutation followed by another query; we can't say that the XPath
spec guarantees the attribute order across the mutation, because
some XPath data models are based on hashtables. So there's no way
to guarantee that you put one first.
Leigh Klotz: Where's the problematic
language?
John Boyer: Bullet point 6 doesn't say
anything about the insertion.
Leigh Klotz: The comment says 6a and
6b. Should we just strike that sentence?
John Boyer: We have to do a little
more, in point 7 it mentions the target location.
Leigh Klotz: What is the datatype of
"target location."
John Boyer: It doesn't have one.
Leigh Klotz: So we can say "If the
cloned node is an attribute, "...
John Boyer: "then the target location
is the the attribute list of the insert location node."
Leigh Klotz: Is the insert location
always an element?
John Boyer: No. The context must
always be an element but the nodeset can be an attribute.
Leigh Klotz: So if the insert location
node is an attribute, then insert location is the attribute list of
the insert location node's parent element. Is parent element the
right phrase here?
John Boyer: Yes. The specxml from Eric
has a "TODO" comment about fixing this!
Leigh Klotz: We should tell Eric about
the issue element.
Resolution 2007-06-14.3: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Action?id=105 we change 6a and 6b to say that the insert location is the attribute list of the insert location node's parent element.
Leigh Klotz: Is at optional?
John Boyer: Yes.
Leigh Klotz: What does it say
John Boyer: "Optional
attribute..."This attribute is ignored if the Node Set binding is
not specified or specifies an empty node-set."
Leigh Klotz: Could we add "or
specifies an attribute".
John Boyer: Then we'll have to change
point 4. But it's not necessary because it just narrows it down to
a particular attribute whose parent we then use.
John Boyer: Do we have a problem with
delete? Unless someone complains it is ok. We should be able to
delete node we have a hold of.
Leigh Klotz: I agree.
Steven Pemberton: Personally I
think this is better than what we currently have which is putting
it on the model.
John Boyer: Yes, it says any element
now. We'd have to fish it out of the host language elements. What
happens with conflict?
Leigh Klotz: So this joins the repeat
attributes as being an attribute in a foreign element.
John Boyer: Can you restrict foreign
namespaced attributes on elements using XML Schema?
Leigh Klotz: Yes, in fact you have to
allow them.
Steven Pemberton: If there were a
Schema for this document type, then it would include the xf:version
attribute.
John Boyer: I'd like to be able to
grab all the XForms elements at once.
Leigh Klotz: You already have the
model and the UI scattered.
Keith Wells: You have that problem
with the repeat elements already.
Steven Pemberton: It's nice to have
it on the root element.
John Boyer: What if someone puts it on
the body instead? Does it apply to stuff in the head?
Leigh Klotz: I kind of have a
preference for not requiring it on the root element because it
makes it hard to include XForms without altering the document. I
don't have an opinion (yet) on allowing it.
Steven Pemberton: I see.
John Boyer: [reads] We already have a
way to do this, on the model.
Leigh Klotz: I think that there needs
to be an allowance for an XForms processor integration to specify
the level.
John Boyer: The root attribute does
that. The model attribute is a request from the form author.
Leigh Klotz: I think that legacy
implementations will support no attribute meaning 1.0 but future
implementations are likely to start at 1.1 or 1.2 and not bother
implementing then-deprecated 1.0 semantics.
John Boyer: Our processor doesn't use
the 1.1 declaration but our host language has strong
versioning.
Charlie Wiecha: The model attribute
doesn't help the UI elements.
John Boyer: The UI is instantiated
from the model.
Leigh Klotz: This is supposed to
reduce the flurry of emails by being easier to find but I don't
think the top of the HTML file is a good place to put it. And if
you run this through a 1.0 processor it won't tell you anyway. Why
don't we ask Mark to write an example using the suggestion from
Keith to read the version property and pop up a message.
Steven Pemberton: The mistake is that
1.0 doesn't have this and won't object. In the future they should
object.
Leigh Klotz: We have that on the
model.
Steven Pemberton: The root attribute
is more widely accessible.
Steven Pemberton: What about lazy
authoring where there is no model?
Leigh Klotz: It requires a model for
the model-construct-done and ui init events.
John Boyer: We have
xforms-version-exception to the default model if the version on the
model doesn't match.
Leigh Klotz: I don't have any
objection to allowing it. I object to making it the only way.
John Boyer: I object to that too. So
we have to keep the version attribute on the model. As currently
specified, it doesn't leave an opening. Then we break backwards
compatibility.
Leigh Klotz: ...two issues, XForms 1.0
errata to look at this and XForms 1.1 going forward.
John Boyer: What about xf:output with
mediatype that includes XForms models.
Leigh Klotz: Version conflict with
xf:output mediatype is the least of the problems with recursive
composition inside xf:output.
John Boyer: This is a new
feature.
Leigh Klotz: It's a feature
change.
Charlie Wiecha: It's fairly late for a
feature.
John Boyer: Let's wait for Mark.
Steven Pemberton: It should have a hyphen and be error-information.
Resolution 2007-06-14.4: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=96 we change to error-information with hyphen.
Keith Wells: Let's read the other
comments on this.
John Boyer: Joern strongly disagrees
with allowing xf:version on any element. I agree.
Leigh Klotz: He brings up the dynamic
documents issue, and also says that it's a pity that XForms 1.0
didn't do it.
John Boyer: We can add it to XForms
1.0 Third Edition but we have to add the exception.
Leigh Klotz: Or just say "processing
stops" because it's not handleable.
Steven Pemberton: It's not either/or,
it's one or both.
Leigh Klotz: I think it's model or
both. There are too many objections to requiring it on the root
element.
John Boyer: Then what does it
do?
Keith Wells: If model always wins,
what's the point?
John Boyer: Then what's the
point?
Leigh Klotz: Ask Steven.
Steven Pemberton: I thought this
proposal was for anywhere, not just root element. If we had fixed
it in 1.0 then it wouldn't be a problem to try to tell 1.0
processors.
Leigh Klotz: Does it matter whether
1.0 has the root element or model element in 1.0?
Steven Pemberton: No, it
doesn't.
John Boyer: So I suggest we put this
in the future features list and leave model in for now.
Keith Wells: I agree, we should defer
this.
Steven Pemberton: This is just like
missing it for 1.0; it gives us another legacy version we can't
fix.
John Boyer: Part of the problem is
assuming we can fix it in the future.
Charlie Wiecha: It's not suggesting
taking it off the model.
Keith Wells: A future
requirement.
John Boyer: Later when we aren't doing
last-call issues.
Steven Pemberton: If Mark is just
suggesting this as documentation then I don't think it has any
value add, really.
John Boyer: Yes. To avoid email
there's something you can do to the form instead.
John Boyer: The proposed resolution
(waiting for Mark) is that we defer this as an issue for further
discussion after 1.1.
Leigh Klotz: Something like this
instead:
<xf:message ev:event="model-construct-done" if="property('version') lt 1.1">
This document requires XForms 1.1.
</xf:message>
Mark Birbeck: [joins]
John Boyer: Would you be willing to
accept that resolution?
Mark Birbeck: I'm reading the minutes
now.
John Boyer: We're not based on
XPath 2.0 so this is a future features issue and isn't a 1.1
requirement.
Leigh Klotz: Yes, XForms 1.2.
Resolution 2007-06-14.5: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=107 XPath 2.0 features, though valuable, are not in scope of the XForms 1.1 requirements, so we accept this as for XForms 1.2 future features.
Mark Birbeck: This isn't a new
feature; I was asked to submit this not as a new feature but
because the version attribute on model doesn't work. It doesn't
really achieve what we want it to achieve. If you have a form that
is compatible with XForms 1.0 and XForms 1.1 it will get rejected
if you put XForms 1.1 on there. We had a discussion where we said
we shouldn't be so draconian and give some indication to the
readers of the document but the processor shouldn't be so
draconian.
John Boyer: So backing up a step, the
use case you identified in the issue is covered by the markup we
provided. The other issue you are raising, that the version
attribute in XForms doesn't do what we want it do to, can you go
over that again? I don't think that's correct. I think you said if
you designed a form to work in a 1.1 and a 1.0 processor it would
be rejected by a 1.0 processor. Why? Just leave the version
attribute off.
Mark Birbeck: How do you know that
that's how you designed your form? Authors who are going to cut and
paste. If you take a form that is 1.1 but doesn't use any 1.1
features, why should it be rejected?
John Boyer: We have separately talked
about adding to an erratum for 1.0 support for the version
attribute.
Leigh Klotz: If we did that then would
we have version=1.0, version=1.1, and version missing meaning
processor's choice?
John Boyer: I don't think so. The
author should know.
Mark Birbeck: Suppose a hard-coded RSS
feed submission; the author should remove that.
John Boyer: They're really smart to
write the example.
Mark Birbeck: I wrote the
example.
John Boyer: So they modify your
example?
Mark Birbeck: It seems to me you need
to be too aware of the where the feature comes from. If I remove
the resource element and replace it with action=x then I need to be
aware of that.
John Boyer: That's the reverse case
right?
Mark Birbeck: The document would be
rejected by 1.0 but there's no reason it should be.
John Boyer: You're talking about
downgrading.
Leigh Klotz: Can't we just have
version=1.0 as an erratum, and version=1.1 for XForms 1.1, but if
left off, leave it as unspecified, and say authors "should" put it
on.
Mark Birbeck: If you find any element
that isn't in 1.0 then you must reject the form. Then if
xf:resource pops up it should be an error.
John Boyer: There are features of
XForms 1.1 vs. 1.0 that behave differently.
Leigh Klotz: Why can't we leave it
missing as unspecified?
Mark Birbeck: There are a number of
implementors who aren't going to implement 1.1?
Leigh Klotz: Almost every significant
implementation has already implemented 1.1 features in 1.0 anyway.
I argue for version=1.0 and version=1.1 being strict and no version
being loose.
John Boyer: If the form really depends
on the features then an actual message action would be necessary. I
think that construct would get used more than the attribute
itself.
Mark Birbeck: Possibly.
Leigh Klotz: I agree with Mark's point
that people who say version=1.1 might not know what they're
doing.
John Boyer: I like the proposal that
missing version is whatever version.
Mark Birbeck: Or maybe we can retrofit
cherry-picked versions into 1.0. [leaves]
John Boyer: I think the version
attribute has been shot down before.
John Boyer: Mark's message says
something not enforced, which we can read according to what he said
on the phone as "less draconian." So if we can enforce a
version-conformant processor only when the version-conformant
processor is specified, and if the version is not specified, it's
up to the implementation to do its best job with the markup.
Leigh Klotz: What does an XSLT 1
processor do when XSLT version=2? Is there a compatibility
mode?
Nick van den Bleeken: You can run
XSLT1 in XSLT2 compatibility mode with version=1.
Leigh Klotz: We can do that too.
John Boyer: XForm isn't a host
language though. There's XHTML as a host language which is less
strict and web-do-your-best-job. There are other more strict host
languages such as the one I have. I'm sure there are other types,
but the versioning requirements come from expectations about that
host language.
Leigh Klotz: So you should be able to
let your host language integration specify the conformance
level.
John Boyer: We do it in ours on a
feature-by-feature basis.
Leigh Klotz: Interestingly we removed
the XForms 1.0 normative reference so there's no way for an XForms
1.1 implementation to implement XForms 1.0 semantics because XForms
1.0 semantics is not defined in the XForms 1.0
John Boyer: So we need to remove the
"default value = 1.0" text.
Leigh Klotz: So we do that and we say
that the version attribute is used by the host language integration
to determine which XForms processor to run; the only behavior for a
given XForms processor is that it throws an error if the processor
cannot implement it.
Nick van den Bleeken: What about if we
have 1.2 and it's compatible with 1.0 and 1.1?
John Boyer: I'm sensing a
space-separated list.
Uli Lissé: I'm not sure I like
the no-attribute version.
Leigh Klotz: Right now Chiba supports
1.0 or 1.1 or neither?
Uli Lissé: Something
between?
Leigh Klotz: So neither. And the
documents presently have no attribute, so that's current
state.
Uli Lissé: Right
Leigh Klotz: But if it has version=1.0
you could stop doing the 1.1 behaviors?
Uli Lissé: Right, but I'm still
uncomfortable.
Leigh Klotz: ...
Uli Lissé: ...
Leigh Klotz: There are many
uncomfortable positions.
Uli Lissé: We should do like
XSLT and be strict.
Leigh Klotz: But in xslt, if you leave
off version="1.0" the 1.0 processor won't run it.
John Boyer: OK, Straw poll.
Steven Pemberton: OK.
Charlie Wiecha: No objection
Roger Perez: No objection
Keith Wells: I think it should do its
best with no value.
Nick van den Bleeken: What about
when 1.2 comes out?
John Boyer: So is space-separated list
good?
Leigh Klotz: Is it OR or AND? We have
to decide.
John Boyer: It's AND.
Leigh Klotz: If we change it from
float-like things to NMTOKEN people will put foo-feature in and
expect AND so we have to say specifically.
John Boyer: Then it turns into
feature-codes.
Leigh Klotz: And nobody wants to
urn:uid: feature codes.
Uli Lissé: I don't get
it.
John Boyer: If it works in 1.0 and 1.1
and people put that in and it doesn't work in 1.2 then people need
to put that in.
Uli Lissé: ...
John Boyer: So do we not want
versioning?
Steven Pemberton: One option is to say
that XForm is always compatible but that blocks you off from
certain kinds of additions.
John Boyer: Or you keep having
revisions of past specs.
Leigh Klotz: And retroactively declare
people noconformant.
John Boyer: OK so we remove the
default value of 1.0.
Leigh Klotz: If we make it a list type
then it would be nice to make it a list of a simpleType rather than
a pattern-based restriction.
John Boyer: Hopefully the type is
already described and we just need a space-separated list of
those.
Leigh Klotz: OK.
John Boyer: The model version
attribute has a normative reference to XForms 1.0. The XForms
Processor is a thing that may interpret more than one version of
the language. I don't see how a user agent would choose.
Leigh Klotz: OK, so my proposal for
implementing this won't work, splitting up the functionality. Are
we still doing version not specified means version not
specified?
John Boyer: I'm trying to.
Action 2007-06-14.4: John to change in section 7.12 'stop processing' by 'processing halts', issue XPath/34
Action 2007-06-14.5: John Boyer to fix formatting to relevant and validate attributes to submission.
Action 2007-06-14.6: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Controls?id=30 John to delete the first "Description" in 8.1.5
Action 2007-06-14.7: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Actions?id=75 John Boyer to delete extra double quote at end of example in http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Actions?id=75 (PR actions/75)
Action 2007-06-14.8: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=39 John Boyer to change in section 7.5.3 UI Binding Expressions 'Dynamic dependences' by 'Dynamic dependencies', issue XPath/39
John Boyer: We need to have the
discussion before Roger leaves for his flight, which is a bit
earlier tomorrow.
Steven Pemberton: Roger, you said the
date would work for you?
Roger Perez: Yes, but we would like to
move it.
Steven Pemberton: It's been this date
for more than a year now and people have made arrangements. I for
one would prefer not to renegotiate those dates.
Roger Perez: He said he would like to
move it because of holidays.
Steven Pemberton: Also the next
meeting is eight weeks after that, between September and November.
We also have the issue of which days we would like to meet at the
Cambridge meeting. Are we going to meet on Saturday, for instance?
The meetings start Thursday and run until Saturday at
lunchtime?
Action 2007-06-14.9: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=40
John to change in section 7.6 The XForms Function Library
'xforms-binding exception' by xforms-binding-exception
missing -, issue XPath/40
Steven Pemberton: Should I accept
this?
John Boyer: We had a thin spec, then
last call. That's the difference.
Steven Pemberton: They want to know
about changes to insert and delete processing, not spelling changes
with hyphens.
Leigh Klotz: John, is your objection
to having it writing it?
John Boyer: Writing it, I guess.
Steven Pemberton: I have some notes.
Let me find them. http://www.w3.org/2007/Talks/05-15-steven-xforms11/#xforms11
John Boyer: Do you have the XTech
talk for me to add to the XForms publications list?
Steven Pemberton: http://www.w3.org/2007/Talks/05-15-steven-xforms11/
Steven Pemberton: http://www.ebaymobile.co.uk uses XForms, server-side.
Action 2007-06-14.10: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Actions?id=31, John Boyer to change in section 10.14 Conditional Execution of XForms Actions second trigger tag has wrong closing tag ( instead of ), issue Actions/31
Action 2007-06-14.11: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Misc?id=35 John Boyer to fix 8 typos reported by Gary F Stevens, issue Misc/35
John Boyer: Mark, there's your
proposal for the root element attribute, and the underlying thing
that people have to know too much about version boundaries to get
their forms to work. We've attempted to relax the version checking
to accommodate. The first thing to note is that the default is now
empty string. Empty string is synonymous with no version setting;
then the forms processor is free to use whatever conformance level
is available to it. The attribute would have a space-separated list
of zero or more version strings. If one or more versions is
indicated, then the processor gives an error if doesn't support any
of them.
Mark Birbeck: So it wouldn't work on a
1.2 processor?
John Boyer: Only if it doesn't support
1.0 or 1.1.
Mark Birbeck: So it's a mode.
John Boyer: Yes. If more than one is
specified it can pick any level it wants. There's one more thing
I'll fix. Then I scratched out the note because we removed the
normative reference and Uli said he could live with this if we
added this to 1.0 as well.
Mark Birbeck: OK.
John Boyer: I accidentally deleted the
version exception if the version-setting is on a non-default model
which conflicts with the default model.
Leigh Klotz: It seems to me if the
default model has no constraints and the other two models have "1.0
1.1" and "1.1" then the constraint is solvable.
John Boyer: But not in other cases.
It's easy enough to make your models consistent. We had this
constraint before that all must be equal.
Charlie Wiecha: That breaks the portal
case.
John Boyer: It was broken before.
Steven Pemberton: Should we put the
introduction into the spec?
John Boyer: No
Leigh Klotz: A note, like XForms for
HTML Authors
Steven Pemberton: But as a service to
the reader?
Leigh Klotz: A link?
John Boyer: An informative one.
Leigh Klotz: So it still doesn't
define "conflict." Is it not equal?
John Boyer: Not equal.
Leigh Klotz: So if the first model
says version="1.0 1.1" and the second says nothing then it's a
conflict.
John Boyer: Yes.
John Boyer: If the second model says
1.1 and the first doesn't care, that's a conflict
Leigh Klotz: I worry about the other
case. The first model can set the version, but the other models
should conflict.
John Boyer: OK. But the error should
go to the first model.
Leigh Klotz: OK.
Mark Birbeck: I really like this
functionality but is the name version ok? Mode or processor?
Nick van den Bleeken: It's like
supported-versions.
Mark Birbeck: "There are two ways of
processing this; please use this one." You're saying something
about how you want the document processed, not about the document.
That's right.
Leigh Klotz: A minute ago you said
this was for copy and paste and not understanding.
Mark Birbeck: I'm imagining this will
be used by more experienced programmers. I think this still does
that.
Action 2007-06-14.12: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Submission?id=54 John to change in section '11.6 The resource Element and Attribute' change 'first child,' to 'first child element,' (second occurrence of first child in this section), issue Submission/54
Keith Wells: How do we
respond?
John Boyer: We already said defer to
future on this because we don't know how to get the types out of
the XSD namespace from XSLT 2. We now use the names in the XForms
namespace by default, if not prefixed, so our solution works out
better for XForms authors anyway.
Steven Pemberton: We have an
xforms:yearMonthDuration. These are now allowed to be empty? We
should be clear.
Keith Wells: Those are not listed
under section 5.2.7.
John Boyer: We overlooked them.
listItems should allow empty as select uses it.
Steven Pemberton: It covers zero if
list covers zero.
Leigh Klotz: It looks like it
does.
Nick van den Bleeken: ...
Steven Pemberton: ...
John Boyer: We built the corresponding
datatypes to allow empty strings. We didn't look at our
datatypes.
Steven Pemberton: Otherwise, required
doesn't work. My feeling is that everything in the XForms namespace
ought to allow empty.
John Boyer: Are there any datatypes
other than those six: listItem, listItems, dayTimeDuration,
yearMonthDuration, email, and idCard.
Leigh Klotz: So a listItems is a set
of space-separated empty strings?
John Boyer: We have a real problem
with select and select1 and empty values. We keep having this
debate. David has a use case with a select1 and an item with a
label and a value. So a select of a copy matches empty because the
XPath text value of the complex content is the empty string. It's a
design limitation around select and select1. For listItem and
listItems you would use that but if you try to use a type MIP to
assign them to a node, would you then ref that node with a select
or select1? The argument about empty is required. But it is a MIP
used with a ref.
Steven Pemberton: Nobody really does
this.
Leigh Klotz: Let's check the data
binding restrictions. It does say it is "facilitating."
Leigh Klotz: So are we going to change
listItem to be empty?
John Boyer: We are. listItems then is
a union with empty string.
Action 2007-06-14.13: Mark Birbeck to update schema and text for listItem and listItems to support empty content; we suspect that listItems will have to be a union with empty string.
John Boyer: So here is the new
text.
Leigh Klotz: It says conflict in one
place and compatible in another.
John Boyer: OK. Compatible and
incompatible. Anybody have a conflict or incompatibility with this
text?
Leigh Klotz: OK.
John Boyer: I think it's good
John.
Resolution 2007-06-14.6: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=104 , we change section 3.3.1 to default model version to empty, and define empty to mean that the processor gets to choose the version. If no version chosen is available, the xforms-version-exception is dispatched to the default model. The declaration on the default model is used to make the choice. Later models may offer declarations of model version but xforms-version-exception is dispatched to the default model if their declarations are incompatible with the version chosen.
Steven Pemberton: "already allowed"
and "indicated". I'll put the update text in the issue.
John Boyer: OK.
Leigh Klotz: Let's get rid of the two
lists, and list only our types and define the others by exception.
Let's remove the quasi-basic asterisks and language. Then we have
only one list.
Keith Wells: Michael Kay has the same issue, but wants more information.
Resolution 2007-06-14.7: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=22, and http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=22, they all accept empty; we are fixing the confusing text.
Action 2007-06-14.14: John to remove in
after within in section '11.2 The xforms-submit Event'
(action processing is blocked within in the default processing),
issue Submission/79
Action 2007-06-14.15: http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=57 , John to update the overview table in '4.1 Events Overview' (move xforms-rebuild after xforms-recalculate, move xforms-submit-error to Error indications section, add xforms-output-error)
Keith Wells: Michael Kay points out
there is no * next to xsd:double.
John Boyer: That's an XForms Basic
issue.
Leigh Klotz: It's not XForms Basic;
that's another spec. We just removed the list.
Steven Pemberton: And XForms Basic
does not have double.
Leigh Klotz: But XForms 1.1 might.
Let's move the list of xforms types up.
Steven Pemberton: And with or without
a namespace.
Resolution 2007-06-14.8: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=136 , we remove the asterisks and the table of xsd types and replace it with mention of XSD types, no indication of what XForms 1.0 Basic Profile might or might not do, and a table of xforms-namespace datatypes.
Resolution 2007-06-14.9: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=98 We approve.
Action 2007-06-14.16: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=98 , John Boyer to update to update the listItem, listItems timeDuration, email, and card to types in XML Schema and text to allow empty content.
Action 2007-06-14.17: Mark Birbeck to update schema
for email to to wrap regexp pattern in (...)?
Steven Pemberton: There's a problem between lexical space and value space. He says that in http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6
Resolution 2007-06-14.10: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6
we respond that we accept and will be clearer, but there is
something in section 6 already.
John Boyer: Do we convert here? What's
the pattern? What's the common practice?
John Boyer: Should we convert to the
RFC 2822 space or not?
Steven Pemberton: Do we convert to
space here or should we use Unicode email addresses? I will ask
him.
Resolution 2007-06-14.11: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=10 we respond that we would like to a regular expression that matches email addresses including international ones (both left and right of @).
Action 2007-06-14.18: Charlie Wiecha to look up lexical and value space for http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6 and http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6 and confirm lexical/value space and provide the email screenshot for 8.1.2 input control and spec text for the conversion for international email addresses.