13:44:12 RRSAgent has joined #forms 13:44:12 logging to http://www.w3.org/2008/02/05-forms-irc 13:44:32 zakim, reserved now? 13:44:32 on Tue Feb 5 08:44:00 2008 I see 66 reserved [26 available], 83 ports 30 minutes later [9 available], and 93 ports 60 minutes later [overbooked] 13:45:44 wellsk has joined #forms 13:49:34 zakim, room for 3 for 190 mins? 13:49:36 ok, Steven; conference Team_(forms)13:49Z scheduled with code 26631 (CONF1) for 190 minutes until 1659Z 13:49:39 John_Boyer has joined #forms 13:49:55 zakim, code? 13:49:55 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Steven 13:52:01 zakim, call Forms-f2f 13:52:01 ok, wellsk; the call is being made 13:52:02 Team_(forms)13:49Z has now started 13:52:03 +Forms 13:53:01 Meeting: Forms WG FtF Raleigh, NC, USA, Day 2 13:53:25 Chair: John Boyer 13:53:54 rrsagent, make log public 13:57:38 markbirbeck has joined #forms 13:58:24 klotz has joined #forms 14:04:20 ok, will dial in now. 14:07:00 zakim, code? 14:07:00 the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), klotz 14:08:12 trying again 14:09:15 +Leigh_Klotz 14:11:46 CharlieW has joined #forms 14:11:57 Scribe: CharlieW 14:12:36 On the record: http://www.snee.com/bobdc.blog/2008/02/the_future_of_rdfa.html 14:13:30 John: should we continue to XForms 2.0 features or deep-dive into an example module? 14:13:56 Steven: i know how modules work, so i'd prefer 2.0 discussion 14:14:15 Steven: but it's important to see how to make progress on that 14:14:19 Uli: 2.0 14:14:29 John: could do an hour 14:14:46 Charlie: would like to have a template 14:15:17 Mark: we should start with a modularization template, but i haven't gotten in touch with shane yet 14:15:23 John: do we need an overview 14:15:34 Mark: could do that but i also have an example -- using a message on a div 14:16:11 John: let's start with that, then switch over to 2.0 later on 14:20:40 Topic: upcoming meetings 14:21:02 http://www.w3.org/MarkUp/Forms/wiki/FaceToFace 14:21:07 June 9th-12 in Amsterdam, no virtual days 14:21:26 Tech plenary will be in Cannes, not Paris, two virtual days beforehand 14:21:38 s/beforehand/aforewords 14:22:29 Topic: Action element content model 14:22:45 John: currently has "+" requiring at least one element 14:22:53 John: we agreed it should be "*" 14:22:58 John: should we change this for 1.1? 14:23:07 yes, we should do it 14:23:13 John: it's an easy spec change 14:23:27 Leigh: it's really editorial 14:23:38 Uli: does it make sense? 14:24:17 Leigh: could argue it's not editorial, since we're adding a test case 14:24:30 Leigh: but the test is against XML Events, not our spec so it's editorial 14:24:46 John: right, this change would add to the test suite, require support in the implementation reports 14:24:51 Leigh: nice test case for XML Events 14:24:58 John: have we publicized the test suite? 14:25:15 Keith: making changes to chapter 1 to emphasize new features...need to get people looking at it for accuracy 14:25:18 John: time frame? 14:25:27 s/accuracy/accuracy 14:26:16 Keith: about a week 14:26:36 John: do we need a formal issue process for the CR phase? 14:26:51 Steven: don't anticipate many issues 14:26:56 ttp://www.yugma.com/app/loading.php?user=&role=0&collsession=203673916 14:27:04 http://www.yugma.com/app/loading.php?user=&role=0&collsession=203673916 t 14:27:07 ttp://www.yugma.com/app/loading.php?user=&role=0&collsession=203673916 14:27:09 John: i have the action item to change the action element content model 14:29:25 Steven-eee has joined #forms 14:30:42 s/ i / I / 14:30:55 rrsagent, make minutes 14:30:55 I have made the request to generate http://www.w3.org/2008/02/05-forms-minutes.html Steven 14:32:22 Present: Nick, Keith, John Boyer, Mark Birbeck, Steven, Uli, Charlie, Leigh 14:33:58 i can't hear Mark 14:34:35 Mark: does example of modularization in web conf 14:35:19 Mark: most ajax libs have functions to display, e.g. modal dialog boxes -- as encoded in div's or span's as templates 14:35:35 Mark: instead of having multiple ways of doing this, why not use xf:message, xf:hint etc etc 14:36:33 Mark: the example in the demo uses a message, registered on a div rather than an xforms element 14:39:47 Mark: in what we're proposing for the hint module, you wouldn't even see the mouseover event registration 14:39:58 John: how would you do a help? 14:40:07 Mark: still to F1, or to platform-specific help feature 14:40:13 John: but our module would not say that 14:40:17 Mark: right 14:41:57 John: so label could be a module... 14:42:06 Mark: yes, it's handy to have in lots of places 14:45:36 Mark: focus is on the markup, underneath the script can be platform-specific 14:45:45 Mark: to enable the wiring, do show/hide etc 14:46:58 Mark: e.g. for styling, we can just inline some css, whereas in the script world you have to go find the message template and set various attributes procedurally 14:48:27 Mark: as well as control visibility explicitly 14:50:30 John: does this content cause problems for the XHTML schema? 14:50:37 Uli/Steven: yes, that's what modularization is about 14:51:02 Mark: we already have dtd's for xhtml+rdfa 14:51:12 Mark: already on the w3c server 14:52:02 +1 14:52:22 Steven: didn't require a new req track activity, just a combination of existing stuff -- power of modularization 14:54:28 John: when people say they need "valid" html what do they mean? 14:54:36 Mark: they need valid against *some* given schema 14:55:30 q+ 14:56:02 Leigh: i like the idea of making these modules (help, hint, label) available 14:56:16 Leigh: but we need to figure out how to make them available inside message to make them usable 14:56:29 Leigh: event model is not worked out 14:56:46 Mark: not sure we need that from day 1 though, we can allow anything inside those elements, no other forms controls 14:56:57 John: as soon as someone does a message+input 14:57:15 Leigh: i'm more worried that we'll decide to change message, for example, and we'll have modularized the old one... 14:58:34 John: certainly one of the problems for message if that you put lots of controls in there, e.g. trigger, ui events will bubble up and cause the message to reappear 14:58:57 q- 14:59:23 Mark: right, but the context is focused enough here that we could get those details right...i.e. no trigger in the initial modules 14:59:35 Mark: then we need to clearly define how these controls behave to avoid these problems 15:00:09 Mark: for example, by narrowly restricting the events you subscribe for (as target not bubble, for example) 15:01:06 Mark: need both target and bubble for different scenarios, but we haven't spec's which we need and when 15:01:18 s/spec's/spec'ed 15:01:40 John: we might need to say something doesn't bubble outside of message, needs more xml events machinery 15:02:11 Mark: we would need to be clear in our module, not just attach for a mouseover but only on the element that applies etc 15:02:18 Mark: easier to define since it's a small space 15:02:38 John: when we provide not just message but hint and help too, how would we tell people to make those work if they have controls in them 15:03:05 Mark: in the way i just said, they only fire when element they're attached to is targeted -- this is for implementors not authors 15:03:25 Mark: markup is normal xforms markup 15:06:04 Mark: given we wouldn't have xml events in this first module, we probably couldn't have an explicit event binding for message 15:06:21 Mark: or put onclick="DOMActivate" 15:06:49 c/DOMActivate/message.activate() 15:08:47 shepazu has joined #forms 15:09:53 Mark: candidate for module #2 might be xml events 15:10:10 Steven: but it's already modularized 15:10:34 Mark: so we could pull this together if we needed to 15:11:15 John: how do i filter on events targeted to my parent, just in xml events? 15:12:06 John: could we have a new event like ev:sourcetarget that would allow for this filtering? 15:12:42 John: to avoid the bubbling out of our children problem -- retriggering ourselves 15:12:47 http://www.w3.org/MarkUp/DTD/xml-events-qname-2.mod 15:13:28 John: almost like we want to say "message means stop propagation for all children"... 15:14:02 Leigh: then we won't get submit propagated outside of the dialog 15:14:11 John: but the default processing still happens 15:14:50 http://www.w3.org/MarkUp/DTD/xml-events-2.mod 15:16:21 John: we really need phase="target" in xml events 15:16:45 Mark: but we could do this in prose, telling implementors what the behavior should be -- offer the semantics not implementation 15:17:28 Mark: we could add xml events from day 1 but that might be too much...need more incremental approach 15:18:32 John: don't we need to specify the joint behavior of these specs? 15:19:28 Mark: these issues arise already today 15:20:35 Uli: is this endless loop really a problem? 15:21:38 Mark: in my example, the message element is a template, moved elsewhere in the tree, so any bubbling of events is not a problem in terms of triggering the message 15:23:23 Mark: we could define the behavior of the module to require this "disconnected" behavior -- in its own display space 15:23:33 John: yes, this would solve a lot of problems 15:24:16 John: vs. for repeat where we defined the variable elements to be part of the original tree 15:25:56 Mark: there are lots of details in terms of how the template (and styling) are used to create the instance to be displayed 15:34:19 Mark: so again we just need to specify in prose what we want the bubble/triggering behavior to be 15:36:36 John: problem is we said there's already an xml events profile around, so there's another way to activate the message and one which could well cause the bubble problem 15:36:53 John: I want that to mean ev:phase="target" 15:37:06 John: so don't we need the document that says how to combine these... 15:37:26 John: so it has to go into the message module, which doesn't depend on xml events 15:38:03 Mark: we can talk about dom events in the message module, not xml events 15:39:16 Mark: so we should define the xforms-hint event in this module, but not say how it's fired 15:40:21 break 15:52:39 unl has joined #forms 16:01:38 rrsagent, help 16:04:17 i/i can't hear Mark/Topic: XForms Modularization 16:05:19 rrsagent, make minutes 16:05:19 I have made the request to generate http://www.w3.org/2008/02/05-forms-minutes.html Steven 16:07:56 zakim, reserved now? 16:08:23 on Tue Feb 5 11:07:00 2008 I see 205 reserved [overbooked], 180 ports 30 minutes later [overbooked], and 123 ports 60 minutes later [overbooked] 16:10:16 Mark: our module documents might be more informal than a traditional spec 16:10:25 Mark: more like the pattern discussion yesterday 16:10:39 Mark: list elements, examples, give events that are part of the package and their behavior 16:10:49 Mark: effectively have defined the interface 16:11:08 Mark: but elements and event names are still independent of implementation, which i think is preferable 16:11:31 http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features 16:11:41 John: under our "modularization of existing patterns" category 16:11:52 Topic: Message, Event, Hint, Alert modules 16:12:10 Mark: we could just call this the "XForms Message Module" 16:12:24 Steven: yup 16:13:14 John: want to avoid misunderstanding that it can only be used in xforms 16:13:30 Mark: want to use this as on-ramp for xforms 16:13:37 John: so once you have it you might want more xforms 16:17:25 Leigh: must have a download so they can run with it 16:17:37 Mark: right, needs script impl, screen shots, etc etc 16:17:49 Mark: we're part of the ajax world but it's a different approach 16:18:38 Leigh: we're going at this backwards... 16:19:14 Leigh: they're not going to be interested in the spec, just the impl 16:19:39 Leigh: the spec is the "Cambridge" approach 16:19:46 Leigh: we just need working code 16:20:09 Mark: i agree, when it gets to ajaxian the headline is ... "new library available..." i.e. it's about the code 16:21:22 Mark: but the missing bit is the movement toward having standards in the ajax world...we have more than a library, confirms to a w3c standard 16:21:28 Mark: we need to close the loop 16:21:34 Leigh: yes, but it can be done incrementally 16:22:26 Mark: i can do that, but i think it needs the module 16:22:32 Leigh: but your readers don't 16:22:45 Leigh: by the time they want it it'll be ready...3 months from now 16:23:46 Mark: if i were to set up a separate site, define the behavior, it wouldn't have the status of xforms 16:23:55 Leigh: yes, it would as a partial implementation 16:24:09 Mark: so i'm hearing that maybe that work should be part of the group 16:24:54 Leigh: this will push it along faster 16:25:23 Leigh: you're not inventing new markup, it's refactoring and getting xforms out there 16:28:53 John: i'm willing to participate on the spec side -- it's like a mini-version of submission 16:29:19 John: there is spec work to do, it's not just pulling things out, but there are important details 16:30:21 Leigh: or Mark does his code first, says it's part of the xforms wg, we do a draft, etc iterating code first 16:44:03 John: what are next steps>? 16:44:12 Uli: I'd like to have/see Mark's code 16:44:19 John: what are the next steps on code? 16:44:39 Mark: need to combine some attributes into the hint element 16:44:46 Mark: would be great to use in Chiba 16:46:10 John: so will you add phase=target to xml events? 16:46:33 Charlie, I would love to *help* Mark with the coding 16:46:48 even better 16:51:21 http://www.w3.org/TR/xforms11/#ui-repeat-processing 16:52:44 Uli...thanks, by the way. :) The plan would be to open source this too, so there will be lots of opportunities to work on this. 16:53:15 nick has joined #forms 16:53:38 The repeat item generation and repeat index update on insertion must behave as if it occurs in response to the xforms-insert event dispatched by the insert action. The index update must behave as if it occurs when the xforms-insert event reaches the target instance element in the capture phase. 16:54:03 John: does this make sense? is there a notion of an event reaching the target element *in the capture phase* ??? 16:54:26 John: i.e. before any other handlers that might be defined for that event in the bubble phase 17:03:28 http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture 17:04:08 Mark: i believe there are implementations in html events that put default processing at this point -- before bubbling 17:04:38 John: trying to read xml event spec but getting "abuse of IP address" blocking 17:05:36 lunch time 17:08:11 -Leigh_Klotz 17:12:53 Steven-mobile has joined #forms 17:13:12 disconnecting the lone participant, Forms, in Team_(forms)13:49Z 17:13:15 Team_(forms)13:49Z has ended 17:13:16 Attendees were Forms, Leigh_Klotz 17:36:01 http://xformstest.org/klotz/shibumiscript/ 17:42:24 ebruchez has joined #forms 17:57:24 zakim, reserved now? 17:57:24 on Tue Feb 5 12:57:00 2008 I see 123 reserved [overbooked], 57 ports 30 minutes later [35 available], and 57 ports 60 minutes later [35 available] 17:58:11 zakim, room for 3 at 1300 for 300 mins? 17:58:12 ok, Steven; conference Team_(forms)18:00Z scheduled with code 26631 (CONF1) at 13:00 for 300 minutes until 2300Z 17:58:35 nick has joined #forms 17:59:40 CharlieW has joined #forms 18:01:27 Scribe: Nick 18:05:27 unl has joined #forms 18:05:29 Team_(forms)18:00Z has now started 18:05:36 +Leigh_Klotz 18:06:15 John: Explains the XML eventing model 18:08:12 +??P1 18:08:54 you aren't dialed in..erik andi are here 18:09:43 sorry 18:09:50 our mistake 18:10:00 zakim, call Forms-f2f 18:10:00 ok, wellsk; the call is being made 18:10:02 +Forms 18:10:36 Steven: ev:phase:="capture" and ev:target="target' isn't allowed 18:11:29 zakim, call Forms-f2f 18:11:29 ok, wellsk; the call is being made 18:11:31 +Forms.a 18:11:48 John: Points out that http://www.w3.org/TR/xml-events/images/event-flow.png is confusing 18:12:13 zakim, ??p1 is ebruchez 18:12:13 +ebruchez; got it 18:12:17 zakimthans 18:12:18 thanks 18:12:37 John: The diagram suggests that there is a capture phase at target 18:13:03 -Forms 18:13:32 MarkB: It is specified in DOM2 events that there is no capture phase in the target 18:15:08 John: The diagram suggests otherwise 18:15:49 Charlie: The paragraph under the diagram also hints that there is both a capture and bubble phase on target 18:22:31 John: So we need a spec change 18:25:22 John: Can we have an XForms implementation that does not have DOM 2 events? 18:25:30 MarkB: Don't think so 18:27:27 John: If you have an event that doesn't bubble, and it reaches target what is the phase then? 18:27:38 http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow 18:27:42 MarkB: It is buble 18:30:05 Key phrases in DOM 2 Events: 18:30:11 First, in 1.2.2: 18:30:13 "A capturing EventListener will not be triggered by events dispatched directly to the EventTarget upon which it is registered." 18:30:35 Second, in 1.2.3: 18:30:42 "Events which are designated as bubbling will initially proceed with the same event flow as non-bubbling events. The event is dispatched to its target EventTarget and any event listeners found there are triggered." 18:32:33 Action: John to fix XForms 1.1 wording for repeat processing to associate repeat index updating with capture phase on containing model, not target instance 18:32:33 Sorry, amibiguous username (more than one match) - John 18:32:33 Try using a different identifier, such as family name or username (eg. jkugelma, jboyer) 18:33:17 s/buble/bubble/ 18:35:17 http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features 18:36:01 zakim, who is making noise 18:36:01 I don't understand 'who is making noise', nick 18:36:03 i have been on mute a while 18:36:06 I am muted 18:36:07 zakim, mute ebruchez 18:36:07 ebruchez should now be muted 18:36:18 zakim, who is making noise? 18:36:19 is it a scratchy noise? 18:36:23 buzzing 18:36:24 at least my Skype is supposed to mute me 18:36:28 nick, listening for 10 seconds I could not identify any sounds 18:36:29 zakim, mute klotz 18:36:30 sorry, Steven, I do not know which phone connection belongs to klotz 18:36:37 zakim, who is here? 18:36:37 On the phone I see Leigh_Klotz, ebruchez (muted), Forms.a 18:36:38 On IRC I see unl, CharlieW, nick, ebruchez, Steven-mobile, shepazu, Steven-eee, klotz, markbirbeck, John_Boyer, wellsk, RRSAgent, Zakim, Steven, trackbot-ng 18:36:42 zakim, mute leigh 18:36:42 Leigh_Klotz should now be muted 18:37:12 ok 18:37:15 k 18:37:20 zakim, drop forms 18:37:20 Forms.a is being disconnected 18:37:21 mm mm mmmm mmm 18:37:21 -Forms.a 18:37:37 zakim, dial Forms-ftf 18:37:37 I am sorry, Steven; I do not know a number for Forms-ftf 18:37:54 zakim, dial Forms-f2f 18:37:54 ok, Steven; the call is being made 18:37:55 +Forms 18:38:15 zakim, unmute leigh 18:38:15 Leigh_Klotz should no longer be muted 18:38:21 zakim, unmute e 18:38:21 ebruchez should no longer be muted 18:38:59 TOPIC: XForms 2.0 18:39:14 Steven: More stuff working automatic 18:39:44 no audio from you now 18:41:33 Steven: A lot of our problems with insert and delete are because we can't define constraints on structure (calculations) 18:42:44 John: We have a bullet 'Better authoring of repeating constructs' 18:43:20 Steven: You are asking for a synchronization, is it really a cacluta 18:43:42 s/cacluta/calculate/ 18:44:24 Steven: Typically it is not the structure that you are putting in is not the structure that you want to send back 18:45:25 s/is not the structure that you want to send back/that is the structure that you want to send back 18:45:37 s/is not the structure that you want to send back/that is the structure that you want to send back/g 18:45:51 Steven: What sis the bullet point? 18:46:10 John: Structural constraints. 18:47:57 s/Steven: What sis the bullet point?/John: What sis the bullet point?/ 18:48:12 s/John: Structural constraints./Steven: Structural constraints./ 18:48:29 John: What does it fix? 18:48:54 Steven: I have to reconstruct the use cases I hit in the past 18:49:58 John: Web services is a good example 18:50:18 Steven: This is just a function 18:51:33 but I believe we want constraints as well 18:52:09 Action: Steven to write up use cases and basic design for Structural Constraints 18:52:09 Created ACTION-450 - Write up use cases and basic design for Structural Constraints [on Steven Pemberton - due 2008-02-12]. 18:52:47 John: Going back to the list (enumerates XForms 2.0 (high priority)) 18:53:55 Steven: Packagings could be one of the new features 18:54:22 s/Packagings/Packaging/ 18:55:30 John: Don't we have that partially in XForms 1.2 with 'Custom XPath functions' 18:56:46 John: What is extra in XForms 2.0? 18:57:18 ouch, gotta work on those XPath functions 18:58:26 I.e., http://internet-apps.blogspot.com/2005/04/css-xforms-dependency-engine-and.html 18:58:28 :) 18:58:49 Charlie: Unifying our UI based events and model based events 18:59:59 can't hear Charlie well, but I don't see improved UI events in the list of 1.2/2.0 features 19:00:20 i.e. replacing the IMO broken current UI events 19:01:36 John: That is Drive UI (presentation) properties from data and calculates 19:03:20 Charlie: But also constraints on UI properties, e.g.: If the size of an image is dependant on a slider, when the size passes a threshold a red border is shown 19:04:29 MarkB: Whole the document is the instance 19:04:54 John: If we have structural constraints and the whole document we don't need repeat 19:05:43 Steven: Steven explains that repeat is constructional constraints plus .... 19:06:33 Repeat is structural constraints from the instance to the UI 19:06:43 We also need such constraints between instances 19:06:51 and Charlie says between UIs 19:08:00 John: It is hard for digital signatures if the whole document is data, then you no longer have the markup as a separate thing to sign 19:10:01 19:10:01 19:10:01 19:10:01 __delta__ 19:10:01 19:10:02 19:10:04 19:10:06 __presentation__ 19:10:08 19:10:34 s/_delta_/_data_ 19:10:41 I assume ;-) 19:11:07 19:11:07 subtract delta 19:11:07 19:11:20 oops, wrong correction then 19:11:27 s/_data_/_delta_/ 19:11:34 sorry about that 19:14:09 nick has joined #forms 19:15:43 John: Explains why if the whole document is the instance, breaks a signature of an application (document without instance data) 19:22:18 John: My reference system can refer to attributes in the whole document, but if you keep following the attributes expressions you get to the data 19:23:18 MarkB: Instsance is then meaningless 19:23:48 John: Instance has a meaning, it is the only thing that can change 19:24:15 I understand how this helps XML signatures, but it also sounds restrictive 19:24:25 MarkB: That is leap for XForms, but it isn't a leap compared what they are doing in AJAX 19:24:43 i.e. "all state information must lead to XML data" 19:28:59 MarkB: Example before we had output mediatype="image/*" we had the value of the output to create the image element. But now you can't nor more dynamically change the size of the image 19:30:19 John: I like driving UI properties from data, but I want to identify the 'data' 19:32:03 John: Now we say that the referencing engine is limited to the instance 19:33:38 MarkB: 19:34:06

19:35:06 MarkB: In current browsers it is easy to handle 'unknown' elements, but not for values of attruributes 19:36:52 will enable our calculates on the style attribute on xf:output elements (style="with: { @width}" ) 19:39:02 19:39:02 19:39:08 19:43:10 19:43:11 19:43:11 19:44:53 19:45:04 that's what you should be able to write 19:46:17 klotz: This can solve styling rows with alternating color 19:47:28 19:47:28 19:48:28 John: One of the things that jumps out is integration and generalisation 19:50:22 (gotta go for ~1 h) 19:50:28 -ebruchez 19:52:10 http://xformstest.org/klotz/shibumiscript/ 20:00:03 zakim, mute klotz 20:00:03 sorry, wellsk, I do not know which phone connection belongs to klotz 20:00:28 zakim, who is noisy? 20:00:40 John_Boyer, listening for 11 seconds I heard sound from the following: Leigh_Klotz (94%) 20:00:51 mute, klotz 20:00:54 zakim, mute Leigh_Klotz 20:00:54 Leigh_Klotz should now be muted 20:02:13 http://www.svgopen.org/2004/papers/ConstraintSVG/ 20:02:26 e.g.: c:constraint attributeName="x" value="id('c')/@cx"/> 20:03:51 sorry dunno what the noise was. 20:04:08 Action: Steven to write strawman proposal for Repeat Pattern 20:04:08 Created ACTION-451 - Write strawman proposal for Repeat Pattern [on Steven Pemberton - due 2008-02-12]. 20:08:23 I hate to say this (sort of) but we were doing presentation constraints in the late 80's. Here is a paper by a student of mine from 1992: http://www.cwi.nl/ftp/CWIreports/AA/CS-R9262.pdf 20:08:53 "Maintaining presentation invariants in the Views system" 20:08:57