Forms WG FtF, Cannes/Mandelieu Day 1 -- 20 Oct 2008

<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

http://lists.w3.org/Archives/Public/public-forms/2008Oct/0035.html

Agenda overview

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

Submission module

http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features#head-be04577d9d30bd43068682d94500a856092896b0

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

<nick> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features#head-f707002d9a6fe056325ffcd24c1b157ebe4bad68

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

XML Security

<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> 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

trying to redial

yo!

XML Events 2

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?

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?

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> ...

<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>.

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)

- DRAFT -

Forms WG FtF, Cannes/Mandelieu Day 1

20 Oct 2008

Attendees

Contents

http://lists.w3.org/Archives/Public/public-forms/2008Oct/0035.html

Agenda overview

Submission module

XML Security

XML Events 2

Summary of Action Items

Scribe.perl diagnostic output