See also: IRC log
<Steeeven> hi
<John_Boyer> hi
<klotz> OK net up but phone not yet
<nick> http://www.w3.org/MarkUp/Forms/wiki/FtF_2010_03_24_Agenda
<Steven> hair: Steven, Leigh
<wiecha> Scribe: wiecha
1 line summary of each agenda item
rechartering looks good so far
Steven sending request to w3m with details for final approval
who to invite to join the WG?
we should list our preferred invited experts and talk with other companies soliciting participation
Test Suite agenda topic:
were going to do "bashing"
John: what does this entail?
Steven: create some tests
Nick: were some tests recently that we thought would go into new version of the test suite
UI events: Erik
Erik: at last F2F we had some agreement except Uli's objections on changes
in my opinion, would like to get closure on general concepts
toward future version of the spec
XML Events2
have a draft
taking further
who owns? Mark and???
shane
<nick> http://www.w3.org/MarkUp/Drafts/#xml-events2
<nick> http://www.w3.org/MarkUp/2008/ED-xml-events-20081223/
depending on Mark's role I (Steven) might take this over as I was an editor of version 1
JSON
need better extensibility for submission and respose handling
XPath 2.0
discussion of how/when to move to offering xpath 2.0 support
Erik: last discussion was around function signatures
might need more work
one question was whether signature of xforms xpath functions should be compatible with 1.0 or native 2.0
e.g. date function in 2.0 can return xsd date which is not in 1.0
Nick: both arguments and return types
downside is won't be backwards compatible
Erik: hard to say...don't have much experience
if you change sigs you'll have to rewrite. but you don't have to use 2.0
<scribe> new forms would hopefully start in 2.0
Steven: would declare at the top which version is being used
John: understood that 1.0 is required and 2.0 is recommended
Erik: would have to cast the strings into native types
Custom XPath: Erik
at last F2F followed up by contacting xslt wg sent to the list...we should review
Michael Kay also made recommendations based in Erik's questions...should review
can then complete draft spec already started
Node creation functions: Nick
did some work on the wiki
functions to create nodes from strings
<nick> http://www.w3.org/MarkUp/Forms/wiki/Node_%27create%27_functions
subtrees of XML from data
Components/patterns
could discuss some work on composite patterns such as master/detail and list to list
<nick> node creation functions : the discussion started when sequences were 'needed' for child content
is there an opportunity to simplify this
then package as components...which leads to the
XBL topic
Erik: not the answer for everything, solid base
should consider requirements for custom components
Steven: good approach, main approach is it's at odds with declarative nature
needs js
Erik: doesn't require JS
the way we use it the components are 100% XForms plus XBL, does not require JS
would be good to look at some examples in Orbeon
Nick: didn't take me long to write some custom components based on that approach
Variables: Erik
maybe naming is the issue to discuss
don't think we have spec ready text
Leigh: doesn't include AVTs
John: scope and lifetime are the big topics
closures etc
External models: have text to review
XForms for HTML
Leigh: would like to get agreement on scope for this doc
and then quick outline
Live documents: Steven
alter the document the form is in, e.g. tying class name to dependency graph
Erik: options could be special control
Map/Reduce support
make our constraints work on structure of instances as well as values
e.g. structural binds
<klotz> I am adding the one-liners to http://www.w3.org/MarkUp/Forms/wiki/FtF_2010_03_24_Agenda#Agenda
map/reduce are structural transforms
Leigh: what about controls for recursive or nested structures
e.g. trees
separate topic from map/reduce
Putting Control in Charge
@ref vs @nodeset vs @select
Erik: more general question of whether control is conceptually in charge of binding policy
vs. external attributes determining how control behaves
as implementor my impression is we can't escape control identity object which defines behavior
could name attributes however...
Errata...
<John_Boyer> links to two added above
HP and Adobe will be joining
Leigh: not sure about HP, has anyone talked with them?
John: they are doing interesting stuff with interactive docs and workflow...could be those folks
Steven: other candidates?
and for invited experts?
should invite Joern as expert
<nick> Alain Couthures
and Mark
and XRX folks
Kurt Cagle
Dan McCreary
EMC
AmpleSDK
Jadu
Atlassian
Nuxeo
Alfresco
Charlie: does it make sense to make better connection with the XML activity?
John: what's the benefit of being a separate activity just for XForms?
Steven: we could explore joining the XML coordination call
but moving the WG might be hard since the staff time there is very constrained now
John: is the ubi-web domain a better placement for forms?
Steven to explore joining the XML coord call, Leigh to participate if ok
response from XML CG: http://lists.w3.org/Archives/Public/public-forms/2010Mar/0030.html
<Steven> [back]
<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2010Mar/0027.html
The appearance attribute is not the same format as @class
does not take a space-separated list
Nick: what to do with conflicts?
e.g. minimal and full
John: right, could do that but it's really a hint
Erik: CSS handles conflicts with well-defined rules
John: right
CSS defines how to resolve conflicts
Steven: not really conflicts, just get applied in order
Erik: we'd have to specifiy
John: not really, it's a hint
Leigh: any QNames
John: yes
Leigh: thought we discussed this before and decided not to
Steven: changed the def to one of our and any number of others
Erik: not really a solution, can't say "minimal full"
are we happy to do that strict validation?
John: I'd be happy with just a space separated list...just pick the first one
Erik: or the last one
Leigh: so we could just restrict it to one of ours
John: now we've said you can only have one entry...what happens if you put multiple in now?
Nick: fails in Chiba
Leigh: if it's not defined it's undefined
Erik: doesn't this go against interop?
Steven: but interop is in terms of what's defined...rest is ok
Nick: could be confusing across multiple implementations
this is really a new feature, not an erratum
Leigh: but this shouldn't affect a conformance test
similar to loosening order for help, hint, alert
Nick: think it will be confusing
Erik: what are the use cases?
Leigh: two orthogonal things
John: an example in the email is minimal but also control what's shown when collapsed
e.g. full state/province names when pull down is open but abreviated codes when selection is done
Leigh: seeing lots of straight equality tests in existing code
John: so I could just use a foreign-namespaced attribute for now
if nobody is using this feature in 1.1 I'll do that
http://lists.w3.org/Archives/Public/public-forms/2010Mar/0028.html
what are implementors currently doing for these?
Erik: yes, we do encode these
John: spec is not clear
<ebruchez> http://www.w3.org/XML/2007/04/hrri/draft-walsh-tobin-hrri-00.html
<nick> http://www.w3.org/TR/xmlschema-2/#anyURI
Erik: there's also some work in HTML5 on this
John: I think XML schema is clear on what is valid URI
so we should be able to check for this
<nick> http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators
so form authors could use actual spaces and form processor would encode
encoding is idempotent
Erik: right, we don't have to reinvent
browsers do this today for links input by users
John: yes, would apply for input values that are URLs
Erik: we now apply this only to @src, @schema, etc submission/resource but not in data
John: the internationalization wg also gave this feedback as last call to 1.1
related to IRIs
will increasingly be seen in URLs for asian sites as new characters are used
<ebruchez> got response from @ndw: HRRI came out as this note: http://www.w3.org/TR/2008/NOTE-leiri-20081103/
John: yes, there's some work to look at future versions, but what should we say about 1.1?
Erik: didn't think it was expected for 1.1
John: I did think it was
Erik: as form author I would expect it, but as implementor the spec is not clear
would be a step toward more user-friendliness
John: thought it was obvious
we encode the parameter phase
Erik: want to use leiri algorithm
Leigh: doesn't handle &
<Steven> http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators
John: we could do this in a future version, but what about 1.1?
<Steven> "The Recommendation states that "it is impractical for processors to check that a value is a context-appropriate URI reference," thus freeing schema processors from having to validate the correctness of the URI."
<Steven> http://books.xmlschemata.org/relaxng/ch19-77009.html
Nck: ...examples of difficult encodings...
<klotz> <xf:load resource="http://web.archive.org/web/19970407000143/http://www19.w3.org/:>
<klotz> <xf:load resource="http://web.archive.org/web/19970407000143/http://www19.w3.org/">
<klotz> <xf:load resource="http://web.archive.org/web/*/http://www19.w3.org/">
<nick> http://www.boe.org/my?url=boe?foo
Erik: seems clear that some type of encoding should take place but not sure exactly what
we don't know enough to resolve
<ebruchez> http://www.w3.org/html/wg/href/draft
<klotz> <submission resource="mailto:me.myself@example.com" method="post" />
<klotz> http://www.faqs.org/rfcs/rfc2368.html describes encoding of mailto:
<ebruchez> http://www.blackmesatech.com/2009/03/wah5/uricalc.html
John: we should either say we don't encode or point to a specific encoding policy we use
<nick> from 'Legacy extended IRIs for XML resource identification' Some productions are ambiguous. The "first-match-wins" (a.k.a. "greedy") algorithm applies. For details, see
Leigh: trying to encode when starting from a complete URL leads often to double encoding
<unl> hi steven
Leigh: which will often be the case when starting from user-provided data
John: for 1.1 the xlink encoding is the only reasonable one we have
Leigh: are you proposing this applies to calculated data as well? or just form text
John: applied at moment the URL is used...would not change instance data
nor the source document
get resource or src content and apply this encoding
Nick: if it's in the data w/dynamic URI this would apply
John: yes
<Steven> http://ab.גדהוזח.ij/kl/mn/op.html
So the erratum would clarify whether the content is used directly or first encoded in this specific way
<Steven> http://ab.دخح.جثت/ij/kl/mn/op.html
Erik: how does xlink relate to the leiri stuff?
John: i18n says anyuri is intended to be compatible
Steven: anyuri as lexical space which is what the user would expect.
John: right, e.g. an actual space character
so should actually work in the xforms processor
John: so should we issue a clarification that the anyURI encoding happens just before going over the wire?
Nick: nods
Steven: agree, would like an example of anyURI in lexical and value formats
Leigh: would like some test cases
John: yes, we have a few errata...should have a few tests for each one
Leigh: not clear there's even text associated with this...maybe a note
John: just a clarification
have seen implementations that don't do this encoding
so we ought to be saying something
Leigh: yes, but it's not a normative change
John: clarification not substantive erratum
Leigh: think we still need tests for double encoding problem
question marks etc
<Steven> http://dir.google.com/Top/World/Chinese_Simplified/%E8%AE%A1%E7%AE%97%E6%9C%BA/"
to be sure implementors aren't calling the wrong encoders
<Steven> http://dir.google.com/Top/World/Chinese_Simplified/计算机/
<Steven> Those two are equivalent
<klotz> just as long as it doesn't require this to decide when to encode: http://dir.google.com/Top/World/Chinese_Simplified/%E8%AE%A1%E7%AE%97%E6%9C%BA/%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD/
<unl> there's a trailing space in http://dir.google.com/Top/World/Chinese_Simplified/计算机/%22 ;)
Leigh: I suggest we check with Larry given he's coordinating IRI work
John: yes, if we're going into IRI space in future versions
Leigh: he wrote both of these RFCs
<scribe> ACTION: john_boyer to write up erratum text for encoding consistent with i18n and xlink recommendations [recorded in http://www.w3.org/2010/03/24-forms-minutes.html#action01]
<trackbot> Sorry, couldn't find user - john_boyer
<klotz> http://www.yelp.com/biz/indian-chili-cambridge
<raman> dinner plans?
<John_Boyer> Steven, can you rejoin the teleconference when you guys start?
<John_Boyer> Hi Steven, I rejoined a few minutes ago because it looked like you guys were back. But I am here and will join when you rejoin the teleconference
<unl> me too
<nick> scribe: nick
<ebruchez> http://wiki.orbeon.com/forms/doc/developer-guide/xforms-refresh-events#TOC-Proposal
Erik: Currently he UI events
don't work in a way a form author could use them in a reliable
way
... The current mechanism is based on a marking algorithm in
the instance data
... For the form author the control shouldn't get a
value-change event when the controls value doesn't change
<klotz> For components, could we have an element to express the desire to receive certain events such as MIP or value events?
Steven: When the value changes from 42 to 45 to .. and back to 42 you don't get an event
Erik: correct
wiecha: it should appear as a transaction between refreshes
ebruchez: if the control knows the old and new value, it is the best place to send the events
wiecha: it doesn't make a difference if the control or the control sends the events, the model can still do it
ebruchez: I think this shouldn't
be specified by the spec (who sends the events)
... it simplifies the learning process for form authors (for
value-change, read/write, relevant, required,...)
... explains how you could optimize when the bindings need to
be updated
wiecha: it is a question if we want the model or the UI to do all the work
ebruchez: in our product it is
something between the model and the UI
... it knows the bindings and the UI controls
klotz: do we think that the UI events are meant for the form author, and not for the implementation
ebruchez: so far I don't know an implementation that uses the UI events for controlling the controls
klotz: in custom-controls you
also maybe want events to keep them up-to-date but you probably
don't want the same UI events that could be cancelled by the
form author.
... we should separately consider events that are used by form
authors and events used by custom form controls
... I think we don't have enough experience with the events
used by custom form controls
... does everybody agree?
ebruchez: I aggree
<unl> i agree with leigh
nick: also agree
(looks like the rest of the group silently agrees)
<unl> +q
unl: I also wants to be able to have model only processor
<klotz> So how about this "Res: For XForms 1.2, we will specify UI events designed for author use, and will test for coverage and ease of use against use cases, and will separately consider the question of events for custom controls or model-only processors."
ebruchez: this is another new feature, we have xxforms-value change which is similar to insert and delete events
klotz: do we need to check if the proposals make events in custom events hard
ebruchez: that will be hard, because then we have to look into custom controls
wiecha: if we see a red flag we should take it into account
Steven: does it change anything for the ordering of the events
ebruchez: currently we don't say anything about order
<klotz> So how about this "Res: For XForms 1.2, we will specify UI events designed for author use, and will test for coverage and ease of use against use cases, and will separately consider the question of events for custom controls or model-only processors, and will make good-faith efforts not to impede that direction in the future."
John_Boyer: it is also about the life-cycle of controls and controls in repeats
<klotz> So how about this "Res: For XForms 1.2, we will specify UI events designed for form author use, and will test for coverage and ease of use against use cases, and will separately consider the question of events for custom controls or model-only processors, and will make good-faith efforts not to impede that direction in the future."
RESOLUTION: For XForms 1.2, we will specify UI events designed for form author use, and will test for coverage and ease of use against use cases, and will separately consider the question of events for custom controls or model-only processors, and will make good-faith efforts not to impede that direction in the future.
<Steven_> Meeting Forms WG FtF Day 1
ebruchez: one distinction XForms
has markup that specifies a control and at runtime we have
instances of the controls (it becomes clearer in repeats,
multiple runtime objects for one control in markup, even no
runtime objects)
... If a control is created (runtime object), its value
changes, MIPS changes, and then it can disappear, after it
disappears no events can be send to the control nor can the
user interact with the control
John_Boyer: we have text in the spec that you could style non-relevant controls
<unl> +q
John_Boyer: the controls can show what they last contained (and don't get events anymore)
wiecha: having an extra state in the life-cycle would be helpful
<John_Boyer> it isn't as easy as saying that a non-relevant control is simply not bound to a data node because an xf:input may only be non-relevant by virtue of being bound to a node whose relevant mip is false
wiecha: it looks like binding relevance to the lifetime of a control is a bit ...
unl: you want to keep state if a control becomes non-relevant
nick: you want not to keep state for non-relevant controls, so you don't have to keep all the non-relevant controls in memory
wiecha: same holds for non-selected cases in a switch
ebruchez: gives example of a huge
form with a repeat
... we only have one relevance (can be triggered in multiple
ways), and when not-relevant controls don't 'exist'
nick: a control should not keep state in my opinion
unl: I think that we should limit this
<unl> @nick: i didn't say something like that...
ebruchez: what state do we now have, MIPS comes from model, value too, repeat index, switch case and dialog state are the three that need to be serialized
<unl> my main point was that there's a difference between relevance and existence of a control
ebruchez: there is a need for a switch that remembers state for non-relevant cases
<John_Boyer> As an example of state, if you have a group that contains a switch on case #3, and the group becomes non-relevant, the contained switch will not maintain the state of being on case #3
<John_Boyer> repeat index is another example of state
klotz: did we ever tried model based repeat
<John_Boyer> the value being shown by the non-relevant control is another possible piece of state
ebruchez: there 'could' be two types of relevant, hard (when not pointing to a node), soft (when the node is not relevant)
<John_Boyer> There is language in current spec (could change) which says that a form author *could* style non-relevant controls as visible but disabled
klotz: what do you think of a minimized version of controls (and maybe have a model based version)
<John_Boyer> At which point, one might reasonably expect correct values will be shown even if xforms-value-changed is not dispatched
<unl> another example on relevance vs. existence: a repeat over a non-homogenous collection
John_Boyer: explains that when a control is not relevant the UI events could not be send to a control, nevertheless the control can update its value that is shown
wiecha: why can a non-relevant control track its value changes, when the model isn't calling the refresh anymore
ebruchez: I'marguing for a non-relevant control not keeping state
wiecha: Isn't there an outside
agent that informs the control that it needs to be created and
when it becomes non-relevant
... is the transition from relevant to non-relevant internally
or externally driven?
ebruchez: That doesn't need to be
specified
... it is up to implementers
... Concrete controls are created at the following times:
* During processing of the default action for xforms-model-construct-done event, if they meet the conditions for relevance
* When a new repeat iteration is inserted into a repeat container, if they meet the conditions for relevance
o either during xforms:insert processing
o or during refresh
* During refresh, when the condition for optimization goes from non-relevant to relevant
ebruchez: ...
John_Boyer: for repeat index there is an implicit instance that holds the index, an index() makes a dependency to the node
ebruchez: we don't have UI dependencies defined
John_Boyer: bcz. of the wording
in the spec this will work now
... we have to do the same work for switch
ebruchez: the case() is only
dependent on data in the data bound switch
... so it is only as complicated as repeat in the data bound
switch case
John_Boyer: I'm currently working on the data driven switch
ebruchez: do we have consensus on controls don't keep state when not relevant
Steven: There are places where you see the non-relevant controls so you now you don't have fill it in
John_Boyer: what does it do with non-relevant groups, switches, repeats
ebruchez: you want to style it as disabled
John_Boyer: what happens to the
switch when it is non-relevant
... If we don't keep state, it's appearance will be so strange,
so we should be throw it out
Steven: gives use case again
John_Boyer: I agree, but then it should display accurate values.
ebruchez: We use the concept of read-only for it
nick: there is the use case where you don't want to submit the data, but want to show it disabled to the user
klotz: Is this a new MIP? Or just presentation
John_Boyer: If we allow custom MIPS we are done
Steven: There is conceptual difference between relevant and read-only
John_Boyer: some people don't want to see the form geometry to change when data becomes non-relevant
ebruchez: if we have a new MIP disabled, that is similar as relevant that would be fine
John_Boyer: we already can style it using the current MIPs and CSS
ebruchez: An implementation could style a control as disabled and displaying the latest value
John_Boyer: the control needs to know is position on the screen and how it affects the layout
ebruchez: you could take a snapshot, and forget everything, the only downside is when the switch becomes relevant again it 'forgets' the selected case
John_Boyer: we could introduce a new attribute that drives if we want to keep state if they become non-relevant
ebruchez: if you can put it on
any control, and use inheritance
... we have such an attribute to say if non-selected cases be
still there, and get all the events
... what do we do for input, if the input doesn't binds to a
node (you have to remember the type, value,...)
... I see two ways
1) keep state: It will keep it state around when a control becomes non-relevant
2) keeps updating: It will keep it state around when a control becomes non-relevant, and update it's value -> but what if it's looses his binding
John_Boyer: in option 2, I think the value should be the empty string
ebruchez: in the switch case, you don't want to show the non selected cases, but you want the events to keep happening
<Steven_> [time for a break]
wiecha: We could say that is the
control can choose how it behaves when non-relevant
... we need to define the control life cycle
John_Boyer: why don't the events enabled and disabled be sufficient?
ebruchez: but then a control needs to be still alive in some cases when the control becomes disabled
<John_Boyer> as said in meeting, it's not "adding" complexity to maintain the feature in which non-relevant controls are capable of remembering their state in case they are styled as visible but disabled
<John_Boyer> more (but necessary) complexity is being added to support the feature of UI controls *not* remembering state because this allows significant optimization (and may even become the default)
<John_Boyer> But the ability to remember state is needed to continue to support a feature we already have that is in use, and an XForms processor would still need to support that in case the author explicitly requests version="1.1" processing
<Steven_> [back]
<Steven_> scribe: Steven
<Steven_> Steven: Can we wrap this?
<Steven_> John: Are we trying to remove features we already have?
<Steven_> Erik: They are useful, so we should retain the functionality
<Steven_> ... the main use case that has questioned the proposed lifestyle, is visible but disabled
<Steven_> John: and b) Even if visible showing what is going on
<Steven_> ... in 1.1 that is what happens
<Steven_> ... we detach the event handlers, but don't block the updating
<Steven_> ... now we are considering more optimised behaviours
<Steven_> Erik: The visible behaviour is not *required* by the spec
<Steven_> ... we don't specify it fully
<Steven_> John: Yes we do
<Steven_> Erik: It is not as clear as some other features
<Steven_> John: It's a classic misunderstanding
<Steven_> Erik: I wouldn't have inferred that
<Steven_> John: In repeats nodes are responsive to the node they are bound to
<Steven_> ... even if in a non-relevant group
<Steven_> ... all we do is unhook events
<Steven_> ... there are interesting side-effects
<Steven_> ... if a group becomes non-relevant, the events become unhooked and the controls are unavailable
<Steven_> ... but if a binding becomes empty, that has a bigger effect
<Steven_> Erik: It doesn't follow if you have variables, or if you use XPath 2
<Steven_> John: It is either inheritance or the root element node of the instance
<Steven_> ... if you have more interesting way? of geting context, there would be less egregious consequences if a group became non-relevant because of an empty nodeset
<Steven_> ... but if it becomes non-relevant because of a relevance mip, then it still provides context
<Steven_> Erik: Something is missing
<Steven_> ... when can a control be destroyed?
<Steven_> .... disappearing repeat iterattions
<Steven_> ... but non-relevance is not enoug
<Steven_> Erik: So we need new events
<Steven_> Erik: We are adding new concepts here
<Steven_> John: To support the case of knowing when the objects are created and destroyed for optimization purposes
<Steven_> Steven: Isn't that an implementation detail?
<Steven_> Erik: It is not purely for relevance
<Steven_> ... you can't do the optimisation if the controls are required to do things
<Steven_> ... you can do it in implementations that only do disply:none for non-relevance
<Steven_> s/disply/display/
<Steven_> John: In a group of controls where a payment method has been selected, they make a choice, a change event happens, and a toggle switches on details for thatt method
<Steven_> ... but then they go and do something they didn't mean, and so the payment details become non-relevant
<Steven_> ... and they switch it back, undoing the msitake
<Steven_> ... the controls become relevant again
<Steven_> Steven: You don't destroy the instance values
<Steven_> John: Yes, but switch has selected case 2, you want to keep that
<Steven_> Leigh: In forms 1.2 we can use select @ref
<Steven_> Erik: We agree that there are valiid use cases
<Steven_> s/ii/i/
<Steven_> Erik for both ways
<Steven_> ... some push towards controls not keeping state
<Steven_> John: Even that being default
<Steven_> Erik: ANd for the opposite
<Steven_> s/AN/An/
<Steven_> Erik: So what's the next step
<Steven_> Steven: We're designing XForms 1.2, so let's use model-ased switching#
<Steven_> s/-ased/-based
<Steven_> John: Another use case, data-processing, heads-down data entry, where you don;t want the layout to change
<Steven_> John: so do value changes need to be tracked?
<Steven_> ... some expect it, and would file bug reports
<Steven_> Leigh: Yes
<Steven_> ... that was my point earlier
<Steven_> John: We have three responses to non-relevance 1 display: none, 2. display: hidden 3. Disabbled
<Steven_> Leigh: How is disabled different from read-only
<Steven_> John: Events
klotz: maybe we need prune, instead of relevance and disabled
John_Boyer: we have a use case, and solved it by styling non-relevant, maybe we need to throw it out
klotz: maybe we need both MIPS prune and read-only
John_Boyer: we could throw out
styling on non-relevant
... we don't need prune at the data layer, we already have
relevance at the data layer
... if a control can say that relevance applies to the
control
ebruchez: if you do that how you are going to style it if the control binds to non-relevant data
John_Boyer: we're back to
keep-state, bcz. we want the control some kind of alive
... the default could be not there when non-relevant, another
level could still there but disabled
...
ebruchez: in that case should the
control dispatch xforms-disabled when it doesn't consumes the
relevance property
... otherwise we need another event
... we could add an extra MIP
John_Boyer: I don't like us adding an extra MIP that does almost the same as relevant
ebruchez: in some cases you want
the read-only data to be pruned in other cases you wan't
... we are picking real specific cases, and no general
cases
John_Boyer: if you want to style non-relevant controls you need to keep state
wiecha: if we ditch the feature it simplifies the life-cycle of the control
ebruchez: how do we prune read-only nodes (if required) OR how do we style non-relevant nodes
John_Boyer: if we drop the functionality, do we drop important use cases?
ebruchez: I think giving multiple meanings to relevance makes it complex
Steven: the true thing is your saying that it is non-relevant
ebruchez: relevance is a tool for hiding stuff, and disabling event-handlers
Steven: If you say that relevance is misused for presentation issues then we need to look into that
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/respose/response/ Succeeded: s/hin/hint/ Succeeded: s/though/thought/ Succeeded: s/but/and/ Succeeded: s/I /I'm/ Succeeded: s/layour/layout/ Succeeded: s/and the input doesn/if the input doesn/ Succeeded: s/tt/t/ Succeeded: s/..../.../ Succeeded: s/relevance/optimization/ FAILED: s/disply/display/ FAILED: s/ii/i/ FAILED: s/AN/An/ Succeeded: s/#// FAILED: s/-ased/-based/ Succeeded: s/;/'/ Succeeded: s/bb/b/ Succeeded: s/y/y?/ Found Scribe: wiecha Inferring ScribeNick: wiecha Found Scribe: nick Inferring ScribeNick: nick Found Scribe: Steven Scribes: wiecha, nick, Steven ScribeNicks: wiecha, nick WARNING: Replacing list of attendees. Old list: John_Boyer Charlie Steven Nick Erik Leigh unl New list: John_Boyer Default Present: John_Boyer Present: John_Boyer Charlie Steven Nick Leigh Erik Uli Agenda: http://www.w3.org/MarkUp/Forms/wiki/FtF_2010_03_24_Agenda Got date from IRC log name: 24 Mar 2010 Guessing minutes URL: http://www.w3.org/2010/03/24-forms-minutes.html People with action items: john_boyer WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]