Cannes Face-to-Face , Oct. 21, 2008

21 Oct 2008


See also: IRC log


Charlie, Raman, Nick, Steven, Uli, John(Remote), Keith(remote), Rogelio(remote), Roland(remote), MarkB(remote)
Steven, Charlie, nick




<Steven> Scribe: Steven

Previous: http://www.w3.org/2008/10/20-forms-minutes

User Interface Layer Module

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.2_Modularization

John: There are a number of submosules
... we haven't discussed this module so much yet
... Looking at first bullet
... forms controls
... defines UI binding

Steven: So it defines the generic things you find over all controls

John: Yes, like chapter 8 of XForms now
... look at the beginning of chapter 8
... applies to ordnary controls, but also group and switch
... this module is the home for setfocus; I wouldn't know where else to put it
... also where we have defined refresh
... the model doesn;t have refresh until you get here

Steven; So if you had a language with a model but no controls, you wouldn't need refresh?

John: Yes
... the UI bindings are not distinguishable from other use of bindings syntactically, only semantically
... and that can be seen as a problem
... which we haven't had in the past
... someone else's custom elements can't get the refresh behaviour just by using the binding module for instance
... they have to do something else as well

Steven: Well, it's a problem from the language designers viewpoint, but not from an author's viewpoint

John: Well, the author can't see from the use of the attribute whether you get relevance for instance

Steven: So there is no way for a custom element to say which of the bindings it needs

John: And which should be the default
... message, hint, alert, label, filename, mediatype
... all use ref, neither as an action nor as a UI binding
... so what does ref do on <label>?
... and when you ref a nonrelevant node?
... and message still hapens as an action, even if the thing that is ref'd is nonrelevant

Steven: Interesting

John: So what should we expect for edge cases with elements like help hint and alert


Nick: Never tried it

Steven: My gut feeling is that you would expect it not to work
... nonrelevant means that the data isn't useful in the current state

John: So Keith, how about the test set? DO we test that?

Keith: I'd have to check

<scribe> ACTION: Keith to investigate if we test relevance on elements like help hint and alert [recorded in http://www.w3.org/2008/10/21-forms-minutes.html#action01]

<trackbot> Created ACTION-496 - Investigate if we test relevance on elements like help hint and alert [on Keith Wells - due 2008-10-28].

John: Should this be a clarification on XForms 1.1
... Does anybody agree with Steven's gut feeling above?

Charlie: It seems to be consistent, and therefore makes modularization easier

John: Mark would regard ref on help etc as a UI binding
... An interesting side of that, which means that labels get notification events, is that XML Events 2 distinguishes target and bubble
... and so phase=default is the wrong default for XML Events 2
... the proper default phase should be target

Steven: What? No!

John: The problem is that things like value change events on child events like alert under an input control will bubble up, and you don't want to listen to those while waiting for a value change on the control
... or otherwise not treat ref on an alert etc as a UI control
... It is difficult to identify when a binding is meant to be a UI binding otherwise
... Part of the problem of extending UI binding beyond our elements is that it introduces this problem
... So we could have a different set of attributes that distinguishes them

Charlie: Not thrilled with that
... You could have a meta attribute that encodes the difference

Uli: Not much better
... I'm fine with reusing ref

Charlie: How do you distinguish?

John: What power does the driver author have?

Steven: So why not different modules, where the attributes are spelled the same, but have different semantics
... so the UI bindings are spelled "ref", and the message bindings are also spelled "ref" but they have different semantics
... so the syntax is the same, and the semantics are different

John: But how do the modules themselves introspect and work out which is which

Steven: Oh I see your problem. If the bindings are implemented by a bit of script that has to walk the tree
... Doesn't this mean that there has to be an initial walk of the tree, disambiguating the attributes before processing proper starts?
... otherwise all attributes would have to be lexiacally unique
... and we can't guarantee that in a compound document

Uli: This is too generic

John: How come this never happened before?

Steven: In XHTML, the only attribute with the same name and different meanings is @name
... and we have renamed that mostly
... (I can't think of another attribute with this property offhand)

<John_Boyer> i.e. is it a new thing that we have, in one language module profile, multiple implementations for the same attr and the problem of needing to choose one based on context

<John_Boyer> and if so, what provides the mapping from context to implementation?

John: Should we have different names for the different binding types? Seems harsh

<John_Boyer> maybe css decoration

Steven: THat's what I meant by an initial walk of the tree
... different classes of elements can have a different secret attribute to identify it

Chalrie: That's what I meant by a meta attribute ealrier

John: We can use implied attributes at the schema level

Charlie: That leads to complexity
... and a steep learning curve

Steven: You think that it is easier to understand if you had <input uiref=... and <alert msgref="" ?

Charlie: Yes

Steven: I'm not sure. I think the user can deal with different effects on different elements

<markbirbeck> Very remote...

John: It seems reasonable to leave this design as is, where UI binding is generically applicable
... and there are things that inherit UI bindings, and things that don't
... but do we need that third class of binding, where you are inheriting relevance but not events?
... or do we need to look at the meta-level where we say that the binding ijust for data, or data+relevance, ...

Steven: Do we need to distinguish the first node rule?

John: No we have a different attribute where that kicks in

<wellsk> no objection

John: Are we OK with help hint and alert being a data binding only (no events, and no relevance etc)

Charlie: OK

STeven: Relevance gets ignored

John: Yes

<John_Boyer> summary is that, for now, we stick to having just the two fundamental types of bindings, data and UI.

<John_Boyer> We define that UI bindings are applied to all the things we currently claim are form controls (input, select1, ..., group, switch)

<John_Boyer> We define that other uses of bindings on our current set of modules are data bindings (submission, setvalue, message, label, help, hint alert)

<John_Boyer> and finally, we say that authors of future modules have various mechanisms in their repertoire (prose, schema attribute group usage, css decoration) for indicating which kind of binding is applicable to their new element

<Charlie> Scribe: Charlie

UI specs (cont)

John: thought it good to separate "output" control from the others

seems like a different beast

UI binding on an output is a little different from the others -- only goes in one direction

Steven: yes, but isn't this just a detail?

no way to go in the other way given it's output

if it was 2-way you'd not notice

for example this is really a "read-only" input

John: historicall, R/O comes from data not control

Steven: yes, but behavior is similar/same

Raman: other difference is in business workflow -- r/o to you but writable to mgr, then semantics are different

but wouldn't lose output control for this reason

John: assume then that UI binding on output -- still register for value-change events?

Steven: would hope so, yes

John: and other notification events, yes

inputs are directly manipulable by end-user vs container controls have NSB but don't directly manipulate the data

John: where should trigger go? another output?

it doesn't manipulate the data

fires events

Charlie: not convinced it's part of the output category

John: so which module should it go in? there's trigger and submit

perhaps a third bucket for trigger and submit

though submit is problematic -- unless you're using the submission module do you need submit?

so separate trigger and submit modules

Steven: ok

we can put modules in one spec, i.e. submission and triggering together

John: might be easier to put trigger in with the other input controls

but submit needs the submission module

but perhaps we don't care if the object of the event is really a submission module

<markbirbeck> Probably missed the discussion here. :) But I agree with JB that output is 'different'. An XForms that contains *only* model, instance and ouput, can be regarded as in 'inside-out' XSLT transformation. It can be processed 'one-way', with the result being a static page. I think there are many use-cases for that, and it's something worth documenting. (For a lot of scenarios you no longer require the usual data+XSLT-> static page, because you can throw th

Mark -- did your text get truncated?

John: what about the label module?

labeling is useful apart from whether there are form controls at all

e.g. for group module

seems like all of the other controls require label

Charlie: require?

benefit from yes, but not require

for accessibility we do require label in input now

so in fact the input module does now require the label

John: suppose we have the label module and an additional attribute @for

Raman: as in HTML4

John: so we're still semantically requiring that an input be labeled

Steven: input module doesn't have to require that there be a label

John: as in the driver?

all: yes

Raman: so what about hint, help, etc

John: even if it's optional, my processor would need to know about it to support it when it does appear

Steven: the input control has non-relevant and CSS picks this up and propagates to label

John: label gets this from containing form control, via css, but there still is this relationahip


Steven: but *label* doesn't have non-relevant it's the containing thing

Raman: if label isn't nested then this is problematic

Many: containment of labels in controls is helpful

John: regardless of how the label is specified, do we still say that the associated control drives the label visibility?

Raman: if not nested then the association can still be preserved through css pseudo-classes
... also will get into complex layout issues

John: i'm trying to tease apart syntax from conceptual dependencies

seems to be a property of label and not the control modules to know how to behave

i.e. to capture the relationship

Uli: would even say the label module doesn't need this intelligence

just stick with containment

don't need extra intelligence for label, except perhaps when importing label into another module

especially label doesn't need to know about relevance etc

John: so the xforms driver therefore that puts alert help hint inside form controls?
... in the past have looked at label and hint as control metadata -- info available to the control
... having trouble with the idea that input control doesn't know about its nested elements

Steven: yes, but how does the input control act differently depending on whether it has a label or not?
... behavior is as-if CSS styles are controlling this linkage

John: where does it say in the spec that this is the mechanism/meaning?

Raman: in my recollection we have said it behaves "as-if" there were CSS processing -- to not specify layout

John: no, we've said there is no requirement for CSS

Raman: right, but behavior is "as if" such behavior is available

John: we don't say "as if" CSS

Steven: abstract says we separate presentation from content
... means for me controls are not doing presentation

John: what questions can i ask of a form control? what is your hint, alert?

Raman: we never defined that object model or signatures on the controls in the spec -- not an IDL

John: except that we say input requires a label

Steven: that's syntactic

John: yes, but given this requirement it's reasonable to say that form controls have the following features

Raman: yes, when it's a monolithic spec not with modules

John: ok, now we're trying to decide how to put things together again
... again it's the xforms driver module that puts the original meaning of xforms back together

does it have to say that labels are used with form controls?

Steven: so yes, we'd say that xforms controls not including output are required to have labels
... Mark would point out that label could also be used in other contexts

<markbirbeck> I would like to point out that labels could be used in other contexts. :)

<Steven> Which is just what I said live here

<markbirbeck> That's why I said it!

<markbirbeck> I wrote it immediately after your comment.

<Steven> 1. Labels can be used all over the place. Labels can label tables, images, and so on

<markbirbeck> You said "Mark would point that..." so I did. :)

<Steven> 2. Ther eis nothing semantically wrong with an input that doesn't have a label

<Steven> you could have a language with a single control

<Steven> and it might not need to be labeled

<markbirbeck> When you create a control out of other controls, you often have controls with no label.

<Steven> We require labels on controls (except for output) for a *syntactic* reason, not a semantic

<Steven> one

<Steven> +1 to mark

<markbirbeck> The standard example being an IP input control, that is actually comprise of four input controls.

<Steven> there you go

<markbirbeck> So if we want to 'recursively' use XForms in this way, we need to relax things 'at some point'.

<Steven> So label is not an intrinsic part of a control

<Steven> it is extrinsic

but are those xforms controls or managed controls in the scope of a parent binding?

<markbirbeck> Some higher-level language could impose that restriction, though.

<John_Boyer> but the argument being made here is that in the XForms driver module, the label will be syntactically required by input elements (e.g. each of the four (or six) IP address inputs)

<markbirbeck> I.e., that a control must have a label.

perhaps they have local data binding to the state managed by their parent control not the root data model

<unl> @mark: an IP control could be done in another way: use an appropriate datatype, just like xs:dateTime

in the IP compund control case

<markbirbeck> Yes JB, and the problem with that is that you end up using <label /> everywhere.

<markbirbeck> Kind of defeats the object of enforcing it.

<markbirbeck> @unl: No...I'm talking about using XForms in something like XBL, to define custom controls that are then bound.

<markbirbeck> @unl: You are right that you might use a datatype to instigate the binding, but that doesn't *define* what to bind.

<raman> I must be jetlagged, for the last 10 minutes I have been busily joining the #xforms channel and wondering why I cant hear anyone.

<unl> @mark: see your point, but where's the difference to a date input control? could be done with three inputs, too.

John: so within a particular document the xforms driver module will only require label inside inputs in some context?

how can it decide when they're required and when not, as in the IP control case?

Steven: but the restriction that a control has a label is syntactical not semantic

<markbirbeck> Actually...I'm going to back-track. :)

Steven: so a different module can make a different decision -- e.g. the IP control

<markbirbeck> I'd like to hear from Raman how the IP control should behave in a voice system.

<markbirbeck> Should he get a voice-prompt on each of the four controls?

John: how can the driver tell the difference between these two cases?

<markbirbeck> If so, then we should be using CSS to hide the label, rather than removing it.

<markbirbeck> (For the visual use-case, I mean.)

at some point the labels and ARIA properties merge

perhaps the IP subfields need ARIA properties not labels

<markbirbeck> @Charlie: What does Raman think about that? I.e., should each field have a label?

raman says a label at the group level but not subfields is ok

and they probably don't need aria properties

Raman: some get filled in automatically and the individual meaning is not obvious of the separate subfields

designer of the IP subcontrols should have the freedom to put the label on the composite not subfields

John: ok, suppose the internal xforms inputs do not have labels
... outside of that IP composite field have another input control

are we saying that this individual can't use the xforms driver since it will say *all* input controls require labels?

Raman: IP wizard probably doesn't materialize input controls in the parent document

<John_Boyer> It seems like we have a system where xforms requires all inputs to have labels, but some other module can override that and say labels are not required on inputs. But xf:input is then one element that has two contradictory schema definitions

<John_Boyer> one that requires a label and the other that doesn't

<John_Boyer> So if we compose xforms driver module + ip address editor module, then how do we validate documents under that composition?

Steven: all we're arguing about is whether our input module says it requires label?

John: don't think this mixing of policies for xf:input will work -- two definitions for the same element in the same namespace

Steven: can make it context dependent

Raman: think schema is a red-herring

for this problem

Mark's IP control doesn't belong in the xforms namespace

Raman: there's no contradiction

there's an xforms driver putting together the input and label

Raman: Mark has taken the lower level input element and built his control

John: there is still a contradiction since i have to build a tool that can tell the difference between these two uses of xf:input

Steven: if we were creating a driver that included the IP control we'd specify that content model

John: and the driver for xforms...

Steven: and we'd say that input otherwise is input, label, help, hint, alert

John: so if I want to override the xforms driver rules i can't use that driver

Steven: yes, you have to change the driver -- it's the top level

John: right, so you can't use the xforms driver

Raman: right it's a new custom language

Steven: we're defining the library, but the *main* is the driver

we have a variety of xhtml modules that do this now

John: do you have a situation where you're taking two large modules and composing them with contradictory rules on the *same* element?

seems like you're composing statements about complementary elements not the same

Steven: just requires context dependent syntax checking

<raman> xforms driver == main program tha tuses the various modules as libraries -- it's not a library in its own right. John may be talking of a master xforms.a library that aggregates a set of modules --

<raman> that could be called the xforms 1.1 library.

<raman> but then since that lib doesn't contain custom controls, then you cannot write (and should not expect to) write a program that can use a custom control -- because the custom contol is not part of xforms 1.1

we need a "library" version of the xforms rules

<raman> and mark hasn't even said "hang on a minute"

i.e. a level below "main" that specifies the xforms rules so they can be composable with other extensions such as the IP custom control

break for lunch until 2:00 local time

<markbirbeck> I should also throw in that we have already shown in Ubiquity XForms that you can bind XForms functionality to an HTML input control. That there is *conceptually* the notion of an 'input' that is independent of any label, hint, alert or help. It seems awkward that we don't have that concept in XForms itself.

<John_Boyer> yep, we buy that label is separate from input. The problem I am flagging up is the fact that we're claiming the xforms driver will *require* label in *all* inputs

<John_Boyer> but the ip address module will then contradict that

<John_Boyer> so, if I want a language L ={xforms, ip address control}

<John_Boyer> then I have a language that contains two different and contradictory rules for xf:input

<John_Boyer> make sense?

<markbirbeck> @JB Further to your argument, I wrote this earlier, but I think it was just after you disconnected:

<markbirbeck> "I should also throw in that we have already shown in Ubiquity XForms that you can bind XForms functionality to an HTML input control. There there is *conceptually* the notion of an 'input' that is independent of any label, hint, alert or help. It seems awkward that we don't have that concept in XForms itself."

<John_Boyer> @MB I agree that this would be the way to solve it in this specific case, though it flags up a general problem for modularization.

<John_Boyer> At the most specific level, I'm saying it seems hard to claim that "XForms" (i.e. the xforms driver module) requires label on xf:input when a custom control module author can make it optional.

<John_Boyer> It's an "unenforceable" requirements

<John_Boyer> One way to solve is to eliminate the requirement

<John_Boyer> But more generally, what is supposed to happen when module A makes claim A' about the schema of an element and module B makes claim B' about the same element.

<John_Boyer> Maybe its local elements versus global elements?

<nick> Scribe: nick

Future meeting planning

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

Steven: If HTML and Forms together we can do it twice

John: We expanded our meetings to 4 days

Nick: But steven needs to be in on Saterday

John: We only have two

Steven: That's fine

Raman: Hosting XHTML would be hard at google

Charlie: IBM is next door
... We need to make the Virtual days more formal

Roland: Maybe do 5 half days

Nick: Allocating time is more difficult for a virtual day

Charlie: I we do cont. 4 hours

John: Unless we change our mind about FtF we don't have any virtual days
... before the TP
... California is OK
... What about the UK one

<Steven> scribe: Steven

<John_Boyer> Right now it's also not virtual

<scribe> scribe: Nick

<scribe> scribenick: nick

<Steven> scribenicknick: nick

John: What about 4 hours virtual meetings before the TP


John: Do we want to make a rough agenda for those meetings

Steven: Is Feb. to close, no it's fine

John: We will see how the modules go

The User Interface Layer specifications

John: There is the issue with various models making statements about the same element
... After you left MarkB mentioned that the XForms module will require the label to be required, as apposed to being optional

Steven: John This solves this problem, but anybody can write a driver model that doesn't requires label inside an input
... Then it isn't XForms anymore, but they may do it, we just want to provide models that they can use 'as' they want
... John Don't you believe in context based parsing
... XHTML 1.1 requires you to specify DTD to specify the version, XHTML 2.0 uses a version attribute
... You just check the document based on the version and pick up the right schema for the profile
... Schema doesn't requires you to specify the schema in the document, the language can specify which schema to use

Raman: explains that a schema for a specific language can have local overides

Roland: The schema will include different modules the XForms language uses

Raman: Explains that we can create an aggregator XForms module that is used by the XForms driver

John: What is the difference between a module and a driver

Steven: you can look at a driver as a program and a module as a library, a library can reference other libraries

<Steven> doc= control*

Roland: One module can say that an input may have a label and another module can say that a label is required, the driver can choose then

<Steven> control=inputcontrol|ipcontrol

<markbirbeck> But why not simply have a module that contains all UI controls, unadorned?

<Steven> inputctrl=<input>label</input>

<markbirbeck> Then any language can import those.

<markbirbeck> For XForms we then add label, hint, help, etc.

<markbirbeck> I.e., we *insist* on label.

<John_Boyer> @MB: That solves this specific problem, yes

<Steven> ipctrl=<ip><input></input><input></input>label</ip>

<markbirbeck> But the question is simply, are we going to insist on all other languages also using label.

<markbirbeck> If we are, then fine...put label in the base module.

<Steven> label=<label></label>

<markbirbeck> But if we are moving towards not insisting, then it shouldn't go in.

Steven: I wish I understood what the problem is

John: ok, they are two different elements

<markbirbeck> My feeling is that we *should* insist on label, but at a semantic level. I don't know how to do that yet, but what I mean is that <label for="x" /> is a legitimate way to say that a control has a label. I.e., we shouldn't insist that the label be a *child* element, just because we want there to be a label present.

Roland: The modularization scheme isn't tied to schema, DTD, schematron,...

Steven: For example an 'a' doesn't allows an 'a' as a descendant this couldn't be expressed in XMLSchema but it can be SVG Shema

John: I just want to point out this weakness
... If someone want to use XForms together with their custom IP control that doesn't requires labels

Raman: It is just the rules

Roland: If you don't allow it, will you require MarkB to create a control like input but isn't an input control

John: ...

Raman: It isn't that the labels wouldn't be required on the other input controls

John: Next item container module
... there would be a Group Module, switch module and repeat module
... The repeat module will need an implicit instance for keeping the repeat index
... What about the repeat attributes a separate module?

Uli: A separate module

John: What about the repeat-nodeset attribute?
... Next we have the message module
... Are those 4 modules in one spec?

Roland: I would like to separate the action from the other ones

John: Do these 4 things belong together in one spec

Roland: label belongs in the same category as message, help, hint and alert
... help, hint and label could be put on all elements not only on form controls (alert is tight to forms)

Uli: They just show a special message

Roland: You can also see help, hint and labels as being triggered by a gesture
... label is triggered by the render gesture
... it is a short desc, longer desc and even a longer desc
... alert is only on a form field

John: So how many modules?

Roland: I can label, help and hint are useful in XHTML on elements
... We never had the need for alert of message

Uli: They are all messages

Roland: you can style them to be always visible

Uli: We have text in the spec that says that help, hint and alert are messages

Roland: The whole page could be a message
... Uli you believe that I'm not allowed to style an hint so that it is always visible

Uli: yes your allowed to do that

Roland: Explains how label, hint, help can be used on all XHTML elements
... But can't find a need for allert
... Therefore I think it should be in another module
... ... together with message

Uli: We can have one module for all, or a module for each, but not a union of some

John: label is separate already, hint and help together, alert and message
... Would the driver add data binding to those elements

Raman: Yes

<Steven> welost raman

<Steven> we lost

Future meetings

Nick: 3 or 4 is the same for my company

Steven: 3 days are fine for me and a virtual

Nick: Erik is also located in Palo Alto so he'll be probably there

John: Will we leave Feb. for what it is, and discuss June

Charlie: I like 3 days

Steven: 3 days is better for me too

John: Ok then we go for three days and virtual

Nick: If we to it on Wednesday then we have the 1.5 hour call

John: Ok then we do on Wednesday and Thursday a virtual day of 4 hours
... 4th and 5th Feb are the virtual days
... If we do 4 hours after the teleconf time

Nick: Then we need to eat before 5pm or after 9 pm

John: What about one day on the 5th?
... On Wednesday the normal call of 1.5h and a virtual day (like last week) on Thursday
... We will do the same thing for the UK

Steven: OK

John: That will be June 4th on Thursday
... we will have a virtual day


John: Two virtual days Oct. 28-29, 2009 9am-3pm eastern with 1 hour break at 12pm eastern
... Technical Plenary, 2-6 November 2009 or 16-20 November 2009

Steven: So since we are reducing the number of to two can't we do Tu-Thu

Nick: If we change it I'll have to travel on Sat. and we we will return on Sat

Steven: That's right, maybe we will stay with Mo-Wed



* Virtual day on Feb. 5 9am-3pm eastern with 1 hour break at 12pm eastern


PLUS 9-11 February, San Jose, USA Raman (Google) Hosts


* Virtual day on June 4 9am-3pm eastern with 1 hour break at 12pm eastern


PLUS 8-10 June, London, UK Mark and IBM Host ?


* Two virtual days Oct. 28-29 9am-3pm eastern with 1 hour break at 12pm eastern

* PLUS Technical Plenary, 2-6 November (or 16-20 November), San Francisco Bay Area, California, USA (in conjunction with AC 2009)

John: Who is going to do all this work

Nick: Isn't it is rewriting it as modules as much work as writing the XForms 1.0spec

Raman: I don't think so

Nick: You need to redesign a lot

Charlie Agrees

Uli: I need some more info for Submission

John: Can you lead this on the next telecon

Uli: Yes

<scribe> ACTION: Uli to prepare discussion about Submission on the teleconf of 29th of Oct [recorded in http://www.w3.org/2008/10/21-forms-minutes.html#action02]

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

(Going over the modules)

John: Form Controls contains custom controls and ui refreshings, ui binding attributes, ...

Charlie: I don't think we have to sign those up, there are people not here

Name of the stream line spec

Raman: Call it Forms-A and not WebForms-A

Charlie: We are the Forms group

John: Forms-A
... Good

Charlie: Can you update the draft, John?

John: I'll do

Summary of Action Items

[NEW] ACTION: Keith to investigate if we test relevance on elements like help hint and alert [recorded in http://www.w3.org/2008/10/21-forms-minutes.html#action01]
[NEW] ACTION: Uli to prepare discussion about Submission on the teleconf of 29th of Oct [recorded in http://www.w3.org/2008/10/21-forms-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/10/21 14:58:34 $

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/much/much yet/
Succeeded: s/controld/controls/
Succeeded: s/SO/So/
FAILED: s/altert/alert?/
Succeeded: s/git/gut/
Succeeded: s/DO/Do/
Succeeded: s/WH/Wh/
Succeeded: s/SO/So/
Succeeded: s/poer/power/
Succeeded: s/SO/So/
Succeeded: s/iupt/ipt/
Succeeded: s/rl/lr/
Succeeded: s/SO/So/
FAILED: s/relationalhip/relationship/
Succeeded: s/WHich/Which/
Succeeded: s/There there/That there/
Succeeded: s/John:/Steven: John/
Succeeded: s/John:/Steven: John /
Succeeded: s/are/is/
Succeeded: s/Moud/Mod/
Succeeded: s/Agg/Ag/
Found Scribe: Steven
Inferring ScribeNick: Steven
WARNING: No scribe lines found matching previous ScribeNick pattern: <nick> ...
Found Scribe: Charlie
Inferring ScribeNick: Charlie
Found Scribe: nick
Inferring ScribeNick: nick
Found Scribe: Steven
Inferring ScribeNick: Steven
Found Scribe: Nick
Found ScribeNick: nick
Scribes: Steven, Charlie, nick
ScribeNicks: nick, Steven, Charlie
Default Present: wellsk, John_Boyer, Cannes
Present: Charlie Raman Nick Steven Uli John(Remote) Keith(remote) Rogelio(remote) Roland(remote) MarkB(remote)
Agenda: http://lists.w3.org/Archives/Public/public-forms/2008Oct/0035.html
Got date from IRC log name: 21 Oct 2008
Guessing minutes URL: http://www.w3.org/2008/10/21-forms-minutes.html
People with action items: keith uli

[End of scribe.perl diagnostic output]