00:48:39 timbl has joined #tagmem 00:55:04 noah has joined #tagmem 00:59:36 noah has joined #tagmem 01:01:58 annevk has joined #tagmem 03:50:43 Larry has joined #tagmem 08:34:08 darobin has joined #tagmem 09:06:50 darobin has joined #tagmem 09:24:47 noah has joined #tagmem 10:42:22 darobin has joined #tagmem 10:50:38 noah has joined #tagmem 10:59:10 annevk has joined #tagmem 11:52:09 darobin has joined #tagmem 11:53:58 jeff has joined #tagmem 12:05:43 noah has joined #tagmem 12:20:46 darobin has joined #tagmem 12:45:49 annevk has joined #tagmem 12:51:52 I will be 10 min late to call in. Apologies. 12:52:26 JeniT has joined #tagmem 13:00:44 noah has joined #tagmem 13:02:44 Marcosc has joined #tagmem 13:03:04 RRSAgent, make logs public 13:03:04 Zakim has joined #tagmem 13:03:06 Zakim, this will be TAG 13:03:06 "TAG" matches XML_(TAG TF)10:00AM, TAG_(AWWSW)9:00AM, and TAG_f2f()8:00AM, trackbot 13:03:07 Meeting: Technical Architecture Group Teleconference 13:03:07 Date: 19 March 2013 13:03:21 Scribenick: Marcos 13:03:29 scribenick: Marcosc 13:03:29 noah has joined #tagmem 13:03:32 scribe: Marcos 13:03:51 slightlyoff: meeting time 13:06:47 TOPIC: Local Storage 13:07:36 NM: The TAG that has had things to say about local storage. About the architecture, what is good, what could be better. And also about the use cases. 13:08:13 NM: who is not familiar with the TAGs finding about local storage? 13:08:36 http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20111201 13:09:21 YK: I would like to broaden the discussion to talk about resources generated locally and URIs to reference those things 13:09:33 YK: e.g., bookmarking and sharing 13:09:44 fighting "this passcode is not valid" 13:10:11 it says I'm the first participant 13:10:13 NM: bookmarking is not as critical because you can use your own arbitrary API 13:10:14 are we not dialed in? 13:10:25 can someone please dial the meeting in? 13:10:35 slightlyoff: one sec 13:10:43 timbl has joined #tagmem 13:10:44 slightlyoff: doing it now 13:10:52 hanks 13:10:54 thanks, even 13:11:51 JeniT, this is frustrating as tab auto-complete in systems like irccloud add ":" 13:11:53 Ashok has joined #tagmem 13:11:58 NM: some of this was motivated by #! 13:12:07 slightlyoff so true 13:12:17 the line is noisy 13:12:20 lots of static 13:12:48 YK: the thing to keep in mind about push state, the server needs to return the same resource 13:13:15 Hmm. let me redial 13:13:39 the question here is about the app development model 13:13:47 i.e., what does a local cache "mean"? 13:13:54 the web doesn't have any sync infrastructure now 13:14:02 which means that there's a fight 13:14:15 I'm muted 13:14:16 YK: hash slash is used because because it doesn't send to the server 13:14:47 noisy and quiet, but OK 13:14:48 thanks 13:15:09 TBL: is it helpful for caching? 13:15:11 YK: yes 13:15:41 TBL: I've seen people use the fragid being sent as a header 13:16:05 q? 13:16:07 TBL: because people wanted to what people were looking at with regards to the data 13:16:22 YK: I can see why someone would want that 13:17:42 TBL: but you can't capture those all the time because you can open tabs by shift click, etc. 13:19:37 the server has NO IDEA 13:20:27 q+ 13:20:37 s/use the fragid being/suggest the fragid should be/ 13:20:39 NM: I'm interested in local remote transparency - we all know how the classic google maps uri scheme works (and JS can reconstruct the right map). But if you use those URI in a non-js capable device, it rendered the same map. This is cool because the URI still identifies that map representation? 13:21:07 q? 13:21:24 NM: The URI scheme should avoid trying to avoid explicitly being resolved on the client or on the server (i.e., should work for both) 13:22:33 I'm saying just a bit more than the URI scheme, but yes: I think it's preferable to not bake into the names of things a commitment to implement resolution on client vs. server 13:22:56 q? 13:22:59 ack next 13:23:01 q+ 13:23:11 q+ 13:24:05 as a general rule, people who are trying to do these things aren't listening to our findings, but do things that are economically useful 13:24:11 ack next 13:24:14 ack next 13:25:04 q+ 13:25:41 Marcosc: I was saying that this is, in general, about navigating a partially disconnected graph of nodes 13:25:58 Marcosc: and with ajax, some of those nodes are "cache" or "surfaced" locally 13:26:10 Marcosc: so the role of URL is a lossy addres 13:26:12 address 13:26:19 it doesn't encode most of the UI state 13:26:22 but it's an address 13:26:28 YK: I wanted to talk about what people are doing today. Most of my day job is to build a system that does what everyone is the room are talking about. Peoiple are doing 2 things: 1. people are either intercepting clicks (then XHR to get data); the other side, all the links are on the client side, but all the links refer to links that are local to the client side application. 13:27:07 YK: but you should still architect your app like they are fully running off a server 13:27:15 noah2 has joined #tagmem 13:27:37 ...and to build those toolkits, we need to surface the idea of a graph of data that users are navigating 13:27:38 YK: if was want apps to be bookmark-able, then we need a scheme/model that make sense 13:28:02 looks like trackbot is the only op 13:28:17 AM: what are you using for local storage? 13:28:34 YK: there is no good answer to do offline? 13:28:34 q? 13:28:49 s/?// 13:29:08 ack next 13:29:21 YK: you can use local storage to simulate XHR sometimes 13:29:37 NM: what does the TAG want to do? 13:30:04 YK: when you store your stuff in local storage, you need to have enough information that it's as if coming from a server 13:30:09 noah has joined #tagmem 13:30:30 this is one of the thigns the Navigation Controller design is explicitly working to enable 13:31:15 q 13:31:53 NM: Is there something fruitful for us to do here that explains the model (how local data ralates to remote data ... how that data be made addressable) 13:32:55 +q 13:33:12 NH: we have a finding on this but people are not reading the finding 13:33:17 q? 13:33:20 q+ 13:34:11 YK: there are people who are scared of client side stuff because they are scared of losing stuff. 13:34:47 ??: Who is the target for this? 13:35:29 as a first pass, it's a start 13:36:20 JT: we should have a central document, and spin documents for the various communities 13:36:53 NM: someone needs to review the finding, and see what needs to changed or if it's already good enough 13:37:07 YK: I will review the finding 13:38:06 . ACTION: Yehuda with help from Anne(?) to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state 13:38:19 YK: there is also the case for private URI that are not intended to be shared 13:38:57 ACTION: Yehuda with help from Anne to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state with focus on actual examples 13:38:57 Created ACTION-789 - With help from Anne to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state with focus on actual examples [on Yehuda Katz - due 2013-03-26]. 13:39:48 jar has joined #tagmem 13:40:11 YK: use case to change the URL that is not in the history stack (is transient) ... for example popping up a form that is particular for a user. But the URL is not supposed to be shared. 13:40:34 ACTION-789 - Due 2013-03-16 13:40:47 YK: In Ember, we have a system that forces you to create a new URL 13:41:25 ACTION-789? 13:41:25 ACTION-789 -- Yehuda Katz to with help from Anne to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state with focus on actual examples -- due 2013-04-16 -- OPEN 13:41:26 http://www.w3.org/2001/tag/group/track/actions/789 13:41:34 YK: you need to deserialize the state from the URL 13:41:35 q? 13:41:38 -q 13:42:33 ack next 13:42:44 this is about adressing something in the graph of data 13:42:56 that graph is defined by the app 13:42:56 YT: I would expect that if it's in the address bar, I should be able to use it again 13:43:00 (and is app controlled) 13:43:02 ok, so like a preview of a blog post 13:43:06 ? 13:43:18 but what I think wycats__ is pointing out is that there are states and addressable items that don't always live a long time 13:43:33 so the question is "what's the role of addressing for ephemeral state?" 13:43:47 that's an interesting question 13:44:12 AM: Caching in a very smart way. 13:44:37 I can add anyone here ot the github repo 13:44:42 just dm me 13:45:16 slightlyoff: confirm, I agree that that reflects my concern 13:46:25 I agree 100% with what slightlyoff is saying 13:47:32 the way Ember works is that segments in URLs represent serialized models. When you load a page, those models are deserialized and become the models that power the local templates. When you transition to a new state with a new model, that model becomes serialized into the URL. 13:48:03 pushState is the low-level primitive 13:48:16 AR: templating has state. The URL is really a state. Email clients are exactly the same way. URL address nodes in application management. so what you want to do is to build a structure that helps you address the content. Android provides a good model for this, which we should look at. We don't have a good language to talk about this stuff, wish hash bangs and push state. 13:48:40 YK: Anne and I will go out and read the finding, and provide our feedback. 13:48:46 I'm remembering that I did a blog post on this about 2 years ago: http://blog.arcanedomain.com/2011/03/identifying-documents-in-web-applications/ 13:49:03 Probably nothing that would surprise anyone now, but it seemed controversial at the time 13:49:15 YT: There is something deeper here: moving towards a world where we have separation between the shell of the app and data. 13:49:32 YT: I'm quite interested in that from an open data perspective 13:49:44 s/YT/JT/ 13:49:53 s/YT/JT/g 13:50:47 AM: The finding is focused on a different idea - how do you identify application state. You guys are going beyond that with regards to going off line. 13:51:20 but I go INTO a level 13:51:23 q+ 13:51:31 and I go to the navigation screen for a game 13:52:21 NH: there are apps that are not very documenty. For example, in a car game, describing states in as a URI might not be helpful. Then there are other apps that do feel documenty, but what you want to link really depends on what the user's needs are. 13:52:30 I don't think the word "document" is helping us here 13:53:26 YK: there are a bund of states in a model, and URIs represented those models and can be deserialized. 13:53:31 s/NH:/NM:/ 13:53:51 again, I don't htink "document" is helping 13:54:41 YK draws picture on board ... of how a URL can map to a data base table 13:55:05 well, I think think DB state is also a bit wrong...we're talking about moving between nodes in a graph of data 13:55:10 (it might be relational) 13:55:30 s/data base table/model 13:56:29 YK: several segments of the the URI end up representing different models 13:57:35 YK: sometimes people want to do this for concurrent states, but it doesn't work well. 13:58:07 q? 13:58:07 YK: you many have several models represented in your URI 13:58:22 the solution for portals is: ?page1=/foo/bar&page2=/bar/baz 13:58:24 ack next 13:58:26 which is terrible 13:58:36 is there any chance for Video Conference today? 13:58:38 but at least allows people to represent their sub-app state in a URI 13:58:45 forgot to ask earlier 13:58:49 slightlyoff we don't have that setup 13:58:56 JeniT: if you're interested in this, I'd be happy to work with you as well 13:59:06 annevk: a spare laptop with Google Hangouts? 13:59:23 ACTION-756? 13:59:23 ACTION-756 -- Jeni Tennison to draft rough product page / briefing pape for "distributed web applications" -- due 2012-11-06 -- OPEN 13:59:23 http://www.w3.org/2001/tag/group/track/actions/756 13:59:36 ACTION-772? 13:59:37 ACTION-772 -- Jeni Tennison to with help from Larry to propose CR exit criteria for fragids finding -- due 2013-02-12 -- OPEN 13:59:37 http://www.w3.org/2001/tag/group/track/actions/772 13:59:37 wycats, yes :) 13:59:55 close ACTION-772 13:59:55 Closed ACTION-772 With help from Larry to propose CR exit criteria for fragids finding. 14:00:46 yep 14:00:47 can do 14:00:52 I'm alex.russell on skype 14:00:58 great, thanks! 14:01:22 ACTION: Jeni to do new Editor's Draft of fragids spec for approval to publish as CR 14:01:23 Created ACTION-790 - Do new Editor's Draft of fragids spec for approval to publish as CR [on Jeni Tennison - due 2013-03-26]. 14:02:21 scribenick: noah 14:02:27 topic: Publishing and Linking 14:03:11 NM: Ashok, can you orient us? We need to figure out what the future will be for this work. Can you please remind our new members why we got into this and what we're trying to do? 14:04:29 AM: Sure. This arose because of concerns about legal cases. The TAG felt we needed to clarify to the legal community the differences between publishing and linking. We haven't had an easy time striking the right balance between focusing on technical issues vs. framing things in a way that will help the legal community. 14:05:05 AM: We did this work, but reviews haven't been good: responses included that it's too complex, the audience isn't clear, and for the non-technical/legal audience it's not sufficiently clear or at the right level. 14:05:15 scribenick: noah2 14:05:49 AM: What to do isn't clear. We could try to fix this, turn it into something else, abandon it. 14:07:55 TBL: Thomas Roessler had significant concerns. 14:08:42 TBL: There's a concern that perhaps we cross lines where we're worrying too much about policy. 14:09:38 q+ 14:09:59 TBL: We need to do something, not clear what. 14:10:00 ack next 14:10:14 AM: There hasn't been disagreement this is useful. 14:10:21 NM: I think there has been such disagreement. 14:10:27 TBL: At least the form is controversial 14:10:38 AM: OK, I think we need to think about other formats 14:10:48 http://lists.w3.org/Archives/Public/www-tag/2012Dec/0139.html 14:10:55 ^^ email from tlr 14:12:29 https://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb is 401 for me 14:12:31 NM: Personally would love to have impact here. As chair, very concerned about efforts like this that keep getting reconceived and never gel. 14:13:20 AM: Idea on last telcon was to take one section, the publishing section, and expand it. 14:13:23 http://www.w3.org/2001/tag/doc/PublishingAndLinkingOnTheWeb-20121015.html 14:13:43 I found http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2011-10-27.html via Google which has a number of broken links 14:13:44 JT: Taking bits at a time seems reasonable. 14:13:56 http://www.w3.org/TR/publishing-linking/ 14:14:21 NM: Jeni, you interested in actually doing this. Not sure it's the highest priority for you. 14:14:34 JT: (pauses...looks conflicted) right, it's probably not highest priority 14:15:55 NM: I also want to raise the suggestions Larry's made that this relates to governance: http://blog.arcanedomain.com/2011/03/identifying-documents-in-web-applications/ 14:16:10 AM: I might be willing to contribute time on this, even as an outgoing TAG member 14:16:47 is it not sufficient to say "we believe that publishing is not the same as linking"? 14:17:17 noah: one of the lawyers we talked to said that they wanted it published as a Rec because it has more weight that way 14:17:37 the audio on FT is actually better than the bridge = ) 14:17:43 thanks to plinss for that 14:19:38 [we assess feeling in the TAG] 14:19:40 JeniT, can that REC be that a one-liner? 14:20:21 'cause i think we could get 100% support behind "The TAG believes that publishing is distinct and different to linking in both intent and impact. This is fundamental to how the web works." 14:20:40 slightlyoff, well, there's boilerplate in Recs that would make it more than one line, and probably it would have to have a bit of explanation around the diff between embedding & linking to make it make sense 14:20:55 otherwise, yes 14:21:26 NM: How about we agree, Ashok, that you do any further work it's at your own risk, but I will commit to at least asking the TAG to review whatever you come up with. 14:21:38 if we can kill two birds with one stone, we could ask W3C to make the REC boilerplate one line as well — that'd give us a two line spec 14:22:32 I don't know how to change the audio levels on my side from FT vs. Google Voice 14:22:37 will try to figure that out, though 14:22:39 apologies. 14:24:08 YK: I would be more sympathetic of a group like EFF reached out to us. 14:24:38 JT: We did have early input from Thinh Nguyen (spelling), who had done legal work with creative commons. 14:24:45 YL: We had some request from the membership 14:24:56 TBL: People don't know to reach out to the TAG 14:25:01 ht has joined #tagmem 14:26:00 YK: I doubt the people doing the arresting will read this 14:26:34 TBL: We're not expecting tha 14:26:38 s/tha/that/ 14:26:45 figured out the speakerphone = ) 14:27:29 NM: We are hoping to offer something to the defense (or prosecution) lawyers and judges who may wish to better understand how the system they're discussing actually works 14:28:00 ACTION-776? 14:28:00 ACTION-776 -- Ashok Malhotra to with help from Larry to redraft Publishing and Linking, responding to comments, for review at F2F -- due 2013-01-10 -- OPEN 14:28:00 http://www.w3.org/2001/tag/group/track/actions/776 14:28:13 TBL: Publish as a note first, and then work on making an excerpts better 14:28:18 AM: Could do excerpt first 14:28:26 JT: Isn't it better to get the whole thing out there? 14:28:33 AM: Ah, OK, I guess so. 14:29:32 ACTION-776: Due 2013-04-02 14:29:33 Notes added to ACTION-776 With help from Larry to redraft Publishing and Linking, responding to comments, for review at F2F. 14:30:14 I support publishing a trimmed version of this ASAP, FWIW 14:30:26 ACTION-776? 14:30:26 ACTION-776 -- Ashok Malhotra to with help from Larry to redraft Publishing and Linking, responding to comments, for review at F2F -- due 2013-04-02 -- OPEN 14:30:26 http://www.w3.org/2001/tag/group/track/actions/776 14:30:47 ACTION-779? 14:30:47 ACTION-779 -- Noah Mendelsohn to schedule F2F discussion of whether and how to pursue Publishing and Linking -- due 2013-03-01 -- PENDINGREVIEW 14:30:47 http://www.w3.org/2001/tag/group/track/actions/779 14:30:52 close ACTION-779? 14:30:52 Closed ACTION-779 schedule F2F discussion of whether and how to pursue Publishing and Linking. 14:30:57 ACTION-667? 14:30:57 ACTION-667 -- Noah Mendelsohn to check, when publishing and linking wraps, whether it's time to reinvest in http://www.w3.org/2001/tag/2011/12/evolution/Registries.html -- due 2013-03-20 -- OPEN 14:30:57 http://www.w3.org/2001/tag/group/track/actions/667 14:31:07 I'm not on the queue 14:31:12 (I think) 14:31:13 q? 14:31:27 yeah, i have nothing to add beyond what I just typed above 14:32:02 JT: I think it was just a time management 14:32:14 Alex, by "trimmed version" did you mean one section or the whole doc trimmed down? 14:32:49 Ashok: whole doc trimmed to what you think is the meat. Honestly, when you think it's good, I'm fine with it. 14:33:03 OK. Thx! 14:33:56 see http://www.w3.org/2001/tag/2011/12/evolution/Registries.html for background on registries 14:35:02 NM: I'm curious, do folks feel like the TAG should dig into improving the situation with registries? 14:35:17 AVK: I think the community is using Wiki pages 14:35:29 YK: Maybe we should see what the community does first 14:35:51 JT: A possible role for the TAG is to get people thinking about the solution. 14:36:04 AVK: I think somewhere between wiki page and central is the answer. 14:36:43 NM: Are you sure it won't be much harder to get right after ad hoc things are done? 14:36:58 AVK: HTML group is still trying to figure out what to converge on. 14:37:13 AVK: IETF has heard feedback and is working on improving things 14:37:34 AVK: They're getting better at quick registration, even without specs 14:38:25 it's worth looking at the 'possible findings' at the end of that document 14:38:57 NM: My perception is that registries have been important to you. Am I right, and are you OK with the TAG "backing off" in this space? 14:39:55 TBL: I think I'm OK with backing off a bit [scribe is having trouble getting the nuances of what Tim is saying...I think he's basically saying that watching and listening for awhile, and fact finding, is ok] 14:41:22 TBL: Well, we've tried to avoid central registries, prefer using URIs and avoiding centralization. We seem to depend on DNS, but would prefer if that were the only registry. 14:41:38 AVK: People use registries instead of URIs because URIs are too long. 14:41:53 TBL: There's the default base URI approach 14:42:05 NM: As used in ATOM and for some other thinks. 14:42:33 q? 14:42:44 timbl: sometimes it's useful to have a centralised registry to prevent proliferation 14:43:07 ... it depends on the context in which the values are used 14:43:23 TBL: We need to remember there is a cost to deploying things. So, the design point is not necessarily to encourage users around the world to do 10 a day new ones. 14:44:24 isn't this about huffman coding? 14:45:42 how long is the break? 14:52:42 that's me 14:53:47 jeff_ has joined #tagmem 14:59:30 timbl_ has joined #tagmem 14:59:37 zakim, who is on the phone? 14:59:38 sorry, noah2, I don't know what conference this is 14:59:38 On IRC I see timbl_, jeff_, ht, jar, noah, noah2, Ashok, timbl, Zakim, Marcosc, JeniT, annevk, darobin, RRSAgent, slightlyoff, wycats__, Yves, plinss, trackbot 14:59:39 Norm has joined #tagmem 14:59:44 zakim, this is TAG 14:59:44 ok, noah2; that matches TAG_f2f()8:00AM 14:59:48 zakim, who is on the phone? 14:59:48 On the phone I see WG-meeting, +44.207.346.aabb, Jeff 15:00:22 scribe: Marcos 15:00:27 how do I identify +44... as me? 15:00:32 scribenick: Marcosc 15:00:59 TOPIC: Discussion with Jeff Jaffe 15:01:18 thanks JeniT! one of these days I'll get the hang of this W3C thing 15:01:25 NM: we don't have a set agenda for this discussion 15:01:34 ... Noah introduces everyone ... 15:02:07 JJ: Going to spend a few minutes describing what I would like to see the TAG work on.... 15:02:22 jeff has joined #tagmem 15:03:50 JJ: like any WG, the TAG does it's best work when it's working on what it wants to work on. Happy to see new blood in on the TAG. I would like to reflect on what I think are the big issues for me personally. Reflecting on what is going on in the real world, with regards to web arch: web security is the big issue. 15:04:39 You read about it every day in the news paper. The security issues of the web are quite striking and often reported. The lay person may think that the TAG is likely working on to fix that. 15:04:45 I am contributing directly to CSP 1.1 15:05:43 JJ: security is at risk on all sorts of levels (from technical to social engineering), so it's quite challenging to fix. 15:06:14 brian has joined #tagmem 15:06:22 also, I'm working on an extension that will let users control their experience WRT to XSS: https://github.com/slightlyoff/CriSP 15:07:45 JJ: its time to implement the fixes. When I think about this, I don't know where to turn at the w3c, so I turn to the TAG. Second thing, constructing a coherent Web architecture from the odd 60-70 groups. The fact that there are lots of groups are not coordinating is an issue - so this is an opportunity for the tag to help. 15:09:52 I'd like to vhemently disagree too 15:09:57 q+ 15:10:39 MC: I somewhat disagree...the original idea was that the vocabularies would be decentralized. 15:10:56 well, *some* people do 15:11:01 but we don't have much data today 15:11:39 thanks 15:11:58 ht has joined #tagmem 15:12:01 JJ: Third area of opportunity - centralised vocabularies ... a bunch of companies put together schema.org as a place to track vocabularies. Why didn't the W3C think of that?! They've done a great job. The important things about schema.org is that someone is caring for it. 15:14:13 happy to wait 15:14:14 JJ: The big miss was not the centralisation, but that we didn't provide a way for people to find these centralised sources. We've started a head lights exercise to help us look into the future in certain areas - it would be great if the TAG could contribute in identifying gaps. 15:14:23 ack next 15:17:27 I think this plays to the layering question 15:17:33 AR: Thanks Jeff. It's not that the w3c missed an opportunity with schema.org., the Web has documented it's own semantics (e.g., micro formats). What the TAG could do, can't start to inject the perspective and ask wg to add evidence with regards to vocabularies. 15:18:31 JeniT: yep. It's all about trying to create an environment that reaps the best from every generation and puts it in the "dictionary". 15:19:04 q+ 15:19:21 JJ: my view is, if we have something that is critical to web technology, why was the TAG not involved in that? 15:20:04 AR: I don't think it's fair to say that schema.org has succeeded. 15:20:35 ack next 15:22:44 Jeff, your point is that you need the TAG to raise these kinds of issues to you, right? 15:22:57 Yes, Jeni, Thanks. 15:25:07 Larry has joined #tagmem 15:25:20 how is this relevant? we've clearly failed, as jeff says. HTML hasn't evolved to include these common nouns and verbs 15:25:24 bkardell_ has joined #tagmem 15:25:58 Wondering if we're diving too deep on this one item, which I think Jeff introduced as an example of a case in which he would have welcomed an earlier alert to community developments 15:26:32 TBL: I don't agree that we missed an opportunity. We've discussed this long and hard, we've had conferences about this, etc. There is PhD on this problems, etc. Meanwhile, yes, these groups have been somewhat disconnected from the W3C. There has been some pushback from certain places. So, the semantic web folks regrouped around "linked data", and various groups started producing data like UK gov. Going back to schema.org, the w3c and various communiti 15:26:32 es have been trying to find solutions for this for many years. The cynical folks say that there wasn't enough big players involved... it's a big topic. Maybe it's time to bring together what is happening at schema.org back to other communities. 15:26:44 perhaps one answer is to work out what the big companies are going to worry about 15:26:45 I think we missed signs much earlier 15:26:57 microformats, JS libraries, WAI-ARIA 15:27:02 the TAG missed the boat on all of those 15:27:02 TBL: so, it's not like there has not been an attempt to address this issue of centralisation. 15:27:20 schema.org is just the latest in a string 15:27:30 slightlyoff, so what's next? 15:27:50 q? 15:27:55 JeniT: we watch the web as it's evolving, try to encourage paths that reduce friction to evolution, and help WGs pay attention to that evolution 15:28:19 JeniT: we can be agents of change for data-driven spec evolution 15:28:28 slightlyoff: sure, and that's what the TAG thought that it was always doing, and yet as you say it misses things 15:28:31 JeniT: it's in our charter to say "data can bear on this problem, why don't we look at it?" 15:28:49 JeniT: sounds like the TAG looked at things that weren't the public web 15:29:11 slightlyoff: what does your examination of the public web tell you *now* about the things that Jeff needs to worry about? 15:29:31 JeniT: I'm trying to figure that out: https://github.com/slightlyoff/meaningless 15:29:42 JeniT: and trying to build tools to help tell us what we don't know 15:30:14 here's what my browsing for the last week or so turns up: http://meaningless-stats.appspot.com/global 15:30:30 hopefully this extension/reporting system can be released soon 15:30:43 q? 15:30:44 JJ: describes successful workshop on ebooks, points out that Pearson (spelling) has just joined W3C. In general, TAG may want to consider innovations in this area. 15:30:49 JJ: last month we had a very successful workshop on e publishings - with great participation. We concluded that the that industry has a strong reliance on W3C technologies. If we were to work closer together, we would have a richer web. We have a call next week so the CSS wg can coordinate with the pub community. There are some other workshops coming up. When new industries get involved, it might be good for the TAG to be there to help make links. 15:31:10 I'd like to understand Jeff's focus on security 15:31:14 what JeniT said = ) 15:31:23 JT: Can we talk about security 15:31:24 ? 15:31:33 JJ: sure 15:31:41 JT: Ah.. not that I have anything particular to say...we recognized it's big. I'm still not sure we have the expertise. 15:31:44 +1 15:31:51 1+ 15:31:52 q+ 15:32:03 q+ to talk about how TAG is consituted 15:32:12 JT: We might not have enough people in the TAG with a background in security. 15:32:23 JT: What is W3C strategy? 15:32:32 JJ: We have working groups...(names them) 15:33:05 JJ: we do have a number of groups focused around security 15:33:36 JJ: but my perspective is that, while we do some security stuff, we don't address security at large 15:35:31 JJ: For example, I was reading the discussions about DRM and people complaining that it's broken. But the Web itself is "broken", yet we have standardised the platform... 15:35:40 brian has joined #tagmem 15:35:40 AvK: Can you be more specific? 15:35:49 q? 15:35:59 s/specific/concrete/ 15:37:32 JJ: example 1: in the press, the Chinese governments has been running an operation to go through the web and attack information resources around the web. 15:37:48 ack next 15:38:00 AvK: But there are many layers at where this could be happening 15:38:41 We need some "out of the box thinking about security" ... the current approaches do not seem to work 15:39:12 Yves: heh 15:39:12 q? 15:39:14 q+ 15:39:36 YK: We have elite hackers that can break into anything. That's a poor understanding: there is poor security on the Web and people don't understand that. 15:39:52 http://news.sky.com/story/1053970/chinese-militarys-global-hacking-hq-found 15:40:31 JJ: I was not proposing that the TAG can fix social engineering problems. Though there might be some technological solutions to fixing some problems, like short passwords. 15:40:33 isn't the SSL CA issue is something we should push on? 15:40:38 yeah, compared to DNS ;-) 15:40:49 because no one else is 15:41:01 q+ 15:41:01 JJ: The core Web architecture itself is not impervious to attack 15:41:02 SSL CA issue is governance. Certs are being devalued every year. 15:41:12 see SSL EV 15:42:16 slightlyoff: so, what's the solution to that? 15:42:35 [To the point of lack of security expertise on the TAG; I believe that the TAG could study something and bring in additional experts.] 15:42:46 ack noah 15:42:46 noah, you wanted to talk about how TAG is consituted 15:43:12 SSL MITM 15:43:16 jeff: that's fair. CSP is currently our best hope against XSS, which is our ring-0 attack 15:43:25 +1 to delegation 15:43:53 jeff: and I'm working with the CSP WG directly 15:44:21 NM: The TAG is an interesting body in its makeup. We choose more or less what we work on - but TAG's scope is huge given that it covers just about everything. The membership did a really good job at selecting a good range of people with a range of skills. Although we have managed to do some things well as the TAG, the TAG doesn't have a good track record with regards to security. 15:45:05 This is the second time I've heard about two webs. For an organization that cares about One Web this is surprising. 15:45:21 q? 15:45:25 JJ: if we had a new Web, we could address help communicate how to address some of these security issues. 15:45:30 ack next 15:46:23 ht has joined #tagmem 15:47:13 btw, Mozilla deserves props for driving CSP 15:47:50 this isn't unknown 15:48:16 composition under mutual suspicion is hard, but not unknown in the literature 15:48:30 and that's why the web security model looks a lot like capabilities 15:50:30 bkardell_ has joined #tagmem 15:51:49 TBL: Historically, SSL used to give users a fake sense of security. The TAG suggested the Web Security group, which maybe have helped fix up some of the UI issues around the SSL padlock. There are two areas that the TAG that could help: where JS code comes from (which can come from anywhere) but all running in the same scope. Second area, Mark Nottingham mentioned man in the middle attacks using SSL by installing fake certificates. Happened also in ce 15:51:49 rtain countries. So there is real shakeup needed in the whole browser certificate model. 15:52:10 q? 15:52:44 TBL: is there was one thing, SSL man in the middle attacks... the TAG should talk to groups and make sure they are aware of the problem 15:52:44 ack next 15:53:29 it's actually hard to describe what that mode is. 15:53:56 I'm working to build a profiling chrome extension that helps you understand what the baseline trust is 15:54:02 so you can lock yourself down to that 15:54:05 YK: the main issue with CSP, it does not define a "mode". What I think is desirable, is to provide advice is: if you are starting a new site, this is the headers you could use. 15:55:15 TBL: the validator could also help with validation help check about CSP. 15:55:20 if you dissalow inline script via CSP, inline handlers are already disabled 15:55:25 ht has joined #tagmem 15:55:31 MC: it's like web lint for CSP 15:56:08 slightlyoff: but there is no validator that yells at you 15:56:14 no linting tool that complains in your editor 15:56:18 wycats__: just load the page and look at the console 15:56:27 JJ: the TAG needs to think broad of the large issues. 15:56:29 wycats__: also, i'm looking to get events added for inline reporting 15:56:47 wycats__: 'cause right now you can use a report-only URL to see violations, but that's a bit spammy in the spec 15:56:53 slightlyoff: that assumes you can install the CSP header 15:57:08 wycats__: see the chrome extension 15:57:18 slightlyoff: I want it in my editor ;) 15:57:19 -Jeff 15:57:28 wycats__: the goal of the extenion is both to help you lock yourself down and to build good policies forsites 15:57:39 wycats__: Mike West and I can use help on the configurator UI 16:02:28 -slightlyoff 16:02:59 -WG-meeting 16:03:00 TAG_f2f()8:00AM has ended 16:03:00 Attendees were Alex, WG-meeting, +44.207.346.aaaa, +44.207.346.aabb, Jeff, slightlyoff 16:19:31 bkardell_ has joined #tagmem 16:22:31 ht has joined #tagmem 16:33:24 jeff_ has joined #tagmem 16:34:38 ht has joined #tagmem 16:42:15 annevk has joined #tagmem 16:43:11 TAG_f2f()8:00AM has now started 16:43:17 +Alex 16:48:56 are we starting back up? 16:49:02 +Masinter 16:49:07 -Masinter 16:49:31 +Masinter 16:50:02 usually people come back late after lunch, and it's not 1 in boston yet 16:50:15 annevk has joined #tagmem 16:50:50 they had said quarter to, so I rushed across town 16:51:03 +??P2 16:51:07 noah has joined #tagmem 16:51:11 noah2 has joined #tagmem 16:51:28 +WG-meeting 16:51:37 jar_ has joined #tagmem 16:52:18 annevk_ has joined #tagmem 16:53:03 scribenick: wycats 16:53:15 scribenick: wycats__ 16:53:47 scribe: Yehuda Katz 16:55:26 topic: Polyglot 16:58:01 JeniT has joined #tagmem 16:58:41 scribenick: wycats_ 17:00:17 jeff_ has joined #tagmem 17:01:19 I may need to turn off the FT to participate by phone effectively 17:01:24 noah: Polyglot is a contentious topic. Can we have Henry remind us of what TAG/HTML WG have already done 17:01:45 ht: We filed a request ages ago that said we would like to see a polyglot spec on the rec track 17:01:54 noah: I don't think we said rec track 17:01:59 JeniT: TR space 17:02:14 ht: the WG produced a working draft 17:02:35 ... about 6 months ago without any other event occurring, Henri Sivonen requested that the TAG withdraw, and that's where we stand 17:02:42 JeniT: we responded to that request 17:02:45 http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html 17:03:05 JeniT: that turned into a bug on the polyglot spec to add a status 17:03:20 JeniT: that bug has now been assigned to somebody 17:03:47 -Alex 17:03:49 Here's the original request from the TAG to HTML WG, as conveyed by Sam Ruby: http://lists.w3.org/Archives/Public/public-html/2010Mar/0703.html 17:03:55 ht: I'm assuming that we're in normal W3C ground rule space 17:04:00 ... TAG made a decision to make a request 17:04:10 ... until we make a decision to withdraw the request, the request stands 17:04:21 noah: that's formally true, but I'd rather not emphasize in order to avoid raising tensions 17:04:24 jeff_ has left #tagmem 17:04:35 ... we won't rescind without something resembling consensus 17:04:46 ht: the bar is higher for changing your mind than for a greenfield decision 17:04:53 noah: you're right but it's not important to emphasize 17:05:56 ... this request was sent by Sam Ruby on our behalf to the HTML WG 17:06:09 ... my recollection is that the history of this was that there was some contention about this 17:06:17 ... we arranged a F2F at TPAC with HTMLWG and TAG 17:06:17 i would change "work identically" to "be equivalent" personally 17:06:30 in http://lists.w3.org/Archives/Public/public-html/2010Mar/0703.html 17:06:32 ... I thought we had consensus to have Sam do this 17:06:40 timbl has joined #tagmem 17:06:45 ht: I don't remember 17:06:49 noah: then that's my speculation 17:07:14 or "work equivalently" perhaps. it needs to be a useful equivalence 17:07:40 Sam's original request. 17:08:30 Sam conveyed this to the HTML WG saying it was "an action item from the TAG" http://lists.w3.org/Archives/Public/public-html/2010Mar/0703.html asking for a polyglot spec "in TR space." Noah >thinks< but isn't sure this resulted from joing HTML/TAG F2F discussion. 17:09:04 About 6 months(?) ago Henri Sivonen asked HTML WG not to go this way....(and pick up with description above) 17:09:21 noah: as Henri says, there is a current course and speed 17:09:30 ... the HTML WG hasn't formally answered us 17:09:32 s/Henri/Henry/ 17:09:40 ... let's hear from TAG members who want to convince us to change our mind 17:09:45 need to redial 17:09:54 ... opening the floor for 10 or 15 minutes to listen to pro and con arguments 17:09:56 Ashok has joined #tagmem 17:10:02 +Alex 17:10:27 jrees has joined #tagmem 17:10:53 ... Anne was suggesting that you [Alex] may be useful to speak to the concerns 17:10:56 I think the request is fine, except that 'work identically' is probably too strong, 'work equivalently' would be fine and much more useful 17:11:07 slightlyoff: I'll try to be as even handed as possible but I have an opinion 17:11:21 ... what is in the channel matches my knowledge of the archaelogy 17:11:23 zakim, who is on the phone? 17:11:23 On the phone I see Masinter, ht, WG-meeting, Alex 17:11:40 ... (1) there seem to be a series of unstated assumptions about what we would like to happen and what can happen 17:11:44 polyglot *can* happen 17:11:55 it's relatively clear that we don't know for sure how important this is 17:11:55 I don't think we should be wasting time talking about pros and cons of polyglot, more relevant is whether or not changing the request will (a) make any difference and (b) make a positive difference 17:11:58 we have a theory 17:12:02 the origin of the request was earlier in the HTML/XML task force discussions 17:12:11 ^^ please fix that to add ...'s when scrubbinhg 17:12:46 timbl has joined #tagmem 17:12:49 slightlyoff: I think there's concern from ht that we might be what appears to be advice when it may simply be the case that the document is outlining one potential subsetting 17:12:59 ... intent vs. observation is one way to characterize it 17:13:05 s/ht/henri/ 17:13:05 s/ht/HS/ 17:13:23 ... there is no signpost to suggest whether a document is polyglot or not 17:13:38 ... and there doesn't appear to be a strong argument for how or why to publish in polyglot so other people know 17:13:44 ... which seems fatal to the intent argument 17:13:57 noah: can you clarify? 17:14:04 slightlyoff: there's a signage question 17:14:17 ... how does anybody know whether there is more or less polyglot or if anyone is publishing polyglot 17:14:25 ... you would need to parse both HTML and XML in order to determine it 17:14:33 ... it doesn't seem to me that the arguments about intent hold much water 17:14:47 ... as a note that describes a state of nature I think polyglot is fine 17:14:54 q+ to make the arch. arg't 17:14:56 ... but I don't think it rises to TAG's level of interest 17:15:08 ... I would like to understand from the folks who designed it whether it is meant to be intent or observation 17:15:09 q+ to make the case that having a spec is useful 17:15:12 q+ to talk about threshold of interest 17:15:14 ack next 17:15:15 ht, you wanted to make the arch. arg't 17:15:25 ht: let me try to make the case 17:15:51 ... I think the grounds for the case are most easily motivated by making the historical parallel that Larry made in his recent email 17:16:18 ... with the benefit of hindsight, the consensus position is that the W3C made a mistake 6-7 years ago with XHTML 17:16:44 ... with the idea that the W3C's spec-writing and related activities would focus exclusively on XHTML 17:16:48 I worked on XHTML in the HTML working group in 1999-2000 when I worked for Xerox and then AT&T 17:16:50 ... and that "HTML would wither away" 17:16:59 ... because of the manifest benefits of XHTML 17:17:03 ... we were wrong 17:17:04 Larry sent a number of emails, but I think the one to which Henry refers is: http://lists.w3.org/Archives/Public/www-tag/2013Mar/0082.html 17:17:11 ... it's cost us a lot to scramble back 17:17:35 ... I think it would be exactly as culpable to believe that HTML5 is the way forward for the web 17:17:41 q+ to discuss why those are not the same thing 17:17:42 the only "mistake" was to have a HTML working group at a time when Microsoft & Netscape were trying to kill each other and neither were participating in the HTML working group 17:18:11 ... I don't think it's unreasonable on the part of some people to feel that polyglot is a sort of last ditch effort on the part of those no-hoper XML folks to keep a toe-hold on the web 17:18:54 ... I want to say that just as it was a very fortunate thing that we added the relevant appendix to the XHTML spec about interop with text/html 17:19:12 ... it seems to be precisely the reason why polyglot ought to be document 17:19:18 ... not because we're pushing or endorsing it 17:19:18 q+ 17:19:27 ... but because as Alex said, it's factually the case that the subset exists 17:19:31 ht: what are those goals? 17:19:47 ... people with "certain goals" will have benefit from the description of the subset 17:19:55 ... it is "evidently the case" that people want to do this 17:20:10 ... the W3C owes it to its constituencies to make it convenient and gracefully interoperable 17:20:20 can someone please describe the use-case crisply? 17:20:24 does rescinding the request change the predictable outcome? 17:20:46 ack next 17:20:47 ... we want the web to be safe for people who believe that their constituencies need XML that is parsable and displayable with minimal failure as text/html 17:20:48 noah, you wanted to make the case that having a spec is useful 17:20:49 slightlyoff, if it doesn't, why rescind it? 17:21:12 noah: I agree with people who say that it is an emergent property of the spec that you can do this 17:21:14 JeniT: because of the confusion about intent vs. observation. Why should the TAG be in the middle of this debate at all? 17:21:24 ... the reason I think having a spec is useful is so that people can refer to it formally 17:21:28 ... which I think is very important 17:21:35 ... I think we have seen evidence that the use of this is non-trivial 17:22:24 ... the statistics of things that are polyglot in the wild is likely low 17:22:31 Graham Klyne, in the email thread "As a developer, I really want to know there are patterns I can 17:22:31 generate that work for the widest possible range of clients (browsers 17:22:31 and otherwise)." 17:22:43 ... we don't have a firm grip on how many people are doing it 17:22:54 ... but does anyone really doubt that some people are trying to do it 17:22:59 ... XML is a W3C technology 17:23:09 ... people will want to use it to publish documents that are also text/html 17:23:09 I would argue that if the HTML working group declines to pursue it, the W3C should spin up some other activity to pursue this instead. That is, the recommendation to the Director to ensure that some working group publish a polyglot spec. 17:23:18 ... these could be gas pipeline markup whatever 17:23:26 ... I think it's good to give people a spec they can point to 17:23:40 I don't disagree with any of that. But what does that matter to the open web or the TAG, particularly if that spec is on rails no matter what we do? 17:23:40 ... I think having a spec that says how people should do it is valuable 17:23:45 ... I don't think it's very expensive 17:23:52 ... we can put status notes about encouragement 17:23:59 q? 17:24:00 q+ 17:24:03 ack next 17:24:03 annevk: I think the expense... 17:24:04 masinter, you wanted to talk about threshold of interest 17:24:12 q+ 17:24:15 q+ to disagree that "the spec. is on rails" 17:24:15 masinter: I think the TAG made a request 17:24:44 masinter: the TAG made a request 17:24:52 but will that kill the effort? I don't see how it would? 17:24:58 ... withdrawing the request would send a signal that we don't think it's important 17:25:16 ... polyglot is a transition technology that allows you to... anytime you have one to many communications... 17:25:21 ... any time you have a network communication 17:25:25 do I read the HTML WG differently than masinter does? 17:25:28 ... any time you have multiple recipients and single sender 17:25:35 ... and you want to transition from one technology to another 17:25:45 ... you need a definition that people can use to transition 17:26:06 ... this is an important sub-topic of the long-held versioning topic 17:26:12 ... this is an architectural principle 17:26:32 ... enterprises may be able to handle it, but it's not effective for the web 17:26:45 ... it's an important understanding for how the web differs from other distributed system 17:26:50 s/system/systems/ 17:26:55 why does that have to do with the WG dropping or keeping the Polyglot spec effort? 17:26:55 ... it is an architectural principle 17:27:01 s/"evidently the case"/evidently the case/ 17:27:12 ... we want people who are currently using XML tools 17:27:12 FWIW, I think Larry's argument makes sense, but it's not the one that motivates me. I don't necessarily see it as a transition: I think XML will live a very long time and will be used for purposes that overlap with uses of HTML. I expect that the communities that invest in XML for other good reasons will be the ones who use polyglot, not just as a transition, but as long as XML is useful to 17:27:12 them. 17:27:18 would rescinding the request kill the effort? I get the sense no. What do you think masinter ? 17:27:19 ... is this worthy of a recommendation 17:27:49 ... the % of this is rather small, but the web is a trillion dollars in the world economy, so even 1% is billions 17:27:50 how is the REC question even in our court? 17:27:56 I don't understand 17:27:57 Alex, could you clarify "kill the effort". Are you saying that the HTML WG will write and publish in TR space a polyglot spec anyway? 17:28:03 there's an opportunity cost 17:28:10 noah: that seems to be the case 17:28:12 ... it's worth paving the cowpath 17:28:17 that's the sense I got from Sam 17:28:21 Yes, of course there's an opportunity cost. The TAG was making the case that the value justified it. 17:28:27 it's within their charter and they have volunteers going ahead 17:28:27 ack next 17:28:28 wycats_, you wanted to discuss why those are not the same thing 17:28:34 that isn't the argument Larry was making noah 17:28:49 he was making the case on economic terms without considering opportunity costs 17:28:49 Hmm, what did I miss? 17:29:00 ack next 17:29:12 slightlyoff: I had a couple of questions 17:29:13 My points werwe in email & irc log so this is just reminding 17:29:26 ... it didn't seem to me that there was a particular sense that the TAG has anything to do with this 17:29:35 ... if the TAG rescinded the request, it wouldn't kill the effort 17:29:41 ... they're going to do this regardless of what we do 17:29:49 ... this is a process question 17:29:55 http://lists.w3.org/Archives/Public/public-html/2012Dec/0082.html requested Rec 17:29:55 The TAG is concerned because we want to be >sure< that the W3C is appropriately supporting the coordinated rollout of two related technologies. Cross technology and WG coordination is part of our formal mandate. 17:30:07 q+ to talk about TAG's role and what will happen anyway 17:30:19 ... assuming that the TAG made this request, and assuming that it rescinds it, what does the "signal" it sends affects the effort 17:30:24 q+ 17:30:27 ack next 17:30:48 TBL: The TAG is responsible for things that span groups. This does. 17:31:15 but this is about 2 specs both being published in the HTML WG, no? 17:31:27 annevk: I just wanted to point out that we tried this before 17:31:33 ... it was Appendix C of the XHTML spec 17:31:37 ... and it failed miserably 17:31:47 ... people fail to produce that content 17:31:56 ... it seems to me that some people can do it 17:32:10 ... IE now supports text/xml 17:32:15 if Appendix C "failed miserably", why is it that > 6% of web sites are parsable as both HTML and XHTML ? 17:32:25 ... it seems to me that actually doing it just makes your pipeline more complicated and isn't actually necessary 17:32:28 masinter: vs. the hoped for 100%? 17:33:01 annevk: you need both an XML and HTML parser to consume the content 17:33:05 timbl: no, you just need one 17:33:07 masinter: doesn't pass any class I was ever in = ) 17:33:15 zakim, who is talking? 17:33:22 XSLT specifies, and XSLT tools support, the production of XHTML per appendix C, and that path is widely used 17:33:27 noah, listening for 10 seconds I heard sound from the following: ht (100%), WG-meeting (72%) 17:33:30 timbl: publishing as polyglot supports the greatest number of consumers 17:33:38 annevk: you can just publish as XML if that's what you want 17:33:42 annevk: it will work everywhere 17:33:56 I still haven't heard any response on the process issue that satisfies me 17:34:03 i never hoped ro 100% when I worked on Appendix C in XHTML ... that's a mis-characterization 17:34:03 timbl, masinter: can you try? 17:34:20 timbl: the sorts of examples that people use this is for example to work with XSLT 17:34:21 I'm about to, just waiting to get off the queue 17:34:38 address the process issue. What happens, in your view, should we rescind the request? 17:34:40 Alex, is your process issue: why is the TAG involved? Tim and I have offered quite consistent answers on that: the TAG has a formal mandate to help with technology issues that cross WGs. 17:34:46 timbl: it's bad practice to need an XML copy and a translated HTML copy 17:34:54 scribe admits he doesn't fully follow the argument 17:35:02 noah: but this isn't cross WG. This is just XHTML and HTML, both of which are in the HTML WG 17:35:25 I consult for people who sell and maintain XHTML toolchains 17:35:37 timbl: how many people have used or built large XML system 17:35:43 wycats_: I have wrote a book with XML 17:35:50 ... it was one of the most miserable experiences of my life 17:35:58 I've written huge systems in DocBook 17:36:00 timbl: to what extent is the W3C only browsers 17:36:03 also miserable 17:36:10 (custom XSLT-FO, etc.) 17:36:17 timbl: do we believe the XML community will wither and die? 17:36:19 everyone knows someone who has worked with XML tool chains on HTML. I've certainly done so myself when building an internal web site 17:36:29 noah: what am I missing? isn't this all HTML WG? 17:36:31 annevk: are we talking about producers or consumers 17:36:36 The people I work with attribute _all_ their commercial value to the use of XML->XHTML toolchains 17:36:43 timbl: are people going to stop using XML toolchains 17:36:50 ... at the moment people use XML 17:36:52 there should be *NO* polyglot consumers 17:36:53 I really don't think driving this by our personal experience is the right way to do it. I think if you invited someone from Mark Logic, which has a tremendously successful product that is XML down to the screws, they would have interesting things to say. 17:37:06 there are HTML consumers and XML consumers 17:37:07 then let's invite them! 17:37:09 noah: I agree that personal experience isn't data 17:37:22 q+ 17:37:28 Yes, it's not mainly a browser product. I don't know >what< they'd say, except that XML almost surely remains very important to their customers. 17:37:32 I'm still stuck on the question of process: isn't this all HTML WG? 17:37:43 timbl: if they notice that HTML looks like XML and want to use their tools for it, we can tell them that, yes it works 17:37:49 personal experience *is* data if you're looking for evidence and convincing use cases to assure that the use cases are significant and non-trivial 17:38:03 or is nobody going to bite on this? 17:38:04 Alex, could you respond to what Tim and I have said about the process. You keep saying you don't see why, and we've both offered the same reason. 17:38:19 noah: you've said it's cross-WG, I'm saying "howso?" 17:38:37 noah: that's an honest question 17:38:38 timbl: seems to me that giving people a way to use their existing XML tools with HTML is good 17:38:43 it's a threshold > one percent of the web. maybe it's "half of one percent" 17:38:56 q? 17:39:07 ack next 17:39:30 annevk: if the document was more clearly scoped to be for the XML community, it would be better received 17:39:45 noah: TAG members who are sympathetic to polyglot are sympathetic to intros and status sections 17:39:50 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20707 17:40:09 it's already in their tracker 17:40:19 ... to the extent that the concern is that this is fine as long as it's clear what the intent is we might tackle it on that basis 17:40:21 ack next 17:40:22 ht, you wanted to disagree that "the spec. is on rails" 17:40:44 ht: I believe that consensus is possible around the table 17:41:08 ... around the existence of polyglot and specifying it 17:41:17 ... but the controversy is over process 17:41:41 ... historically, TAG's creation of the task force and interest in the issue was significantly the reason for getting the spec in the first place 17:41:49 ... us saying we don't care does send a signal 17:41:57 ... we were involved in getting it on the rails in the first place 17:42:02 From the TAG's charter http://www.w3.org/2004/10/27-tag-charter.html#Mission our mission includes: 17:42:06 ... the constituencies who want it have a legit need for it 17:42:10 ... the cost of satisfying it is low 17:42:11 "to help coordinate cross-technology architecture developments inside and outside W3C." 17:42:15 ... we're just documenting it 17:42:34 This seems pretty squarely to be coordinating cross-technology (XML and HTML) developments. 17:42:35 jrees has joined #tagmem 17:42:41 ack next 17:42:42 noah, you wanted to talk about TAG's role and what will happen anyway 17:42:43 ... there's already a bug to add a status section that explicitly says that we're not recommending it 17:43:03 noah: but it's about XHTML and HTML, one of which has a dep on XML parsing, but isn't proposing any change to XML in any way 17:43:04 noah: the question about the TAG's role has come up several times 17:43:13 ... I'm curious about why this doesn't make the case 17:43:33 ... one of our three formal mission is "to coordinate cross-technology architecture developments inside and outside the W3C" 17:43:40 ... this is about XML and HTML 17:43:58 ... many of the use cases were using existing tool chains to integrate XML documents to generate HTML 17:44:03 but nobody is proposing anything that's not an XHTML-compatible subset, right? 17:44:14 ... at least arguably for some users this is not two serializations of HTML 17:44:36 ... we're just talking about a serialization that works in both contexts 17:44:58 yes 17:45:03 that's my view 17:45:23 annevk: I'd rather the polyglot thing doesn't happen 17:45:37 noah: there are some people who don't want a polyglot spec 17:45:50 annevk: my advice would be if you want to use XML, publish XHTML 17:46:26 if there are one to many publishers where some of the clients want HTML and others want XML, then you need polyglot for those 17:46:45 but nobody is talking about polyglot as XHTML + namespaces, e.g. 17:47:00 masinter: there's no debate over that 17:47:07 noah: the point is you should be able to serve it as either mime type 17:47:14 ... and serve it however you want 17:47:32 That [serving XHTML as text/html] is certainly what my university does 17:47:54 1000s of pages of it 17:48:04 slightlyoff: so that's the use case, it's a common enough use case to have a standard that can be referenced and reviewed for suitability 17:48:21 noah: the cases I would make is (1) I covered why it's in scope; (2) it is different for the WG to promise that they'll do something than for them to randomly do it 17:48:31 ... in 2/3 years if they stop doing it we can ask them why 17:48:36 ... it makes a difference in a coordinating role 17:49:08 so I'm not *currently* suggesting that we say to WGs that we don't care (although I feel that we shouldn't), but this thing appears to be on rails 17:49:18 ack next 17:49:48 Marcosc has joined #tagmem 17:50:17 slightlyoff: so why bring it up at all? it was done, the request was made, there is no reason to retract it 17:50:55 YK: Someone said something about the trillion dollar web. Yes and we have some leverage, but that means the opportunity cost is important 17:51:03 masinter: because there is a serious concern raised about the Appendix-C-style costs to the community 17:51:21 YK: Also, I worry that even if we say you aren't encouraged to do this, people will think you are. 17:51:26 masinter: honestly, I'm willing to go with big warnings about this in the document 17:51:41 YK: People who have no good need will go through hoops be be polyglot-valid 17:52:00 masinter: but I don't know why the TAG cares, nor do I think it should, but I'm willing to only argue the first for now 17:52:06 TBL: Not convinced. We could argue against most any spec we produce on that basis. I think we have to agree at the top of the document what it says. 17:52:15 slightlyoff: does https://www.w3.org/Bugs/Public/show_bug.cgi?id=20707 cover it for you? 17:52:19 YK: You should not use this unless you have interop concerns. 17:52:34 The "Scope" of a spec should say "What is this good for?" 17:52:40 TBL: Good specs don't say you should or shouldn't: they say "if you do this you will get the following benefits" 17:52:43 masinter: that + suggesting this should go to NOTE and not REC might get me there 17:52:51 YK: Not convinced, some people are compulsive about this stuff and will read it as "do it" 17:53:11 note that there is also the question of updating the spec 17:53:17 q? 17:53:23 zakim, close the queue 17:53:24 ok, noah, the speaker queue is closed 17:53:25 q+ Rec means it has been reviewed for whether the technology described is useful for the scope for which it is claimed to apply 17:53:53 +q 17:54:02 Rec means it has been reviewed for whether the technology described is useful for the scope for which it is claimed to apply. A "Note" carries no force except "for your information" 17:54:10 But a) we don't have that for all browsers and b) browsers are not the only page consumers. 17:54:32 jrees has joined #tagmem 17:54:49 masinter: and I'm ok with NOTE under that definition vs. REC 17:54:57 RECs carry no weight either historically... E.g. DOM Level 1-3, HTML4, CSS1, CSS2 (before .1), ... 17:54:58 I don't understand why XHTML doesn't practically solve the "XML pipeline" issue 17:55:07 noah: I don't really hear consensus 17:55:11 wycats_: it does. 17:55:22 wycats_: except for historical UAs. 17:55:24 q+ 17:55:33 zakim, reopen the queue 17:55:33 ok, noah, the speaker queue is open 17:55:36 Making sure we are understood as supporting the proposed resolution to https://www.w3.org/Bugs/Public/show_bug.cgi?id=20707 is a positive step we should take 17:55:39 ack next 17:55:45 slightlyoff: it sounds like there's the potential for some common ground here 17:55:54 ... Larry and I have been chatting on IRC with the open bug 17:56:06 ... I am ok with modifying our suggestion that this go to a note not a REC 17:56:12 ... basically it says that this is an interop tool 17:56:18 ... and we don't necessarily recommend for all content 17:56:29 ... I don't want to give this inappropriate authority 17:56:40 ... I am concerned about the tenor 17:56:53 ... everyone agrees that polyglot happens and will be described whether we do it or not 17:57:19 masinter: I think that the difference between a REC and a Note is that a Note is used when you can't reach agreement 17:57:25 ... when you're not recommending it 17:57:26 q+ 17:57:37 ... I think the scope of the document is critical 17:57:51 I don't share Larry's concern about note. I would prefer Rec, but I think Note is fine as a compromise. Note is NOT just for dead technologies, IMO. 17:57:53 ... if you're concerned about scope creep, then you do that by fixing the scope of the document 17:58:07 I want to hear about the use-cases for which XHTML is inappropriate 17:58:07 Note vs Rec is not our decision 17:58:18 ... if the HTML WG doesn't want to do it, we should do it elsewhere, like in XML 17:58:53 ... when you obsolete a technology, it is a standard body's responsibility to give people a path off 17:58:55 I would prefer a REC, along the lines Larry is arguing, but, full disclosure, I note that in XHTML1 we find: "C. HTML Compatibility Guidelines: This appendix is informative." 17:59:04 ... the Director should do this somewhere 17:59:08 we'll disagree on that point, I guess 17:59:10 s/do this/get this done/ 17:59:15 q? 17:59:23 ... the TAG is the shepard of technical activities 17:59:32 ... make sure the right thing is done 17:59:57 and I think a REQ is necessary 18:00:04 s/REQ/REC 18:00:32 noah: who would be in favor of Alex's proposal 18:00:47 ... he suggested that the HTML WG would produce a Note not a REC 18:00:55 ... with text on top that bounded the scope 18:01:08 -1 18:01:08 +0 18:01:09 +1 18:01:14 +1 18:01:29 +0 18:01:31 +0 18:01:35 annevk? 18:01:38 +1 18:01:43 +1 18:01:45 ack next 18:01:52 Status is right thing to do, but Rec vs Note is not our decision 18:02:10 JeniT: yes, I agree with that, but we can specify what we'd prefer in our request 18:02:21 JeniT: the membership will vote 18:02:30 FWIW, I prefer Rec, partly because it represents some commitment to keep it up, but as a compromise I can live with Note, because it meets the requirement for normative REC. 18:02:32 Yves: not sure how to deal with new elements like