See also: IRC log
<Steven> Scribe: Steven
Previous: http://www.w3.org/2008/10/20-forms-minutes
<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
s/altert/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
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
s/relationalhip/relationship
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
<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
(consensus)
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
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
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
http://www.w3.org/MarkUp/Forms/wiki/FaceToFace
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
2009
February:
* 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
June:
* 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 ?
Oct/Nov:
* 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
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
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]