Blake Joes, ViewPlus/DAISY
Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Uli Lissé, DreamLabs
Keith Wells, IBM
John Boyer: The next F2F meeting is
in November; October 19th is the deadline for registration.
Leigh Klotz: I won't be attending in
person, but by phone.
Lars Opperman: I also won't be
attending.
John Boyer: Please register and come
if at all possible.
John Boyer: I'm waiting for Steven to make the request to get on the director's calendar, but we don't think they'll need a meeting. We're hoping for the end of the month.
John Boyer: Get out and blog this.
We're getting questions about it; one is "How open is it?" I had
thought it was open to anyone attending the conference.
Charlie Wiecha: That was my
expectation.
John Boyer: They're asking if it's
open to the public as well.
Charlie Wiecha: It's a matter of
having to register with the conference itself.
John Boyer: They said they'd let it be
open to the public and put out a separate signup sheet.
Leigh Klotz: Then there's no pressure
to close it.
John Boyer: I'll do that then.
Mark Birbeck: [leaves with
apologies]
John Boyer: We don't have a clear idea
how many are attending but we'll ask to prepare for a larger room,
as there will be no conflicting events.
John Boyer: We need someone to
answer these.
John Boyer: Would someone answer the
first one, a function to get the query string? He's forwarded it
from his www-dom message.
Leigh Klotz: I can answer this from
the XForms perspective.
Action 2007-10-17.1: Leigh Klotz to answer http://lists.w3.org/Archives/Public/www-forms/2007Oct/0003.html from the XForms perspective.
John Boyer: The next one is the
copy element. Anybody? Erik?
Erik Bruchez: I'm looking...I have
some questions myself.
John Boyer: If you have questions,
post them here. If you have difficulty then we definitely need to
know about it.
Action 2007-10-17.2: Erik Bruchez to answer http://lists.w3.org/Archives/Public/www-forms/2007Oct/0000.html
Leigh Klotz: Isn't this just a
Mozilla bug? Mozilla should be sending only xml requests. However,
we do need a way to specify the accept content type in XForms 1.1
if we don't already because we can accept non-XML responses.
Nick van: Submission already has
this.
Leigh Klotz: What about
instance/@src?
Nick van: That's always XML.
Leigh Klotz: Oh.
Lars Opperman: There can be other
types.
Leigh Klotz: You mean text/xml or
application/*+xml?
Lars Opperman: Or text/plain and parse
it anyway, though that might be an edge case.
John Boyer: Can someone write these
up?
Lars Opperman: I can do that.
Action 2007-10-17.3: Lars Opperman to write up suggested changes to XForms 1.1 in response to http://lists.w3.org/Archives/Public/www-forms/2007Sep/0006.html
Leigh Klotz: We have an
implementation status page.
John Boyer: I think he's talking about
the wiki. I can take a stab at answering this on unless someone
else would like to do it.
Action 2007-10-17.4: John Boyer to answer http://lists.w3.org/Archives/Public/www-forms/2007Sep/0001.html
Leigh Klotz: That's mine. I'm
confused; am I supposed to write new examples?
John Boyer: Just a brief SOAP example,
which I can do. And modulo the GET default.
Action 2007-10-17.5: John Boyer to produce simple SOAP submission example.
John Boyer: We got Erik's response
and not much else.
Leigh Klotz: I reported that we had
originally said post but removed it.
John Boyer: I kind of like the
specificity, and would selfishly not like to create another work
item for myself. Is there anyone who strongly feels we have to get
rid of method=get?
Leigh Klotz: To me this sounds like a
next-gen/transitional issue.
Nick van: [irc] I don't have a real
opinion about this.
John Boyer: Sensing silence here, it
doesn't sound like there are strong feelings here.
Resolution 2007-10-17.1: We leave the issue
of default method=get for a future release.
John Boyer: Steven's not here, but
I'll raise it briefly. I think there was some understanding that
the src link on an instance, if it failed, the XForms processor
might fail-over to using internal instance data; but that isn't
what happens; you get an xforms-link-exception.
Nick van: [irc] I always thought that
the exception was raised
John Boyer: Nick is correct; I thought
it would be useful to have a failover. Does anyone on the phone
care enough to propose spec-ready text?
John Boyer: I sense that as not
wanting to proceed; if Steven cares he can raise it but I'll
consider the matter closed for now.
John Boyer: This is a last-call
issue.
Erik Bruchez: First, I wanted to make
sure that I had an example of acomplexType with
simpleContent.
John Boyer: I agree, that looks
correct to me.
Erik Bruchez: The second part is that
the type now has nillable=true, so if the author puts an
xsi:nil="true" in the instance, is this meant to work as in XML
Schema. One of our users asked; we don't implement this. It seems
like xsi:nil isn't related to the validity of the element and not
just the datatype part.
John Boyer: If you say xsi:nil="true"
doesn't that mean that not only can it accept empty but that state
is invalid unless it is empty. I thought you had to have the
attribute changing its value to reflect what the content actually
was. We can do that with a calculate.
Erik Bruchez: I'm not sure it does
that; by simpleContents...what my type example does is that defines
the contents of the element in two parts: one part is an base type
of state values and in addition adds an attribute to the element.
Clearly to me, the attribute is not going to be validated. It would
still validate the datatypes. This example uses an extension
nillable=true. If I were to have an empty content, it would still
be valid because it's allowed to be nillable. So an empty string
would still validate as true in XML Schema. If I don't put
xsi:nil="true" then I would be invalid.
John Boyer: Am I right in guessing
that xsi:null=true is attached to the element than to
the simpleContent declaration?
Erik Bruchez: I don't think you can
put it on the simpleContent.
John Boyer: It seems to be a statement
about the content element but it is a statement about the content
of the element.
Erik Bruchez: My understanding, not
very advanced, is that I would expect this to related to the
textual content of the element. That appears to be a constraint on
the content of the element. The user would assuem that
nillable=true would do something, but the Schema specs says it
determines the validity of the element, so it's not pure dataType
validation. On one hand you have a strict datatype
declaration...
Nick van: If you have that type that
Erik defines and you assign it to the element state it would be
invalid XML; the parser would not allow it. It's not consistent to
specify a type. If you have a schema and that schema says that
state is of this complexType state-element then this piece of XML
will not validate according to the schema; no content is allowed if
xsi:nil=true.
Erik Bruchez: That is true. There may
be other things like this. One problem we have in XForms which we
postponed was when the XForms engine performs a full Schema
validation and when it performs datatype validation.
Leigh Klotz: Is this an issue about
bind type assignment? Schema validation isn't done at instance load
time.
Erik Bruchez: In this case you're
binding this type to the element. Is the type property marking the
node as valid or invalid in this case? If you just perform the type
MIP validation, what is the result?
Leigh Klotz: We removed the copies of
Schema facets and constraints such as minOccurs and maxOccurs but I
had proposed a nillable one. Recently I proposed it as "optional"
MIP which is like xs:nillable but means simply to type validate
only if non-empty. That's a better solution than the union with
empty string and we shoudld consider it for future versions of
XForms.
John Boyer: Isn't that just
"required"?
Leigh Klotz: No, it's a tri-state.
Required means must be non-empty. If you don't say
required=true() it defaults to
required=false() and means that it may be empty, but
if it's got a datatype, it cannot be empty. We need optional to
mean type-validate if non-empty.
Erik Bruchez: ...
John Boyer: ...
Erik Bruchez: ...
John Boyer: Validation of a type MIP
is datatype only, whenever you do it; whatever you get from simple
content or simple type.
Erik Bruchez: Should we consider
nillable then?
John Boyer: I didn't think there would
be a difference in validation from UI and full validation.
Erik Bruchez: There would be, if this
is part of a document, and I don't have it in my element, then full
Schema validation would say it's invalid. Then I bind that siame
type...
John Boyer: YOu have xs:element,
name="state-element". Doesn't that mean that Schema will apply that
complex type definition to elements named state-element?
Erik Bruchez: Right; it won't touch
that particular element.
John Boyer: So that's badly
named.
Erik Bruchez: I'm not sure that was
intentional. Either it's part of the element or it's purely part of
the data type. Or say it's friendlier.
Leigh Klotz: I have a contrarian
view. This is a Schema problem and not ours, but unfortunately
nillable is Schema structures so bind type can't use it. It will be
caught on submission with XForms full but not otherwise. If you
have xsi:nil out of sync with then content, then it's your fault as
a form author and you should have, as John points out, use
bind/@calculate to make sure it's always right.
Erik Bruchez: Doesn't sound contrarian
to me.
Charlie Wiecha: ...
Erik Bruchez: ...
Leigh Klotz: Do we say we're not
supposed to set xsi:nil when we submit?
John Boyer: We don't. The issue here
though isn't about the valie of xsi:nil; it's about the association
between the Schema type being done by type MIP only.
Leigh Klotz: Let's move on.
John Boyer: Let's add a note to the
spec saying that nillable doesn't apply when applied through the
type MIP, and respond to Erik.
Erik Bruchez: OK
Resolution 2007-10-17.2: We add a note to the spec saying that nillable doesn't apply when applied through the type MIP. http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=92
Action 2007-10-17.6: John Boyer to a note to the spec saying that nillable doesn't apply when applied through the type MIP and respond to message. http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=92
John Boyer: I thought we'd answered
this one already. We expect xsd:date to be there, even if not
declared. Similarly for xsi:type. Does that seem reasonable to you,
Erik?
Erik Bruchez: I think we may have
discussed this at some point. I think Mark Birbeck was waiting on
this as well. So we don't import a Schema but the xsi:type is
processed, it increases our ties to Schema, and the document
happens to contain xsi:type.
John Boyer: I think it has to be. We
also have type MIPS without schema
Erik Bruchez: Yes, but that's just
types. It doesn't apply to Relaxng, but types do. With XML Schema,
we have funny things happening with xsi:type. My only concern was
that if we don't import a schema, then I am wondering.
Leigh Klotz: We've already made this
cut, it's XForms Basic. It supports XML Schema types but not XML
Schema structures, just like Relax.
Erik Bruchez: But it's not
Basic.
John Boyer: We say the XForms Schema
is available.
Leigh Klotz: If you want to build a
Schema-structures free version build it on XForms Basic.
Erik Bruchez: I don't want XForms
Basic. If the form author import a Schema then we use
xsi:schema.
Leigh Klotz: You can't retroactively
take XML Schema out of XForms.
Erik Bruchez: In the future making it
optional would be a good thing. It's not clear now when we process
it; I don't get a feeling that it's all properly specified.
John Boyer: In the future we should
control it on an instance-by-instance basis, but for now, it says
all applicable Schema declarations are processed. What we're
quibbling about is the definition of applicable. Nowhere does it
say that if you don't import a Schema that you can leave it
off.
Erik Bruchez: If the consensus is that
it's clear then I have my answer.
Leigh Klotz: I agree with John that we
don't say xsi:type isn't processed unless you import a Schema. We
can't keep chipping away at this until we declare it broken and
remove it. If we want to remove XML Schema we can do so in the
future, and figure out how to support RNG. Let's discuss this at
the next F2F and talk seriously about RNG and XML Schema
support.
Erik Bruchez: I can report on this at
the next F2F and talk about how XSLT 2.0 is looking at
optimizations.
John Boyer: So for now let's treat
this as a future request. Can you live with that Erik?
Erik Bruchez: Yes.
Resolution 2007-10-17.3: We answer http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=85 as a future request but make no changes to xsi:type which is processed regardless of whether a schema is imported.
Action 2007-10-17.7: John Boyer to repond to http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=85