08:04:32 RRSAgent has joined #tagmem 08:04:32 logging to http://www.w3.org/2011/09/13-tagmem-irc 08:04:43 zakim, room for 3 for 3 hours? 08:04:44 I don't understand your question, ht. 08:05:03 masinter has joined #tagmem 08:05:11 jar has joined #tagmem 08:05:20 noahm has joined #tagmem 08:05:26 scribe: Jonathan Rees 08:05:29 scribenick: jar 08:05:54 ok, Yves; conference Team_(tagmem)08:05Z scheduled with code 26631 (CONF1) for 60 minutes until 0905Z 08:06:21 agenda: http://www.w3.org/2001/tag/2011/09/13-agenda 08:06:24 jar has changed the topic to: http://www.w3.org/2001/tag/2011/09/13-agenda (jar) 08:06:48 topic: Convene, review agenda 08:09:09 Team_(tagmem)08:05Z has now started 08:09:16 +??P2 08:09:27 Zakim, ? is IF 08:09:27 +IF; got it 08:09:43 DKA, you can dial in at your convenience 08:10:14 zakim, IF has Yves, Ashok, ht, jar, masinter, noah, plinss, timbl 08:10:14 +Yves, Ashok, ht, jar, masinter, noah, plinss, timbl; got it 08:10:26 +DKA 08:10:39 yes 08:11:58 Noah will review priorities agreed last time 08:13:04 noah: After lunch: would like to get agreement to publish Ashok's draft 08:13:50 JeniT has joined #tagmem 08:14:41 RESOLVED: minutes of sept 1 http://www.w3.org/2001/tag/2011/09/01-minutes are approved 08:15:34 (talking about list of 5 products here http://www.w3.org/2001/tag/2011/09/13-agenda#Convene ) 08:16:28 ah 08:19:37 masinter: We had a request to talk about character normalization 08:19:41 noah: It's on the agenda. 08:20:08 Noah: I'd like a chance to update the TAG on the upcoming workshop on off-line web applications which I will be co-chairing after TPAC: http://www.w3.org/2011/web-apps-ws/ - should only need 15 minutes but also related to ACTION-544. 08:20:26 masinter: What about xml/html TF? 08:20:38 noah: We agreed on last call to put that off until after the F2F 08:21:51 masinter: Fragids and mime types are convolved…? 08:22:34 Jeni, we're on Zakim 08:22:54 Never heard from you earlier -- can you VOIP to Zakim? 08:25:43 COde is 26631 08:27:10 -DKA 08:27:34 +DKA 08:28:11 Did you see my note on the workshop above? 08:30:01 +??P1 08:32:27 topic: Fragment ID Semantics and MIME Types 08:32:53 noah: Jeni prepared a draft http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 08:33:57 jeni: Expecting help from Peter and Henry 08:36:07 timbl: In general my feeling is disappointment at the conclusion that the inconsistencies are largely theoretical 08:36:13 Tim is commenting on the statement in section 2.2: 08:36:16 "However, the impact of these inconsistencies is largely theoretical from the standpoint of a single application." 08:36:45 … These inconsistencies may seem ok at the beginning but later they become a big headache 08:36:57 q? 08:37:11 … The article is a great analysis, but then shrugs its shoulders 08:37:37 I agree With regard to this document, I think the problem analysis is useful and helpful, but I don't think the recommendations do enough 08:37:40 … Our mandate is to design a strong platform 08:37:55 q+ 08:37:59 I use X-Lite on my Windows PC, and had some success with twinkle on Linux 08:38:03 … At the moment there's no guarantee of what a fragid will do 08:38:05 [For Jeni, sorry] 08:38:50 timbl: Shoulder shrugging seems to break the architecture 08:39:12 q+ to suggest we go through the "Best practices" proposed in the draft 08:39:24 q+ to register uncertainty and plug his talk this afternoon :-) 08:39:26 jenit: I tried to make the conclusions contentious to stimulate figuring out what to do 08:39:27 There are a couple of different things that have to happen: fix up fragment identifier references in MIME type definitions requires some of the "MIME and the web" actions. Fixing SVG fragment identifiers and XML fragment identifiers require updates to those specs. Just putting those things in a finding doesn't seem like it will affect the right specs. 08:39:33 ack next 08:40:41 masinter: Agree, like problem definition, but need stronger recs, different ones in different arenas 08:41:17 timbl: Don't misunderstand "finding" - it's a communication from tag to w3c 08:41:31 masinter: Then how do findings become actions? 08:42:07 ack ht 08:42:07 ht, you wanted to register uncertainty and plug his talk this afternoon :-) 08:42:16 s/it's a communication from tag to w3c/Findings are to the TAG as Recommendations are to the W3c. They can say that things should not be done and should be done./ 08:43:02 ht: I would like to agree with Tim, but the horse is out of the barn. We need to think about why it's so hard to make this work. We've been struggling with this since xml schema at least. 08:43:11 ((I'm not entirely sure what Henry is torn about, and what horse is out of what barn)) 08:43:50 DKA has joined #tagmem 08:44:05 … We've made progress around question of bare names in xml media types… haven't sorted out details, but it seems like it might work to say the same URI means different things at different levels of the stack 08:45:28 I [liked] Best Practice 3: Fragment Identifiers in Media Type Definition: Media type definitions should avoid 'must' language when describing supported fragment identifiers as in practice it is likely to be ignored. Instead, they should provide pointers to any known fragment structures that might be applied to that media type and give warnings of any contradictions between them. 08:45:43 A character sequence has a meaning in a context 08:46:00 … The talk this afternoon will talk about this. Nobody in philosophy of language would agree with the proposition that a character sequence has a meaning. We're making our stand at the wrong level - need to talk about the link level - how it's used 08:46:29 q+ 08:46:35 that's why i kept on putting 'meaning' in quotes in the discussions with JAR on the mailing list 08:46:48 ht: We may need to back off from context-free meaning 08:47:19 … I've been trying to be convinced, but. 08:47:34 the primary context for URIs is A@HREF, and in lieu of other disambiguation, meaning of URIs is its meaning within that context 08:47:46 ht: We don't need to go into that in too much detail. 08:47:55 s/ht:/timbl:/ 08:48:21 i think this reads on the internationalization/equality/disambiguation issues 08:48:25 timbl: But we can say don't use a URI to mean one thing in one place, another thing in another. 08:48:38 ht: We can't live with unique and indeterminate meaning of URI goal 08:49:27 http://www.w3.org/2001/tag/products/fragids.html 08:49:27 noah: (It my intent that we would review the product page at start of each discussion…) 08:49:49 s/indeterminate/determinate/ 08:52:09 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12 08:52:40 I don't understand Best Practice 1 08:52:52 To whom is this directed? 08:52:52 timbl: Should indicate how it's canonical. How? 08:53:18 Discussing Best Practice 1: Canonical Fragment Identifiers 08:53:21 Whose practice should change? 08:53:26 noah: Request that the doc have its own fragids 08:53:28 "Fragment structures which provide multiple ways of addressing the same secondary resource should indicate which fragment identifier is canonical and should be used for making statements about that secondary resource." 08:54:32 Now I know what it means, I think I disagree, as differemt forms of xpointer will have different pesistent quaalities, which will depend from application to pplication. 08:54:34 Do we mean just "making statements about" or do we mean 08:54:41 "as the preferred form of reference" 08:54:43 If there are several ways to point to a single fragment within a document... 08:54:52 ... that are equivalent in terms of what they point to 08:54:54 is this directed at web developers? People who define fragment identifier semantics for a particular MIME type? 08:54:59 q+ to ask, do we really mean just "to make statements about"? 08:55:06 ... then it is helpful to say, when you are designing the fragment identifier scheme 08:55:13 Sometimes, numeric tree address will be more stable than one based on local context 08:55:38 What is a "fragment identifier scheme" ? 08:55:50 ... which one of the many fragids that point to the fragment should be generated 08:56:20 masinter, it's directed at people who define fragment identifier schemes, such as XPointer 08:56:36 jar has joined #tagmem 08:56:43 mastinter, or the media fragments 08:56:58 Should people be defining fragment identifier schemes that aren't associated with specific media types? 08:57:09 q? 08:57:20 ack ashok 08:58:23 ashok: What is this recommendation really telling us? In a MIME type there might be more than one way to specify a 2ary resource. 08:59:00 … If you just use 'should' then this BP won't do much… 'must' is better 08:59:04 well, with xpointer you always have multiple way to point to one element in a specific document 08:59:33 q+ to wonder if the problem is the W3C groups that define generic systems for fragment identifiers without regard for other generic systems... so video/videoformat+xml might be influenced by media fragments, image semantics, and xml but those are in conflict 08:59:36 jenit: In many cases it's hard for there to be only one way. Different fragids for same thing are robust in different ways to changes in the document 08:59:53 … so 'must' is too strong 08:59:56 and then the javascripting interface gives another generic method 09:00:17 this really brings the issue clearer for me 09:00:46 jenit: Different advice to different levels (e.g. xpointer vs. media fragments) 09:01:53 timbl: The editor has to make its own choice. Sometimes when you're scraping the page […] I don't see the value of promoting a canonical one 09:02:03 q? 09:02:08 ack noah 09:02:08 noah, you wanted to suggest we go through the "Best practices" proposed in the draft and to ask, do we really mean just "to make statements about"? 09:02:19 noah: But this is advice re writing mime type registrations, not to document producers 09:02:44 Are they equivalent? 09:03:02 noah: Tim's saying there are reasons to not use the canonical fragid 09:03:27 noah: E.g. for upper/lower case it would be easy to say lower case is preferred 09:03:27 Are multiple fragment identifiers that address the same resource (eg XML element) equivalent at the semantic level? 09:03:38 or when you have fragments that are not normalized unicode and different systems handle equivalence differently 09:03:51 ack masinter 09:03:51 masinter, you wanted to wonder if the problem is the W3C groups that define generic systems for fragment identifiers without regard for other generic systems... so 09:03:54 q? 09:03:55 ... video/videoformat+xml might be influenced by media fragments, image semantics, and xml but those are in conflict 09:04:45 masinter: We have at least 3 different generic systems for defining what fragids mean. XML, scripting interface, media fragments. 09:04:50 (noah, we are not talkng about caonical in teh sense of upper and lower case, but selecting completely diff methods of identifying an element (etc).) 09:05:02 q+ 09:05:13 … mime type is being constrained 3 ways by 3 generic processing systems 09:05:14 Tim: I just used that as a trivial example, but I tried to make clear that I meant the general case. 09:05:19 yves: media fragments are in svg 09:05:35 masinter: There's no advice we can give, since they're already overconstrained 09:05:50 I read Jeni as saying: "designate one form as canonical, for use where practical" I'm about half convinced it's worth saying. 09:05:52 q? 09:05:56 ack next 09:06:00 q+ 09:06:29 timbl: Jeni is dealing [in BP 1] with two fragids for the same thing. I'm more concerned about one fragid for two things 09:06:49 i forgot RDF/RDFa adding another generic one, so there are 4 generic fragment definition systems 09:07:09 Personally I'd recommend using something other than fragment identifiers in URIs 09:07:21 use markup instead 09:07:30 timbl: RDF. same id for two things bad idea 09:07:43 q? 09:07:45 ack next 09:07:47 q+ to suggest that it might be a 'best practice' to not use fragment identifiers when you can use markup 09:08:23 ack next 09:08:24 masinter, you wanted to suggest that it might be a 'best practice' to not use fragment identifiers when you can use markup 09:08:32 ashok: The argument was: different contexts require different styles. Why not say this in the MIME type registration?... 09:09:07 masinter: Fragids are a needle-eye for expressing things that might better be expressed using markup 09:09:46 timbl: But you can't bookmark markup 09:10:00 ack next 09:10:14 yves: Media annotation relies on use of URIs 09:10:41 i think we should invent canonical markup for each of these different application, and urge people to use markup rather than info packed into the string 09:10:55 … Problem comes when you use fragment vs. svg view box… 09:11:41 and W3C shouldn't invent any more systems for using fragment identifiers without having a markup equivalent 09:12:08 using new data is a way in which that's been done 09:12:23 and you can bookmark markup with data: 09:12:39 yves: [different modes of expression are robust to different kinds of change] 09:13:40 to me "canonical fragment identifier" can't be defined by the media type, but by the people creating fraguris, what could be done in the media type definition is to alert about properties of "equivalent" ways of identifying secondary resources 09:14:26 like robustness issues (relative to document change, like pixel-based spatial media fragment on a SVG picture that may change size, etc... 09:14:45 noah: What's best level to engage here? 09:15:29 data:application/videofragment+xml, 09:15:48 Yves, the question for me is whether, at the semantic level, those different types of addressing "the same thing" are equivalent or not 09:16:05 Yves, and perhaps they aren't 09:16:05 Jeni, exactly 09:16:16 q+ to add the issue of normalization and character equality somewhere 09:16:23 Best Practice 2: Generic Fragment Structures 09:16:33 they can be equivalent in many cases, but not always 09:16:34 "Fragment structures should be defined at levels that anticipate content negotiation. For example, the semantics of the svgView() fragment identifiers could be meaningfully applied to all image formats. Were a similar scheme developed in future, it should be defined for all images rather than a particular image format." 09:16:37 ack next 09:16:38 masinter, you wanted to add the issue of normalization and character equality somewhere 09:16:57 Yves, if they're *actually* equivalent, then you need to have a normalising method or comparison method to compare them eg when they're used in statements 09:17:03 masinter: The fragids could have the same problems with char identification as came up with CSS 09:17:05 (unlike the uppercase/lowercase for bare names example that Noah pointed) 09:17:19 Jeni, yes 09:17:26 Yves, :) 09:18:08 -Jeni 09:18:16 look at http://tools.ietf.org/html/rfc5147 09:18:32 URI Fragment Identifiers for the text/plain Media Type 09:19:43 should those fragment identifiers apply to documents that aren't text/plain 09:20:46 -DKA 09:20:56 We dropped Jeni .. too 09:22:25 Zakim? 09:22:36 Zakim, who is on the call? 09:22:36 On the phone I see IF 09:22:37 IF has Yves, Ashok, ht, jar, masinter, noah, plinss, timbl 09:22:54 Zakim, call JenniT-home 09:22:54 I am sorry, timbl; I do not know a number for JenniT-home 09:23:01 ht_home has joined #tagmem 09:23:10 zakim, code? 09:23:10 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), ht_home 09:23:18 zakim, who is on the call? 09:23:18 On the phone I see IF 09:23:19 IF has Yves, Ashok, ht, jar, masinter, noah, plinss, timbl 09:24:00 Team_(tagmem)08:05Z has ended 09:24:01 Attendees were Yves, Ashok, ht, jar, masinter, noah, plinss, timbl, DKA, Jeni 09:24:07 Ashok, putting markup in the query parameters doesn't help at all. The problem is that an unversioned, untyped, unsniffable data structure in the fragment 09:24:17 Dan you there? 09:24:23 JeniT, what is your skype? Can we try skypeing you? 09:24:25 We are going to drop zakim for awhile. 09:25:21 maybe if the generic fragment identifier systems were sniffable 09:25:24 Zakim, IF also holds JeniT 09:25:24 sorry, timbl, I do not recognize a party named 'IF' 09:25:59 q? 09:26:12 masinter: Ashok was saying you could encode markup attributes as cgi query parameters... 09:26:16 q+ to question whether mechanisms other than URIs are in order for this discussion. 09:26:32 … When you look at a fragid, you have to apply many heuristics to determine which meaning was meant 09:26:50 … The generic systems aren't designed with nonoeverlapping syntaxes 09:26:58 s/nono/non/ 09:27:05 s/nonever/nonover/ 09:27:32 noah: I'd like to rule out non-URI syntaxes out of order 09:28:33 masinter: It's legitimate to point out that there are some applications that don't need to use fragids 09:29:11 … And even when they're used, it would be good to have a non-uri syntax defined for expressing same thing 09:29:14 s/I'd like/I'm tempted/ 09:29:35 … Fragids aren't sniffable. No magic number. 09:30:16 timbl: We've got this web built on usefulness of uris… so I'm also tempted to rule it out of order 09:30:37 The reason for, potentially, ruling out of order, is that this whole effort is framed as trying to make the URI-based approaches work better. 09:31:03 timbl: (drawing on board choice between barename and xpointer) 09:31:23 masinter: But that's not what people have implemented. The script gets first whack at it 09:32:04 noah: So people have ignored the specs. The media type reg should say how fragids identify 09:32:21 … So what scripts do is an implementation detail 09:32:31 q+ to offer "_when_ they are used to identify parts of document...." 09:32:48 ashok: Also passing args to functions 09:32:50 Every specification should have an applicability statement which defines the scope of when the specification should be used, and even identify other ways of accomplishing applications which are inappropriate 09:33:57 it's perfectly appropriate for us to limit the domain of applicability for fragment identifiers to those use cases which really NEED to use fragement identifiers, and to urge those who don't need to pack everything into an ascii string to do so 09:34:08 timbl: We have a rule of opaqueness for URIs. When there's downloaded code, the client shouldn't interpret without out of band agreement 09:35:14 noah: The javascript is like an html form… code coming from server that knows how to build uris 09:37:24 DKA has joined #tagmem 09:37:42 "Best Practice: Generic systems for fragment identifiers should use and reserve unique initial strings which disambiguate which generic system is being used" 09:37:45 q? 09:37:48 ack noah 09:37:48 noah, you wanted to question whether mechanisms other than URIs are in order for this discussion. 09:37:50 ack next 09:37:53 ht_home, you wanted to offer "_when_ they are used to identify parts of document...." 09:38:12 Tim doesn't want to go into this, but I think this is quite parallel to the Javascript case: http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#forms 09:39:40 ht: Maybe change the language a little bit. The semantics of a fragid *that point into a document of a certain media type* are… and other fragid uses are constrained in some other way? 09:40:03 RDF, media fragments, xpointer, scripting, XML IDs.... are there others? 09:40:33 Maybe this is the reason for the ! in #! 09:40:40 noah: Say, when javascript uses fragids in a certain way, it must conform to … [scribe mangled] 09:40:50 #! was indeed to avoid conflict 09:41:14 so we should make #! a 'best practice'? 09:42:21 Done, I think 09:42:34 timbl: History state is a sequence of values of address bar 09:43:08 noah: No. I go forward and back and the address bar isn't changing 09:43:20 timbl: Those things have alternate uris that aren't being shown 09:43:28 "!" is the unique signature that should be used for all scripting? 09:43:54 timbl: Is there any reason you want to constrain them in the address bar case? 09:44:30 noah: I might copy them to email. But if I can't get to them, I don't care if there's a fragid that breaks media type rules. 09:44:47 code should only ambush fragments that start with "!" ? 09:44:56 timbl: You're being ambushed by code architecture, there's a different architecture for that 09:45:12 ht: That's what I was trying to say 09:45:34 timbl: Two archs. One is declarative, the other is ambushed-by-code. They have little to do with one another 09:46:01 ht: So if the URI does escape into the world, we won't know which arch applies, so won't know what it means... 09:46:35 noah: To me the javascript most of the time should be an implementation detail 09:49:01 timbl: Think of the fragid as being defined by two things. The media type, and a javascript bit 09:50:15 timbl: There's all this punning going on. There's the Thing that the URI identifies, and then there's the RDF node, the XML DOM, the XML text 09:50:36 noah: So what does the media type reg say? 09:51:08 ht: The URI spec should mention that this other architecture exists 09:52:13 ht: I imagine: That I use the fragid in a URI that I send an HTTP request for (i.e. outside scripting context) 09:52:33 (question of putting the hair in MIME type, vs. in URI RFC) 09:53:49 timbl: For me a spec isn't complete until it meets IETF media type reg requirements 09:54:01 s/spec/format spec/ 09:54:14 I think we could reasonably have a 'guidelines for defining fragment identifier semantics for media types' and hten ask that the media type registration document point to the guidelines, since this is long 09:54:21 I think the scripting thing is a distraction 09:54:39 really? 09:54:44 and that some media types are 'scriptable' and dispatch the fragemnts to the script 09:55:00 I think if we ignore scripting, we still have problems, which are more fundamental 09:55:05 and more important to fix 09:55:16 Jeni -- i think scripting issue is separable... important, a 'distraction' from the main point 09:55:20 I think we can't ignore scripting, but yes, for the non-script case we should spec that 09:55:23 but still needs to be fixed 09:55:24 noah: Media type reg should tell me what the fragid means. Full stop. Fix the html media type reg, that's an anomaly. 09:55:34 q+ to propose way forward 09:55:58 JeniT, in the room I have the scripting case on a separate whiteboard 09:56:02 I agree, the use of js (or scripting in general) already break what is in the definition of static media types, processing the fragment is not a bigger surprise than that 09:56:42 masinter: How about a separate document, guidelines for writing fragment id specs for mime type registrations, and then the appropriate RFCs can reference that 09:58:45 ACTION-543? 09:58:45 ACTION-543 -- Jeni Tennison to propose addition to MIME/Web draft to discuss sem-web use of fragids not grounded in media type -- due 2011-06-28 -- OPEN 09:58:45 http://www.w3.org/2001/tag/group/track/actions/543 09:58:51 ACTION-567? 09:58:51 ACTION-567 -- Jeni Tennison to draft a document describing problems around fragids and ways things should be changed -- due 2011-06-28 -- OPEN 09:58:51 http://www.w3.org/2001/tag/group/track/actions/567 09:59:01 ACTION-509? 09:59:01 ACTION-509 -- Jonathan Rees to communicate with RDFa WG regarding documenting the fragid / media type issue -- due 2011-09-15 -- OPEN 09:59:01 http://www.w3.org/2001/tag/group/track/actions/509 09:59:16 JAR: I sent an email on 509, but am not getting the feedback I need 09:59:48 s/am not getting/have not yet received/ 10:00:16 Generic fragment identifier methods should propose a unique string to disambiguate them from other generic fragment identifier methods 10:00:18 close ACTION-567 10:00:18 ACTION-567 Draft a document describing problems around fragids and ways things should be changed closed 10:00:21 action-543? 10:00:21 ACTION-543 -- Jeni Tennison to propose addition to MIME/Web draft to discuss sem-web use of fragids not grounded in media type -- due 2011-06-28 -- OPEN 10:00:21 http://www.w3.org/2001/tag/group/track/actions/543 10:01:25 reassigning ACTION-543 to Peter 10:02:30 ACTION plinss with Henry produce partial revision of fragment id finding Due 2011-10-18 10:02:31 Created ACTION-594 - With Henry produce partial revision of fragment id finding Due 2011-10-18 [on Peter Linss - due 2011-09-20]. 10:15:06 jar has joined #tagmem 10:17:29 (break) 10:17:32 topic: IETF Draft on MIME and the Web 10:17:40 masinter has joined #tagmem 10:17:47 agenda? 10:20:08 masinter: Not proposing a change of direction. Rather followon in multiple avenues. 10:20:43 Low-quality photos of whiteboard from 1st morning session at http://www.w3.org/2001/tag/2011/09/timbl_whiteboard_declarative.jpg http://www.w3.org/2001/tag/2011/09/timbl_whiteboard_ambushed_by_code.jpg 10:21:20 q? 10:21:23 masinter: (a) is the 'happiana' discussion. How the community including w3c about how things get registered. There's a history of w3c regs not happening. Disagreement in html wg on whether to use an iana registry. Etc. 10:21:24 q- 10:21:29 zakim, close the queue 10:21:29 ok, noah, the speaker queue is closed 10:22:09 … Mark N and others are discussing. Things that look hard have been confusing to non-insiders. Some think overhead of expert review is too high. 10:22:45 … anyone have questions about process of getting things registered? 10:22:54 https://www.ietf.org/mailman/listinfo/happiana 10:23:16 ht: Last time I reviewed this, didn't sound like IETF though there was a process problem. Just that there were failures to execute. 10:24:08 masinter: I understood this differently. There's a core that gets things in, and then peripheral processes that feed into the core. The core has not been the problem. 10:24:41 … Distinction between provisional and permanent has to do with registries being gatekeepers when they shouldn't have been. 10:24:52 ht: So there is some receptivity to the process being reviewed? 10:25:21 masinter: Everyone agrees there's some problem somewhere. Disagreement over where. IANA is doing its job, problem is elsewhere 10:26:14 … What seems to be missing is widespread use of unregistered values, when a registry exists? 10:26:29 … There should be an impetus from somewhere to get these registered. Whose job is it? 10:26:59 yves: There is a provision in new reg scheme for non-"owner" to submit registrations 10:27:14 … a bit controversial 10:27:50 masinter: application/msword was registered so that Linder could use it in gopher 10:28:41 … Possibility of 3rd parties to register & add information (e.g. suggest expanding fragid specification) maybe should be part of process 10:29:29 … Should W3C take on the job of registering all the media types and URI schemes that are in use? 10:29:29 s/Linder/Lindner/ 10:29:42 s/Lindner/Paul Lindner/ 10:30:14 ht: Just a way to jumpstart the process 10:30:48 yves: Not useful unless we're talking about something very widely used 10:32:30 ashok: I spent some time on standards for cloud computing… each format has a different media type. Good idea? Problem? The stuff will be used. 10:33:08 s/format/entity in the model/ 10:33:44 masinter: There's work going on to improve process, there's a wiki about process, but still a gap between what's being considered and what I'd like to see 10:34:14 … that was (a) 10:34:43 (b) update media type reg BP http://tools.ietf.org/html/draft-freed-media-type-regs 10:35:30 If we had a fragid specification document, this could reference it 10:35:39 s/If we/... If we/ 10:35:46 s/(b)/masinter: (b)/ 10:36:43 masinter: there's another document, one that deprecates the use of x- in experimental protocols 10:37:13 http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful-01 10:38:48 masinter: If we want to have something to say about regs, it would be best to update the RFC 10:40:01 https://tools.ietf.org/html/draft-abarth-mime-sniff-06 10:40:41 masinter: (c) Sniffing. http://tools.ietf.org/html/draft-ietf-websec-mime-sniff proposes to say how one should sniff. HTML make normative reference to this. Also ... 10:42:05 … Mime and the web responds to this. I have volunteered to produce an alternate document. Meeting with Tobias next week to go over this. 10:43:11 … it's a security issue. 10:43:55 Scribe -- please move links to these into the transcript of this morning's fragid session: http://www.w3.org/2001/tag/2011/09/Whiteboard1.jpg and http://www.w3.org/2001/tag/2011/09/Whiteboard2.jpg 10:44:13 masinter: Trying to understand scope. Abstract only talks about misconfigured HTTP servers. But then there's a reference to web app packaging... 10:45:38 … We have a TAG finding on authoritative metadata. This document specifically prescribes overriding authoritative metadata. 10:45:42 … This doc is all or nothing. But actually browsers sniff differently in different contexts. 10:45:55 DKA has joined #tagmem 10:47:53 masinter: Probably better to fix the sniffing doc than generate another critique 10:48:44 masinter: I'd rather not have inconsistency between finding and recs 10:49:10 … maybe update the finding 10:49:53 masinter: (e) We'll probably need to update the W3C guidelines. 10:50:36 … So product page maybe should prescribe not a single big document, but rather a set of documents and document updates 10:54:01 masinter: (Call to see interest in these activities among TAG members) 10:57:47 noah: Where's the biggest bang for the buck? 10:58:58 timbl: Low road is html5 attitude: This is how it actually works. If everyone did [continued to do] things like this we'd have predictability. 10:59:24 timbl: High road: This is the protocol, here are its benefits. If you don't want to use it, you don't get the benefits. 11:00:17 timbl: I feel the TAG should probably spend more time on the high road. Less crowded 11:00:56 timbl: Different functions 11:01:28 plinss: We need a path from low road to high road 11:02:19 masinter: Current sniffing document says what to do in all cases 11:02:45 … I propose organizing by situation, and making sniffing optional in each situation 11:03:40 … There was an opt-in proposal from MS - "I really mean this" 11:04:27 masinter: Sniffing is what I most would like help with 11:06:05 masinter: No distinction made between no mime type and mime type in bad syntax 11:07:44 noah: Are we too late on this? 11:10:17 masinter: This is in the purview of the IETF web security WG [?] 11:10:44 http://www.w3.org/TR/widgets/ makes normative reference to this 11:11:13 9.1.11 Rule for Identifying the Media Type of a File 11:11:54 jar: Are we talking 5 products? How does Noah want to organize? 11:12:15 q+ to note on the widgets spec reference: this could be something to bring to the offline apps workshop as an input. 11:12:27 noah: Want to provide community with a way to assess our success 11:12:42 … So set this up as a set of subgoals 11:13:02 s/this/this product/ 11:14:04 step 10 of widgets: "Let content-type be the result of processing file through the [SNIFF] specification." [SNIFF] Media Type Sniffing. A. Barth and I. Hickson. IETF (Work in Progress). 11:14:38 larry: I don't think I got any feedback on any of the documents 11:15:30 … W3C keeps emphasizing important of registries, and this work is central 11:16:25 zakim, open the queue 11:16:25 ok, noah, the speaker queue is open 11:16:47 s/larry:/masinter: 11:16:53 s/larry:/kasinter:/ 11:17:17 *** note to minutes editor: clean up *** 11:17:22 s/W3C keeps emphasizing important of registries, and/W3C has taken a stand that registries should be avoided, yet we keep on coming up with things that need registered./ 11:17:40 s/need registered/need to be registered/ 11:18:33 dka: Maybe circulate draft docs at offline apps workshop, re widgets (day after TPAC) 11:18:56 masinter: I think the reference can be avoided 11:22:49 i think this is a 'filling the potholes' rather than a 'building new bridges' issue 11:23:51 jar: Would anyone be unhappy if Adam's draft progressed? 11:23:54 masinter: Yes 11:24:01 We are adjourned until 13:30 Edinburgh time. 12:10:51 DKA has joined #tagmem 12:12:07 ht has joined #tagmem 12:13:35 masinter has joined #tagmem 12:14:42 jar has joined #tagmem 12:19:15 plinss_ has joined #tagmem 12:22:40 Ashok has joined #tagmem 12:26:16 masinter has left #tagmem 12:26:36 masinter has joined #tagmem 12:26:39 who 12:27:14 noah has joined #tagmem 12:27:23 From the train: http://www.flickr.com/photos/70365734@N00/6141289487/in/photostream 12:33:30 Topic: Web Applications: Client-side state 12:34:04 http://www.w3.org/2001/tag/2011/09/13-agenda#clientState in the agenda is nonreferring 12:35:23 Topic: IETF Draft on MIME and the Web (cont) 12:35:53 LM: W3C may put energy in registering all media types and the TAG may recommend that W3C do so. 12:36:39 also pushing things so that servers won't be released with improper media-type/filext association, the situation that led to mime sniffing 12:36:56 a Community Group of server vendors might work for that 12:37:00 Scribe: Yves 12:37:58 No one wants to take responsibility for changing a client from accepting of invalid to nonaccepting of invalid 12:38:18 Noah: issue is that we need to have an intuition that people who cares about the issue will participate in such work or not 12:38:38 LM: nothing there is uncontroversial 12:39:00 DKA has joined #tagmem 12:39:00 LM: no communities is against changing the default configurations of servers 12:40:44 YL: If you have a server, and the default changes, it does create headaches for people. Even if it's uncontroversial, it will be hard to find people to do the work. 12:41:38 Noah: the issue is to show value in doing work in this. 12:42:06 Tim: validators is a good way to help people doing the right thing 12:42:31 Noah: do you have leverage with big ISP so that they can make it easy for their users to use the right media types 12:43:36 jar: how about doing a hall of shame? 12:44:57 http://www.fred.net/tds/leftdna/ 12:45:55 redbot.otg 12:45:59 s/otg/org 12:45:59 YL: There is an http validator from Mark Nottingham 12:46:16 YL: Open source...you can create extensions 12:46:34 YL: One could imagine one to check content type matches. 12:48:13 YL: the difficult part is finding out real errors from willfull configuration that may look like "errors" per sniffing (so figuring out errors or warnings) 12:51:22 LM: best is to be realistic about what the TAG can do. 12:51:54 "declare success and move on" -- write a document/note saying what we did, what needs to be done, and just move on 12:52:19 lots of things W3C could do, but the TAG isn't going to do any of them 12:53:34 There is a Web Testing Activity proposal: > Web Testing Interest Group Charter > http://www.w3.org/2011/05/testing-ig-charter 12:53:44 DKA: people are reluctant to engage in things that might trigger pushback 12:53:53 LM: there is no risk of pushback here 12:56:44 Noah: two issues, the state of the sniffing document, and the other is the way toward a cleaner state where sniffing is not required 12:58:38 LM: (See the 'let's move on' quote above) 12:59:29 After wrapup, we will remove Mime on Web from list of top priority products, following agreement to Larry's final report 12:59:38 ACTION: masinter to create a final report on Mime and the Web due in one month 12:59:39 Created ACTION-595 - Create a final report on Mime and the Web due in one month [on Larry Masinter - due 2011-09-20]. 13:00:42 ACTION-472? 13:00:42 ACTION-472 -- Larry Masinter to update the mime-draft based on comments & review -- due 2011-07-30 -- OPEN 13:00:42 http://www.w3.org/2001/tag/group/track/actions/472 13:00:53 close ACTION-472 13:00:53 ACTION-472 Update the mime-draft based on comments & review closed 13:01:00 ACTION-588? 13:01:00 ACTION-588 -- Noah Mendelsohn to work with Larry to update mime-web product page Due 2011-08-18 -- due 2011-09-15 -- OPEN 13:01:00 http://www.w3.org/2001/tag/group/track/actions/588 13:01:17 ACTION-588 Due 2011-10-25 13:01:17 ACTION-588 Work with Larry to update mime-web product page Due 2011-08-18 due date now 2011-10-25 13:01:51 Topic: Web Applications: Client-side state 13:02:33 Noah: goal is to progress toward publishing a finding, and find a way to park the original document (as a Note) 13:04:23 http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110910.html 13:05:41 timbl has joined #tagmem 13:06:24 RRSAgent, pointer? 13:06:24 See http://www.w3.org/2011/09/13-tagmem-irc#T13-06-24 13:07:22 LM: stepping back... It is written generically, but really target http URIs, data: URIs and fragment identifiers is not discussed as it is only client-side. 13:07:39 Is the proposal to publish this as a draft finding or a final finding? 13:08:17 Final, I believe 13:10:33 q+ to suggest we step through "Section 5: Recommended Best Practices"? 13:11:15 (discusion about fragment being allowed in data URI or not) 13:12:11 ht: (regarding final or draft finding), we can publish this as final, or we can do a call fo review before publishing 13:12:21 it's up to us to decide 13:12:40 LM: it's the kind of document where we need community consensus 13:13:36 DKA: maybe there is no difference between publishing it as a finding and waiting feedback, and publish a draft and ask for feedback. 13:14:02 DKA: we need to have "Proposed Finding" state 13:14:35 Ashok, can be done in the status section 13:18:40 Or in a covering note 13:18:58 PROPOSED RESOLUTION: We publish the "Identifying Application State" document as a "proposed finding" between now and TPAC, with a fixed feedback time-frame. We bring attention to it at TPAC and encourage people to send feedback. We then collect the feedback and publish it as a finding a [month after] TPAC. 13:22:01 Ashok, got external comments on the previous drafts, not on this one 13:22:10 s/Ashok,/Ashok:/ 13:23:50 Ashok: there are two actions opened, we should close them and open a new one. 13:24:12 Noah: Do you want to publish before or after TPAC? 13:24:28 Ashok: the plan is to publish as soon as possible and talk about it during TPAC 13:28:26 RESOLUTION: The TAG publish the "Identifying Application State" document as a "proposed finding" by 30 Sept. 2011, and will solicit feedback to be due by 15 November. We will bring attention to the draft at TPAC and encourage people to send feedback. Unless major concerns are raised, goal is to publish a final finding no later than Jan. 2012 F2F. 13:29:55 jar will help doing some copy editing before publication 13:30:36 ACTION: Jonathan to copy edit the finding on application state Due: 2011-09-21 13:30:36 Created ACTION-596 - Copy edit the finding on application state Due: 2011-09-21 [on Jonathan Rees - due 2011-09-20]. 13:30:58 ACTION-481? 13:30:58 ACTION-481 -- Ashok Malhotra to update client-side state document with help from Raman -- due 2011-09-10 -- OPEN 13:30:58 http://www.w3.org/2001/tag/group/track/actions/481 13:31:06 close ACTION-481 13:31:06 ACTION-481 Update client-side state document with help from Raman closed 13:33:23 . ACTION: Ashok to publish a final draft for public review of the finding on Application State Due: 2011-09-30 13:34:11 ACTION: Ashok to publish a final draft for public review of the finding on Application State Due: 2011-09-30 13:34:11 Created ACTION-597 - Publish a final draft for public review of the finding on Application State Due: 2011-09-30 [on Ashok Malhotra - due 2011-09-20]. 13:34:21 ACTION-586? 13:34:21 ACTION-586 -- Ashok Malhotra to add text covering advice equivalent to "Use of AJAX implementation technology is not a sufficient excuse for failing to provide first class URI identification for documents on the Web" -- due 2011-08-11 -- OPEN 13:34:21 http://www.w3.org/2001/tag/group/track/actions/586 13:34:31 close ACTION-586 13:34:31 ACTION-586 Add text covering advice equivalent to "Use of AJAX implementation technology is not a sufficient excuse for failing to provide first class URI identification for documents on the Web" closed 13:35:25 YL: Wrt to Raman's draft, we can remove the content or mark as legacy, indicating that it's superceded by the TAG finding. 13:35:36 YL: But...this can't happen until the TAG finding is final 13:38:19 ACTION: Yves to publish as a note what had been the FPWD (Raman's draft) on client side state: Due: 2011-01-15 13:38:19 Created ACTION-598 - Publish as a note what had been the FPWD (Raman's draft) on client side state: Due: 2011-01-15 [on Yves Lafon - due 2011-09-20]. 13:38:32 ACTION 598 Due 2012-01-15 13:38:32 Sorry, couldn't find user - 598 13:38:39 ACTION-598 Due 2012-01-15 13:38:40 ACTION-598 Publish as a note what had been the FPWD (Raman's draft) on client side state: Due: 2011-01-15 due date now 2012-01-15 13:45:23 ht has joined #tagmem 14:00:32 ht has left #tagmem 14:01:41 Topic: HTML5 Last Call -- Overview 14:03:44 (a) follow up from our last call comments 14:03:54 Noah: proposal... one part of the work was on microdata/RDFa. That is now tracked outside, so we should mark last call review as done, and get action to track further development of HTML5 14:03:55 (b) things that should be done for HTML.next, not HTML5 14:06:50 LM: we need to track the 'author' view 14:08:29 LM: there are discussion about HTML.next,rechartering etc... This could be a topic for the TAG 14:15:28 PROPOSED RESOLUTION: The TAG will close out the major TAG "Product" titled HTML5 Last Call Review, but will pursue ongoing related initiatives (e.g. microdata/RDFa), and will generally keep tracking HTML5 developments 14:16:20 RESOLUTION: The TAG will close out the major TAG "Product" titled HTML5 Last Call Review, but will pursue ongoing related initiatives (e.g. microdata/RDFa), and will generally keep tracking HTML5 developments 14:16:58 jar has joined #tagmem 14:16:58 NM: Worth having a general tracking action on HTML5 14:18:12 DKA has joined #tagmem 14:18:21 ACTION: Noah to close out HTML5 review product Due: 2011-10-15 14:18:21 Created ACTION-599 - Close out HTML5 review product Due: 2011-10-15 [on Noah Mendelsohn - due 2011-09-20]. 14:19:26 LM: do we have any comments on what needs to be done in the future of HTML? 14:19:38 AM: What do you mean future version? 14:20:03 NM: What would be called HTML6 if you were/are using version numbers 14:21:22 ashok: looking at issue list, we have many that are postponed, assigned to 'next release' 14:25:45 discussion about html-xml TF and the possibility of the community doing convergence 14:27:04 Noah: let's look at the first use case 14:27:17 LM: not sure the two solutions allow me to use XSLT 14:28:23 Noah: it does as it light the path on the work to be done to do concrete integration 14:31:16 (discussion about the polyglot vs html5 parser of "invalid" markup) 14:33:03 should the Authoring view of HTML document make documents non-conforming if they can't be turned into polyglot 14:35:07 ACTION-560? 14:35:07 ACTION-560 -- Henry Thompson to review HTML polyglot last call Due 2011-06-06 -- due 2011-06-02 -- OPEN 14:35:07 http://www.w3.org/2001/tag/group/track/actions/560 14:35:40 NM: Overtaken by events? 14:35:59 HT: No, I want to review it, please bump the date. 14:36:41 ACTION-560 Due 2011-11-30 14:36:41 ACTION-560 Review HTML polyglot last call Due 2011-06-06 due date now 2011-11-30 14:39:51 LM: we failed to apply comments on things that were under way, however it would be good to discuss and give input on what's next 14:40:11 ht has joined #tagmem 14:42:51 jar: we have a collision with research on distributed systems and what's deployed using HTML now 14:43:32 DKA has joined #tagmem 14:43:35 s/with/course with/ 14:43:56 /me 14:43:56 Hello Working Group, 14:43:56 14:43:56 Now that the Last Call period is over, it's a good time to start thinking about the next steps in the evolution beyond HTML5. 14:44:00 14:44:03 There are a few ways we can start thinking and talking more about HTML.next: 14:44:06 14:44:09 1) Let's start up some discussion and collection of post-HTML5 feature ideas. 14:44:12 14:44:16 2) Though we cannot yet publish post-HTML5 deliverables as Working Drafts, nothing stops us from creating Editor's Drafts. So current editors and anyone else who is interested are encouraged to create post-HTML5 proposed Editor's Drafts for consideration, in parallel with the versions working their way through the LC process. 14:44:19 14:44:22 3) To be able to publish post-HTML5 delieverables, we will have to change the charter of the Working Group. There are two possible tracks we can take: 14:44:25 A) Come up with a detailed definition of the requirements, scope, and expectations for our next-generation deliverables, and cast that as a new charter. 14:44:26 Tim: issue is that if we decide what should be next, it could end up like XHTML2 14:44:28 B) Update the current charter and give a fairly loosely defined scope for post-HTML5 deliverables. 14:44:32 14:44:35 Option A is much more clear about the next phase of our work, which is helpful in some ways, but it may require longer discussion to be clear about the scope. Option B likely requires less careful wording and negotiation. There is some interest in completing rechartering by the time of TPAC 2011. To achieve that, we'd have to have a draft charter ready in 3-5 weeks. We have W3C staff members who can help with the drafting. 14:44:38 14:44:39 14:44:42 The Chairs welcome discussion of any or all of these topics. This will also be a discussion item at this week's telecon. 14:44:46 14:44:49 Regards, 14:44:52 Maciej 14:44:55 14:44:58 14:45:02 14:45:50 my question is whether the TAG wants to/should participate in that process 14:46:20 ht: it is evolutionary, it gather more functionalities, the browser becomes the platform. But the browser was not originally designed to transform itself in an OS. 14:46:38 "it wasn't meant to do X" … 14:47:46 dka: web runtimes as alternative clients (widgets) 14:48:29 q+ 14:48:49 dka: enormous pushback on widgets 14:49:20 DKA: the intent of widget was packaging web application, install them _as real applications_, and it's widely deployed. There was a lot of pushback as it was seen as destroying the web 14:49:49 It's widely deployed? I thought he said widely "villified" 14:50:02 he said both 14:50:14 q+ ashok 14:50:26 q+ noah 14:50:35 q? 14:51:00 I said that Adobe Air was widely deployed - and that this was a good example of a Web Runtime environment (though a proprietary one). The idea of W3C Widgets was to standardise the approach to packaging up apps for such a runtime enviornment. 14:52:05 Tim: there was a set of competitive languages, and javascript won. This direction got some momentum. For web application, many things were missing, like giving access to the web (see CORS). Packaging is not really an issue, the main one is about master 14:52:08 files 14:52:41 q- 14:52:42 using all the pieces we currently have and create a few more steps, we can really go further 14:52:46 ack next 14:52:47 masinter, you wanted to propose way forward 14:52:53 ack timbl 14:53:00 q+ 14:53:04 ack next 14:53:05 DKA, you wanted to suggest we step through "Section 5: Recommended Best Practices"? 14:53:13 masinter has joined #tagmem 14:53:58 DKA: native apps vs the web... when talking about widgets.. people were complaining that it was not the web (even if using web techniques) because it was not running in the browser 14:54:22 one issue is the possibility to address 'web runtime' 14:54:44 q? 14:54:47 q? 14:55:07 there is a need for a version of widget that is really part of the web 14:55:22 and it may converge with an upgraded version of appcache 14:55:27 q+ jar to wonder about how predictable the trajectory ought to be 14:56:04 AM: Things run in the browser, right? 14:56:09 dka: The app runs inside a webkit instncce, but not a browser 14:56:20 ... it is a web runtime , not a browser 14:56:20 DKA: No, not in the story I told. Something like Webkit, yes, but browser typically not. 14:56:39 tim; It has the DOIM and many browser-lie things 14:57:06 Ashok: Suppose we don't use JS? 14:58:53 q? 14:58:55 ack next 15:00:04 ack next 15:00:19 ht: I said that we don't need a meeting to discuss about the browser evolving. A meeting is good for radical changes, but not sure it's needed 15:02:00 noah: there is a group of people who will work on what's next, it may or may not go through radical changes, but the question is "should we engage in that process" be it monitoring, doing charter change, give small or bigger input etc... 15:03:21 ack next 15:03:23 jar, you wanted to wonder about how predictable the trajectory ought to be 15:04:32 LM: in august, Maciej sent a note about the rechartering. So it's about the TAG having an input on the charter or not 15:05:14 DKA: the workshop on offline web application may lead to such input 15:05:39 http://lists.w3.org/Archives/Public/public-html/2011Aug/0263.html 15:05:59 NM: Can anyone get involved in HTML next tracking 15:06:13 DKA: Can you report to the TAG on it 15:06:17 http://www.w3.org/2011/web-apps-ws/ 15:06:34 s/DKA/NM/ 15:06:44 DKA: Yes, I think I could. Relates closely to the workshop. 15:06:52 LM: Workshop scope is narrower. 15:07:13 s/LM:/DKA:/ 15:07:29 What I said ws that web-apps-ws is orthogonal to HTML.next 15:07:51 web-apps could be done entirely with SVG and XML and not HTML anywhere 15:08:18 ACTION: Appelquist to report to TAG on goals, scope and progress to date for HTML.next work Due: 2011-10-18 15:08:18 Created ACTION-600 - Report to TAG on goals, scope and progress to date for HTML.next work Due: 2011-10-18 [on Daniel Appelquist - due 2011-09-20]. 15:09:30 ACTION: Noah to document in product pages wrapup of HTML5 last call work, leading to HTML next review Due: 2011-10-11 15:09:31 Created ACTION-601 - Document in product pages wrapup of HTML5 last call work, leading to HTML next review Due: 2011-10-11 [on Noah Mendelsohn - due 2011-09-20]. 15:11:15 at TPAC, Tim, Peter, DKA, ht, Noah, Larry should be there 15:12:58 everybody is expected at the january f2f 15:13:08 Topic: Administrative 15:22:44 the TAG proposed plan for april meeting seems ok with everybody, so almost ready for confirmation (need Jeni's input to finalize) 15:29:37 ht_home has joined #tagmem 15:35:00 ACTION-565 15:35:05 ACTION-565? 15:35:05 ACTION-565 -- Noah Mendelsohn to talk to Bernard about possible IAB/TAG co-location -- due 2011-08-16 -- PENDINGREVIEW 15:35:05 http://www.w3.org/2001/tag/group/track/actions/565 15:35:11 close ACTION-565 15:35:12 ACTION-565 Talk to Bernard about possible IAB/TAG co-location closed 15:35:39 ACTION: Noah to work with IETF liaisons to propose possible TAG participation in IETF paris Due: 2011-10-10 15:35:39 Created ACTION-602 - Work with IETF liaisons to propose possible TAG participation in IETF paris Due: 2011-10-10 [on Noah Mendelsohn - due 2011-09-20]. 15:36:14 formal liaisons are Thomas Roessler and Philippe Le Hegaret, and Mark Nottingham 15:38:30 This is the workshop on the future of offline webapps: http://www.w3.org/2011/web-apps-ws/ - set for 5th of November in Redwood City. 15:39:47 ACTION: Noah to mention to Ian to document level of TAG commitment in nomination info 15:39:48 Created ACTION-603 - Mention to Ian to document level of TAG commitment in nomination info [on Noah Mendelsohn - due 2011-09-20]. 15:45:19 NM: Should app cache vs. app packaging be on the headsup list for Jeff? 15:45:23 DKA: Yes. 15:45:29 NM: OK, please remind me. 15:50:10 q? 15:50:13 q+ 15:54:02 ht_home has left #tagmem 16:04:16 jar has joined #tagmem 17:59:12 Zakim has left #tagmem 18:24:37 timbl has joined #tagmem