See also: IRC log
<Charlie> hi john ... good morning
<John_Boyer> good morning
<John_Boyer> Charlie, I have the webcon software installed; during xml sec visit, would you be able to project for me please?
<Charlie> k
<Steven> Hi from Cannes/Mandelieu
<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2008Oct/0035.html
<John_Boyer> John will just do overview of agenda quickly, then we'll need a scribe for submission discussion
<Steven> SCribe: Steven
<scribe> scribe: Steven
John: Timing is 9 to 5, all Ok with that?
Steven: Sure
John: First submission, then a
coffe break, then a meeting with XML Sec people
... they have a telecon set up
... and there are some slides if necessary
... I will be talking about integrating XML Signatures with
XForms
... also covering ODF+XForms
Keith: Same conference code?
John: No, let me find it
... their room is bigger, so that is why we are going to them
and not v.v.
http://www.w3.org/Guide/1998/08/teleconference-calendar#s_3328
Steven: Code is XMLSEC
John: 12.30 to 2 is lunch
... with room with being France
... 2 to 3 is XML Events
... then tea break 3-3.30
Charlie: AT 4 I have to go to Multimodal
John: And at the end of day the
UI layer
... extending to tomorrow
... then 2 sessions of Webforms/a
... then future meetings
... AOB?
Charlie: The panel on Wednesday?
Steven: Mark said he'd be willing/able to replace John on the panel
John: Shall we discuss the panel in the 2-3 slot tomorrow?
<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
John: [Overviews module
structure]
... Charlie is driving an implementation of this stuff
... So we're doing submission today
... Uli and I own this module
... some of the bullet points need some clarification
<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
John: The first bullet point says
we need an event for submission result received
... and it would be better if the end of submission event had a
default action to process the results of the submission
Steven: Yes an event is much better
John: The submission module wil
define what is in chapter 11 at present
... Then we have elements and attributes, but I'm unsure about
the driver adding the ref and bind stuff
Steven: Is it the aim of this module to be usable by other specs such as XHTML or Voice?
John: Yes, but we have to then work out how it can be independent of the data island module
Steven: Last week we said that data might come from other places than the instance
Charlie: In the future yes, not this version
Steven: As long as it looks like XML to the XPath selectors, we don't need to care
<John_Boyer> irc has dropped everyone at TPAC, steven is starting a text file for minutes
[network breaks]
Raman: Why bother, just say that some XPath expressions don't have any effect with Jason.
John: Yes, just have a profile of
XPath
... so the question is who adds the single node bindings? The
module or the driver.
Charlie: It seems to be reasonable to let the submission module do it.
Roland: Well, we should ask from the viewpoint of the other users of the module
[Plh leaves]
Charlie: ANd different expression languages? Not sure.
Raman: Sounds like a bad idea.
Rat hole.
... every application is using XPath now already
Nick: Yes, but JQuery is using CSS3 selectors
Raman: But it is a disaster.
John: The issue of the expression language is not a submission issue; we just use the binding attributes. The driver will decide which expression language.
Uli: Having started on the subnission module, I have difficulty to understand how to get the data to submission if we factor it out.
John: I agree.
[network returns]
John: And that covers all the attributes in the second bullet point
"XForms driver module would define attributes ref, bind, validate, relevant, replace, target, instance"
Uli: I would like to see it factored out, I just don't know how to do it
John: Add it to the future
requirements, or try to achieve it now?
... Consider @relevant
... that is harder than @validate
... @relevant is about relevance pruning and is by default
true
... so the data will by default be pruned
Steven: But relevance has to be
optional
... for apps that only load data, mess with it, and submit it
back
John: Well, data has to be
prunable in practice
... the context for the submit event needs to say where the
data is
Steven: Charlie, any implementation experience?
Charlie: No, we're tied to instance
John: Within ubiquity, for the insert action, it was fairly easy to do via event context
Nick: There is a danger that you generate copies of the data
John: Yes
Steven: I don't understand
Nick: If relevance processing
happens outside of he submission module
... then it has to copy the data to return a version of the
serialisable data
Steven: So currently it is serialization that knows about relevance
John: Yes
Raman: Can't the instance contain a relevant bit?
Nick: But then if others use it, they may not have relevance
Raman: Well, we may be overdesigning here, designing something that doesn't exist
John: Yes, there is a base implementation that serializes everything, and a specialization, or subclass does the relevance
Uli: But we have validation too that sits between pruning and serialization
Roland: Validation is at the end
of the pipeline before serialization
... submission doesn't need to know about relevance
<John_Boyer> The xforms-submit event should just have additional context info. Specifically, the submit-node and the target-node
<John_Boyer> This will avoid making copies of instance data by xforms driver, but generalize submission to applications beyond just xforms.
Roland: The serializer doesn't need to know whether it is relevant, just whether it should be serialized
<John_Boyer> Such applications can just configure the xforms-submit event rather than using binding attributes
<unl> @John: What would target-node contain in case of replace="all"?
<unl> "document()" ???
<John_Boyer> nothing, that's for replace instance
John: Maybe the xforms-submit
event can supply context information, and the new event (submit
received) could have context information about where to put the
result etc.
... wherever we see "the driver has to do that" we should look
again
Steven: But isn't it a question
of the difference between syntax and semantics
... the driver supplies the attributes to do relevance pruning,
and the submission module either does relevance pruning or not
depending on whether the hooks have been filled
Raman: our relevance model is a bit tangled at the moment
John: [explains problem area]
Raman: Is that a problem with
Schema or with relevance?
... We shouldn't burden our model with that if it is
John: The problem is with modules
not knowing about each other
... I am not convinced it is an XML Schema problem... oh yes,
it is, you're right
[scribe hopes John will type in what his problem was]
John: Schema doesn't understand relevance, so we have to do it, and that is the weak link
Raman: Since it is our design, by the time a form has been instantiated, you could prune earlier than we do it
John: Good point
... relevance itself is not powerful enough
... it is decorating the nodes rather than inserting or delting
them
Raman: Water under the bridge really
John: I think Uli and I have
enough information to continue
... next session in room exec 6
<wellsk> John has slide deck titled "XML Signatures for Interactive XML Documents"
<Steeeven> we are in #xmlsec
<wellsk> John: is giving overview of XML Signature
<wellsk> ... digitally sign multiple resources
<wellsk> ... including xforms data
<wellsk> ... fingerprint for each resource
<wellsk> ... authenticate refs of resources
<wellsk> ... final hash in <signatureValue>, includes <signedinfo> content
<wellsk> ... metadata of signature in <objectId>
<wellsk> ... sign any kind of data
<wellsk> ... each resource covered by Reference, URLs can be used for location of content
<Steeeven> Slides at http://www.w3.org/2008/xmlsec/f2f-2008-10-20/xforms/XMLSignatures.TPAC2008.pdf
<wellsk> ... working offline, detached, enveloped, enveloping signatures
<wellsk> Ramen: question about agreeing on something that you didn't really agree with..
<wellsk> John: answers with validation step
<wellsk> ... reproduce signature to what was signed
<wellsk> ... cached copies of URIs, ODF docs (1) standalone xml file, (2) zip file with multiple resources
<wellsk> ... URIs relative to zip file
<wellsk> ... Signing ODF zip files
<wellsk> ... caching capabilitiy
<wellsk> enveloped can talk to others within zip file
<wellsk> detached sigs can not look into other resources in zip file
<wellsk> ... ODF -- relative URIS within ODF zip file
<wellsk> detached: not in ODF file
<wellsk> enveloping: content is inside XML signature
<wellsk> enveloped: contains signature
<wellsk> enveloped -- empty URI attribute
<wellsk> XML signature within xml instance
<wellsk> in xforms
<wellsk> want to sign the entire content not just instance data
<wellsk> so uses no URI attribute
<wellsk> Intro to XForms
<wellsk> showing XForms markup
<wellsk> xforms model
<wellsk> xforms instance
<wellsk> this is where xml dig sig will go too -- in the instance data
<wellsk> User data from UI goes to instance data
<wellsk> question about calculated attr
<wellsk> "what is it doing"
<wellsk> calculates node c from inputs updated by end user
<wellsk> John brings up @resource in instance element
<wellsk> during runtime -- separate dom
<wellsk> xml signature will live in the instance data
<wellsk> URL resolver, takes out the instance data within same document
<wellsk> odf <office:document-content...>
<wellsk> when standalone doc
<wellsk> odf: three levels: model, form controls, presentation level
<wellsk> shows <ds:Signature> element within instance within model
<wellsk> static vs interactive docs
<wellsk> URI="" indicates root of document
<wellsk> structured data(xforms is good at this) and unstructured data (ODF is good at this)
<wellsk> dsig to point to unstructured data
<wellsk> signing only the data, without signing the resources in creating the data (form) -- this would be useless for repudiation
<wellsk> need to be able to reference the containing document
<wellsk> when are you signing, what are you signing? If sign the instance data within document and then signing document, does this mean you sign the instance data twice?
<wellsk> sign the current state of the document
<Steeeven> keith, wellsk? Seen channel #xmlsec?
<wellsk> question: do you have to sign the processing steps for xforms?
<nick> You can have a problem with an xf:output with a calculate that uses extension functions
<Steeeven> :-) on staying awake
<wellsk> discussion revolves around instance data entered by user, saving context of data, serialization of data
<wellsk> wrinkle: sign entire doc + instance data, resolve ref and digest of signed info
<wellsk> generate signature and save to disk
<wellsk> account for fact signature value is changed
<wellsk> envelope transform "here()" function (data dom not document dom) -- no access to "here()" function
<wellsk> xforms would have to use dsig filter
<wellsk> add/remove pieces from digest
<wellsk> and then adding something new to document after the document has been signed
<wellsk> invalidates the signature
<wellsk> creates a signature to a document, after the document has been signed
<wellsk> delete signature from document being referenced
<wellsk> omit signature being generated
<wellsk> here() is the wrong document
<wellsk> relative URI references would be broken in the saved signature case
<wellsk> repeated content in xforms, creates problems for which signature is being omitted
<wellsk> xml dig sig spec 4.3.3.1
<wellsk> transfom wording, also ref 4.3.3.2
<John_Boyer> zakim got confused again and wouldn't let me on
hi
trying to redial
yo!
hi mark
<markbirbeck> bonjour!
we're on zakim too
usual xforms channel
oh you speak french as well
<markbirbeck> bien sur. :)
tiens tiens
<markbirbeck> A little tricky to get to a phone...but I can at a push.
<markbirbeck> What would you like from me? :)
<John_Boyer> there will be a discussion of XML Events 2, which you may want to join
<Roland_> latest editor draft : http://www.w3.org/MarkUp/2008/ED-xml-events-20080625/
<nick> Scribe: Nick
<unl> the better picture is at http://www.w3.org/TR/DOM-Level-3-Events/images/eventflow.png
<unl> and even in svg http://www.w3.org/TR/DOM-Level-3-Events/images/eventflow.svg
<markbirbeck> hi shane :)
Roland: XML events 2 was intended to be incorporated in XForms
<Roland_> http://lists.w3.org/Archives/Public/public-forms/2008Sep/0029
Roland: We will start with issues
that Nick raised
... Events attribute group, target: there is already an
attribute in target in XHTML 2
... that is why we changed it to targetid
<ShaneM> I would note that the XHTML Target Attribute Module only puts the target attribute on some elements...
Nick: We can support target and targetid and deprecate target
Roland: From XML events 2 you can incorporate them in your namespace
Uli: I just don't like it targetid the id isn't adding something
<ShaneM> http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_targetmodule
ShaneM: target is not a global
attribute
... target in XML Events is a global attribute
Roland: While and if are only allowed on action, lets see if target is allowed everywhere
MarkB: Target in XML events 2 is allowed on all elements, you can specify the handler
Roland: Would there will be a problem with using target in XML events 2 if there is no collision
ShaneM: <a> is an important collision
John: Would you make a an handler?
<markbirbeck> <a ev:targetid="..." ev:handler="...">
MarkB: You can specify a handler using an handler attribute
<markbirbeck> 'a' is not a handler, here
John: Why would an 'a' want to say that?
Steven: 'That is not your business' ;)
MarkB: (Describes his example, that he posted in the irc)
Roland: So we can call it target
<markbirbeck> http://www.w3.org/TR/xhtml-access/
<markbirbeck> @targetrole & @targetid.
MarkB: Explain that targetid is a could name, but acces uses it with a list of id's
<Steven> ev:eventtarget
<unl> +1
Raman: attarget
Steven: DOM events uses eventtarget
MarkB: Do we need this?
<markbirbeck> <a ev:observer="o" phase="target">
MarkB: Is there alternative markup?
Steven: That doesn't work bcz 'a' needs to be the target
MarkB: But the observer is on it
<markbirbeck> <listener event="click" observer="para1" targetid="link1" handler="#clicker"/>
<markbirbeck> ...
<markbirbeck> <p id="para1">
<markbirbeck> Here is some content in a paragraph that includes a link to
<markbirbeck> <a id="link1" href="Overview.html">the
<markbirbeck> <em>draft</em>
<markbirbeck> document</a>.
<markbirbeck> </p>
Charlie: It is more complex, then putting on one attribute
<Roland_> EventTarget.dispatchEvent() - http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-flow
ShaneM: The goal is to make it declarative (and be able to do anything we can with scripting) if we remove this do we lose anything?
MarkB: I don't think it is directly in DOM 2 events
Roland: We still want this for
dispatch
... Do we want it as global attribute for the listeners
<markbirbeck> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTarget
<markbirbeck> There is no way to register for *only* target.
<markbirbeck> We added that as a convenience.
<markbirbeck> But an implementation would need to,...er,...implement it. :)
Steven: There is a solution you can query the phase and target
MarkB: Yes but you have to layer it on DOM 2 events
Roland: So what would we loose
Steven: The two options are remove it and say how you could do it without target, the second option is to rename the attribute
<Steven> if=(eventcontext(target)='myid')
<John_Boyer> observe="ancestor" phase="target" if="event('target')='descendant'"
<John_Boyer> get rid of phase
<John_Boyer> it will always be bubble or capture at the ancestor
Steven: I don't think we need the target attribute
<markbirbeck> event('target').id
<John_Boyer> event('target')/@id = 'descendant'
<unl> or @xml:id ;-)
<John_Boyer> yes
<markbirbeck> wrong hierarchy, though :)
MarkB: The element is the UI and therefore you couldn't do any xpath expressions on it
Roland: we call it
eventtarget
... If you go to dispatch in DOM events 3
<markbirbeck> http://www.w3.org/MarkUp/2008/ED-xml-events-20080625/#section-dispatchEvent-element
MarkB: is 'to' not targetid
John: If we switch from namespace
attributes to local attributes the rename would be OK
... So the global name would be good for back-wards
compatibility
<ShaneM> I am fine with eventtarget, but I note that this is an "interface" in DOM 3, not a property.
Roland: we changed to 'to' from targetid in the dispatch action
Steven: We should do this some
other time
... We change the name to eventtarget
John: Do we incorporate the attributes in our namespace in XForms 1.2?
<markbirbeck> @eventtarget still has ambiguity, as to whether this is where the event came _from_, or is going _to_.
Steven: We(XForms) can do this, it is supported by XML Events 2
<ShaneM> I asked about "camel case" for the eventTarget attribute. I note that we use camel case for some element names, but not for any attribute names.
<markbirbeck> I would just like to record that I would prefer something that makes this clear, like @srcTarget.
John: We can use XML events 2 without namespaces and XML Events 1 with the namespace
ShaneM: It is recommended to use both in the same document
Roland: Next item is "The 'target' attribute is renamed to 'to' " on dispatch
<Steven> dispatchEvent raise="click" to="myelement"
Charlie: raise is bad, it sounds like an exception
<John_Boyer> multifarious raise puns have been raised.
Roland: 'to' becomes eventtartget
<Steven> like "a raise is never bad"
MarkB: I'm not happy with
it
... We used eventtarget has the source and now we use it as the
target
<Steven> dispatchEvent which="click" to="place"
Roland: We not used it as source but as target, We listen to events that are sent 'to' something
MarkB: I want targetid for
'to'
... Explains that targetid in access is the same as 'to' in
dispatchEvent
ShaneM: I aggree they are the same
Roland: They have a list of id's
ShaneM: we can make it a list
Uli: does it makes sense?
Roland: It may be used a list, it can be useful in some cases
MarkB: You can do three submissions at one time
Roland: We rename it to targetid
and make it a list of id's to make it in sync with access
... next item Element is renamed to 'dispatchEvent'
MarkB: We changed the name to make it in sync with DOM Events 3
John: We will import XML events 2 in the XForms namespace, we get an action element and dispatchEvent which formerly called dispatch
MarkB: You could keep the old one
Nick: Do we deprecate dispatch?
MarkB dispatchEvent does not do deferred update and dispatch does deferred update
John: It is not dispatch that decides this it is another module
Uli: I like that they are modelled to DOM level 3 Events
<unl> but I don't like camel-case names!
John: The element names can be decided by XML Events 2 WG
MarkB: You can add a legacy module that contains all the old elementNames
Roland: Is dispatchEvent a name that we can live with
group: Yes lets call it dispatchEvent
Roland: Next item The 'name' attribute is renamed to 'raise'
ShaneM: I agree that raise hints an exception
Roland: Any other names?
<Charlie> dispatch="x"
Uli: Why can't we use event?
Roland: event is a global attribute
<markbirbeck> 'type' is actually used in DOM 2/3 Events to describe the 'name'
<markbirbeck> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Event
<ShaneM> eventName ?
<unl> qname
<unl> scnr
<markbirbeck> Arg name to initEvent(), for example is eventTypeArg.
Steven: In XForms we can change type to data:type
<Steven> I didn't say that!~
<Steven> (for the record)
<Steven> I said we still have an issue with datatype
<unl> or: use namespaces!
<Steven> ooh! Idea!
group: It is event-type
<ShaneM> 'eventtype' isn't it?
<ShaneM> or 'eventType'
MarkB: delay should be in XML Events 2
Roland: XML Events 2 passes all properties available in DOM Level 3 events
<ShaneM> John's issue is # 8056 and was a last call comment.
John: Could you ask if an event is in the capture phase?
<markbirbeck> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Event
MarkB: Yes you could
Roland: Yes we can add examples for the event function
<markbirbeck> event('eventPhase')
<Steven> hello
<John_Boyer> hi
<Steven> (Charlie and Raman at Multimodal WG)
Roland: Listening to other
documents, and it makes it nervous it are separate documents,
and we need to be careful for security
... But for the special XForms case it can be defined, there is
a note in the spec that XML Events 2 doesn't want to deal with
cross document communication, nor does DOM level 3 Events
<Steven> +1 on security
John: That is why the insert and delete events are targeted to the host document
Steven: I agree on the security, but SVG has a use case for 'stuff' embedded in the SVG
Roland: We should first ask how you do it with DOM Level 3 Events
John: It is easy with DOM 3 bcz. I can get a reference to a document
Roland: It is different, for example do the events flow through the different DOM's
John: We say this for repeats
Roland: Maybe we should review
this shadow DOM for XForms 2
... We need to define where it has access to
John: I want to listen for mutation on the instance data and do mutations on the instance
Roland: So you want to put your action handlers in the instance
John: I don't want to put them in the data
Roland: Yes I know, it is something like a 'bind', connect it in the instance
John: But XML events 2 doesn't has a way to specify the other DOM
Nick: We need to be careful that browser implementers can implement it due to security issues for cross domain access
John: The XForms processor could be defined as listening on one DOM and the processor can redirect them from the real instance
Roland: It is a good solution
because the bridging is done by XForms and nothing general and
is just a solution for this instance
... Is it OK that XML Events 2 doesn't provides the bridging
facility, but XForms can do it
<Roland_> http://lists.w3.org/Archives/Public/www-html-editor/2008AprJun/0005.html
John: I think it is OK
<Roland_> http://lists.w3.org/Archives/Public/public-xhtml2/2008Aug/0035
Uli: they are all dealt with, only the camelCasing but I don't mind, but I want it to be consistant
<ShaneM> I agree that the camcl casing in xml events 2 is not currently INTERNALLY consistent. we need to take a decision and fix it.
<Roland_> Forms WG comments on XML Events 2 Editor's Draft : http://lists.w3.org/Archives/Public/public-forms/2008Jun/0020.html
ShaneM: Does anyone has a strong feeling about camelCasing
John: XML sec uses it
ShaneM: We do it for some attributes but not all in XML Events 2
John: When we import it into XForms, it will be not consistant
Roland: The long names aren't readable
<ShaneM> there are 3 candidate attributes in xml events 2 - defaultAction, eventType, and eventTarget
Nick: We have some hyphenated attribute names from XSLT and some without hyphenation but indeed most are single words
Roland: Now treating Charlies e-mail
John: The picture isn't
clear
... You can't say at the target on the way down or at the
target on the way up
Steven: We don't have a way to change how DOM events 3 work
<Roland_> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-flow
Roland: I propose that XML Events 2 uses the DOM Level 3 Events picture
Steven: Should the bottom green arrow be solid
ShaneM: I will grab the image, if they don't fix it we will fix it
Roland: Next item "a handler can only listen for one phase, to listen for both..."
ShaneM: We tried to update this
Roland: It will help if we have the new diagram in
John: You can now say phase equal target which is good
Steven: at target is not a
phase
... it is a state
Roland: There is no capture phase at the target
Uli: In DOM level 3 events an event is in atTarget phase at the target, so not in the bubble phase
ShaneM: I agree, if it is at the target it is not in the capture nor in the bubble phase
John: language in XML Events 2 also suggests that target and bubble are separate phases
Roland: DOM level 2 also has the three phases
Steven: DOM Level 3 Events is not yet in Last Call
Roland: Next Item CONFORMANCE REQUIREMENTS
<Steven> he gasps
ShaneM: It is not in the document anymore
Roland: Next item EVENTS MODULE
John: It is editorial
Roland: Next item XPath EXPRESSIONS
ShaneM: It is a note to the reviewers
John: Yes we want to provide a
richer context
... We provide a rich evaluation context for the if and while
attribute
Roland: This is the end of all the notes related to XML Events 2, did I forget any? (silence, so it is done)
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/I have/Charlie, I have/ Succeeded: s/CH/Ch/ Succeeded: s/everyone/everyone at TPAC/ Succeeded: s/chei/chie/ Succeeded: s/prin/prun/ Succeeded: s/CH/Ch/ Succeeded: s/WI/Wi/ Succeeded: s/"// Succeeded: s/GO/Go/ Succeeded: s/wrt/rt/ Succeeded: s/fro/for/ Succeeded: s/suthenicate/authenticate/ Succeeded: s/looki/look/ Succeeded: s/wenow// Succeeded: s/taget/target/ Succeeded: s/taget/target/ Succeeded: s/:/"/ Succeeded: s/loose/lose/ Succeeded: s/two options is/two options are/ Succeeded: s/o/ancestor/ Succeeded: s/hieracrhy/hierarchy/ Succeeded: s/find/fine/ Succeeded: s/in .../in the dispatch action/ Succeeded: s/dispatch/dispatchEvent/ Succeeded: s/-/:/ Succeeded: s/Ra/Ro/ Succeeded: s/No /Now / Succeeded: s/they fix/they don't fix it/ Succeeded: s/Roland/ShaneM/ Succeeded: s/users/reviewers/ Found Scribe: Steven Inferring ScribeNick: Steven Found Scribe: Steven Inferring ScribeNick: Steven Found Scribe: Nick Inferring ScribeNick: nick Scribes: Steven, Nick ScribeNicks: Steven, nick WARNING: Replacing list of attendees. Old list: +49.297.aaaa John_Boyer wellsk New list: wellsk John_Boyer +03349297aaaa Cannes markbirbeck ShaneM +49.297.aabb Default Present: wellsk, John_Boyer, +03349297aaaa, Cannes, markbirbeck, ShaneM, +49.297.aabb Present: Uli Raman Charlie Nick Steven Roland John_(remote) Keith_(remote) Rogelio Philippe Le Hegaret Shane MarkB Agenda: http://lists.w3.org/Archives/Public/public-forms/2008Oct/0035.html Got date from IRC log name: 20 Oct 2008 Guessing minutes URL: http://www.w3.org/2008/10/20-forms-minutes.html People with action items:[End of scribe.perl diagnostic output]