W3C

- DRAFT -

Weekly Forms WG Teleconference

28 Jan 2009

Agenda

See also: IRC log

Attendees

Present
wellsk, wiecha, unl, John_Boyer, +0207689aaaa, prb, Steven, Nick_van_den_Bleeken, ebruchez
Regrets
Leigh
Chair
John
Scribe
Paul

Contents


 

 

<nick> ?me I'm not feeling wel

<John_Boyer> scribe: Paul

<John_Boyer> scribenick: prb

<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2009Jan/0045.html

John: First on Agenda, talk about next F2F, late getting out infopage and signup sheet
... Steven, can you arrange that with Raman?

Steven: yes, I'll work that out

John: We don't have much time before the next one, to get those pages up
... same time, we need to develop an agenda for what we'll cover in the F2F, to be as effective as possible, so I'm opening up the floor
... We have a virtual day on Thursday, after the Wednesday telecon, then the three days in Califonia at Google

<Steven> Who is going to be there, phsically?

Keith: Maybe XForms for HTML?

John: alright, I've not seen notes about it, but we can go over the draft and talk about some of the fine points there. That's a good thing
... I think Raman and Leigh,

<ebruchez> Erik too

Steven: I think Nick

<wiecha> i don't have approval yet

John: I think I will be there, but I don't have approval yet, but it's in my backyard

<nick> uli is going to be there

John: hopefully I'll get approval soon
... Charlie, you don't have approval yet?

Charlie: correct

John: Will you attend remotely?

Charlie: Yes

John: Steven, I assume you'll be there?

Steven: As long as there are enough people

John: Keith?

Keith: I'll attend remotely

Paul: I won't be there

Steven: Nor will Mark
... The physical dates are 9th-11th, Monday-Wednesday yes?

John: yes
... Virtual Days are February 5th, 9am to 3pm Eastern Standard Time, with Hour Break
... We have used Yugma for session management, we had some difficulties on yesterday's backplane call, can everyone ensure they have the latest version for their platform
... It will be difficult to have a lenghty meeting without support from web conferencing
... I'm sure not everyone has focussed on the details of XForms for HTML, any others?

Keith: We could go through some of the implementation status reports to discuss things that are problematic

John: It might be useful to consolidate some of the results in the meeting
... e.g. we have full reports for EMC, and Firefox, and Chiba have given a report

Keith: What about optional functionality? Does there have to be any passing implementation?
... e.g. p3ptype and mailto submissions
... I don't know what the score is with the w3c process wrt optional items

John: I'll put that in my bullet list of agenda items
... I also saw an email from Uli about problems with modularising submission

<nick> sounds good

<nick> maybe we can do some real writing of modules

John: Do you find it useful to try to work through the details of modularising submission in the F2F?

Charlie: and other modules
... We could do some actual writing of some

<nick> I hope I can peropare something for the MIPs module

<Steven> Meeting attendance at http://www.w3.org/2002/09/wbs/32219/formsftf200902/

John: Are you suggesting that the principal module author would be ready to project their working environment, and discuss wording, then edit actively?

Charlie: yes, it will be a bit tough with some of us remoting

John: Whoever's projecting will also have to project on Yugma

<nick> yes, It's wiondows

John: Nick, do you have an operating system that yugma supports for projection, i.e. not Mac

Charlie: What's the problem? Yugma does well on a mac

John: in terms of projecting?

Charlie: that's just video out, Yugma is fine for initiating a meeting

<wiecha> i was confused about what we meant by "projecting" ... yugma on the mac can be used to initiate the share, yes

John: in terms of testing out Yugma, I think that next week at Wednesday's meeting, we'll do a dry run, not that we have anything to share, but to make sure that everyone on the call can use it, and have a day to respond
... I suppose we have the bind module modularisation to work through and sweat the details of
... What else?
... I want to have a rough sense of what we will talk about on each day

Charlie: I'm a bit lost on how we've left the granularity of the modules

John: this modularisation is proving challenging, and I'm a little concerned about how much time we put into it

Keith: We should have a short hour conversation about our goals as workign group this year

John: OK
... particularly since our charter is technically up at the end of the year, and we'll have to go for rechartering, so we need to figure out what we hope to achieve to support that effort
... we have a number of 1.2 features that we have talked about adding, not many, but some dot-release things that help us close some gaps
... some folks, including me have some action items here
... instead of taking these features, and waiting for spec-ready text, it may be good to do some group design, and outline the spec for those features
... In parallel to the modularisation, what do we think about writing a thin spec for 1.2 new features?

<nick> spec ready text?

John: stuff that will eventually be consumed byt the
... modules that define those new features.

<nick> bcz some features require trweaking all over the spec

John: a way to detect what's new, and give us some velocity on modularisation, by removing worry about new language
... Does a thin spec sound reasonable?

<nick> unmute, me

Charlie: I'm worried about bandwidth, we're not getting much traction on work we are doing

Nick: I've tried to write some modules for new features, and it requires tweaking throughout the whole spec, it depends on how much we are modularising, if we are writing very small modules, it might be difficult
... the most important thing is to get something modularised as soon as possible, and not to create too small modules, as that's not going to work with the work we have on now

John: People doing modules, are you starting with the very latest 1.1 editor's draft text?

Nick: I was using the CVS, so yes, the latest

John: We have a couple more odds and ends of action items of changes to 1.1 that have cropped up over the last year and a bit, so module authors will have to keep their eyes open for any changes in the text that they are consuming, we will have some parallel work going on
... I'm concerned about modularisation because it's not going very well, or very fast. It's an eggs in one basket problem, as if we don't have anyone doing 1.2 features, then we don't have anything to show, if modularisation keeps going as is
... When we get 1.1 to PR, then it will be time to start trying to specify, with more spec-ready texr, any features of 1.2. It makes sense to ensure that 1.1 goes to PR first, so it is frozen
... that leaves open the question of whether we spend time talking about these features in more detail in the F2F, so that people know what they are doing when they come to do them
... If no objections, I'll put them on an agenda
... we have submission, bind, do we want to go over some data modules?

Charlie: yes

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features

John: either Thursday 5th (Virtual), a hard pass, where we go through it together until we have something ready to go to 1st WD, I suspect we'd do Binding attributes and Data Islands, and Data Accessors together

Charlie: Are we proposing to fold those back in again? What is the granularity?

John: Are we going to put them in one spec, even though they are separate modules. If we can cut down on the number of specs we are pushing through W3C, it would be better

Charlie: It would help us work out issues of making cross-module references

John: Do you have CVS Access yet?

Charlie: not yet

John: You need a tool called Putty, which produces what is needed

<Steven> http://putty.darwinports.com/

<Steven> for mac

John: I have some instructions for myself on how to do it

<nick> http://www.w3.org/2006/tools/SettingUpSshCvs

<nick> for eclipse http://www.w3.org/2006/07/eclipse/eclipse.html

John: I did this in 2005, the only hint was open ssh
... Keith, you have CVS access already?

Keith: yes

John: I can segue into things after agenda development, I'll try to put together more of a day by day agenda, and run it by you on Wednesday

Steven: Uli wants Access, too. I'll see what I need to do

John: Uli, If you are using windows, there is a putty tool that will produce the kinds of keys you need to send Steven
... XForms 1.1 implementation reports and progress
... One agenda item - Keith could you check in some of your updated FF reports into the CVS tree, in the location where the others are?

Keith: I can do that

John: Could you put the EMC ones up there as well

Keith: I'll do that, and I'll get one started for Chiba,

John: In the case of Chiba, we could start with the email that they sent, and turn it into a focussed report. Even as a text file. Just so it isn't too much of a heavy project. Reasonable?

Keith: I can do that.

John: making something beautiful might be too much work

<Steven> CVS at W3C info here - http://www.w3.org/Project/CVSdoc/

John: We also have the ubiquity-xforms growing and changing report
... There are features that I know we have in ubiquity, but don't necessarily pass the tests, and I suspect this is true of other implementations. This seems to be because the tests use non-required features
... Charlie has finished submission/resource, for http and https, but the tests, for convenience, are operating over file.
... I wonder if it is advisable to rewrite some of the tests, so that they don't use non-required features
... As we run across them, when someone is doing an implementation, We need 2 things
... if someone thinks a different test would be reasonable, we see if it is suitable, and swap it in, but it may cause implementations to fail that passed before

Charlie: I made such a change, but I didn't want to put it into the W3C Tests

John: If the implementation reports are dated, then we have an audit trail of changes, so if a test fails after that date, then we can see that that may be the cause
... In the case of resource, the chance isn't zero that we will mess things up, so do we need to go to implmentors and ask them to retest

Keith: The test suite is not always in step with the living, breathing spec document

John: e.g. there are still outstanding changes in the header feature
... how many implementations will pass those?
... I can't remember what the changes are, do we have good tests for those? The test suite doesn't cover everything
... Is there a test of insert for the root element, using the @context? I supsect not, as we'd have 200 tests in the actions chapter alone

Keith: it's not really a unit test, more a concept test,

John: what we did with 1.1 was that the exit criterion for CR phase (implementation) is defined in terms of the test suite
... the test suite is the basis for defining interoperability and conformance
... the way w3c reccomendations work, is that the test suite needn't be perfect, but good, and it is good
... the recommendation can acheive it's purpose of stability, interoperability, and suitability for uptake across the wider computing industry. it is the end point for a standards committee, but the start point for further work
... for some of these changes to 1.1 during the course of implementation it's not necessarily the case that we need a whole lot of new tests for them, we can sort of have a tagged revision of the test suite, saying here is a snapshot of the suite when we advanced the recommendation. We may continue changing after PR

Keith: it is in CVS, so it can be branched and tagged by whoever

Charlie: I think John is suggesting doing this at rare intervals, such as advance to PR, yes?

John: I think so, so the question is - what is the process by which we gain approval to change a test

Charlie: possibly an email code review, someone could chek into a changes directory, like in ubiquity

John: if we have a lot of people with CVS access, they could send it to the group, saying here is the test, this is why it should change, etc. and we could discuss it here. if they have access, they can chek in

Keith

Keith: it would be good to tie the tests to the spec authorship process. Looking back, writing the words for the spec, and the test case reviewed with the spec in mind would be helpful

John: when we first created the suite, we had people in pairs at a F2F, and they tried to test all the assertions made in that chapter. We didn't have the bandwidth to complete it with multiple teams
... You did all the 1.1 stuff, which was a lot of work
... this will be an issue as we modularise. People need to think - how do we advance that module? Each module needs a test suite attached, which is a lot of work

Keith: going back to the process, if you want change, sending an email with the test, and why it should be changed, gain a minimal approval, then I could meld it into the CVS tree

John: Once we actually decide to update a test, we could send a message out to www-forms saying - if you want to update your implementation report, please do
... but we'll just leave it as passing
... do you fail because you lack a feature, or because there's something wrong with the test.
... they will let us know if they pass
... That's only if you are implementing file: protocol

Charlie: I'll look at the tests, to see if I should replace with HTTP, or split into two different tests
... I don't want to move conformance backwards

John: We'll have to play it by ear, and wait for feedback
... if there are other places where we are using optional features to test required features, those are the kinds of changes we want to make
... we had some emails about errors in the tests for action - did that correspond to test suite updates?

Keith: yes it did, there was one that I retested because I thought it was working fine, but another that I fixed.

John: did those changes get reflected in ubiquity?

Keith: yes?

John: Did FF and EMC update based on these?

Keith: I tested FF, I'm not sure about Chiba
... to follow up: both Chiba and EMC, we removed 40-45 test cases from the 0-1 implementation report list

<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2009Jan/0044.html

Keith: that was very helpful to us

John: That link is your latest email, yes?

Keith: there was one this morning

<wellsk> http://lists.w3.org/Archives/Public/public-forms/2009Jan/0050.html

Keith: I'm trying to juggle these implementation reports along with the ubiquity implementation reports. We have the reports on the ubiquity-xforms google site. So they are available in public if anyone wants to question the process

John: WRT this updated email. Are there any of these things that we say are required, that we might need a different conformance level for - e.g. the chapter 7 things such as hmac and digest. we have tests for different sha...
... why are they split? I'd prefer five, ubiquity fails because of no sha256,

Keith: My understanding is that all XPath functions are required

John: I may have missed a required or optional when putting together the conformance
... all functions are required, but are all parameterisations of all functions required?

<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#fn-digest

Keith: That's not spelled out

John: look at function digest, 1, 256 are required and 384, 512 optional

Keith: so we can move some off the list and onto optional

John: so that begs the question about sha256, I think Leigh argued that it should be required, but should it be recommended?
... We need to discuss that deeper, but we need to do some triage - how badly do we need them?

Keith: if they are optional how does that affect PR

John: The w3c process is that we define our exit criteria for CR, when we enter CR, assuming the director approves document (which he did) what we said in the document is what we are held to
... so we have 2 implementations of all required feature and one of any others
... so it would require changing the requirements on the features themselves. If we do that, we should have a focussed (2nd) last call. We go back to last call for the minimum number of weeks to find out if there are any formal objections to the changes we are making
... so one would be that if we say something is optional, then there doesn't need to be any implementation of it, just "if it is to be done, this is how"
... this is an open question, not needing resolution right now. Do we entertain the notion of making conformance level changes? It's looking advisable
... Do we have any features whose conformance level we want to change, and a change that means we don't need any implementations of optional features to exit CR
... I'm feeling a lot more comfortable that we'll have a full agenda, which is good

<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2009Jan/0042.html

John: topic in Action items list that we have to skip, but we could get through an easy bugfix issue and generate action items
... here is an email I sent, when I was doing a ubiquity code review about insert actions
... I noticed a disconnect between the appendix example, and what the insert action says it should do
... we claim that it is possible to replace the instance document
... it looks like the wording is to replace the root element, any of its siblings must be deleted with a regular delete
... if you try to insert into the children of the root node, you end up with an ill formed XPath data model, and an ill-formed instance data, because you can only have one root element
... So we wrote it to say if you refer to the root node, with the context attribute, then the target for insertion is the old root element, so replacement will happen
... we gave no example in Appendix B, but in B12, we use nodeset, so there is a second case in which we are inserting a node into the root node, so that there is a sibling of the root element

<John_Boyer> Old wording: If the target location was the root element of an instance, then the cloned node replaces the instance root element."

<John_Boyer> this in bullet 8

<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-insert

<John_Boyer> Go to bullet 7a

<John_Boyer> then look at the second bullet in 7a

John: If the insert location node is the root node of an instance (which is the parent of the root element), and the cloned node is an element, then the target location is the root element of the instance.
... the only way to get the insert location node to be the root node is to use the context attribute

<John_Boyer> Problem is 7b

John: we are covering off that when you have identified that you are inserting into the root node, and it is an element, then it is a replace of the root element

<John_Boyer> 7b covers what happens in appendix B.12 example

John: The problem is 7b: which is what happens in appendix B12
... when you identify the root element with nodeset, then the target location is immediately before or after, depending on @position
... so when you get to step 8, the target location is not the root element, but immediately before or after it
... so I suggest a wording change to cover both cases simultaneously
... What's common here is that if the parent node of the target location is the root node, and the cloned node is an element, then we should be replacing the root element before inserting the cloned node

<John_Boyer> New wording: If the parent node of the target location is the root node of the instance, and the cloned node is an element, then the instance root element is deleted before the cloned node is inserted."

John: This does a couple of things. In the old 7a case, when the target location is the root element, then we have the root node, which is good, but in 7b when it is before or after, we get to cover both bases
... is anyone uncomfortable with this change?

<nick> it looks good for me too

John: Erik says it looks good, and he's closely associated

ACTION John_Boyer Effect the change to insert based on http://lists.w3.org/Archives/Public/public-forms/2009Jan/0042.html

<trackbot> Sorry, couldn't find user - John_Boyer

John: Steven, did you want to say anything about the test suite?

Steven: I have spoken to picoforms, they haven't forgotten, it's just a question of manpower.

John: We might be able to ask them for a focussed report, like Chiba

<Steven> http://www.w3.org/MarkUp/Forms/wiki/FtF_2009_02

Steven: They also have a big announcement, which will be exciting
... the F2F is web page and registration is up

John: Good work for today, upgrade Yugma

<John_Boyer> Due to a missing colon, rrsagent missed the following action item, so I'm typing it again to ensure it doesn't fall through the cracks

<John_Boyer> ACTION: John_Boyer Effect the change to insert based on http://lists.w3.org/Archives/Public/public-forms/2009Jan/0042.html [recorded in http://www.w3.org/2009/01/28-forms-minutes.html#action01]

<trackbot> Sorry, couldn't find user - John_Boyer

Summary of Action Items

[NEW] ACTION: John_Boyer Effect the change to insert based on http://lists.w3.org/Archives/Public/public-forms/2009Jan/0042.html [recorded in http://www.w3.org/2009/01/28-forms-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/28 17:23:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/yes/correct/
Succeeded: s/say/saw/
Succeeded: s/requires/require/
Succeeded: s/Charli/Charlie/
Found Scribe: Paul
Found ScribeNick: prb

WARNING: No "Topic:" lines found.

Default Present: wellsk, wiecha, unl, John_Boyer, +0207689aaaa, prb, Steven, Nick_van_den_Bleeken, ebruchez
Present: wellsk wiecha unl John_Boyer +0207689aaaa prb Steven Nick_van_den_Bleeken ebruchez
Regrets: Leigh
Agenda: http://lists.w3.org/Archives/Public/public-forms/2009Jan/0045.html
Got date from IRC log name: 28 Jan 2009
Guessing minutes URL: http://www.w3.org/2009/01/28-forms-minutes.html
People with action items: john_boyer

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]