00:33:00 timbl has joined #tagmem 00:33:07 timbl_ has joined #tagmem 01:36:26 JeniT has joined #tagmem 01:40:55 jar has joined #tagmem 02:20:03 ht has joined #tagmem 13:14:40 RRSAgent has joined #tagmem 13:14:40 logging to http://www.w3.org/2012/06/13-tagmem-irc 13:15:09 scribenick: masinter 13:15:15 scribe: Larry Masinter 13:15:21 topic: Storage 13:17:59 noah: Storage including synchronization 13:18:09 http://lists.w3.org/Archives/Public/www-tag/2012Jun/0032.html 13:18:14 http://lists.w3.org/Archives/Public/www-tag/2012Jun/0032.html 13:18:35 ACTION-647? 13:18:35 ACTION-647 -- Robin Berjon to draft product page on client-side storage focusing on specific goals and success criteria -- due 2012-06-29 -- OPEN 13:18:35 http://www.w3.org/2001/tag/group/track/actions/647 13:18:55 Robin recommends: 13:19:00 [The TAG SHOULD NOT] attempt to provide a solution for synchronisation problems. It is a complex research area, and if a standardised solution were to be established (which may not be necessary, and certainly not yet) it ought to be created by a dedicated working group with the requisite expertise. 13:19:08 there could be room for the TAG to release a short advisory note that would document 1) the known pitfalls in dealing with data synchronisation, 2) the primary patterns and solutions, and 3) an overview of the terms of the trade. The goal of such a document would be to ensure that someone who may be an adept Web application developer but has no knowledge of this specific problem space to save precious time by being bootstrapped with the basics one needs to s 13:20:44 I suggest this is a topic for the TAG Blog 13:21:06 I hadn't meant to ask about synchronization 13:21:12 http://lists.w3.org/Archives/Public/www-tag/2012Jun/0035.html 13:21:34 noah: in terms of other storage work, what should the TAG do? 13:22:13 q+ to ask about synchronization anyway for a status summary of the field 13:22:20 darobin: In terms of architecture, it would be useful to revisit the notions we have URI stability, in terms of distributed minting of URIs 13:22:54 darobin: we might want to look at versioning, and the databases are massively distributed and unlikely to be running the same version 13:23:16 I think when we've spoken of versioning in the past, it's most often been regarding which version of a language or format is used. I think Robin is speaking of the synchronization of versions of particular data 13:23:16 darobin: problem of vendor lockin, if you have data locally and want to switch user agents 13:23:46 robin: if there is any TAG work to be done, the rest falls under "these are pitfalls" 13:24:23 q+ 13:24:31 timbl: what about sharing and access control? If you have lots of apps access to your address book ... 13:24:31 robin: SOP solves the access control problem. timbl: I don't think so 13:25:00 timbl: I want to have standards for the data, for interoperaebility 13:25:25 q+ to agree with Tim that access control is important/unsolved; disagree with implication TAG is the place to worry about it now, except maybe to alert the community that it's important 13:25:40 timbl: I buy an application, use it on the ipad, and i can't do anything at all with the data 13:26:20 darobin: 2 things: vendor lockin, if data stored is _only_ in UA and only locally, then that would lock you into a UA 13:26:59 darobin: sharing, you don't want to give another application access to your storage directly because you might change htem 13:27:16 darobin: ((something about webintents, group being chartered)) 13:27:41 darobin: webintents provide standardisation around data structures 13:28:12 timbl: there is another model, from the link data platform, where you DON'T use APIs 13:29:09 timbl: people are fed up with every app having little APIs that everyone else has to use. Instead you give access to a file, where the file uses linked data representation 13:29:56 darobin: it's not that different a model. The APIs are data oriented with a discovery component. 13:30:10 timbl: standardizing an ontology instead 13:30:41 NM: Robin, if you have to leave, anything else? 13:30:56 darobin: standardizing an ontology and standardizing an API are very similar in these cases 13:30:58 +1 on common model between webintents and linked data platform 13:31:04 RB: Not beyond what's in my e-mail. I am interested, as Tim implies, in finding common model between Web Intents and Linked Data 13:31:44 darobin: could we make use of json-ld, (something), we've been looking at options 13:32:04 - +33.1.43.14.aaaa 13:32:07 noah: what is your interest in writing in this area? 13:32:13 - +1.617.715.aabb 13:32:14 TAG_f2f()8:00AM has ended 13:32:14 Attendees were +33.1.43.14.aaaa, +1.617.715.aabb 13:32:21 ack next 13:32:25 q? 13:32:27 darobin: I can help but I don't want to drive 13:32:49 q+ test 13:32:54 q- test 13:33:46 timbl: form my point of view, I'd love to have someone explain why, after all these years, that sync is hard 13:34:23 noah: Capp theorem... it's hard. 13:34:58 timbl: Mac has had over years sync services, and still over the years there are failures 13:36:19 noah: if you're willing to keep some amount of state and don't have ((various caveats)) unbounded number of replicates, this is a "solved problem" 13:36:35 timbl: Robin said this is still a research issue 13:37:17 noah: the research is for cases which are more complicated 13:37:47 timbl: (description of situations where synchronization has failed for him on odd occasions) 13:38:14 ashok: re vendor lockin: what is required is that you can take your data and move it to another machine 13:38:28 Some references on CAP theorem: 13:38:29 http://en.wikipedia.org/wiki/CAP_theorem 13:38:40 http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 13:38:48 ashok: thinking about replication: what has happened in the last few years is NoSQL 13:39:06 ashok: they replicate the databases to make them all available 13:39:16 We have 20 mins or so to settle what TAG is doing in this space. 13:39:21 ashok: They have this semantics of "eventually consistence" 13:39:37 ashok: that works OK if there is no semantic difficulty 13:40:13 timbl: the mac has a layer where it generates a UI and asks the user about semantics 13:40:40 ashok: if you use CouchDB, it keeps copies of your documents, and ... ((...)) ... 13:41:06 ashok: if you don't have conflicts it is a solved problem. If you do have conflicts, ... (something)... 13:41:32 ashok: I want the WebApps guys to make an interface to SQL 13:41:39 I think it's also a difficult problem if the existence of replicas is not well controlled. I believe Lotus Notes allows anyone to create new replicas, which means you can >never< be sure you've been in touch with all the replicas. 13:42:17 ashok: if you use SQL, the database syncs, it's what databases do 13:42:33 In Notes, this is dealt with be assuming that all replicas are (transitively) in touch over, say, ever 6 months. If you leave a laptop in a drawer for 2 years and reboot, you can have things like deleted records reappearing. So, that case remains hard as far as I know. 13:42:35 ashok: databases can even send you updates to previous queries 13:42:46 q? 13:42:58 q+ to say that it sounds like these are patterns that we could usefully summarise 13:43:18 timbl: from the RDF point of view, it would be appealing to define sync for arbitrary RDF graphs 13:43:34 q- 13:43:37 noah: (time) 13:43:56 noah: there were two items: storage & synchronization 13:44:20 ashok: robin spoke about 2 things 13:44:51 noah: we need to define what the TAG is doing 13:45:13 q+ 13:45:26 noah: what is the TAG's business? 13:46:19 noah: Synchronization vs. Storage, what do you think the TAG should pursue? 13:46:53 ashok: when robin started, he said "we could write something that would alert people about storage" 13:46:58 We did sync stuff with cwm in the SWAP project around 2001 http://www.w3.org/DesignIssues/Diff 13:47:28 jeni: why not bite of syncrhonization about storage 13:47:38 jeni: would like some kind of output 13:48:31 noah: I think someone needs to research the state of the art, looking at web environment, all in the context of writing architecture 13:48:57 jeni: we're looking at people trying to get out of walled garden 13:49:37 I'd like to propose a direction for consideration 13:50:32 NM: Suggest we use next 10 minutes to see whether people agree TAG work on sync, and if so, get short list of detailed goals. 13:50:46 lm: The only interesting idea I've heard is for the LD platform could provide a framework for unwalled synchronization . Surveying sync literature is uninteresting, because nobody will come to us for that. 13:51:04 LM: I think TAG won't look for us to that. What might be useful is to narrow focus to linked data synchronization. 13:51:07 q+ to about sync being proprietory 13:51:27 ack next 13:51:31 ack next 13:51:32 timbl, you wanted to about sync being proprietory 13:51:34 q+ jeni 13:51:45 s/I think TAG/I think the community/ 13:52:12 s/for us to that/to us for that/ 13:52:22 It occurs to me that things like Dropbox are very widely deployed embodiments of sync, albeit at the file level. 13:52:53 rsync is also pertinent to a degree, I think, though as far as I know it's not bi-directional. 13:52:55 timbl: because the architecture was hub (or adaptor and hub) and spoke 13:53:06 q+ to say that the interesting thing is synchronisation on the web, with the use of URIs and of REST, and standard formats, all of which LDP should take full advantage of 13:53:12 q- jeni 13:53:26 +1 to what Jeni's about to say :-) 13:53:43 timbl: EAI Enterprise Application Integration (something) 13:53:49 ack next 13:53:51 JeniT, you wanted to say that the interesting thing is synchronisation on the web, with the use of URIs and of REST, and standard formats, all of which LDP should take full 13:53:51 ... advantage of 13:54:27 timbl: that may be why syncrhonization is a black art: the market is based on solutions where the hub is a black art 13:55:13 q? 13:55:20 zakim, close the queue 13:55:20 ok, noah, the speaker queue is closed 13:55:23 jeni: what i think is interesting is applying the principles we've learned in other systems. If it's done right, LDP should be a great example of it being done eright 13:55:39 ashok: it's an example we're intereested in 13:56:06 jar: message shouldn't be "You should do it this way" but "If you want to do it this way, here's how" 13:56:22 … and what advantages you might get 13:59:35 larry: the question is -- update conflict resolution in general requires understanding the application -- does using link data deconstruct updates such that a generic conflict resolution mechanism for rdf graphs could be used? 13:59:58 noah: who's willing to do X 14:00:17 jeni: i'd rather have an action to write something 14:01:11 noah: (wants a product page) 14:01:16 s/rather have/rather someone have/ 14:01:36 (discussion of whether we're doing a product page or a document or ...) 14:01:54 ashok: I'll talk to Robin when I can catch him 14:02:39 ACTION: Ashok to propose outline for possible TAG document (finding or rec) on architectural issues relating to storage sync, linked data, etc. Due 2012-07-15 14:02:39 Created ACTION-717 - Propose outline for possible TAG document (finding or rec) on architectural issues relating to storage sync, linked data, etc. Due 2012-07-15 [on Ashok Malhotra - due 2012-06-20]. 14:03:14 ACTION: Ashok to propose goals and success critera for TAG work on architectural issues relating to storage sync, linked data, etc. Due 2012-08-15 14:03:14 Created ACTION-718 - Propose goals and success critera for TAG work on architectural issues relating to storage sync, linked data, etc. Due 2012-08-15 [on Ashok Malhotra - due 2012-06-20]. 14:03:20 i think the scope in the action is broader than i wanted 14:04:02 ACTION-647? 14:04:02 ACTION-647 -- Robin Berjon to draft product page on client-side storage focusing on specific goals and success criteria -- due 2012-06-29 -- OPEN 14:04:02 http://www.w3.org/2001/tag/group/track/actions/647 14:04:07 close ACTION-647 14:04:07 ACTION-647 Draft product page on client-side storage focusing on specific goals and success criteria closed 14:05:16 ACTION-693? 14:05:16 ACTION-693 -- Robin Berjon to draft scope and goals for the Patterns/Pitfalls work in local/remote storage synch -- due 2012-04-19 -- PENDINGREVIEW 14:05:16 http://www.w3.org/2001/tag/group/track/actions/693 14:05:31 close ACTION-693 14:05:31 ACTION-693 Draft scope and goals for the Patterns/Pitfalls work in local/remote storage synch closed 14:10:25 topic: tag effectiveness 14:10:57 noah: Jeni suggested some meeting facilitation methods to use, so I will turn the meeting over to her 14:11:24 noah: I think it is important that we think carefully about what we're trying to achieve 14:11:50 noah: People come in and complain "the community isn't listening ..." 14:12:25 noah: and i ask myself whether the charter is wrong or whether we're performing it wrong 14:12:53 noah: people complain X and propose Y but it's easy to jump to conclusions 14:13:18 noah: as chair I see operational things that are boring but are important 14:14:20 noah: try to get required reading, ready in time. I'm angry that people don't read the required reading. My intuition is that people would do the required readong. 14:14:32 noah: some of those things are bigger 14:15:29 noah: finally, there's quite an asymmetry depending on who is contributing, participating in meetings. To some degree, the last 6 months hasn't been bad. 14:15:39 the fragid thing looks like pretty good work 14:16:24 s/the/noah: the/ 14:17:14 noah: there's a lot positive we've done 14:18:14 TAG_f2f()8:00AM has now started 14:18:15 +Yves 14:19:53 + +1.617.715.aaaa 14:22:43 (noah reviewing charter) 14:23:28 noah: Issues are called out in the charter; maybe we've swung too far from issue-oriented to product-oriented 14:26:44 ashok: what do you mean by community review? 14:27:30 ashok: when we published the finding i wrote, we did several rounds where we asked for comments. Are you thinking we should have done more of that? 14:27:57 noah: I think we've tried in good faith to be open 14:28:51 noah: in my time on the TAG we have bent over backwards ... people don't complain that we haven't answered comments 14:31:32 jeni: structure brainstorming of strengths and weaknesses..... 14:32:11 jeni: opportunities and threats, 10 minutes for each to write down, and group to write down 14:32:31 https://en.wikipedia.org/wiki/SWOT_analysis 14:33:35 jeni: one we can prioritize, do brainstorming first, clusters second 14:33:37 jeni: brainstorming -> clustering -> priorities 14:35:23 lm: what are we trying to optimize? 14:38:40 lm: "we don't explicitly discuss goals; rather, in the discussion of strengths, weaknesses, opportunities and threats and clustering those, we back-derive our common understanding of goals" 14:38:44 lm: right? 14:38:47 jeni: right 14:48:34 timbl_ has joined #tagmem 15:33:08 (group has put up postits for strengths, weaknesses, threats, opportunities, Jini will review categories in that order) 15:33:28 jeni: big strength is experience, expertise, knowledge 15:34:01 jeni other big category strength is we're good people 15:34:44 jeni: others acess to W3C, TimBL 15:35:15 jeni: weaknesses: thrashing, ratholing 15:35:30 jeni: weakness: conflict within group 15:35:49 jeni: problems around time available for tag work 15:36:02 jeni: weakness: travel funding 15:36:27 jeni: weakness: quite a lot of membership churn 15:36:59 jeni: weakness: lack of knowledge in specific areas (security, privacy, network protocols) 15:37:40 ((ashok is typing outline)) 15:37:48 timbl_ has left #tagmem 15:38:24 jeni: weakness: our ability to educate others, lack of power, lack of enforcement 15:38:58 jeni: threat: bad PR 15:39:07 noah has joined #tagmem 15:39:18 jeni: threat: creating recommendations take a long time 15:39:21 noah has joined #tagmem 15:39:49 jeni: threat: general issues around connection with other groups 15:40:08 jeni: threat: liaison to other groups (ECMA, OASIS) 15:40:32 jeni: threat: web is moving, getting broader, more areas 15:41:07 jeni: threat: over in opportunity side: help persuade community 15:41:32 s/threat: over in opportunity/opportunity: / 15:41:50 jeni: opportunity: liaise with ietf iab 15:42:08 jeni: opportunity: meet more with customers, chairs, staff 15:42:37 jeni: opportunity: (2 more) 15:43:46 noah: we should find some middle ground to find some high-value things 15:47:42 Topic: TAG Effectiveness 15:47:58 Strengths - Experience, expertise and knowledge - Good people - Common understanding of Web - Good writing skills - Tim is with us - Access to W3C Process 15:48:15 Weaknesses - Thrashing, ratholing - Conflict within group - People are busy - Problems with travel funding - Membership churn - Lack of knowledge about some areas: security, privacy, protocols - Fear of producing poor work - Relevance of the work - Ability to educate others and have impact on them - Enforcement. No power. 15:48:37 Threats - Bad PR - Creating Recs and how long that takes. - Not enough external review - How to persuade peple about importance of architecture - Connection with other groups - Technology is changing, scope is growing, moving away from areas where we have skills (this may be also an opportunity) 15:48:55 Opportunities - Help persuade people this matters - Help WGs - Liaise with IETF - Feedback on WG work - Meet with customers, etc. 16:00:42 -Yves 16:01:55 timbl has joined #tagmem 16:01:56 timbl_ has joined #tagmem 16:05:46 Norm has joined #tagmem 16:23:02 https://en.wikipedia.org/wiki/Comparison_of_instant_runoff_voting_to_other_voting_systems#Voting_system_criteria 16:50:02 timbl__ has joined #tagmem 17:07:22 plinss, have you seen http://www.sitepoint.com/12-css3-vendor-prefix-crisis-myths/ 17:07:50 no 17:08:00 you have now 17:36:31 Scribe: JeniT 17:38:15 Ashok has joined #tagmem 17:38:27 ENGAGEMENT 17:38:49 - Disconnect from community (5) 17:39:10 - People don't care about architecture (1) 17:39:41 - Persuading community that arch. matters (1) 17:40:01 noah: some people have a short-term/long term 17:40:03 - Helping WGs/involvement in W3C 17:40:26 - Education of Community (4) 17:40:26 masinter: if you're a browser making, you care about browsers, not about semantic web 17:40:31 ... it's about breadth of scope 17:40:41 - Enforcement (1) 17:40:55 - Getting comments / spec process 17:40:59 ... we're trying to bring a broader perspective, for applications they don't think are important 17:41:02 CHANGING WEB 17:41:26 - Threats (3) and opportunities (2) 17:41:32 INTERNALS 17:41:44 - Time/money/efforts 17:41:59 i think the main pushback on "architecture" is that a broader architecture presents opportunities for others to innovate (which they don't care about) or about applications they don't care about 17:42:05 - Thrashing / Ratholing 17:42:50 Ashok: on reacting to the changing web 17:42:58 ... I was involved in 'Headlights' effort 17:43:12 so if you're doing document production, you might not care about 3D, and if yo'ure doing a browser, you don't care much about email, and architectural constraints for supporting applications they don't care about means introducing requirements for features that don't manage 17:43:12 ... they had five Headlight areas, one of which was 'Cloud' 17:43:19 ... which is a hot topic now 17:43:36 ... we argued about whether we should do cloud 17:43:47 you are tempted to characterize this as a "short term" vs "long term", but I think it's narrow vs. broad 17:43:49 ... we thought W3C didn't have anything to offer 17:44:08 ... they all use URIs, all use REST, but cloud is application management 17:44:28 ... we thought the W3C should be doing fundamental web technologies, to use in cloud, in big data or elsewhere 17:44:38 ... otherwise, it's out of the comfort zone of W3C 17:45:50 noah: we should focus our TAG improvements around these themes 17:46:10 ... is there anything else that we should have mentioned? 17:47:01 ... over the next little while we should remind ourselves and focus around these clusters 17:48:14 masinter: we've done this analysis, shouldn't we try to identify actions 17:48:58 jenit: what actions do you see (Larry), so we can have those as input for anything we do tomorrow? 17:49:08 masinter: a set around engaging leaders in the community 17:49:21 ... not people who subscribe to www-tag, but community of the web 17:49:36 ... we could go and talk at conferences, but that's not efficient 17:49:48 ... instead, target chairs of working groups, team members 17:50:04 ... talk to dozens of people in leadership positions rather than hundreds 17:50:09 Ashok: should we have a TPAC presentation? 17:50:38 masinter: I'd like to get better feedback, based on data, on our work 17:50:57 ... for example, web stats on how many people are reading these documents 17:51:14 noah: I'm not sure that all leaders are chairing WGs 17:51:30 ... I'm concerned of not getting balanced feedback 17:51:45 ... like an advisory group, to look at what we're doing 17:52:08 masinter: I was going to ask W3C for a programme manager to work to survey the community for a while 17:52:14 ... to help prioritise our work 17:52:51 ... we need to decide what we work on, so that what we work on matches the needs of the community 17:53:08 ... and we should be explicit about doing things that the community doesn't think they need, and why they really should 17:53:21 noah: it would be great to do an organised job to get that feedback 17:53:51 ... I don't want it to take a lot of my time 17:54:12 ... they are going to call me a lot, to coordinate 17:54:41 ... let's make sure it would actually work 17:54:46 jar: could we just talk about the ideas? 17:55:18 Ashok: if we agree that this is what we ought to do, we should do it regardless of noah's schedule 17:55:31 masinter: second thing is how we publish what we have worked on 17:55:45 ... there's the presentation of the website, to find out what we do 17:55:49 ... it's hard to find out 17:56:10 ... a lot of draft findings, only a few findings, it's hard to find out what the latest thing we've said is 17:56:19 ... then there's the finding vs. recommendation issue 17:56:52 jar has joined #tagmem 17:56:52 ... a recommendation reflects community agreement, said on behalf of community 17:57:17 ... sometimes what we do needs to get engagement from community even wider than W3C community 17:57:33 ... would be nice if chairs needed to look at architectural recommendations 17:57:45 ... I don't know how to solve those problems 17:58:07 ... but asking someone else to change the way that they work is difficult, they need to be involved in that change 17:58:45 plinss: it's good having putting documents through the Rec process, because you have to identify WGs from which you need feedback 17:59:08 masinter: then there's how we get selected, how many TAG members there are, whether they are funded and so on 17:59:14 ... I don't have hope for additional funding 17:59:28 ht: I thought it was worth putting down as a marker 17:59:49 ... to say that if W3C did get more money, the TAG might be a place to spend it 18:00:10 masinter: what we work on, how we publish it, how we work 18:00:21 ... spending time on administrative topics, how we organise 18:00:36 ... those things are more easily adaptable, we can try different internal organisations at will 18:00:48 ... it's harder changing the way we present and interact with others, and the way we prioritise 18:01:05 ... I think we should put more priority on how we work externally, because it will affect how we work internally anyway 18:01:16 ... more blog posts, for example, would change our internal working 18:01:39 noah: is there anything that you would say that isn't on the board? 18:01:50 masinter: the one thing is increasing the priority of our liaison work 18:02:11 ... especially with IAB 18:02:23 ... OASIS doesn't have an architecture committee, does it? 18:02:40 noah: do we only want to liaise with people who are organised like we are? 18:02:51 ... we should liaise for example with WHATWG 18:03:05 masinter: the principle is, do they talk about architectural issues in the same way that we do 18:03:32 ... they write vocabulary/architecture documents like we do, lots of opportunity for cross-review 18:03:40 ... and coordination 18:05:12 Topic: Positioning of Web and Native applications 18:05:13 Ashok has joined #tagmem 18:07:40 http://www.w3.org/2001/tag/2012/06/12-agenda#nativevsweb 18:11:21 masinter: the main point from this was the death of the application layer 18:11:38 ... native vs web app was one question among many 18:11:50 noah: so Hannes wasn't asking us to take on long-term work 18:11:55 ... I still think it's an interesting question 18:12:06 ... is this a promising area? it feels like it is to me 18:12:36 ... web vs. native, and within the web app, things that used to be managed at the protocol level are now being managed through Javascript 18:12:46 masinter: the trend started with layering on top of HTTP 18:12:54 ... and it's going rapidly in that direction 18:13:34 noah: my inclination is to go into this, to indicate tradeoffs 18:14:02 masinter: used to think of 7 layers 18:14:13 ... the layers are still here 18:14:25 ... you would draw this as an hour glass, because everything went through TCP/UDP 18:14:37 ... doesn't matter what's above, what's below, so long as everything went through that neck 18:14:46 ... rich applications in layers above that hour glass 18:15:04 ht: and that bottleneck being where it is meant there was work for the IETF in designing protocols 18:15:14 ... right about TCP/UDP you had protocols 18:15:19 s/about/above/ 18:15:41 masinter: in the new diagram, the bottleneck is at the protocol layer, we have HTTP, WebRTC 18:15:49 ht: IETF doesn't need to design protocols any more 18:16:03 ... that was the emotional subtext to the discussion at the IETF 18:16:12 ... "what is there for us in this new world" 18:16:18 masinter: and how to manage the parts they're doing 18:16:47 timbl: the TCP bottleneck meant that underneath the bottleneck, stuff underneath could change without us having to change our code 18:16:57 ... does this top bottleneck have this property as well? 18:17:10 ... could we make huge changes to the way HTTP works? 18:17:20 ht: SPDY is evidence that you can 18:17:43 timbl: otoh we've learned that apps have to look a little bit down through the bottleneck 18:17:52 ht: SPDY is about avoiding a bit of that 18:18:01 ... to avoid having to play games to get parallelism 18:18:17 timbl: in the LDP model, the bottleneck is HTTP+RDF+SPARQL Update 18:18:28 ... the application level, the design is in ontologies and rules for their use 18:18:49 ht has joined #tagmem 18:18:49 noah: that only says so much about how we optimise delivery of a video stream 18:19:07 timbl: video is an independent part of the web 18:19:15 noah: video benefited from the old hourglass 18:19:53 masinter: I disagree, they discovered because of firewalls they couldn't deliver video how they needed to 18:19:56 ... to get real-time stuff 18:20:19 noah: a whole lot of TV goes through the hourglass 18:20:23 RTP, RTMP, now MPEG-DASH using hTTP 18:20:24 ht has joined #tagmem 18:20:34 Ashok: we're speaking between native apps and web apps 18:20:42 ... what's the difference? 18:20:44 timbl has left #tagmem 18:20:45 MPEG-DASH is delivering streaming video using HTTP using the top neck 18:20:57 two hourglasses 18:21:04 noah: devices have APIs 18:21:14 s/glasses/glass necks/ 18:21:30 ... native apps are written to exploit the platform APIs 18:21:39 http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP 18:21:44 ... not tuned to write application that run on a different device or platform 18:22:04 ... released in lock step with device releases 18:22:17 ... people wrongly associate it with marketplaces, and charging 18:22:24 Ashok: it does not run in the browser 18:22:33 noah: but some use Webkit components for example 18:22:38 Ashok: does it work with a server? 18:22:43 noah: many do 18:22:51 Ashok: can you access another external website? 18:22:58 noah: some do some don't 18:23:07 http://phonegap.com/ 18:23:24 ... I bet weather apps use RESTful APIs to access their data 18:23:57 ... ESPN apps appear purely native, and you then get a web page, no back button 18:24:05 plinss: not a full interactive browser 18:24:13 noah: some intercept links, some don't 18:24:24 Ashok: the only difference I'm seeing is that they don't run in the browser 18:24:28 noah: that has huge implications 18:24:32 masinter: no it doesn't 18:25:05 Ashok: so it doesn't run in browser, and it has priviledged access to hardware? 18:25:24 noah: plugging iPad into mixing device 18:25:41 ... we have nothing in the web space to do that 18:25:54 ... people are building businesses on that 18:26:14 Ashok: I'm trying to figure out what the differences are 18:26:26 noah: native priviledged control of hardware 18:26:54 jar: but this could also apply to communication with a server 18:27:15 ... proprietary protocols between two parts of the system 18:27:22 Apache Cordova (aka PhoneGap) uses web infrastructure to build apps 18:27:45 "proprietary protocols" => "private device APIs" 18:27:54 ... if you have an application in mind and it involves a client/server, your choice is affected by multiple considerations 18:28:05 WebIDL should be in scope for architecture 18:28:11 Ashok: the part that uses the hardware, the special hardware, that *has* to run on the device 18:28:18 jar: the special hardware could be on the server 18:28:30 masinter: I have 40 native apps on my phone, none of which access specialised hardware 18:28:56 noah: analogy between relationships between Macs and Laserwriters 18:29:20 ... the web community needs to support multiple devices 18:29:32 ... and interfaces with them 18:29:46 jar: seems like there are multiple considerations that would lead to deploying as native vs web 18:29:54 ... maybe hardware is one of them, but there will be a bunch of others 18:30:05 ... these issues are orthogonal to interoperability 18:30:28 masinter: I hear Robin saying we shouldn't talk about this because there are WGs trying to make native apps irrelevant 18:30:44 ... then there are articles saying that companies build native apps is because of monetisation 18:30:59 jar: I think we could list four considerations for making the decision 18:31:53 jenit: these issues are well known 18:32:07 masinter: I've read that the main issue is monetisation 18:32:15 ... and we have nothing to say about that anywhere within W3C 18:32:41 noah: maybe we need to help W3C to see this 18:32:46 the motivation for innovation in the web is monetization 18:32:54 timbl: the whole webapps drive at W3C has been going for a while 18:33:11 rights management video is also driven by monetization 18:33:13 ... the push that people should use webapp technology is several years old 18:33:29 ... we must have talked about trusted apps 18:33:32 q+ to correct what i said. The W3C *is* talking about monetization for video 18:33:56 ... that's one example where web apps aren't trusted apps 18:34:02 I want to correct what i said. The W3C *is* talking about monetization in the context of DRM for video 18:34:05 ... making the list of reasons is a good idea 18:34:14 ... putting it in order is a silly idea, because everyone is different 18:34:24 ... many different markets, many different kinds of apps 18:34:29 ... based on different criteria 18:34:45 ... whole tranche that cares about monetisation, another that really doesn't care 18:35:04 ... I think we should map pros and cons, or point to it 18:35:17 ... and flag any things that give us particular concern 18:35:24 ... we've said that payment protocols is a gap 18:35:56 lm: it isn't true that the w3c doesn't talk about monetization. videos. DRM, subscription 18:36:20 lm: we haven't said much about book or text content [or software] 18:36:58 q? 18:37:21 pl: A lot of this interesting things here, but why to the TAG? Any architectural issues? 18:37:39 pl: What could lead to us having any effect? 18:38:24 nm: Having a task group go off and look at this might help 18:38:51 timbl: I thought this was a discussion about the TAG making sure that the webapp in the future, w3c to fix any architectural gaps in the future 18:39:01 pl: There are other people finding the gaps and filling them in 18:39:12 timbl: There's an activity 18:40:00 lm: The IAB had a presentation on the death of protocols. Concerned about extensibility in the architecture. New hourglass in the stack, now at the web, therefore apps are being defined in terms of the web rather than in terms of TCP, 18:40:53 … making concerns of infrastructure folks harder to penetrate. E.g. traffic shaping, you can't tell the nature of the content because of http multiplexing. Wait, W3C, why are you doing all of this, that makes our life hard? 18:41:53 nm: Helping the w3c to focus and validate to make web-based platform successful. But LM is saying (something else) 18:42:51 lm: I don't think we can affect marketplace success, but we can document impact of what is being standardized. E.g. the APIs. We're analyzing privacy considerations. Useful regardless of whether native or web 18:44:04 timbl: IAB question is a very interesting. They should get over it, by which I mean: They used to have the luxury of looking at port numbers. When the IT people started looking at port numbers, they were cheating. I understand why it's been useful in categorizing traffic. Now the distinctions are hidden... 18:44:40 … now we have pages and proxies… the whole point is the heavy use of layering 18:45:10 lm: Now we take what we used to do with ports and streams, and figure out how to do it in the new regime 18:45:58 nm: Suppose we want to add traffic class to HTTP. I would think IETF would show that to us in draft form… why wouldn't they take the lead? 18:46:18 lm: They sent the message to the entire IETF community. We're just not monitoring that list 18:46:50 am: How would we write trusted apps that don't run in the browser in a portable way? 18:47:10 nm: There are things vendors intentionally make hard, so that access is difficult 18:48:04 am: We write standards that work within the browser. Should we start thinking about standards for native apps. 18:48:22 timbl: there are lots of apps where the browser is the desktop, like Boot-to-chrome 18:48:35 ... I can't think of any architectural questions, except for the trusted app issue 18:48:48 masinter: very frequently there's a service available on the web and in the native app 18:48:57 ... it has more trust, it has an icon, you don't have to log in 18:49:16 ... if your goal is: does it use standard protocols, is it interoperable? yes, it does 18:49:31 ... you can send URLs, and it will bring up the app or the browser 18:49:44 ... it's ok to develop standards that aren't for browsers 18:49:51 ... it's reasonable 18:50:08 timbl: at first blush I don't see what requirements there would be if I were writing a native app that I don't have writing a web app 18:50:14 ... I need to look at local storage 18:50:23 Ashok: Javascript would have to execute natively on the platform 18:50:35 timbl: there would have to be a stripped down browser, one without the chrome 18:50:39 ... what's hard with that? 18:50:45 masinter: that's what Windows did 18:50:52 Ashok: a skinny browser 18:51:06 timbl: a browser that's fat in features, the only thing that's missing is the window 18:51:18 noah: IE5 did that 18:51:31 ... the native app might not be browser based 18:51:38 ... maps might be an example 18:52:00 so why should we care whether W3C specs are being used for things that aren't run in the browser? After all, "web services" didn't run in the browser 18:52:03 ... if you have a Google Maps URI, the phone looks at the URI, cheats, decides to open a specific maps app 18:52:14 ... no way to to tell whether it's using REST/HTTP 18:52:21 Ashok: but it uses the URI 18:52:38 plinss: if you click a Google Maps link in a browser, it launches the native app 18:52:47 noah: it feels more native than wrapped web 18:53:26 noah: where should we go with this? 18:53:32 Ashok: I'm not hearing any direction 18:53:45 noah: we did have a contact from Hannes, should we have a response? 18:53:57 ... if we have more TAG work, we should have focused analysis with a goal 18:54:11 masinter: I have what I think is a new thought 18:54:19 ... W3C often works on things that have nothing to do with browsers 18:54:26 ... XML protocol for example 18:55:05 ... why should we care that these standards are being used by native apps? 18:55:26 ... people are spending more money building native apps 18:55:34 noah: you imply those native apps are rendering HTML 18:55:49 ... and if they're not, our stuff is totally irrelevant 18:56:04 ... I can't tell if they are standalone, if they use HTTP 18:56:42 jar: I think we should be looking at the interoperability problems 18:56:58 ... some are to do with the internet and some aren't 18:57:10 ... there are all kinds of standards organisations 18:57:16 ... that's different from getting work done as a developer 18:57:25 masinter: the question is what should be in scope for W3C 18:57:36 ... what's the scope of the architecture? 18:57:44 ... what W3C does vs what we expect others to do 18:57:49 ... that's not entirely up to the TAG 18:57:55 ... but we might have some input on it 18:58:17 noah: what should our next step be? 18:58:41 masinter: I suggest we put this on our status report to Jeff 18:58:55 ... I think we have new information, that the IAB would like to know 18:59:04 noah: he'll immediately ask what we're doing about it 18:59:16 ... what should we do? 18:59:19 should we try to define what we think W3C's scope is? 18:59:55 ... is someone going to step up to analyse the area and provide goals? 18:59:57 i'm convinced by this discussion that native apps using web technology should be in scope for W3C and the TAG and AWWW 19:00:12 ht: get something on the broken record 19:00:25 ... there's the potential for a big revolution 19:01:02 and that DRM for native apps might be a candidate enabling technology 19:01:15 ... providing apps over the web is repurposing 19:01:22 ... without any rearchitecturing 19:01:35 ... it might be that now we know what we want, we should design one and ship one 19:01:39 and there might be some 'best practices' that would have to be review URIs, security, login 19:01:43 q+ 19:02:02 ... Flash was designed much more to be that mechanism for delivering apps 19:02:24 ... if the idea of a distributed deployment platform gets traction 19:02:26 Evolution of Javascript is repeating evolution of Java (somewhat out of order) 19:02:33 ... then we need to pay attention 19:02:36 http://phonegap.com/about 19:02:50 ... different from web browsers, which have a different goal, and weren't designed to be a distributed deployment platform 19:03:05 http://phonegap.com/2012/04/12/rolling-releases-how-apache-cordova-becomes-phonegap-and-why/ 19:03:26 timbl: the idea of redesigning from scratch sounds like a bad idea 19:03:39 ... but we could look at what it would look like if we did 19:03:55 jar: history is repeating itself, so we could look at that, eg Java, Adobe 19:04:26 timbl: I'm not interested in the TAG doing a redesign, except as a thought experiment to identify we might be missing 19:04:32 ... to do a course correction 19:05:08 . RESOLUTION: The TAG says that Native apps using web technology are in scope for W3C and the TAG 19:05:49 noah: does someone want to propose direction? 19:06:15 ... the more work we can do offline, the better 19:06:24 ... we need someone to do legwork to bring in some facts 19:06:36 . RESOLUTION: The TAG says that Native apps using web technology are in scope for W3C and the TAG, and that the TAG will consider architectural questions, and that the community is encouraged to bring architectural questions, in this space. 19:06:46 ... I propose we have no actions, except that we owe Hannes an answer 19:07:14 noah has joined #tagmem 19:07:15 ... Larry, did you want to propose a reply to Hannes? 19:07:37 . ACTION: Larry to reply to Hannes summarizing the discusison, pointing to th eminutes, and asking him if he has any more specific questions. 19:09:02 ACTION: Larry to reply to Hannes pointing to the minutes, summarizing the discussion, and asking him if he has any more specific questions. 19:09:02 Created ACTION-719 - Reply to Hannes pointing to the minutes, summarizing the discussion, and asking him if he has any more specific questions. [on Larry Masinter - due 2012-06-20]. 19:23:43 Norm has joined #tagmem 19:27:09 http://incubator.apache.org/cordova/ 19:30:29 Topic: Administration 19:31:37 noah: tentatively between 7-10th Oct in UK 19:33:27 ... agreement on 7-9th Oct in London? 19:34:20 ACTION: Noah to make sure we have somewhere to meet in London 7-9th October 19:34:20 Created ACTION-720 - Make sure we have somewhere to meet in London 7-9th October [on Noah Mendelsohn - due 2012-06-20]. 19:36:49 RESOLUTION: TAG will meet in London 7-9th October 19:37:52 noah: we may meet on 21st June 19:38:02 ... but cancel meetings of 28th June & 5th July 19:38:11 ... but have a meeting on 12th July 19:38:48 ... TPAC is 29th Oct - 2nd Nov 19:38:52 ... in Lyon 19:39:32 ... I probably won't be able to get there 19:39:52 ... December meeting, latest is 20th December 19:40:07 Ashok: maybe January instead? 19:40:59 noah: possibly 8-10th January in California 19:42:41 ... Timbl not free 19:50:08 (lots of date discussion) 19:51:03 (18-20th December out as TimBL unlikely) 19:51:19 (early Jan difficult for Henry & Noah before lectures scheduled) 19:51:46 noah: we have a room at TPAC even though I'm unlikely to make it 19:52:53 (Tim, Ashok, Peter, JeniT likely at TPAC) 19:53:05 (Larry possible, Henry unlikely) 19:53:21 Topic: TAG Priorities 2012 19:53:39 noah: we're doing good work on fragids 19:53:45 ... taking serious run at ISSUE-57 19:54:20 ... publishing & linking is kind of ok, except main assignee (JeniT) also doing the other main priorities 19:54:57 ACTION: Noah to update product index to target date on publishing & linking 19:54:57 Created ACTION-721 - Update product index to target date on publishing & linking [on Noah Mendelsohn - due 2012-06-20]. 19:55:36 ACTION jar Review 'publishing and linking' due 2012-08-01 19:55:36 Created ACTION-722 - Review 'publishing and linking' due 2012-08-01 [on Jonathan Rees - due 2012-06-20]. 19:56:14 noah: my concern is that 9 people working 20% time should be doing more work 19:56:30 ... are any of the medium priority work items things we should move up to high priority? 19:56:58 masinter: I'd prioritise based on what we talked about this morning, focus on things that get us engaged with the community we're trying to serve 19:57:35 noah: what technical topics would you prioritise based on that? 19:57:47 masinter: engagement is important, so we should raise priority of web architecture pages 19:58:10 ... it's simple, and gains engagement 19:58:51 noah: the only thing that's held that back is that we assigned actions and only Jeni's done it 19:59:02 ... we need to get members who take on the actions to buy in to doing them 19:59:31 masinter: I think people work on things that you feel other people care about 19:59:47 - +1.617.715.aaaa 19:59:48 TAG_f2f()8:00AM has ended 19:59:48 Attendees were Yves, +1.617.715.aaaa 19:59:50 jar: people should work on things they are motivated to work on 20:00:21 TAG_f2f()8:00AM has now started 20:00:28 + +1.617.715.aaaa 20:00:36 dialing 20:00:39 zakim, passcode? 20:00:39 the conference code is 0824 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Norm 20:01:31 +Norm 20:01:47 Topic: HTML/XML Unification 20:03:01 http://lists.w3.org/Archives/Public/www-tag/2012Jun/0051.html 20:03:44 noah: what's happened since we last met, and what should happen next? 20:04:05 Norm: we met and chatted in December 20:04:14 ... a bunch of us were in Prague for XML Prague 20:04:35 ... Jeni, Robin & Anne (and me) thought setting up a community group in this space would be a good idea 20:04:44 ... Anne agreed to edit 20:04:50 ... I agreed to chair 20:05:08 ... there was a flurry of email, and there's Anne's draft based on XML5 20:05:23 ... I have been behind, but I caught up yesterday 20:05:40 ... I've tried to pull out the larger issues that I don't think are in the draft or where we have consensus 20:05:58 ... next step would be to try to get more review of Anne's draft within the group 20:06:06 ... to see whether that draft satisfies some of the requirements we have 20:06:24 ... we could spend time on use cases if we were more diligent 20:06:40 ... I'm not sure we could get that much discipline, but I'll make a stab at it 20:06:50 noah: when we met at Tim's, we reviewed the TF report 20:07:00 ... at the time, you said you wanted the TAG's help to get it published as a Note 20:07:11 ... it was published on Feb 9th 20:07:16 ... just before XML Prague 20:07:39 ... most of what you've focused on is Anne's presentation at XML Prague & XML-ER 20:08:11 Norm: the group of people who are willing to work on this problem, have voted with their feet to work on something more concrete, along the lines of Anne's work 20:08:18 ... the TF was useful in framing the discussion 20:08:28 ... but the TF has done all it will successfully do 20:08:45 ... we should be looking at engaging the XML-ER folks 20:09:12 noah: the TF was a big deal for the TAG 20:09:28 ... are we happy to move in the direction that Norm is signalling? 20:10:04 Norm: we do need to get use cases out there to help make choices 20:10:14 ht_home has joined #tagmem 20:10:18 ... for example, the case of an interactive editor 20:10:30 ... there are some people who think that's critical and others that think it isn't 20:10:47 ... that will help drive refining something like Anne's draft 20:10:50 http://www.w3.org/2001/tag/products/htmlxmlunification.html 20:11:24 noah: I propose we close out the HTML/XML work 20:11:47 ... declare success on this bit of the work 20:11:59 Norm: I'm agnostic 20:12:27 ... in the perfect world, we might want to do more work along the lines that was originally envisaged 20:12:38 ... but we should move in the direction of the community 20:13:11 noah: we need to make a decision not to pursue other aspects from the report 20:13:33 timbl: unless there's some huge thing that people haven't noticed, we should follow what the community is doing 20:13:43 ht: my energy is going to go on monitoring polyglot 20:13:55 ... because it's the XHTML constituency that we have responsibility towards 20:14:08 Norm: that's a good and wise thing to do 20:14:19 . RESOLUTION: The TAG notes the publication of the HTML/XML Task Force Report on 9 Feb 2012, the focus of the community on XML-ER. We thank Norm Walsh for his wonderful assitance to the TAG, and close our formal project on HTML/XML. 20:15:13 ht: as long as I can continue to monitor polyglot, closing is fine 20:15:51 noah: any objections? 20:16:23 RESOLUTION: The TAG notes the publication of the HTML/XML Task Force Report on 9 Feb 2012, and the current focus of the community on XML-ER. We thank Norm Walsh for his wonderful assitance to the TAG, and close our formal project on HTML/XML. 20:16:53 noah: would it be helpful to talk with the TAG on XML-ER? 20:17:39 Norm: the biggest question is the first one in my email: how can we describe what this process of reading characters and making a tree is? 20:17:47 ... is it a processing model or a declarative model? 20:17:59 ... the other issues are smaller 20:18:21 Discussing lists.w3.org/Archives/Public/www-tag/2012Jun/0051.html 20:18:35 ... is there a pre-processor that does clean-up and then uses an XML parser 20:18:42 Point 1: declarative vs imperative rules for the mapping from character sequence to (fixed up) tree 20:18:54 ... or is it a procedural/streaming process? 20:19:10 ht: it's stupid to define it procedurally 20:19:41 noah: there was a similar decision in the HTML spec 20:20:02 ht: it wasn't an explicit decision for HTML 20:20:37 noah: for HTML, the asynchronous scripting environment might be legitimate grounds for saying it's hard to define this declaratively 20:20:43 ... but that doesn't apply in XML-ER 20:20:50 ... there's no asynchrony 20:21:09 ... Norm, do you think there are good technical reasons for speccing it procedurally rather than declaratively? 20:21:36 Norm: I don't think there are technical reasons, but Anne's influenced by the HTML parsing method 20:21:44 http://dev.w3.org/html5/markup/ is declarative 20:21:49 ... and he's not interested in editing anything other than in that style 20:22:16 noah: I'd love to see it done declaratively, but I don't think we should fight it now 20:22:34 ... I wish I had the time to do it 20:22:50 Norm: if someone looked at Anne's draft and picked some subset and rewrote it using declarative rules 20:23:21 ... doing a large enough section so that other people in the CG who aren't familiar enough with declarative approach might be shown how it works 20:23:30 masinter: HTML5 is defined declaratively, there's a document that does it 20:23:50 Norm: there's an exposition of how it's done, but it's not declarative 20:23:57 http://dev.w3.org/html5/markup/ 20:24:08 noah: it's not a declarative mapping to a DOM tree 20:24:11 ht: it's also incomplete 20:24:22 noah: the goal with XML-ER is to map a character string to a DOM tree 20:24:40 ... the document you're pointing at focuses on legal HTML for good reasons 20:24:49 ... the target for XML-ER is illegal XML 20:25:07 masinter: in the email discussion I was not understanding the use case that XML-ER is intending to address 20:25:21 Norm: someone sends you a document that they've served as XML, but isn't well-formed 20:25:26 ... you want to process it with XSLT 20:25:35 masinter: what's the use case for that? 20:25:54 noah: I thought a use case was that someone had written XHTML and they've made mistakes, and they hate the brittle stop-on-error model 20:26:08 ... so you would have an alternative browser mode, that would process XHTML and keep going 20:26:22 masinter: that's not enough of a use case, because it's a personal preference 20:26:35 noah: people are using HTML because XHTML kept breaking for them 20:27:02 masinter: give me a scenario where something doesn't work, where the requirements of the use case are that you need XML-ER 20:27:11 timbl: an RSS aggregator 20:27:25 masinter: one that's getting XHTML? 20:27:31 timbl: it contains embedded HTML5 20:28:17 Norm: another one is an XML database company, which wants to ingest documents 20:28:22 ... that purport to be XML 20:28:30 ... 30% of them are broken 20:28:40 ... you can do proprietary attempts to fix the markup 20:29:05 ... having a standard would enable two independent companies to ingest the documents and build the same trees 20:29:18 ... which would enable XML databases, XSLT processors etc to work on them 20:29:34 ... we would get better interoperability across these applications 20:30:05 masinter: is it a requirement that it's consistent with the HTML parser? 20:30:19 norm: There is LOTS of broken XML out there 20:30:24 Norm: as compatible as it can be without torturing the spec 20:30:31 masinter: for these use cases 20:31:02 Norm: the requirement is that the processor processes it without falling over 20:31:23 ht: this is a perfect demonstration for why a declarative definition would be better 20:31:33 ... we could process with both an XML-ER and HTML parser to see 20:31:49 masinter: is there a requirement that they be equivalent? I think I've heard not 20:31:59 Norm: the vast majority cases are really easy to fix 20:32:07 ... missing angle brackets, quotes and so on 20:32:15 ... the focus is on recovering bad data 20:32:26 ... we don't want to get into "correct" interpretations 20:32:36 ... we need to fix up the obvious mistakes 20:32:58 noah: the RSS case is different: it's divided between what humans see and those they can't 20:33:24 ... automatic processes on sensitive documents is risky 20:33:49 Norm: if you have mission critical data going through this, you deserve what you get 20:34:07 noah: if we can refine the use case to exclude these scenarios 20:34:22 Norm: you can't tell people how to use your spec 20:34:26 noah: but you can warn them 20:34:28 Can this be defined as a sequence of fixup transformations? 20:35:02 timbl: I don't think we have to warn people about obvious things 20:35:09 which isn't either declarative or procedural 20:35:34 Norm: the spec should say that correcting markup errors necessarily introduces the possibility of saying something the author didn't intend, but no more than that 20:35:52 masinter: there's another way of defining the spec as fix-up transformations 20:36:08 noah: if I were doing it declaratively, I think I'd do it as fix-up transformations 20:36:17 masinter: then you don't have to worry about the DOM tree at all 20:36:34 ... you can have a pre-processor that does the first fixups 20:36:38 ht: that's how tagsoup works 20:36:46 ... which the CG is ignoring 20:36:52 what's wrong with tagsoup? 20:37:46 masinter: we should ask the XML-ER CG why they are ignoring it 20:38:18 noah: the HTML5 spec took into account what browsers were using and other inputs 20:38:27 ht: I think Hixie only looked at what the browsers were doing 20:38:36 noah: this fits into that path 20:39:01 if there's a widely deployed implementation that meets the requirements, why isn't compatibility with that system a possibility? Does tagsoup work for the use cases? 20:39:01 Ashok: does tagsoup handle these use cases? 20:39:13 ht: tagsoup is best-of-breed, nearly the only one 20:39:34 ... it has two phases: a micro phase and a macro phase 20:39:48 ... the micro phase is done at the level of angle brackets and equal signs 20:39:56 ... macro phase at open & close tag level 20:40:01 ACTION: Noah to record final closing of work on HTML/XML Unification in product page Due 2012-08-01 20:40:01 Created ACTION-723 - Record final closing of work on HTML/XML Unification in product page Due 2012-08-01 [on Noah Mendelsohn - due 2012-06-20]. 20:40:01 http://mvnrepository.com/artifact/org.ccil.cowan.tagsoup/tagsoup/1.2 ? 20:40:04 ... not quite well-formedness vs. validity 20:40:11 Norm: tagsoup is also table driven 20:40:14 Ashok has joined #tagmem 20:40:22 ht: yes, but it does useful work with an empty table 20:40:32 JeniT: is it specced anywhere? 20:40:39 ht: there's something approximating a spec 20:40:56 ... and I've done work with a grad student to make the table declarative 20:41:11 ... so it's an open question how well tagsoup would do at satisfying the RSS use case 20:41:11 https://groups.google.com/forum/?fromgroups#!topic/tagsoup-friends/Y2qA29CM4n4 20:41:22 ... I don't know which use cases the XML-ER CG has written down 20:41:40 Ashok: but take MarkLogic, where they really need this 20:41:45 "http://groovy.codehaus.org/api/groovy/util/XmlSlurper.html" ? 20:41:49 ht: Norm, why doesn't MarkLogic use tagsoup? 20:41:58 Norm: probably because it's written in Java 20:42:04 "The semantics of TagSoup are as far as practical those of actual HTML browsers." http://ccil.org/~cowan/XML/tagsoup/#what 20:42:08 ... I think we have tidy incorporated 20:42:46 "BeautifulSoup is closer to my TagSoup, but is written in Python and returns a parse tree. I believe its heuristics are hard-coded for HTML. There is a port to Ruby called RubyfulSoup." -- http://ccil.org/~cowan/XML/tagsoup/ 20:42:55 noah: anything else we should be talking about? 20:43:02 JeniT: media type maybe? 20:43:45 Norm: yes, we're talking about processing documents where the media type is a lie: it says its application/xml when it isn't 20:44:10 noah: the authoritative metadata finding suggests that if the user has input, that's OK 20:44:33 Norm: yes, one thing is to try with an XML parser, and then try again with the XML-ER parser if it fails 20:44:39 masinter: it depends on context 20:45:14 Norm: one of the goals of a parser is that it should produce the same thing as an XML parser on a well-formed XML document 20:45:17 Tag finding on authoritative metadata, pertinent section: http://www.w3.org/2001/tag/doc/mime-respect-20060412#silent-recovery 20:45:21 masinter: is this intended for XHTML or all XML? 20:45:23 is this really intended for ALL XML? 20:45:31 Good practice: Web agents SHOULD have a configuration option that enables the display or logging of detected errors. 20:45:33 both of the use cases were HTML 20:45:35 Norm: intended for all XML, on XHTML I think I'd just use an HTML parser 20:45:52 http://www.w3.org/2001/tag/doc/mime-respect-20060412#consent 20:46:02 Constraint: An agent MUST NOT ignore or override authoritative metadata without the consent of the party employing the agent. 20:46:03 masinter: what kinds of documents would you be reading into a database? 20:46:16 Norm: some horrendous stuff from database dumps and logs and so on and on 20:46:22 question is what the nature of the errors are and where they came from 20:46:26 TagSoup references: http://home.ccil.org/~cowan/XML/tagsoup/tagsoup.pdf, http://home.ccil.org/~cowan/XML/tagsoup/ 20:46:29 RSS feeds are different 20:46:30 ... that's where I've encountered this problem 20:46:50 Pyxup (declarative version from me): http://conferences.idealliance.org/extreme/html/2007/Thompson01/EML2007Thompson01.html 20:46:55 noah: I've added links to the authoritative metadata finding where we talk about this 20:47:33 ... other than that, I don't think we're discouraging it 20:47:39 masinter: what about HTML Tidy? 20:47:44 ht: it's even less documented 20:47:53 ... you could ask Dave Raggett to help you decompile it 20:48:07 timbl: I don't think Dave is a committer now 20:48:25 ... you could fit it into the test suite 20:48:36 noah: the fixups you might want to do would depend on the use case 20:48:52 ... Tidy was mostly used by authors to clean up what they'd written 20:49:01 I believe the open source Tidy project is dormant 20:49:09 ... but stuff in the HTML spec is done by the user agent 20:49:24 ht: I use Tidy to convert HTML to XHTML so I can work with it 20:49:35 timbl: I use Tidy to help me publish as polyglot 20:50:00 http://tidy.sourceforge.net/ 20:50:16 noah: is there any followup from us? 20:50:25 Norm: I'm going to try to get the group re-energised 20:50:49 HTMLtidy - Revision 1.46 - Wed Mar 25 21:37:11 2009 UTC (3 years, 2 months ago) by arnaud02 20:50:58 ... I'm inclined to say that anyone in the TAG who wants to influence direction should join the CG 20:51:12 ... I can keep coming and giving status updates 20:51:16 http://www.w3.org/community/xml-er/ 20:51:58 (Norm is directed to upload a picture) 20:51:59 given deployment of tagsoup and xmltidy, it is likely that they won't go away, and thus the goal of the group is there a standard for fixup won't be accomplished 20:52:07 Ashok: how active is the group? 20:52:27 Norm: there was a flurry of mail earlier in the year, and it's been dormant over the last few months 20:52:37 ... I'm going to try to get it going again 20:53:01 noah: on the TAG side, we just closed down HTML/XML work: we're not doing anything formally now 20:53:18 ... do we need to follow up more formally? 20:53:37 masinter: I think we should give them feedback to look at tagsoup and to ask about use cases 20:53:47 Norm: if someone wants to chime in about tagsoup, that would be good 20:54:25 (Norm reports that there's a picture in his W3C account and it doesn't show up on that page and that isn't his fault, he so asserts) 20:54:27 ht: it's easier to give input if there are use cases and test suites 20:54:39 noah: should we have an action? 20:55:09 ht: we don't need to: Norm's heard, Jeni's heard, Robin will read the minutes 20:55:29 noah: we've decided we don't need to do any more 20:56:02 ... thank you again to Norm for all his work 20:56:35 -Norm 20:56:37 - +1.617.715.aaaa 20:56:37 TAG_f2f()8:00AM has ended 20:56:37 Attendees were +1.617.715.aaaa, Norm 20:57:03 Ashok: I think this work will just dribble away 20:57:23 s/think/have a fear that/ 20:58:13 ADJOURNED 20:59:13 masinter: if you talk about proliferation of schemes, please look at RFC 4395bis on scheme registration guidelines 20:59:24 ... we want to make it easier to register schemes 20:59:42 ... because the consensus of IETF is that making it hard to register schemes is lots of unregistered schemes 21:00:08 Larry wants us to look at RFC 4395bis when we talk about scheme proliferation -- it attempts to facilitate scheme registration. 21:00:18 ... there's a lot of reasons why you wouldn't want to deploy schemes or use schemes 21:00:22 LM: You might not want to deploy or use them all, but registering them is often good 21:00:26 ... but that's different from not registering them 21:00:59 ... it's not much of a risk when you have a scheme that isn't recognised 21:01:10 timbl: the only risk is if two people take the same unregistered scheme 21:01:55 masinter has joined #tagmem 21:02:45 http://tools.ietf.org/id/draft-ietf-iri-4395bis-irireg-04.txt 21:03:30 masinter: I like narrowing CSS prefixes to extracting documentation of deployment plan in CSS documents and make it a separate document 21:03:45 ... then see if we can extract important aspects of deployment plan 21:03:52 ... as hints for how to plan for extensibility 21:04:17 ... some people think CSS prefixes is successful, and we should capture what works about it 21:06:01 REALLY ADJOURNED! 21:10:33 JeniT has joined #tagmem 21:34:33 ht has joined #tagmem 23:07:44 ht has joined #tagmem 23:54:22 JeniT has joined #tagmem