Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Charlie Wiecha, IBM
Uli Lissé, DreamLabs
Erik Bruchez, IBM
Philip Fennell, MarkLogic
John Boyer, IBM
Charlie Wiecha: I've accepted a new
position within IBM. I will be somewhat afield of forms for the
near future, and will be withdrawing from the Forms WG. I think
there's a nice connection between document capture and forms. I
think forms plays a role in BPM, but this is an unstructured
capture. I can see them coming together from paper capture to
electronic form. I'll be working on engineering work for right now
though.
Steven Pemberton: That's really too
bad. We'll definitely miss you. Good luck and I hope we'll be
seeing you soon.
Charlie Wiecha: I won't be in Lyon
either. I will continue talking with John as we're part of the same
management structure.
Leigh Klotz: The ECM industry uses
XForms extensively.
Charlie Wiecha: Our level of semantic
interpretation adds value beyond capture and once we ship we'll
look again.
Charlie Wiecha: I'll stay in
touch.
Steven Pemberton: Who hasn't signed
up but will be there physically?
Uli Lissé: I will be
there.
Nick van: I still don't know.
Uli Lissé: What about
Alain?
Steven Pemberton: I think maybe he
said he wouldn't be coming. It's almost a direct train for you,
Nick.
Nick van: It's not the travel, but a
customer demo we've been working on for a year.
Steven Pemberton: Please sign up as
soon as possible. Otherwise it will be Uli and I and a a
telephone.
John Boyer: I don't know yet. Do you
have to sign up to call by phone?
Steven Pemberton: I don't think
so.
John Boyer: I need to work on trave
approval.
Steven Pemberton: I say this
regularly, but they need to move this to the beginning of the
year.
John Boyer: Yes, end of year budget is
difficult.
Philip Fennell: I tried the ZIP
file and oXygen doesn't want the start element.
Leigh Klotz: We do have a simple
XHTML+XForms RNC but with NVDL don't you need the
Steven Pemberton: We need a
validator.
Leigh Klotz: Yes, we need a rec-track
document.
Steven Pemberton: We discussed turning
the XHTML + XForms attributes into XHTML+XForms documenting what
people do.
Leigh Klotz: This is the schema for
that, using NVDL.
Philip Fennell: So I will go back to
the XML Schema and integrate Owen Newnan's comments.
Leigh Klotz: Yes, there are also some
questions from Owen.
John Boyer: Has anyone ever sent
unregrets before?
Leigh Klotz: Unregrets, I've had a
few, but then again, too few to mention.
Steven Pemberton: I got no answers.
John Boyer: Do we include tutorial
and debugging on www-forms or do we split the list?
Leigh Klotz: We do have
www-forms-editor.
John Boyer: That's for formal
comments.
Leigh Klotz: Maybe we can move the
formal comments there.
John Boyer: Or keep forms technology
questions on www-forms.
Steven Pemberton: Or we could make a
forms-help list.
John Boyer: Keep a separate list to
sign up for. Or re-purpose www-forms and live with the
traffic.
Steven Pemberton: Does anybody feel
the level is excessive?
Leigh Klotz: If there is a bigger
success, we'll get all mailing lists flooded. But I don't see it
yet.
Erik Bruchez: Yes, there's less
traffic. Splitting mailing lists may eliminate activity instead of
reducing it.
Action 2010-09-15.1: Steven Pemberton to change descriptions of www-forms to allow forms use discussion.
Steven Pemberton: I'll research changing the description and add something.
Leigh Klotz: I mentioned this on XML CG and was given another link which I can't get at the moment.
Steven Pemberton: I think Chris Lilley was asking
for us to make a public statement. He wanted information about
implementations.
Leigh Klotz: Orbeon uses XBL2. We're
using it internally in Xerox.
Steven Pemberton: And Ubiquity?
John Boyer: In Firefox it uses
XBL.
Erik Bruchez: I think XBL2 is not
implementd in Firefox; as far as I remember they have the older
version.
Steven Pemberton: Yes, XBL isn't
anywhere except Firefox. The idea was to standardize it. They
created XBL2. For a long time we had a working draft, and now this
message from Ian Hixie saying that he's dropping a lot, including
namespace support.
Erik Bruchez: You seem to have figured
out that too much has been removed.
Steven Pemberton: Read: "I've dropped
namespace support, made it part of HTML rather than its own
language, dropped <style> and <script> in favour of
HTML equivalents, dropped all the <handler> syntactic sugar
(and redirected event forwarding to internal object instead),
dropped <preload>, dropped mentions of XForms and XML Events,
and so on."
Erik Bruchez: I personally wouldn't
mind some stuff being removed from XBL2, such as the replication of
XML events, key modifiers, and event filtering. I think there is
some work to do there to make it inline with things that we've done
in XForms. Dropping events isn't quite the right way to do that. If
there is actually progress on XBL on the HTML side, and we could
make sure whatever was done is usable...I'm not concerned about the
XBL namespace or whether namespaces are supported, it's easy to add
for us. If others are working on XBL, that we could leverage, that
would be good.
Leigh Klotz: I think we should
congratulate the HTML5 WG on making XBL available as Ubiquit and
others will benefit, but we need to keep the spec separate and have
the HTML5 profile and a namespace version as a separate
document.
Erik Bruchez: Is there general
interest in a component system for the HTML? If so, they may use
it.
Steven Pemberton: May I suggest an
action to send mail to HCG saying that this doesn't satisfy our
needs, referring to this message? There's no coordination so
far.
Action 2010-09-15.2: Leigh Klotz to send message about recent XBL2 news to HCG saying it doesn't meet our needs.
Leigh Klotz: Erik summarized in
http://lists.w3.org/Archives/Public/www-forms/2010Sep/0017.html
Leigh Klotz: Erik, did you mean
something beyond the "@" credentials in HTTP?
Erik Bruchez: It's too much to ask
form authors to understand HTTP. You can put it in the URL, but in
our implementation you can also put it in request attributes. You
might not want to put it in the URL as it might reveal it in a log
file. So perhaps it could be provided out of the box by XForms. And
of course, there is a need for base64-encoded data as part of more
general stuff.
John Boyer: We had base64 encode and
decode in XForms 1.1, but we removed it because of decode problems
with binary blobs not being XPath strings.
Leigh Klotz: When you use http://user:pass@example.com it
doesn't send user:pass in the HTTP GET request. That's just a
lexical coding and the wire transport is done using normal HTTP. I
think we could add a user and password and possibly domain to the
submission/resource element.
John Boyer: So we need to see what XHR
does.
Leigh Klotz: I'd be willing to do the
experiment.
Action 2010-09-15.3: Leigh Klotz to experiment with XHR authentication and supplying password authentication.
Leigh Klotz: What about
<resource value="/path/to/foo" username="/path/to/user"
password="/path/to/pas" />
Erik Bruchez: The resource element
replaces an attribute. Adding those attributes breaks the
assumption, so I'd prefer additional nested elements.
Steven Pemberton: I have a different
view, that we realized that we should have made all our attributes
dynamic ones in the first place, and in the cases where we had them
already we created dynamic child elements but we used dynamic
attributes for the new ones since you can make them static.
Erik Bruchez: XForms has some
attribute that are XPath expressions (ref) and others that are
better as literals. I think there's a distinction. I think if the
resource were natively an XPath expression, the additional single
quotes required in teh most common case would be confusing. That's
why I like AVTs. Or, a nested element that allows you to do the
same thing.
John Boyer: I think you can still do
that on the resource. You can use the content of the resource to
get the content. There's still a way to avoid single quotes.
Erik Bruchez: I don't like username
and password on the resource element because it breaks.
Leigh Klotz: My reasons are two-fold:
it shows the credentials are for the resource. The second is that
it is equivalent to the lexical representation of http://username:password@.
Erik Bruchez: I'd like to see more
consistency.
Leigh Klotz: It would be consistent in
resource on load as well.
Nick van: I also would prefer the
username and password on the parent element not the dynamic
element, but this is just my opinion. and if you do basic
authentication the username and pasword are REALM based. depending
on the parameters another REALM could be requested