See also: IRC log
<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
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]