Blake Jones, ViewPlus/DAISY
Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Rafael Benito, SATEC
Steven Pemberton, CWI/W3C
Keith Wells, IBM
Erik Bruchez, Orbeon [late]
John Boyer: We should discuss the
features at risk. In the status of the document they now require
what features we feel might cause a problem for implementers; if
they don't get implemented, they could be removed and still proceed
directly to PR.
Steven Pemberton: So if we say they're
at risk then we don't have to go through last call.
John Boyer: There's also a
slightly-different set of last call requirements: two
inter-operating implementations of every feature, and not one
complete definition of everything.
Steven Pemberton: We did that because
it was a good idea.
Leigh Klotz: That was a last call
comment.
John Boyer: It depends on how many we
have signing up for reference implementations; if only two
companies sign up, then we have to have two full
implementations.
Steven Pemberton: I see.
John Boyer: Do we have anybody signed
up yet?
Steven Pemberton: Who are the
candidates? Mark Birbeck, Nick, Mark Seaborne?
John Boyer: PicoForms had said they
wouldn't have 1.1 full but even partial implementations would be
useful.
Mark Birbeck: [joins]
John Boyer: Mark, would FormsPlayer be
ready?
Mark Birbeck: What is the
timescale?
John Boyer: Until the end of May at
least. The process document says I should have a list for
transition.
Mark Birbeck: By May?
John Boyer: For transition to CR,
mid-November.
Steven Pemberton: And we really do
need three, to be on the safe side.
John Boyer: The more the merrier. Then
we can figure out where the work is to do.
Mark Birbeck: I got the impression
that on the FireFox forum they weren't planning all the
features.
John Boyer: I don't think they'll have
a full 1.1 in that timeframe. And I don't know whether SATEC
stands. Two implementations of each feature is enough to get beyond
CR.
Leigh Klotz: And the list of
features?
John Boyer: In the status of the
document section, we have to say what we think are the exit
criteria. What I said for now is that we'd have a test suite and an
implementation report for at least two for each test of a required
feature. That's different than saying two interoperable
implementations for each test; we can make things be should or
may.
Nick van: [irc] need to talk to Joern
about this, I'm doing quite some work on chiba in my spare time,
but won't be able to implement all the features in my spare time.
I'm currently switching the XPath engine and that is quit some
work...
Charlie Wiecha: That sounds like a lot
of work.
John Boyer: It may be better than
removing features. So we are defining features in terms of the test
suite. There could be many more tests than what we have.
Leigh Klotz: So you are expecting the
number of tests to increase before we get out of CR?
John Boyer: It may. We may add or
modify the tests; we're not required to nail them down to
transition to CR.
John Boyer: We don't say how the
schemas are applied to the data. The implication is that we apply
all schemas to all data. Then we have type libraries; they declare
types, but not elements or attributes. So, one of the classic type
libraries is the XForms type library that consists of our date and
integer types. You'll get an error that says there is no type
declaration for this element.
Leigh Klotz: That's the question about
lax processing vs. strict processing.
John Boyer: It says processors may
continue to validate the content of the element. Processors aren't
required to do the lax validation of the content, and we kind of
rely on that for xsi:type, but the root level element is reported
as not valid according to a strict processor.
Leigh Klotz: What is a strict
processor?
John Boyer: The default is strict
processor.
Leigh Klotz: Yes, but it's clear that
it works so we just have imprecision in our spec.
John Boyer: The easiest thing to say
is that we have a general schema problem and we could live with the
Schema default being strict, and defer this issue to a future
release. The next step is to define a type library class of Schema,
or Erik's idea of taking a page from XSLT and apply a validation
attribute to the instance.
Leigh Klotz: I proposed the three
rules for when there are declarations and not in the message and I
think they work; with the exception of the xmlns="".
John Boyer: The interfaces aren't
there.
Leigh Klotz: I think I got this from
Uche Ogbuji at Microsoft on xml-dev [
http://lists.xml.org/archives/xml-dev/200209/msg00089.html],
but the idea when I moved the schemas from the instance to the
attribute so they would be shared was that the processor would
build up a schema in the no-namespace with includes for the
mentioned schemas. So the three rules would then be applied.
Erik Bruchez: [arrives]
John Boyer: Erik, would a note to that
effect work?
Erik Bruchez: What are the rules for
when to do lax?
Leigh Klotz: If there is no element or
attribute definitions.
Erik Bruchez: So we have to do lax
processing and then you iterate and find other elements inside and
validate them?
John Boyer: I'd like to avoid having
to alter the schema engine.
Erik Bruchez: The schema spec doesn't
say this is the only way to process it; it's up to the application
to do it. It looks like your schema validator does it in a certain
way.
John Boyer: Leigh said that you could
do it with a schema that includes others.
Leigh Klotz: That's how we planned to
do it but when I checked with implementers (Kenneth and David at
the SAP F2F) they said they wrote their own.
John Boyer: I think we can make this
an implementation note.
Leigh Klotz: I think we need to be
clear about what we want, and leave it up to implementers how to
say it.
John Boyer: Can you and Erik work on
it today?
Leigh Klotz: I share Erik's concern
but want to decide whether we leave it as it is, or put in the
goals.
John Boyer: Can you get this done
today?
Leigh Klotz: Yes.
Erik Bruchez: I'll do my best.
Action 2007-10-31.1: Leigh Klotz and Erik Bruchez and write up specxml for inclusion in XForms 1.1 to answer issue http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=87
John Boyer: This is our last open issue. We have a few approved items that need work.
John Boyer: Steven have you heard
any more on this?
Steven Pemberton: I haven't heard
anything back.
John Boyer: Is it informative?
Steven Pemberton: It's certainly
optional; I don't know if it's informative.
John Boyer: Could you ask for it by
Friday?
Steven Pemberton: Done.
John Boyer: I can do this.
Steven Pemberton: Thank you. I'm in a
crunch.
John Boyer: The group agreed to
language like output, with display:inline being default styling and
they wanted that on all for controls. Do we want that on
repeat/switch/group or should they be block? I'm ok with either
one.
Steven Pemberton: Yes, sounds like
block to me, really.
Mark Birbeck: In XHTML we have block
level, etc.
Steven Pemberton: That's CSS. CSS took
those terms over from HTML, but then there was a misunderstanding
and CSS happened to use the same word. In XHTML we use new terms.
These are CSS terms we're talking about now.
Mark Birbeck: Aren't these what we
would have called block-level elements? You could have a group in a
span, or a repeat, for example. You could flip a coin and make a
case for inline or block.
John Boyer: Especially if it's the
default.
Steven Pemberton: We have to say one
or another.
Leigh Klotz: Why?
Steven Pemberton: For interoperability
of styling.
Leigh Klotz: It doesn't help me much;
there are so many problems with CSS in different
implementations.
John Boyer: Can we work this out on
the list today or tomorrow.
Mark Birbeck: Once you start defining
one, why not all? I'm not sure we can do it in time. We discussed
this on list and default values in the wiki.
John Boyer: This is a last-call
comment for this property.
Mark Birbeck: For me, I'd say sorry we
agree we want default styles but we need lots of them, not just for
one element.
John Boyer: We already agreed to do
it. Is inline really the right thing for group/switch/repeat.
Leigh Klotz: If it's the default, we
have it for all elements, and there's always going to be a
different use case for each, and we've already decided, then
there's no reason to switch from what we've decided.
Nick van: Can we make it so that it
decides by the container?
Steven Pemberton: That's the host
language that decides block or inline.
Mark Birbeck: That's ....
Nick van: If you want it styled in
block or div, why's that not legal?
Mark Birbeck: Context isn't
relevant.
John Boyer: So I suppose I can proceed
with inline for everything as we resolved and if that proves to be
a problem I'm sure we'll hear about it.
Leigh Klotz: Sounds good to me. We
already resolved it, it's just a default, it's always wrong for
somebody.
John Boyer: How do we need
this?
Steven Pemberton: You ask Shane
nicely.
Nick van: [irc] shouldn't we first
update the system?
John Boyer: I'll make a preliminary
report and link it in.
John Boyer: Erik, did you see the
text about Issue 139?
Erik Bruchez: I'll try to do it.
John Boyer: Let's take it offline
today. Something fast and easy would be great.
Erik Bruchez: I'll let you know.